Danny and Son

Good to know, so is there a PlayerInventory#getItemStack equivalent in the Mojang mappings, or is AbstractContainerMenu#getCarried the way to go? I don't actually need to know at this point, and I'm not sure of any scenario where you'd need it and not have a container menu available. I'm just curious and also wondering for the benefit of someone else with the same question who finds this post.

Thank you! I did notice AbstractContainerMenu#getCarried and was able use that. Sorry, I am maintaining my mods in 1.16.5, 1.17.1 and 1.18 right now, and I just noticed that PlayerInventory#getItemStack does indeed exist in 1.16.5 but not 1.17.1 which doesn't have PlayerInventory at all, just Inventory which does not have getItemStack. My title should have said 1.17.1+. Sorry for the confusion.

In 1.15 and before, you could get the item being held/dragged by the cursor using PlayerInventory#getItemStack. This no longer seems to be the case. How do we do this now?

Is your init function being called? It doesn't look like your subscribing to RegisterCapabilitiesEvent.

Interesting. Thanks for sharing that. I haven't tested it since 37.0.30. I ended up changing over to SaveData. It's much simpler to work with, gives me a lot more control, and I don't have to worry as much about it breaking every time Minecraft updates. The only drawback is that the data will persist even if player data files are deleted. They would have to delete the custom data file instead. I don't think that's a big issue, especially given that the tradeoff is that the data also persist through death, dimension changes or whatever without having to play any dirty tricks.

As far as I know, no solution has been found. I might need to open an issue on the MinecraftForge GitHub. I have a couple questions for you just to make sure we're both dealing with the same issue: Are your capabilities working when the player leaves and rejoins? Have you also tried using reviveCaps() with no success? Is your code posted publicly or can you share an excerpt of your PlayerEvent.Clone event?

Ditto to nearly everything @Luis_ST said. McJty's tutorials are really helpful. Also, Minecraft by Example was super amazingly helpful for me! Currently, it's only up to 1.16 though. And, I found Silent Chaos's tutorials really helpful too. He moves much faster than McJty and assumes some background knowledge, so some people might find it harder to follow, but he takes you on a much faster path to getting a basic mod working. Overall though, the process involved a lot of searching, looking at other mod code, and digging into Minecraft and forge code. Sometimes it feels like the information you want isn't there, but then you find something, and it all comes together. It can be frustrating, and then exhilarating. Then, it gets easier.

Can someone confirm that Player.reviveCaps() does, indeed, restore capabilities attached to the player? This does not appear to be happening in my case. I have thoroughly debugged my code (otherwise I would not have opened this thread), and the only issue appears to be that LazyOptional.isValid becomes false on death and dimension change, and this is not changed to true when calling reviveCaps(). In short, reviveCaps is not doing what I think it's supposed to do. So, either it's not working correctly, or I am misunderstanding how it's supposed to work.

It might help to add that when I check the player object at any other point, such as when opening the mod's GUI, nutritionalBalanceLazyOptional.isValid = true. So, I'm guessing it's being invalidated by the death and dimension change, and reviveCaps() is not changing that. Based on my understanding of the commit you referenced above, reviveCaps() is supposed to change that to true. Right?

My provider is returning a valid cap in every other circumstance though. Just not during cloning or dimension changes. Data is saved on leave and rejoin. GUI elements that query the caps are working as expected. Other events that are taking actions based on values within the caps are working. In the debugger, I can see all the data in my cap in the 2 above scenarios. It is exactly what it's supposed to be, but event.entity.capabilities.caps[0].nutritionalBalanceLazyOptional.isValid = false and it remains so after calling reviveCaps(). Other than that, the debugger is showing that all the other data is exactly what it's supposed to be. What would cause isValid to be false?

That doesn't seem to work unless I'm doing it incorrectly: @SubscribeEvent public void onPlayerDeath(PlayerEvent.Clone event) { if (event.getEntity() instanceof Player playerEntity) { event.getOriginal().reviveCaps(); event.getOriginal().getCapability(CapabilityNutritionalBalancePlayer.HEALTHY_DIET_PLAYER_CAPABILITY).ifPresent(originalInutritionalbalancePlayer -> { playerEntity.getCapability(CapabilityNutritionalBalancePlayer.HEALTHY_DIET_PLAYER_CAPABILITY).ifPresent(newInutritionalbalancePlayer -> { . . . . }); }); event.getOriginal().invalidateCaps(); } } After running event.getOriginal().reviveCaps(), the caps are still invalid, so the lambda code is never executed. Similarly for dimension changes: @SubscribeEvent public void onDimensionChange (PlayerEvent.PlayerChangedDimensionEvent event){ event.getEntity().reviveCaps(); } The caps are still invalid after executing this. Am I doing something wrong?

It appears players are losing capability data on dimension change as well (tested in 37.0.25 and 37.0.30).

Oh right. It's the capability provider for Entity, not for attached capabilities.

Ah, ok. Good to know it's not just me being stupid. It looks like LivingEntity is overriding reviveCaps(). Perhaps it should be calling super.

Thanks! I think I'm not fully understanding how to implement this, though. Calling reviveCaps() on the original player object does not validate the capabilities. It looks like I need to call reviveCaps() on the provider, but I'm not sure how to do that in this context.

When a player dies, and I attempt to copy my custom capabilities data from the original player object to the new player object in the PlayerEvent.Clone event, the getOriginal().getCapability method is not giving me the capability. Upon further inspection in the Debugger, the capability is marked as invalid. Specifically, event.original.capabilities.caps[0].mycapabilityLazyOptional.isValid = false. This is unique to 1.17.1. In 1.16.5, with the same code isValid = true, and the data is copied as expected. All other functionality seems to be working fine in 1.17.1. Data is being saved when a player leaves and rejoins, and can be found in their player data file NBT. It can be queried by other methods and classes while the player is alive. It is only on death that the capability data of the original player object can not be retrieved. Do we need to take a different approach in 1.17.1 or is something not working as expected?

I understand that, but I think you missed the point of my suggestion. The current system is confusing for users and frustrating for pack makers, because when we make changes to the default configs, it does not affect existing worlds. I am personally finding myself repeatedly explaining this system to people and telling them to delete the serverconfigs within their worlds in order to take on the new default configs. This is why I'm suggesting changing it so worlds use the default configs, by default, rather than copying the default config to the world file. And that, all server configs be generated in the default configs folder, and not in the world folder. The serverconfigs folder can then be used just to override the default configs. There has been a fair amount of push back from the community about this feature. Many mod authors are choosing to use common configs for cases that should be server configs and users are complaining. There's even a mod to change the behavior by forcing default configs to be copied to existing worlds, which defeats the purpose of this whole system. The suggestion I'm making would solve all these issues and make the server config system more intuitive and easier to maintain.

The new server config system is amazing in that it allows servers and worlds to have different config settings than the client, but it is really confusing for a lot of users. It's difficult to imagine a time when mod devs will be able to stop re-explaining how this system works to confused users and new pack devs. Nearly every Curseforge mod page has this "where are the configs?" conversation repeatedly in its comments. One adjustment that would make it much simpler to understand, while still maintaining the new functionality. Instead of server configs generating within world folders by default, it would be better if they could generate in the defaultconfigs folder instead. The world/serverconfig folder would be used to override server configs. The server would first look in the world's server config, and if the config file isn't there, it will look in the defaultconfigs folder. I think it would be much more intuitive this way.