rplace.live wiki - User contributions [en-gb]

Zekiahepic

2023-07-15T11:53:51Z

31.54.72.74: Correze zekiahepic casing

{| class="informbox"
! colspan="2" | {{{subj|zekiahepic}}}
|-
! colspan="2" | [[File:Zekiahepic discord profile picture.png|256px]]
|-
| colspan="2" style="text-align: center" | <small>{{{capt|The green default discord profile picture used by zekiahepic}}}</small>
|-
! Owner
| {{{leaders|[[of rplace.tk]]}}}
|}

The extremely overworked main developer of rplace.tk. Responsible for most of the updates that deviate from the base r/place game (and also 90% of the site bugs). Will say he is going to add a feature/carry out a moderation action/do l'''i'''terally anything then procee'''d''' to disappear from ex'''i'''stence or ghost whoever asked. Has his discord permanently set to display as offline because he is too scared to go on and face all the players waiting for him to deliver things he told them he would carry out. Supreme internet troll and will intentionally work '''o'''n things nobody has asked for out of spite. Has been earning negative money since the project started and is about £50 behind in AWS invoices, ignoring about 100 emails from amazon to pay (his accoun'''t''' got terminated forcing rplace to have to make a server migration).

"There is no country in the world that has wages even 1% as low as what I earn from working on rplace" - Zekiahepic 15/07/2023

Development

2023-07-15T02:53:50Z

31.54.72.74: /* Chat packet */Fix typo

rplace.tk has had a rocky development history. With such a high demand for different things, features have remained broken, scrapped or non-existent for long periods of time. Despite these issues, with the 10+ contributors to the main project, lead mostly by zekiahepic, and initially BlobKat. The site has found a relatively stable update cycle, with new features, fixes and bug improvements appearing each fortnight.

= The game protocol =
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: ===
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 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", 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)

Development

2023-07-15T02:52:37Z

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

rplace.tk has had a rocky development history. With such a high demand for different things, features have remained broken, scrapped or non-existent for long periods of time. Despite these issues, with the 10+ contributors to the main project, lead mostly by zekiahepic, and initially BlobKat. The site has found a relatively stable update cycle, with new features, fixes and bug improvements appearing each fortnight.

= The game protocol =
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: ===
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 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)

Rplace.tk

2023-07-15T02:29:09Z

31.54.72.74: /* The rules */Fix bad reference format

rplace.tk is a project with an intent to revive the original r/place 2022 experience. It was founded by BlobKat and Zekiah. The website has a little-known community with a very saturated history.

[[File:Rplace UI.png|thumb|alt=Rplace main UI screenshot|Screenshot of the main rplace.tk user interface]]

== Interface ==
=== Controls ===
When you enter the website for the first time, you enter the very center of Canvas 1. You may navigate the canvas by dragging the canvas with your mouse, clicking on a pixel to move to it, or by using the arrow keys. Pixels can be placed using the color selector, accessible by pressing the "Place a pixel" button at the bottom of the screen, or by using the key on the keyboard which corresponds with the color to be placed.

=== Navigation ===
By selecting the triple-dot icon in the top left of the screen, a Reddit-inspired user interface is revealed, featuring links to other canvases, useful tools, as well as some other websites.

==== Overlays ====
By pressing the "O" key, or by pressing the Overlay button in the navigator, an overlay menu can be accessed. A 1:1 scale drawing of a planned build must be uploaded in order for it to work properly. Parameters that may currently be changed are the overlay opacity and the coordinates of the top left corner of the overlay.

==== Timelapses ====
A partially functioning timelapse tool is present on the website.

==== Accounts ====
Account management was a short-lived feature of rplace.tk. It was removed due to its lack of functionality for the time. Plenty of features are available if you register, e.g. a dashboard for self-hosted canvases, though you were unable to register.

== Development history ==
The website was launched on 5 April, 2022, shortly after the r/place event, as a rehabilitation and continuation of it.

== The rules ==
"You may not use more than one bot"<ref>"Bots are allowed on this site, as long as they follow the rules, this means that they only place 1 tile per the time limit, and do not make use of any proxies or VPNs, or botnets of multiple devices (multiple bots all controlled by one machine/repo) to operate. Please use common sense, botting a massive area just to grief or print scams is obviously not going to fly and will be removed.
Keep in mind we are not liable for any damage or malware you receive due to the use of a community bot, we recommend that you only make use of bots if they are trusted and open source, and you do so at your own risk." (zekiahepic [https://discord.com/channels/960966748289507338/960970134313373777/960986507391434762 on the discord info-rules channel])</ref>

In the early months rplace.tk staff would often perform rollbacks due to mass scale botting, or the construction of nazi/nsfw content, however with the deprecation of the moderation tools, and a general loosening on the rules, such moderation was eventually relegated to players self erasing such content by placing pixels over.

== References: ==

Development

2023-07-15T00:58:15Z

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