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.