rswiki-book/317-Begin-player-updating.mediawiki

[[Category Packet]]
[[Category Packet 317]]
== Player Updating ==

=== Description ===

This packet begins the player updating. (I will use Hyperions player updating to sort of explain this packet--by the documentation)

MAY TAKE A BIT READING :P

I need time to finish trying to explain this packet to my best ability. If you hate what I have so far or doesn't make ANY sense. Just edit it. I wouldn't mind.

=== Setup  ===
Step 1: The first thing we need to do before this packet is fully received, we need to check if the player's map region has changed. If it has, then we need to send the Map Region packet (241). 

Step 2: Then we set up an update block, like so: { (1)...PacketBuilder updateBlock = new PacketBuilder(); } 

Step 3: Since this packet is written in bits instead of bytes and holds information about the local list, players to add/remove, movement and which updates are required we need to do: { PacketBuilder packet = new PacketBuilder(188, VARIABLE_SHORT); } Then once we've done that we need to make that new field initiate the bit access like so: { packet.initiateBitAccess(); }

Step 4: We then need to update both the players movement and the player itself. For this go to Player Movement and Update Player.

Step 5: We need to write the current size of the player list so we put bits (8, and the size of the local players). Then we need to iterate through the local player list with a, for loop. And within that for loop we get the next player. Then check if the player should still be in our list. If so, then we send the update player movement method and check if an update is required. If so, send the player update. If the player should not be in our list still, then remove the player from the list and tell the client to remove the player by putting bits (1, 1) and (2, 3).

Step 6: Loop through every player and check if there is room left in the local list. If the size is >= 255 then there is no more room left. Therefore, we cannot add more players, so we just ignore them until they get replaced by the other players that get removed. After that, we check if they should not be added, by going through the local player list and seeing if it contains the other player, if so, ignore them (continue). After those checks we add the player to the list, add the player in the packet, and update the player forcing the appearance flag.

Step 7: Check if the update block is not empty, if so, write a magic id indicating an update block follows. We do that by putting bits (11, 2047), then we are finished with the bit access. Still in the update block check, we add the update block at the end of this packet. If the update block is empty, we terminate the packet normally (which means finish the bit access).

Step 8: We write the packet.

=== Player Movement ===
Check which type of movement took place. (PRIMARY) If no movement did take place, check if an update is required. If an update is required put bits (1, 1)//Update happened  and (2, 0)//No movement. If no update is required put bits (1, 0)//Nothing changed. (SECONDARY) The player moved but didn't run? Put bits (1, 1)//Update required (2, 1)//moved one tile (3, (PRIMARY))//Write the primary sprite and (1, isUpdateRequired() ? 1 : 0). We then put an else statement for the (SECONDARY) check. Within that, we put bits (1, 1)//Update happened (2, 2)//Two tiles (3, (PRIMARY))// Walking direction (3, (SECONDARY))//Run direction and (1, isUpdateRequired() ? 1 : 0)//Block update happened.

=== Add Player ===
putBits(11, otherPlayer.getIndex()); int yPos = other players y - players y; int xPos = other players x - players x;

=== Explaining (1) ===
The update block packet holds update blocks and is sent after the main packet.