Thread: Reducing overhead during player updating

Page 1 of 3 123 LastLast
Results 1 to 10 of 25
  1. #1 Reducing overhead during player updating 
    Banned Market Banned Market Banned


    Join Date
    Jan 2011
    Age
    21
    Posts
    3,122
    Thanks given
    1,198
    Thanks received
    1,478
    Rep Power
    0
    Does anyone have any tips or tricks to reduce the amount of overhead produced while updating? I'm already caching update blocks as well as executing it in parallel, although I only have two cores available to use. But is there anything else I can/should be doing to ensure that updating goes by more smoothly?

    EDIT: I posted this in the wrong section, my mistake.
    Reply With Quote  
     

  2. #2  
    Banned

    Join Date
    Mar 2011
    Posts
    4,069
    Thanks given
    194
    Thanks received
    688
    Rep Power
    0
    dont do what most servers do and update appearance every tick, only when necessary
    Reply With Quote  
     

  3. #3  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,602
    Thanks given
    234
    Thanks received
    970
    Rep Power
    1244
    Quote Originally Posted by relex lawl View Post
    dont do what most servers do and update appearance every tick, only when necessary
    the client caches appearances so if player 20 "aaron" we'll call him, goes out of view and aaron doesn't log out and his player id stays the same AND his appearance was the same when you last saw him as it is now, you don't have to send appearance.

    to accomplish this you need to keep track of what players the client has cached and the modification time of the appearance. if they don't match then synchronize.
    .
    Reply With Quote  
     

  4. #4  
    Registered Member
    Join Date
    Jun 2014
    Posts
    21
    Thanks given
    2
    Thanks received
    4
    Rep Power
    11
    sorry but all ur objects are slowing it down
    Reply With Quote  
     

  5. #5  
    Banned

    Join Date
    Mar 2011
    Posts
    4,069
    Thanks given
    194
    Thanks received
    688
    Rep Power
    0
    Quote Originally Posted by Supah Fly View Post
    the client caches appearances so if player 20 "aaron" we'll call him, goes out of view and aaron doesn't log out and his player id stays the same AND his appearance was the same when you last saw him as it is now, you don't have to send appearance.
    edit2: what the client does cache is the player model, still reads all the data sent by the appearance block beforehand though


    umm does it? i dont see it, where exactly is this happening?

    Code:
    private void updatePlayers(int bufferSize, JagexBuffer buffer) {
            anInt839 = 0;
            localPlayersIndex = 0;
            updateClientMovement(buffer);
            updateOtherClientMovements(buffer);
            addNewLocalPlayer(buffer, bufferSize);
            updateLocalClientMasks(buffer);
            for (int index = 0; index < anInt839; index++) {
                int player = anIntArray840[index];
                if (players[player].time != loopCycle) {
                    players[player] = null;
                }
            }
            if (buffer.offset != bufferSize) {
    			throw new RuntimeException("Error reading player updating packet - [size, expectedSize] : [" + buffer.offset + ", " + bufferSize + "]");
                //signlink.reportError("Packet size mismatch in player updating - buffer offset: " + buffer.offset + ", size: " + size);
                //signlink.reportError("Error packet size mismatch in getplayer pos:" + stream.offset + " psize:" + size);
               // throw new RuntimeException("eek");
            }
            for (int index = 0; index < playerCount; index++) {
                if (players[playerIndices[index]] == null) {
                    signlink.reportError(myUsername + " null entry in pl list - pos:" + index + " size:" + playerCount);
                    throw new RuntimeException("eek");
                }
            }
        }
    Code:
    private void updateLocalClientMasks(JagexBuffer stream) {
            for (int index = 0; index < localPlayersIndex; index++) {
                int id = localPlayers[index];
                Player player = players[id];
                int mask = stream.readUnsignedByte();
                if ((mask & 0x40) != 0) {
                    mask += stream.readUnsignedByte() << 8;
                }
                handlePlayerMasks(mask, id, stream, player);
            }
        }
    Code:
    if ((mask & 0x10) != 0) {
                int j1 = in.readUnsignedByteC();
                byte abyte0[] = new byte[j1];
                JagexBuffer stream_1 = new JagexBuffer(abyte0);
                in.readBytes(j1, 0, abyte0);
                aStreamArray895s[pid] = stream_1;
                player.updatePlayer(stream_1);
            }

    edit:

    Quote Originally Posted by ill_e View Post
    sorry but all ur objects are slowing it down
    lmao
    Reply With Quote  
     

  6. #6  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,602
    Thanks given
    234
    Thanks received
    970
    Rep Power
    1244
    you didn't even post any of the code that handles it. the client saves the entire appearance block locally when you send it (look where it reads appearance) which is why you need to send length when you update appearance, and look at where a new player is added to your view, it loads the cached block if there is one.

    aStreamArray895s[pid]
    .
    Reply With Quote  
     

  7. #7  
    Banned Market Banned Market Banned


    Join Date
    Jan 2011
    Age
    21
    Posts
    3,122
    Thanks given
    1,198
    Thanks received
    1,478
    Rep Power
    0
    Quote Originally Posted by relex lawl View Post
    dont do what most servers do and update appearance every tick, only when necessary
    So what you're saying is I should keep track of if the player's equipment/combat level/standing animation/etc. have changed and if they haven't I shouldn't send the appearance block at all?


    Quote Originally Posted by Supah Fly View Post
    you need to keep track of what players the client has cached and the modification time of the appearance
    how would you even do that?


    Quote Originally Posted by ill_e View Post
    sorry but all ur objects are slowing it down
    leave
    Reply With Quote  
     

  8. #8  
    Registered Member
    Join Date
    Dec 2010
    Posts
    498
    Thanks given
    41
    Thanks received
    84
    Rep Power
    54
    Quote Originally Posted by lare96 View Post
    So what you're saying is I should keep track of if the player's equipment/combat level/standing animation/etc. have changed and if they haven't I shouldn't send the appearance block at all?



    how would you even do that?



    leave
    Time stamped update blocks, save the hash of the last update black of each kind sent per each player seen.
    Reply With Quote  
     

  9. #9  
    Banned

    Join Date
    Mar 2011
    Posts
    4,069
    Thanks given
    194
    Thanks received
    688
    Rep Power
    0
    Quote Originally Posted by Supah Fly View Post
    you didn't even post any of the code that handles it. the client saves the entire appearance block locally when you send it (look where it reads appearance) which is why you need to send length when you update appearance, and look at where a new player is added to your view, it loads the cached block if there is one.
    aStreamArray895s is only used when adding a new player locally...

    Code:
        private void addNewLocalPlayer(JagexBuffer stream, int i) {
            while (stream.position + 10 < i * 8) {
                int j = stream.getBits(11);
                if (j == 2047) {
                    break;
                }
                if (players[j] == null) {
                    players[j] = new Player();
                    if (aStreamArray895s[j] != null) {
                        players[j].updatePlayer(aStreamArray895s[j]);
                    }
                }
                playerIndices[playerCount++] = j;
                Player player = players[j];
                player.time = loopCycle;
                int k = stream.getBits(1);
                if (k == 1) {
                    localPlayers[localPlayersIndex++] = j;
                }
                int l = stream.getBits(1);
                int i1 = stream.getBits(5);
                if (i1 > 15) {
                    i1 -= 32;
                }
                int j1 = stream.getBits(5);
                if (j1 > 15) {
                    j1 -= 32;
                }
                player.setPos(myPlayer.pathX[0] + j1, myPlayer.pathY[0] + i1,
                        l == 1);
            }
            stream.finishBitAccess();
        }
    it still updates the player's appearance either way, use any pi and make updateAppearance in client send a message below where the last value is read (usually a short reading total levels, unless modified), you will get that message every tick. so it's reading all the data every tick when it should only read it when necessary, equipping/unequipping items, changing clothing, etc

    edit: also what do you mean look at where it reads appearance? i dont see how it makes sense for the client to "cache" the appearance...since if youre sending an update mask for it, it's supposed to be reading a new appearance. the only thing that "caches" is "appearance" (aLong1718), which is used when fetching the player model

    Code:
    public void updatePlayer(JagexBuffer buffer) {
    		buffer.offset = 0;
    		gender = buffer.readUnsignedByte();
    		prayerId = buffer.readUnsignedByte();
    		skullId = buffer.readUnsignedByte();
    		npcDef = null;
    		team = 0;
    		for (int index = 0; index < 12; index++) {
    			int equipmentId = buffer.readUnsignedByte();
    			if (equipmentId == 0) {
    				equipment[index] = 0;
    				continue;
    			}
    			int equipment_index = buffer.readUnsignedByte();
    			equipment[index] = (equipmentId << 8) + equipment_index;
    					
    			if (index == 0 && equipment[0] == 65535) {
    				npcDef = NPCDef.getDef(buffer.readUnsignedShort());
    				break;
    			} else if (index == 0 && equipment[0] != 65535) {
    				npcDef = null;
    			}
    			if (equipment[index] >= 512 && equipment[index] - 512 < ItemDef.totalItems) {
    				int team = ItemDef.getDef(equipment[index] - 512).team;
    				if (team != 0) {
    					this.team = team;
    				}
    			}
    		}
    		if (npcDef == null) {
    			for (int index = 0; index < 5; index++) {
    				int color_index = buffer.readUnsignedByte();
    				if (color_index < 0 || color_index >= Client.VALID_COLORS[index].length) {
    					color_index = 0;
    				}
    				appearanceColor[index] = color_index;
    			}
    		}
    		if (npcDef == null) {
    			super.standAnimIndex = buffer.readUnsignedShort();
    			if (super.standAnimIndex == 65535) {
    				super.standAnimIndex = -1;
    			}
    			super.turnAnimIndex = buffer.readUnsignedShort();
    			if (super.turnAnimIndex == 65535) {
    				super.turnAnimIndex = -1;
    			}
    			super.walkAnimIndex = buffer.readUnsignedShort();
    			if (super.walkAnimIndex == 65535) {
    				super.walkAnimIndex = -1;
    			}
    			super.turn180AnimIndex = buffer.readUnsignedShort();
    			if (super.turn180AnimIndex == 65535) {
    				super.turn180AnimIndex = -1;
    			}
    			super.turn90CWAnimIndex = buffer.readUnsignedShort();
    			if (super.turn90CWAnimIndex == 65535) {
    				super.turn90CWAnimIndex = -1;
    			}
    			super.turn90CCWAnimIndex = buffer.readUnsignedShort();
    			if (super.turn90CCWAnimIndex == 65535) {
    				super.turn90CCWAnimIndex = -1;
    			}
    			super.runAnimIndex = buffer.readUnsignedShort();
    			if (super.runAnimIndex == 65535) {
    				super.runAnimIndex = -1;
    			}
    		} else {
    			super.standAnimIndex = npcDef.standAnimation;
    			super.turnAnimIndex = npcDef.getDegreesToTurn;
    			super.walkAnimIndex = npcDef.walkAnimation;
    			super.turn180AnimIndex = npcDef.turn180Animation;
    			super.turn90CWAnimIndex = npcDef.turn90LeftAnimation;
    			super.turn90CCWAnimIndex = npcDef.turn90RightAnimation;
    			super.runAnimIndex = npcDef.walkAnimation;
    		}
    		name = TextUtils.fixName(TextUtils.nameForLong(buffer.readLong()));
    		combatLevel = buffer.readUnsignedByte();
    		//skill = buffer.readUnsignedShort();
    		title = buffer.readSignedShort(); //custom data
    		gameMode = buffer.readSignedByte(); //custom data
    		showGameModeTitle = buffer.readSignedByte() == 1; //custom data
    		visible = true;
    		appearance = 0L;
    		for (int k1 = 0; k1 < 12; k1++) {
    			appearance <<= 4;
    			if (equipment[k1] >= 256)
    				appearance += equipment[k1] - 256;
    		}
    		if (equipment[0] >= 256)
    			appearance += equipment[0] - 256 >> 4;
    		if (equipment[1] >= 256)
    			appearance += equipment[1] - 256 >> 8;
    		for (int i2 = 0; i2 < 5; i2++) {
    			appearance <<= 3;
    			appearance += appearanceColor[i2];
    		}
    		appearance <<= 1;
    		appearance += gender;
    	}

    Quote Originally Posted by lare96 View Post
    So what you're saying is I should keep track of if the player's equipment/combat level/standing animation/etc. have changed and if they haven't I shouldn't send the appearance block at all?
    dont really need to "keep track of", just update when necessary, when a player equips an item, unequips an item, levels combat (or any skill if you're using that variable below combatLevel in client, not sure what jagex used for exactly), activates or deactivates head icons (either prayer, skulls, hints, etc), changes their appearance (make-over mage), also if you're forcing a render animation (such as stand anim as youve said), using npc transformation, basically anything that's being read in the above method i showed
    Reply With Quote  
     

  10. #10  
    ???

    funkE's Avatar
    Join Date
    Feb 2008
    Posts
    2,602
    Thanks given
    234
    Thanks received
    970
    Rep Power
    1244
    yeah, if a player is at the edge of your view and keeps entering and leaving it doesn't make sense to send the same data over and over.

    like I said, it caches appearance blocks (as you can see from your code where it handles appearance update) and reads them when a new player is added. you don't have to send an appearance update if the client has previously seen the player and their block is up to date with current appearance.

    imagine running flax with like 100 people, it saves bandwidth not updating appearance for people you keep seeing when they haven't changed since last you saw them.


    also you could modify the protocol to have bitflags for what sections of appearance are being updated. it'd work pretty easily into the client
    .
    Reply With Quote  
     

Page 1 of 3 123 LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. The player updating procedure
    By veer in forum Informative Threads
    Replies: 30
    Last Post: 01-08-2012, 11:24 PM
  2. Replies: 2
    Last Post: 04-22-2009, 01:19 PM
  3. Need Player Update Help! (RichScape)
    By Russian in forum Requests
    Replies: 0
    Last Post: 12-25-2008, 08:48 PM
  4. [508] Player Update Masks.
    By Ian... in forum Configuration
    Replies: 9
    Last Post: 08-30-2008, 06:12 PM
  5. All 481 Player Update Masks
    By ZachHaley in forum RS2 Server
    Replies: 13
    Last Post: 07-07-2008, 07:30 AM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •