The Datawatcher

hydroflame · August 11, 2013

so lets talk about this guy

basicly the datawatcher is a threadsafe object that will detect changes in values that should be sync between the client and the server. it allows you to store a variety of different type (byte, short, int, float, string, ItemStack and ChunkCoordinates) and will automaticly sync them between clients and the server. sounds good

now DataWatchers watch object (of type enumerated above) and place them in a hashmap, yet for some reason there seem to be a check to have a data id smaller then 32

Quote
public void addObject(int par1, Object par2Obj)
{

Integer integer = (Integer)dataTypes.get(par2Obj.getClass());

if (integer == null)

{

throw new IllegalArgumentException("Unknown data type: " + par2Obj.getClass());

}

else if (par1 > 31)

{

throw new IllegalArgumentException("Data value id is too big with " + par1 + "! (Max is " + 31 + ")");

}

which is weird because obviously a hashmap can contain MANY more values :\

and the method that writes the object into the packets isnt restricted in any way about the amount of information that can be sent in it:

 public static void writeObjectsInListToStream(List par0List, DataOutput par1DataOutput) throws IOException
    {
        if (par0List != null)
        {
            Iterator iterator = par0List.iterator();

            while (iterator.hasNext())
            {
                WatchableObject watchableobject = (WatchableObject)iterator.next();
                writeWatchableObject(par1DataOutput, watchableobject);
            }
        }

        par1DataOutput.writeByte(127);//terminator btw
    }

now if we look into example EntityPlayer class, we can see that the maximum data id that will be occupied by the EntityPlayer data watcher is id 18

protected void entityInit()
    {
        super.entityInit();
        this.dataWatcher.addObject(16, Byte.valueOf((byte)0));
        this.dataWatcher.addObject(17, Float.valueOf(0.0F));
        this.dataWatcher.addObject(18, Integer.valueOf(0));
    }

this implies that there are still a couple of values left free that modders could potentially use (of course in other class too)

Is there a reason why we are not increasing the limit of datawatchers ? (note that would require a partial rewrite of DataWatcher.readWatchableObjects because it does something related to the 31 limit)

also i search a little into the forge class and there didn't seem to be anything that would "reserve" a data id for your mod (alerting other mods that this is was already taken)

couldn't there be a sort of system that would automatically allocate the available id between the different mods that needs them ?

hydroflame · August 11, 2013

ah i see, probably missed it last night.

in any case theres still a couple of free id and it wouldnt be imposible to rewrite the methods to expand to higher id

hydroflame · August 11, 2013

hey if no one is going to use those id because "theres not a lot free" ill gladly use them without looking back im not saying we should store 32000 new id on datawatchers im saying we could use the remaining ids to store value that require update on a regular basis (mana?, energy?)

lets take the example of a mod that adds energy to plauers and want the energy to change the way the player is rendered (he looks like exhaustedwhen he is low)

the datawatcher is a perfect place to store that as it update on a regular basis and it will update only to players who needs it (i dont need to spend time optimizing the distance from player to send the packet, mojang already did that for me)

also maybe just changing one class isnt enough, but my test showed me that it seems possible

i just want to check the efficiency of the system before and after to make sure performance hasnt dropped dramatically

Mazetar · August 11, 2013

Just wondering, wouldn't it be easier to create a new system.

Sort of like an ExtendedDataWatcher or something, which we can utilize like we do with the extended properties?

GotoLink · August 11, 2013

Personally I would replace the Exception thrown by an hook to another class.

hydroflame · August 12, 2013

after more research in the issue i have discovered that there is actually a very low amount of values that are actually used

result:

Reveal hidden contents

meaning we actually have more values to play with then we tought we would (average of 22 free id)

considering the proper usage of these (like i said earlier, values changing a lot like mana or energy) we probably don't need to expand it further then 31 for now

values worth interrest:

Entity uses 0, 1 meaning 29 free id

EntityLivingBase use 0, 1, 6, 7, 8, 9 meaning every single of your mobs has 25 id free!

EntityAnimal uses 12 (as well as every other before) for age. 24 free for your passif mobs

EntityPlayer uses 16, 17, 18 as well as EntityLivingBase so you still have 22 free id! (should be enough for our small needs)

so considering the free space, its probably not a big deal to expand the watch list size, but for the sake of it i did it anyway

all you have to do is remove the check for id>31, change the "writeWatchableObject" method to write [int][byte] (id, type) instead of [byte] (which was 3 bit for type 5 for id) and finally change the "readWatchableObjects" so that it reads [int][byte] instead

@Mazetar, the goal was to use the already implemented system to pack all values in 1 packet and prevent overhead caused by sending multiple packet. but it might be possible to simply add more information after the end byte that vanilla puts in the packet and retreive that information later

@gotoLink, same as maz

hydroflame · August 12, 2013

good point... i did not think of that, do you remember if the Datawatcher class is loaded when you connect to the server or before that ? (in one case you could simply omit to change the class, in the other you would have to launch the game in "normal datawatcher mode")

hydroflame · August 12, 2013

well with 1.6 its actually very easy to change between profile, so in the worst case you could specificly tell that you cannot use this on a vanilla server

but i think you're right and it's not worth it, there's probably only a very small amount of mods that will need to use those and for now we probably wont be running out of id

the minimum that we should do (those who want to use datawatchers) is to get the id from a config file, so that if 2 mods come in conflict the player can always change them

hydroflame · August 12, 2013

yes and no, im my case i need mana to be sent to the players (and i want the amount of mana to affect how players are rendered, so every client must know about the mana stats of every player)

so in my case i have to take one of the 22 free id and use one to store the mana level

but generally speaking yes people could probably use the datawatcher for their custom mobs without screwing up everything

Sign In

The Datawatcher

Recommended Posts

hydroflame

hydroflame

hydroflame

Mazetar

GotoLink

hydroflame

hydroflame

hydroflame

hydroflame

Join the conversation

Announcements

Recently Browsing

Posts

Topics

Who's Online (See full list)

Browse

Activity

Important Information