[1.8.9+][Capabilities] So yeah... updating.

[Ernio]

Hey guys,

 

While reading all those example codes:

https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/TestCapabilityMod.java

https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/NoBedSleepingTest.java

And other sources (docs and google)...

... I can't help to wonder - What the hell am I supposed to do (with my particular implementation).

Note: We are only talking about LivingEntities!

 

With IEEP things were pretty straightforward: You bind data on Entity's Construction. It doesn't matter what kind of data it is, you can even bind 1000 different Objects (IEEPs) to different entities, and still keep them all with same registration name (e.g: "MyIEEP").

 

Well, my big-ass piece of code strongly depends on this fact. I am (was) treating all EntityLivingBase similar to player, with one fact - player had special extension on IEEP registered onto him.

Structure: (I = interface obviously)

IExtendedEntityProperties

--->IExtendedBase (API mod)

------>ExtendedBase (abstract implementation of API)

--------->ExtendedEntity (implementation of base)

--------->ExtendedPlayer (implementation of base)

 

Now, I was registering stuff like this:

@SubscribeEvent
public void onEntityConstructing(EntityConstructing event)
{
	if (event.entity instanceof EntityPlayer) ExtendedPlayer.register((EntityPlayer) event.entity);
	else if (event.entity instanceof EntityLivingBase) ExtendedEntity.register((EntityLivingBase) event.entity);
}

 

Now, because of this I was able to use common abstract class (ExtendedBase) to reference either Player or other LivingEntities using:

ExtendedBase.get(EntityLivingBase);

 

This was very nice solution since in my mod, all livingEntities have on "profile" (stats), but players can have multiple (ExtendedBase returned singular for Entities and "current" for Player, but using ExtendedPlayer.get(EntityPlayer) you could also skim over "other" profiles (stats)).

 

So now - how can one implement such system when Capabilities REQUIRE you to have default non-abstract implementation class. How can I register different Capability class for LivingEntity and Player, but keep them under same "title/name".

 

Additional question: Can @CapabilityInject be placed anywhere in code? In most examples I see it in Mod's main class but e.g: docs say it can be anywhere?

[LexManos]

The annotation can go anywhere as long as it's static.

And you need to have a default implementation of your capability.

You don't need to USE that default implementation.

You can do whatever you want. Caps can do everything that IEEPs can. If you design them correctly.

The problem with your old design is it's the exact opposite of IEEP/Caps. You're having a central storage {atleast thats what it looks like from your snippits} of entity -> data. Instead of having the data IN the entity itself which is what caps/IEEP is supposed to do.

 

Give more code, and explain what you've tried.

[Ernio]

In fact I just really needed 2h nap to refresh brain, it's always best to just read code, yet still - Thanks for help!

 

Extra: I really like flexibility of this system.

 

Only thing that I don't get is why would anyone want to actually use IStorage? I mean - saving and loading happens directly from e.g: capability#serializeNBT() which is part of ICapabilitySerializable - and that one can be easily reimplemented by user of some API.

 

E.g: API gives you come interface for capability and you replace it (implement not-default class) with your own modification, but then - you can also edit its saving/loding processes (serializeNBT()), so why have IStorage? Is it just to give modders way to "only edit saving/loading" or is there some other goal here? Docs say "This allows for a central implementation of saving the data."

[LexManos]

Capability and Capability PROVIDERS are different things.

ICapabilitySerializeable is a Serializable Capability Provider. I just knocked off the Provider part of it because thats a long fkin name.

 

Take a look at this: https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/NoBedSleepingTest.java

The Default implementation and the storage provider are DEFAULT serializers.

As a normal modder {Not the one writing the API} my implementation of saving/loading is just this:

                public NBTPrimitive serializeNBT() {
                    return (NBTPrimitive)SLEEP_CAP.getStorage().writeNBT(SLEEP_CAP, inst, null);
                }

                @Override
                public void deserializeNBT(NBTPrimitive nbt) {
                    SLEEP_CAP.getStorage().readNBT(SLEEP_CAP, inst, null, nbt);
                }

I can do that for ANY capability. I dont need to care that IFuelHandler stores 100,000 NBT elements. Or Sleep stores one.

I will get one NBT object from the storage handler and I know that it will load and save the state completely fine.

 

Now here is a important part: The storage handler is ONLY garenteed to work for the DEFAULT implementation.

SLEEP_CAP.getDefaultInstance()

If I have a some custom handler that relies on 15 different things and needs to store them all in the NBT. Then I will have to write my own serializer.

 

 

So ya remember ICapabilityProvider and INBTSerializeable are two different things. I made ICapabilitySerializeable PURELY as a convenience interface so that my patch files can be smaller. See My comment

 

Get it now?