Integration with ender backpacks as a "team backpack"

[fennifith]

Hi! I'm working on Yet Another Minecraft BINGO and have had a request for "team backpack" behavior - and while I think fully implementing my own backpacks is a little out of scope, I would like to make this possible with other mods (such as this one!).

I've taken a look around this mod, and while it seems feasible to achieve the desired behavior, it might involve a few changes - so I wanted to get your thoughts on it first.

• It seems like ender backpacks will change ownership as soon as they get punched or picked up by another player. For a team backpack, every player on the team would need to have a backpack with the same inventory so that they can share items.
  • I haven't actually figured out how this is implemented. It seems like the backpacks don't store ownership data at all unless they're crafted or placed down - and if crafted, they still don't always share the same inventory when used by another player. Not sure if I'm missing something, though.
• It might make sense to implement a "persistent" flag for this case - for which an ender backpack will never change its stored ownership. This way the backpack stores a set player name and UUID.
  • I don't think the underlying ender storage needs to be changed to accommodate this. Yes, it might be possible for a "team backpack" to have a UUID collision with another player... but that's extremely unlikely! As long as there's a way to manually set the backpack to a UUID that is not dependent on a player, it should be fine.
  • The stored "player name" could replace the "Bound to:" display in the item tooltip - so that it can show "Bound to: Green Team" in my use case.
• I'd suggest exposing the following method in CompatHelper to make this possible:
  • static ItemStack createEnderBackStack(UUID id, String playerName)
• For my mod, this usage looks like:
  • Create a stored UUID for each team
  • Use CompatHelper.createEnderBackStack(team.uuid, team.name) to get a "team backpack" item for each player
  • Equip a stack to each player with CompatHelper.setBackStack(player, stack)

Let me know if this makes sense! I'd be happy to help contribute this in a PR if I get the time :D

[BeansGalaxy]

Sorry I missed this! Team Backpacks would be a cool implementation and I could see how it could work in the current implementation. Also this is my first mod and I'm glad to say it's feature complete. I've been going through all my code and bringing all of it up to the same quality and my server saving implementation is next.

First to clear some things up, ownership never changes unless a player trims someone else's backpack OR on death if /beansmod config unbindEnderOnDeath is set to true. All that logic is to assign an owner if the ender backpack has none since I could never ensure the backpack always has an owner.

createEnderBackStack is something I can do. All an entry needs is a uuid and a name to get started. I'll likely expose a setEnderDataTrim(UUID id, CompoundTag trim) so you can color the trims on their backpacks too. And do you need me to add a config command to disable trimming changing ownership?

[fennifith]

No problem! I'm not in any rush :)

Having checked again, I think what I was seeing is that backpack inventories are not always visually synced between players with the same ender backpack (at least on 0.19 - v2). When interacting with them, both players can put in and pull out the expected items, but the client will display different items in the tooltip than the current state on the server.

Turning off the trimming changing ownership would be great if it can be done on a per-item or per-uuid basis! I don't really want my mod to affect the behavior of unrelated items if I can help it. (i.e. if a player crafts their own ender backpack, that should still behave the same)

Also - I know I'm bringing up a few issues, but this is an awesome first mod. Great work!

[BeansGalaxy]

Cool, I'll look into adding those methods. As for the Ender backpack inventories syncing to the client, since I plan to go over it's code, how would you handle syncing that to a player's client? I think I'll have to collect a list of the players wearing the inventory then send the inventory every time it updates but if you have any techniques on keeping the client synced I'm all ears. :)

[fennifith]

Yeah! I think most parts of the game use packets to send partial "change updates" rather than sending the full state/inventory at once - any sent packet is guaranteed to reach the client as long as it remains connected, so this is usually safe to rely on.

Storing a list of players does mean that you need to track the state of those players as well - e.g. if a player logs off the server, retaining a reference to their ServerPlayerEntity would cause a memory leak. Likewise, when players respawn or switch dimensions, I believe their entity class is re-created (but I've only briefly looked at this logic). Even if you only store the player UUID, this still requires tracking a lot of events to keep the list up to date. What if a player runs the /clear command? Are there ways to equip/remove a backpack that you won't be able to track?

I'd consider something like the following:

• When a player equips the backpack, send its full inventory to the client
• Whenever the inventory is changed, loop through all online players to find players with the same backpack equipped, and send an update packet to each.

This is less efficient than keeping a direct list of entities that are tracking the backpack... but not by much. You might lose a few nanoseconds looping through all players to check their backpack slots, but it'd be a lot easier to write and debug.

Likewise, as it doesn't happen too frequently, re-sending the entire inventory on each update likely wouldn't have much impact either. I'd prioritize whatever makes it simpler to write, as - in my experience - avoiding complexity (and bugs that come with it) is often more important than performance.

(this suggestion might be exactly what you just described - so I think you have a good approach!)

[BeansGalaxy]

I've spent some time re-working the tooltips and added a help menu in the inventory in the latest update and now I'm getting started on adding your ideas.

You've given me somewhere to start with "change updates" so I'll see how it goes. Also you're right that I shouldn't worry abt performance since 0.0215 extra seconds of latency isn't going to make a dent, especially to the person playing with ray-tracing shaders on grandma's old laptop from 2006.

[BeansGalaxy]

Version 20.1-0.22-v2 has the exposed methods you needed. I'm using Forge's naming structure so I hope I'm not speaking a foreign language but this website is effing amazing if you need help translating Yarn class names to Forge class names or vice versa.

updateEnderEntry

This creates a new entry with the uuid or if an entry already exists it'll override it's display name and trim if either are present, if it gets an Optional.empty then it won't change it.

I gave you access to the name as a component so you could make it translatable and format it how you'd like. The name appears every time you look at a placed backpack so I didn't want to limit how you could make it look.

The trims are formatted exactly how they're stored in an ItemStack "Trim" tag. The CompoundTag should be like {pattern:"minecraft:shaper", material:"iron"} (idk if this is really how it's written but its damn close). It shouldn't include the Trim:{} tag itself, only it's contents. I'm not sure how to build it from scratch but I would look at NbtUtils.snbtToStructure(String tag) and the in game data of a trimmed item.

I also included a second method incase you're using Yarn and everything broke in translation. The second class takes all Java classes and uses them for the first method. In String name you can use § for coloring or pass the translation and boolean translatable to true. String trim you can type nbt how it's written in commands and it'll parse it to a CompoundTag. If either of those Strings are null then that value wont be updated.

createEnderBackpack

Takes an Optional<UUID> as the owner of the backpack. It could be empty since I have fail safes that default to the player interacting with it. The boolean persistent will add a nbt tag to the ender backpack that means it won't change ownership if re-trimmed or my config is set to unbind equipped ender backpacks on death.

---

And that's it. I also cleaned up syncing Ender Data to clients. I ended up collecting players if they equip a backpack and ender packs when theyre placed, Then every update to the inventory I iterate through that list removing players that don't have it equipped and sending the whole inventory to the players who do. Placed packs then get removed when they're destroyed or unloaded.

lmk how it goes and if you need anything else
: - )

[fennifith]

That's awesome! I'll be trying that out soon - thanks for adding all this :D