Development - Revision history

Admin: Update protocol docs to point to github

2025-04-17T23:45:24Z

Update protocol docs to point to github

← Older revision		Revision as of 01:45, 18 April 2025
Line 4:		Line 4:
	The site was initially coded within a day, and main development, jump started by BlobKat over three. This has had many long lasting impacts on the site, resulting in some development decisions that made sense for that short term period, but have proved very complicated and confusing in the long term. One of the biggest impacts was the choice to use "git and changes system", for syncing the canvas between the client and server, while also ensuring minimal bandwidth on the hoster's behalf. Further complicated by the introduction of the new server software, RplaceServer, which chose to use a completely new system, wherein the site is solely dependent on the monolithic server software, which handles both the socket live pixels, and hosting the canvas files directly for client consumption in a compressed form.		The site was initially coded within a day, and main development, jump started by BlobKat over three. This has had many long lasting impacts on the site, resulting in some development decisions that made sense for that short term period, but have proved very complicated and confusing in the long term. One of the biggest impacts was the choice to use "git and changes system", for syncing the canvas between the client and server, while also ensuring minimal bandwidth on the hoster's behalf. Further complicated by the introduction of the new server software, RplaceServer, which chose to use a completely new system, wherein the site is solely dependent on the monolithic server software, which handles both the socket live pixels, and hosting the canvas files directly for client consumption in a compressed form.

	~~== Packets ==~~
	The site uses websocket for live client server communication. All packets are composed of an initial '''code''' byte, representing the type of the packet to be identified on the server, with all numberic packet data being formatted as big endian.

	~~=== Pixel packet: ===~~		Basic protocol and API documentation is made available on the rplace github at https://github.com/rplacelive/game/blob/main/PROTOCOL.md
	~~The pixel packet is one of the simplest. It~~ is ~~a six byte packet, the first byte being the packet '''code,''' the second to 5th~~
	bytes being '''position (board index)''' of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the '''colour''' in the palette that the pixel represents.

	~~One can retrieve~~ the ~~X and Y position from an given pixel index with some basic math. To get the X position, we do '''index % canvas_width''', and to get the Y position '''floor(index / canvas_width)'''.~~

	~~=== Chat history packet ===~~
	~~[[File:Text.png\|thumb\|[yeah] Ok, where? - in~~ rplace~~.live Eng chat ~12.10.2023 19:00 Greenwich Mean Time~~ https://~~discord~~.com/~~channels~~/~~960966748289507338~~/~~963181334942081084~~/~~1162104300554694757 Link to message]]~~
	The chat history packet is used to ask the server to load a certain set of messages from the database, for example, in the context of attempting to load previous chat messages from before a client connected to the game session when scrolling up in the chat history.

	* (u8) packetCode = 13
	* (u32) fromMessageId (If set to 0, AND you are asking for messages sent BEFORE this specified message Id (see next byte), it will give you messages relative the most recent messageId in the channel (see last n bytes))
	* (u8) message count AND before\|after (last 7 bits will tell the server how many messages you want before or since the specified message Id, first (most significant) bit will tell the server if you want messages from BEFORE or AFTER the specified message Id)
	* (n bytes) name of chat channel as a UTF8 encoded string

	~~MessageId ascends as new chat messages are sent, so greater message ID = more recent~~.

imported>Fowl at 21:50, 14 November 2023

2023-11-14T21:50:31Z

← Older revision		Revision as of 23:50, 14 November 2023
Line 14:		Line 14:

	=== Chat history packet ===		=== Chat history packet ===
			[[File:Text.png\|thumb\|[yeah] Ok, where? - in rplace.live Eng chat ~12.10.2023 19:00 Greenwich Mean Time https://discord.com/channels/960966748289507338/963181334942081084/1162104300554694757 Link to message]]
	The chat history packet is used to ask the server to load a certain set of messages from the database, for example, in the context of attempting to load previous chat messages from before a client connected to the game session when scrolling up in the chat history.		The chat history packet is used to ask the server to load a certain set of messages from the database, for example, in the context of attempting to load previous chat messages from before a client connected to the game session when scrolling up in the chat history.

2A02:C7C:643A:EE00:4A3B:777B:1884:56D1: /* Chat history packet */

2023-10-24T12:33:07Z

Chat history packet

← Older revision		Revision as of 14:33, 24 October 2023
Line 17:		Line 17:

	* (u8) packetCode = 13		* (u8) packetCode = 13
	* (u32 fromMessageId (If set to 0, AND you are asking for messages sent BEFORE this specified message Id (see next byte), it will give you messages relative the most recent messageId in the channel (see last n bytes))		* (u32) fromMessageId (If set to 0, AND you are asking for messages sent BEFORE this specified message Id (see next byte), it will give you messages relative the most recent messageId in the channel (see last n bytes))
	* (u8) message count AND before\|after (last 7 bits will tell the server how many messages you want before or since the specified message Id, first (most significant) bit will tell the server if you want messages from BEFORE or AFTER the specified message Id)		* (u8) message count AND before\|after (last 7 bits will tell the server how many messages you want before or since the specified message Id, first (most significant) bit will tell the server if you want messages from BEFORE or AFTER the specified message Id)
	* (n bytes) name of chat channel as a UTF8 encoded string		* (n bytes) name of chat channel as a UTF8 encoded string

	MessageId ascends as new chat messages are sent, so greater message ID = more recent.		MessageId ascends as new chat messages are sent, so greater message ID = more recent.

2A02:C7C:643A:EE00:4A3B:777B:1884:56D1: /* Chat history packet */

2023-10-24T12:32:07Z

Chat history packet

← Older revision		Revision as of 14:32, 24 October 2023
Line 17:		Line 17:

	* (u8) packetCode = 13		* (u8) packetCode = 13
	* (u32 fromMessageId (~~if it is~~ set to ~~message ID~~ 0, ~~and~~ you are asking for messages sent BEFORE this message ID (see next byte), it will ~~actually just~~ give you messages relative the most recent messageId in the channel (see last n bytes))		* (u32 fromMessageId (If set to 0, AND you are asking for messages sent BEFORE this specified message Id (see next byte), it will give you messages relative the most recent messageId in the channel (see last n bytes))
	* (u8) message count AND before\|after (last 7 bits will tell the server how many messages you want since ~~that~~ message id, first(most significant) bit will tell the server if you want ~~all~~ messages BEFORE or AFTER ~~that~~ message ID)		* (u8) message count AND before\|after (last 7 bits will tell the server how many messages you want before or since the specified message Id, first (most significant) bit will tell the server if you want messages from BEFORE or AFTER the specified message Id)
	* (n bytes) name of chat channel as a UTF8 encoded string		* (n bytes) name of chat channel as a UTF8 encoded string

	MessageId ascends as new chat messages are sent, so greater message ID = more recent.		MessageId ascends as new chat messages are sent, so greater message ID = more recent.

2A02:C7C:643A:EE00:4A3B:777B:1884:56D1: Change this to talk about chat history packet instead. Chat packet is obsolete

2023-10-24T12:29:11Z

Change this to talk about chat history packet instead. Chat packet is obsolete

← Older revision		Revision as of 14:29, 24 October 2023
Line 13:		Line 13:
	One can retrieve the X and Y position from an given pixel index with some basic math. To get the X position, we do '''index % canvas_width''', and to get the Y position '''floor(index / canvas_width)'''.		One can retrieve the X and Y position from an given pixel index with some basic math. To get the X position, we do '''index % canvas_width''', and to get the Y position '''floor(index / canvas_width)'''.

	=== Chat packet ===		=== Chat history packet ===
	The chat packet is the ~~epitome~~ of ~~new features being bolted onto an old system~~, ~~consisting of the first byte as the packet '''code'''~~, ~~then~~ the ~~rest, UTF-8 formatted string data separated with newlines for each section~~ of the ~~message payload~~.		The chat history packet is used to ask the server to load a certain set of messages from the database, for example, in the context of attempting to load previous chat messages from before a client connected to the game session when scrolling up in the chat history.

	~~This string data follows the following format as such for sending a packet from the client to the server:~~		* (u8) packetCode = 13
	* Name*		* (u32 fromMessageId (if it is set to message ID 0, and you are asking for messages sent BEFORE this message ID (see next byte), it will actually just give you messages relative the most recent messageId in the channel (see last n bytes))
	* Message*		* (u8) message count AND before\|after (last 7 bits will tell the server how many messages you want since that message id, first(most significant) bit will tell the server if you want all messages BEFORE or AFTER that message ID)
	~~* Channel*~~		* (n bytes) name of chat channel as a UTF8 encoded string
	* Type (~~"live"\|"place"~~, ~~optional~~, will ~~default to live~~)
	* X (~~e.g. "1234"~~, ~~optional, only needed~~ if ~~type == "place"~~)
	* Y (~~e.g. "5678", optional, only needed if type == "place", if X exists, Y must also~~)

	~~Most server softwares should reformat incomplete~~ chat ~~packets so that they can be correctly consumed by a client, but precautions should be taken by the client. When recieving a chat packet from the server, expect it to look like this:~~		MessageId ascends as new chat messages are sent, so greater message ID = more recent.
	* Name (If a verified name system is being used, a ~ will be appended to the end of their name if using a verified name without authentication to show the client that they are ~~likely impersonating~~, ~~while a "✔" will be appended to alert the client that this is the verified owner of such name)~~
	* Message
	* Channel
	* Type
	* X
	* Y
	* Uid (A unique identifier for the chatter that is persistent across different usernames, etc. ~~Most commonly based off a hash of the user's IP and used for moderation purposes)~~

31.54.72.74: /* Chat packet */Fix typo

2023-07-15T02:53:50Z

Chat packet: Fix typo

← Older revision		Revision as of 04:53, 15 July 2023
Line 21:		Line 21:
	* Channel*		* Channel*
	* Type ("live"\|"place", optional, will default to live)		* Type ("live"\|"place", optional, will default to live)
	* X (e.g "1234", optional, only needed if type == "place")		* X (e.g. "1234", optional, only needed if type == "place")
	* Y (e.g. "5678", O		* Y (e.g. "5678", optional, only needed if type == "place", if X exists, Y must also)
	optional, only needed if type == "place", if X exists, Y must also)

	Most server softwares should reformat incomplete chat packets so that they can be correctly consumed by a client, but precautions should be taken by the client. When recieving a chat packet from the server, expect it to look like this:		Most server softwares should reformat incomplete chat packets so that they can be correctly consumed by a client, but precautions should be taken by the client. When recieving a chat packet from the server, expect it to look like this:

31.54.72.74: /* Packets */Implemented description for chat packet

2023-07-15T02:52:37Z

Packets: Implemented description for chat packet

← Older revision		Revision as of 04:52, 15 July 2023
Line 12:		Line 12:

	One can retrieve the X and Y position from an given pixel index with some basic math. To get the X position, we do '''index % canvas_width''', and to get the Y position '''floor(index / canvas_width)'''.		One can retrieve the X and Y position from an given pixel index with some basic math. To get the X position, we do '''index % canvas_width''', and to get the Y position '''floor(index / canvas_width)'''.

			=== Chat packet ===
			The chat packet is the epitome of new features being bolted onto an old system, consisting of the first byte as the packet '''code''', then the rest, UTF-8 formatted string data separated with newlines for each section of the message payload.

			This string data follows the following format as such for sending a packet from the client to the server:
			* Name*
			* Message*
			* Channel*
			* Type ("live"\|"place", optional, will default to live)
			* X (e.g "1234", optional, only needed if type == "place")
			* Y (e.g. "5678", O
			optional, only needed if type == "place", if X exists, Y must also)

			Most server softwares should reformat incomplete chat packets so that they can be correctly consumed by a client, but precautions should be taken by the client. When recieving a chat packet from the server, expect it to look like this:
			* Name (If a verified name system is being used, a ~ will be appended to the end of their name if using a verified name without authentication to show the client that they are likely impersonating, while a "✔" will be appended to alert the client that this is the verified owner of such name)
			* Message
			* Channel
			* Type
			* X
			* Y
			* Uid (A unique identifier for the chatter that is persistent across different usernames, etc. Most commonly based off a hash of the user's IP and used for moderation purposes)

31.54.72.74: /* Pixel packet: */Fix code sample and confusing writing

2023-07-15T00:58:15Z

Pixel packet:: Fix code sample and confusing writing

← Older revision		Revision as of 02:58, 15 July 2023
Line 8:		Line 8:

	=== Pixel packet: ===		=== Pixel packet: ===
	The pixel packet is one of the simplest. It is a six byte packet, the first byte being the '''code,''' the '''position (board index)''' of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the '''colour''' in the palette that the pixel represents.		The pixel packet is one of the simplest. It is a six byte packet, the first byte being the packet '''code,''' the second to 5th
			bytes being '''position (board index)''' of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the '''colour''' in the palette that the pixel represents.

	One can retrieve the X and Y from an given pixel index with some basic math. To get the X position, we do '''index % ~~CanvasWidth~~''', and to get the Y position '''~~Math.Floor~~(index / ~~CanvasHeight~~)'''.		One can retrieve the X and Y position from an given pixel index with some basic math. To get the X position, we do '''index % canvas_width''', and to get the Y position '''floor(index / canvas_width)'''.

imported>Zekiah: Typo fix on pixel packet

2023-07-14T21:20:25Z

Typo fix on pixel packet

← Older revision		Revision as of 23:20, 14 July 2023
Line 10:		Line 10:
	The pixel packet is one of the simplest. It is a six byte packet, the first byte being the '''code,''' the '''position (board index)''' of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the '''colour''' in the palette that the pixel represents.		The pixel packet is one of the simplest. It is a six byte packet, the first byte being the '''code,''' the '''position (board index)''' of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the '''colour''' in the palette that the pixel represents.

	One can retrieve the X and Y from an given pixel index with some basic ~~maths~~. To get the X position, we do '''index % CanvasWidth''', and to get the Y position '''~~Maht~~.Floor(index / CanvasHeight)'''.		One can retrieve the X and Y from an given pixel index with some basic math. To get the X position, we do '''index % CanvasWidth''', and to get the Y position '''Math.Floor(index / CanvasHeight)'''.

imported>Zekiah: More info about pixel packet

2023-07-14T21:19:50Z

More info about pixel packet

← Older revision		Revision as of 23:19, 14 July 2023
Line 9:		Line 9:
	=== Pixel packet: ===		=== Pixel packet: ===
	The pixel packet is one of the simplest. It is a six byte packet, the first byte being the '''code,''' the '''position (board index)''' of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the '''colour''' in the palette that the pixel represents.		The pixel packet is one of the simplest. It is a six byte packet, the first byte being the '''code,''' the '''position (board index)''' of the pixel, represented by a 4 byte unsigned 32 bit integer, and finally a byte representing the index of the '''colour''' in the palette that the pixel represents.

			One can retrieve the X and Y from an given pixel index with some basic maths. To get the X position, we do '''index % CanvasWidth''', and to get the Y position '''Maht.Floor(index / CanvasHeight)'''.