Per-player entity equipment

[Machine-Maker]

Is your feature request related to a problem?

Pure api (without need for packet manipulation) to change what equipment clients see on entities.

Describe the solution you'd like.

I was thinking of just a Table<UUID, EquipmentSlot, ItemStack> for each player (the UUID is the entity's UUID). then in the ServerEntity and any other places the ClientboundSetEquipmentPacket is sent, just check the table first.

Describe alternatives you've considered.

Using a protocol library to manipulate the equipment packet.

Other

Just made this issue to discuss the best approach. I think the ideal is one where an entity's equipment for a player is saved so long as the player exists. If the player leaves and rejoins, the player then no longer has special equipment to show for an entity.

[u9g]

Bukkit#setEquipmentOverride(Entity, EquipmentSlot, @NotNull ItemStack)
Bukkit#clearEquipmentOverride(Entity, EquipmentSlot)

That's my thought on the best way to approach api around this, that way the table can be an implem detail.

[Machine-Maker]

Well its all gonna be an implementation detail. but why would the method be there and not on the entity? I more care about how to track this stuff, whether it should just send a packet and not track it, or keep track and override it when the server tries to send a new packet with changes.

[u9g]

Oh you’re right it would be on the entity. Why wouldn’t you just send a packet when an override is applied, and when the override is removed send a packet to update the armor to what it really is.

[Machine-Maker]

Because in between that the entities actual equipment may change and it'll send a new packet with that. Or when an entity goes in and out of tracking distance. So you have to keep track of what each player should see somewhere.

[electronicboy]

us storing all of this stuff is generally just a royale PITA especially if it's for data which plugins can efficiently recalculate, if an API was created for this it would generally be better to just have events which let people efficiently deal with this on their own, be that if they wanna store the data themselves or compute it dynamically, all we'd generally maybe need to do is store a bool as to if equipment updates should be sent by us, not 100%

[yannicklamprecht]

I would rather not only save a Table<UUID, Equipmentslot, ItemStack> instead creating a visiblibility override compound.

Map<UUID, DisguiseCompound>

The disguise compound can not only hold equipment slot overrides, instead it could be extended in future to support more, like values for overriding entity DataSyncher entries.

Or is that out of scope?

[u9g]

Done by upstream: https://hub.spigotmc.org/stash/projects/SPIGOT/repos/bukkit/commits/6c45a80e2ea268983d5a98b9f98b17e67496ca5a Can be closed

[Machine-Maker]

Please read the issue, that is not what this issue is talking about. I want a persistent change (hence the talk about a Table to store the information), similar to how entities can be hidden from specific players. Sending one equipment change doesn't do that, the next time the entity leaves the comes back into the players tracking range, the equipment will be back to normal.

[u9g]

Please read the issue, that is not what this issue is talking about. I want a persistent change (hence the talk about a Table to store the information), similar to how entities can be hidden from specific players. Sending one equipment change doesn't do that, the next time the entity leaves the comes back into the players tracking range, the equipment will be back to normal.

Oh, nevermind. You’re right, this is completely different from what I thought it was.