Player Updating Issue In 317 Server & Clients

Well this is the known issue people have been having in the 317 protocol.

They can only update up to 80 players then the client will get a T2 error directing at the player updating opcode.

Issues I found:

Once you log into your server, teleport, or move into a region with more then 80 players your client t2's. Well you need to start loading up to 5 to 15 players at a time per cycle.

Then appearances send every cycle. Appearances should send when their was a change of clothing, look, item wearing, or if a player enters your region area.

Buffer size of the server should be set to 30,000 along with the client.

This is code from a non-renamed Client in the 317 protocol era

Code:

---

public static Class30_Sub2_Sub2 method396(int i, int j)
    {
        synchronized(aClass19_1415)
        {
            Class30_Sub2_Sub2 class30_sub2_sub2_2 = null;
            if(i == 0 && anInt1411 > 0)
            {
                anInt1411--;
                class30_sub2_sub2_2 = (Class30_Sub2_Sub2)aClass19_1414.method251();
            } else
            if(i == 1 && anInt1412 > 0)
            {
                anInt1412--;
                class30_sub2_sub2_2 = (Class30_Sub2_Sub2)aClass19_1415.method251();
            } else
            if(i == 2 && anInt1413 > 0)
            {
                anInt1413--;
                class30_sub2_sub2_2 = (Class30_Sub2_Sub2)aClass19_1416.method251();
            }
            if(class30_sub2_sub2_2 != null)
            {
                class30_sub2_sub2_2.anInt1406 = 0;
                Class30_Sub2_Sub2 class30_sub2_sub2 = class30_sub2_sub2_2;
                return class30_sub2_sub2;
            }
        }
        if(j < 9 || j > 9)
            throw new NullPointerException();
        Class30_Sub2_Sub2 class30_sub2_sub2_1 = new Class30_Sub2_Sub2(false);
        class30_sub2_sub2_1.anInt1406 = 0;
        if(i == 0)
            class30_sub2_sub2_1.aByteArray1405 = new byte[100];
        else
        if(i == 1)
            class30_sub2_sub2_1.aByteArray1405 = new byte[5000];
        else
            class30_sub2_sub2_1.aByteArray1405 = new byte[30000];
        return class30_sub2_sub2_1;
    }

---

Notice at the bottom this:

Code:

---

if(i == 0)
            class30_sub2_sub2_1.aByteArray1405 = new byte[100];
        else
        if(i == 1)
            class30_sub2_sub2_1.aByteArray1405 = new byte[5000];
        else
            class30_sub2_sub2_1.aByteArray1405 = new byte[30000];

---

So just set the Buffer to 30,000 on both server and client. That should handle the issue with out any further complications.

why not 10k?

where is the buffer set client side?

Why the hell have you set the buffer to 30k...

Code:

---

/**
 * The maximum amount of players to add
 * per cycle (as Lmctruck30 said should be 5-15..)
 */
final int PLAYERS_ADDED_PER_CYCLE = 5;

int playersAddedThisCycle = 0;

/**
 * Loop through the player's in this region.
 */
for(Player otherPlayer : player.getRegion().getPlayers()){
    /**
    * If there is already 255 player's added to the player list
    * then stop adding players.
    */
    if(player.getLocalPlayers().size() >= 255){
        break;
    }

    /**
    * If the player we're going to add is you or if the player is
    * already in the player list, then skip this player.
    */
    if(otherPlayer == player || player.getLocalPlayers().contains(otherPlayer)){
        continue;
    }

    /*
    * If we've already added the maximum amount of players
    * this cycle, then stop adding players.
    */
    if(++playersAddedThisCycle > PLAYERS_ADDED_PER_CYCLE){
        break;
    }

    /*
    * Add the player to our local player list.
    * Then do any updating such as appearance etc.
    */
    plr.getLocalPlayers().add(otherPlayer);
}

---

As simple as that, without client edits.

Quote:

---

Originally Posted by Vastico [Only registered and activated users can see links. Click Here To Register...]

Why the hell have you set the buffer to 30k...

---

The normal rs client already has it set to 30k lol.

@Clifton
You need to do client edits or else you will not hold more then 255 players in a region. I have tried and tested even with hyperion. You still get the issue where the client t2's at 80 players. But that is with a bot that changes appearances every cycle along with head icons. So please try to test that and tell me it works because it wont work.

Quote:

---

Originally Posted by Lmctruck30 [Only registered and activated users can see links. Click Here To Register...]

The normal rs client already has it set to 30k lol.

---

Perhaps you could provide some evidence of this. In the clients I have seen it has always been 5,000.

Quote:

---

Originally Posted by Lmctruck30 [Only registered and activated users can see links. Click Here To Register...]

The normal rs client already has it set to 30k lol.

@Clifton
You need to do client edits or else you will not hold more then 255 players in a region. I have tried and tested even with hyperion. You still get the issue where the client t2's at 80 players. But that is with a bot that changes appearances every cycle along with head icons. So please try to test that and tell me it works because it wont work.

---

You wont T2, if you put in the one line of code that has been excluded from all servers updating protocall...

Quote:

---

if(bufferSizes > 4995) break;

---

and it will hold 255 players in a region fine, I've never heard of a bot before that was clever enough to keep changing its appearence (+ its uneeded in most servers because there programmed so badly),

increasing the buffer size just seems like an easy way out tbh, as the fix requires all those, playerAppearenceUpdate = true, to be removed. Delta servers will get a whole lot worse once they start adding this...

Quote:

---

Originally Posted by Martin [Only registered and activated users can see links. Click Here To Register...]

You wont T2, if you put in the one line of code that has been excluded from all servers updating protocall...



and it will hold 255 players in a region fine, I've never heard of a bot before that was clever enough to keep changing its appearence (+ its uneeded in most servers because there programmed so badly),

increasing the buffer size just seems like an easy way out tbh, as the fix requires all those, playerAppearenceUpdate = true, to be removed. Delta servers will get a whole lot worse once they start adding this...

---

Thanks Martin, so the buffer of 4995 is basically the max for 255 players updating appearance?

Quote:

---

Originally Posted by Vastico [Only registered and activated users can see links. Click Here To Register...]

Thanks Martin, so the buffer of 4995 is basically the max for 255 players updating appearance?

---

no the max buffer size is 5000, so by stoping it at 4995, it means the client will stop adding players, and just process that amount of data.

If in the case of a delta server, they constantly call an appearence update, which means the max buffer size is reached at 80 players, but if its removed, you can easily process 255 players.