Original Reddit post

Hello, humble annonymous plugin dev here. Whenever you see someone in game, the server sends information about the player to your client which can render them. For example, when you do an animation, the animation data is not sent. Instead, Player.animation updates the integer from -1 to the integer corresponding to the animation. Your client reads this and begins processing the animation. Fun fact: This is why running into someone’s render distance mid-animation does not cause the animation to start midway through the animation and instead causes them to stand still. This is an example of a variable which can be indirectly written by your client and read by other clients. As a result, it prevents the server from storing every frame of an animation and playing them one at a time to every person in render distance. If we just had one more manipulatable attribute, one which could not be written through normal gameplay, we could do so much more. Imagine there is a public attribute called “other” which is simply a standard 32 bit int and Jagex gave your client freedom to write whatever it wanted to your player’s attribute. You could play prop hunt with friends. You could have raid party plugins which track which users are FFA and which users want to split. You could organize custom gamemodes where your team gets special options or hilights. Now I know what you’re thinking: This is all already possible. And yes it is. But only by sharing user IP addresses or hosting a server. If you are a dev who wants to host a server, good luck getting any donations to cover the cost. And if you think sharing IP addresses with strangers on the internet is a good workaround, I got a few TCP SYN packets coming your way. That doesn’t even factor in the additional 200-300 ms delay if you want to play with people accross the atlantic. Just giving us a few free bytes of data would allow us to use the game’s built in communication to enhance our plugins and deliver experiences which were not possible without indefinite personal expernse, illegal autotypers, or sketchy IP swaps. 2 bytes is limiting but fits within the existing equipmentIds attribute. A seperate 4 byte attribute would allow for unique session IDs to be sent with the data and no apperant back end changes A seperate 16 byte attribute would reduce the risk of collisions, but is unnecessary in my personal opinion. And what about impact on the game? Well, even at 16 bytes, it would be trivial. The total additional disk space would be just 32 KB in a completely full world And given that any indivudal player is constantly transmitting around 125-175 bytes per tick to the client, this would be about a 10% reduction in the amount of players which can be transmitted to any given client. The lag you feel in crowded areas is also typically from your rendering process, which is unaffected by this data. If you’re worried about stacking 2000 players into a single area, this additional data is not likely to be the straw that breaks the cammel’s back. Please give us this tiny change to the back end data structure and let us build you the next cool addition to your game. submitted by /u/Lumpy-Experience758

Originally posted by u/Lumpy-Experience758 on r/2007scape