[1.13.2] Item capabilities - LazyOptional?

[DoctorLOGiQ]

As per https://github.com/Choonster-Minecraft-Mods/TestMod3/blob/d045f88657816da463adfc631ee2ff1c96599798/src/main/java/choonster/testmod3/capability/pigspawner/CapabilityPigSpawner.java#L111, I have created a LazyOptional function, to return (supposedly) the capability from the ItemStack. 

 

The problem is, I can't actually USE the ruddy thing. *Apparently* you can cast to the capability interface as seen here: https://github.com/Choonster-Minecraft-Mods/TestMod3/blob/d045f88657816da463adfc631ee2ff1c96599798/src/main/java/choonster/testmod3/item/ItemPigSpawner.java#L42) (also side-note, typo in the documentation for this function - "...if amy"). But can I actually cast to the capability interface in reality? Not so much...

 

net.minecraftforge.common.util.LazyOptional cannot be cast to ((capability interface))

is being thrown from

Item#addInformation()

where I have tried to access the capability, as is done in the TestMod, to no avail.

 

How do I cast this to something usable?

I have done capabilities in 1.12.(I wanna say... 2), but this system is so weird and changes so often it's hard to keep up.

 

I'm not posting any code because it's unnecessary, I can guarantee I've spent the past 3-4 hours ensuring I've done everything I need to (and no more) pretty much as it was done before, but using the new changes, and referencing the TestMod for ALL OF IT. In other words, the code is *exactly the same* (except for the names, and the actual capability itself, of course. I ain't spawnin' no piglets!). And yes... the capability is being registered.

[Cadiboo]

I assume you want Optional.ifPresent(()-> do something with capability if it exists);

[V0idWa1k3r]

I can confirm that the code of the testmod just doesn't match here. Look at the commit history of the CapabilityPigSpawner.

Especially this commit

https://github.com/Choonster-Minecraft-Mods/TestMod3/commit/b191f331519093a5d6986f01508812fb95cd59bb#diff-8b7fdc96f9790467595ac30419c94981

It happened at Mar 1, but the ItemPigSpawner was only updated Feb 27, so it still references the old code from said file.

Especially look at this change

https://github.com/Choonster-Minecraft-Mods/TestMod3/commit/b191f331519093a5d6986f01508812fb95cd59bb#diff-8b7fdc96f9790467595ac30419c94981L112

This change changed the return value of the method to be a LazyOptional from the actual instance.

So yeah, the item sources just weren't updated to compile with the changes, you can't make a cast like that in java, this is not a programming language where you can define custom implicit/explicit casts.

Just get the value from the lazy optional and operate on that, it should be an instance of your interface or whatever you specify in the getter method.

[Choonster]

The 1.13.2 update of TestMod3 is still very much a work in progress, there are lots of parts that haven't been fully updated to the new version and the mod as a whole doesn't compile yet.

 

@V0idWa1k3r is correct that the ItemPigSpawner class is still referencing the 1.12.2 version of CapabilityPigSpawner.getPigSpawner. The CapabilityX and command classes are probably the best place to look for updated examples of capability use.

 

LazyOptional#ifPresent is probably the most common method you'll be using to interact with capabilities, but there are other methods in LazyOptional depending on what you're trying to achieve.

[DoctorLOGiQ]

Alright, I didn't realise the code had been changed. Which method in LazyOptional is the best to use to return the interface instance? Yes, the TestMod is an excellent resource and I thank you for that @Choonster.

[Choonster]

5 minutes ago, DoctorLOGiQ said:

Alright, I didn't realise the code had been changed. Which method in LazyOptional is the best to use to return the interface instance? Yes, the TestMod is an excellent resource and I thank you for that @Choonster.

 

Generally you should use LazyOptional#ifPresent to run a function (usually a lambda expression) if the value is present. The function receives the interface instance as an argument.

 

If you need the interface instance itself, you can use LazyOptional#orElse or LazyOptional#orElseGet.

[DoctorLOGiQ]

1 hour ago, Choonster said:

Generally you should use LazyOptional#ifPresent to run a function (usually a lambda expression) if the value is present. The function receives the interface instance as an argument.

How would this work with, say, an Item's addInformation() method? I would like to be able to display information retrieved from calling a getter method within the interface, would that be possible, or should I try a different approach? This information should be specific to an ItemStack, and the stacks are limited to a max size of 1.

 

Edit: My sincere apologies, this is me being dumb now. Of course a lambda expression would still be inside the function. For some reason I was thinking of it as a separate thing, heck knows why ? I will adapt and test my code and provided it doesn't continue crashing the issue should be resolved. However, there was a new error occurring a while ago to do with saving NBT data, but I think I know a possible cause of that. 

Edited April 23, 2019 by DoctorLOGiQ
Moronic question was idiotic, *ding!*

[DoctorLOGiQ]

Ok, I have seemingly got the capability working. Now the problem is, I don't think it's properly synced between the client and server sides, or otherwise something *very strange* is going on. In my Item's addInformation() method, I have a single line; 

tooltip.add(new TextComponentString(ChatFormatting.DARK_GRAY + "State: " + instance.getStateStringFormatted() + " (" + instance.getState().toString() + ")"));

which is meant to print the "state" of the item (just one of my enums).

Inside the implementation, getStateStringFormatted() returns:

switch (this.state)
{
  default: case Off: return ChatFormatting.RED + "Off";
  case Booting: return ChatFormatting.AQUA + "Booting";
  case Booted: return ChatFormatting.GREEN + "Booted";
}

and getState() returns

this.state

. So therefore, you would expect, that both these calls should print the same value, but guess what! They don't.

 

Does some kind of synchronisation need to happen?

[Cadiboo]

4 hours ago, DoctorLOGiQ said:

Does some kind of synchronisation need to happen?

By default capabilities are not synced to the client. However I would assume that Choonster’s code would have something in it to sync the values. Choonster said that the 1.13.2 update if their test mod is very WIP, so it might not be on GitHub it even written yet.

[Choonster]

I have a system to sync ItemStack capabilities here and here, the packet classes can be found here. You can see the implementation for IPigSpawner (IPigSpawnerFinite) here and the corresponding packets here.

[DoctorLOGiQ]

Thank you, I will take a look. It does seem like an incredible amount of classes/work just to send packets to/from a server, but I will *try* to make sense of what's going on there. Thanks for your help!