So I'm about to implement the ability to add extended entity properties, and I'd like to know if there is a common ID I can use to get the player.

 

The reason I'm asking is because the data for all instances in forge-clj (my library for Clojure, see signature) are stored together in one place. I then grab data for an individual instance by using a unique key (for example, I use the x, y, and z values to get the correct data for a Tile Entity). As such, I'm wondering if there is a common ID I can use to get the correct data.

 

Would a UUID work for this? Or is it different between client and server?

Ok, related question, what's the difference between getUniqueID and getPersistentID on entities?

TBH - there is none - from code side.

Why is it that the same player has a different UUID in the EntityConstructing Event than when they are passed in via onItemRightClick?

Why is it that the same player has a different UUID in the EntityConstructing Event than when they are passed in via onItemRightClick?

 

EntityEvent.EntityConstructing

is fired from the

Entity

constructor, which is called before the

EntityPlayer

constructor sets the

Entity#entityUniqueID

field to the player's

UUID

.

Why is it that the same player has a different UUID in the EntityConstructing Event than when they are passed in via onItemRightClick?

 

EntityEvent.EntityConstructing

is fired from the

Entity

constructor, which is called before the

EntityPlayer

constructor sets the

Entity#entityUniqueID

field to the player's

UUID

.

 

Yeah, I need the UUID for my Extended Properties. Is there an event I can safely call later or something?

Unfortunately that won't work with the way I'm structuring things. I'm using a different way of storing fields (in order to make the code cleaner and minimize field mutation). When the entity is constructed and the properties are registered, it gets the UUID in order to differentiate between instances within a hash-map. Due to this, a single instance has no fields, but just contains the required implementations in order to store these things in a global state.

 

For example, player1 has a uuid in the hash-map bound to a map containing a test value of 0, while player2 has a different uuid in the same hash-map with a test value of 1. Keeps the instances separate, but in one place. I did this successfully with tile entities, where instead of a uuid, I just used the x, y, and z values as the map key.

 

So yeah, because of that what you said won't really work. Thanks though.

Ok, nvm, I think I actually found something that worked (I tried using the player object itself as the map key, and it seems to be working).

 

Unfortunately, Forge seems to generate a random player name every time I use ./gradlew runclient, so I can't properly test everything. Is there a way to make it so that forge doesn't change the player name every time?

 

As for your question, the answer basically sums down to "it's a more Clojure-y way to do it". I'd elaborate further, but it's 1:00 AM here and explaining things take too long.

You can provide the --username argument (and --password if you want to log in).

 

And again, I do not see why you need this. Forge has IExtendedEntityProperties, which handles everything for you...

 

Ok, thanks for this, that was useful.

 

As for why, maybe I am reinventing the wheel here, but it mostly comes down to Clojure coding and how people typically structure their Clojure code, or at least from what I've seen. It's to make it more "Clojure friendly", really.

 

Actually wait, where do I put the argument? I thought it was a console argument, but it doesn't seem to like that.