public class ArmorProvider implements ICapabilitySerializable<NBTBase> {

     @CapabilityInject(IArmor.class)

     public static final Capability<IArmor> Armor = null;

    
     private IArmor instance = Armor.getDefaultInstance();

    
     @Override
     public boolean hasCapability(Capability<?> capability, EnumFacing facing)
     {

         return capability == Armor;

     }

    
     @Override
     public <T> T getCapability(Capability<T> capability, EnumFacing facing)
     {

         return capability == Armor ? Armor.<T> cast(this.instance) : null;
     }

    
     @Override
     public NBTBase serializeNBT()
     {

         return Armor.getStorage().writeNBT(Armor, this.instance, null);

     }

    
     @Override
     public void deserializeNBT(NBTBase nbt)
     {

         Armor.getStorage().readNBT(Armor, this.instance, null, nbt);

     }
}

It breaks at:

 private IArmor instance = Armor.getDefaultInstance();

Because ... well it's null.

But here:

https://www.planetminecraft.com/blog/forge-tutorial-capability-system/
 

And in other places it says this is how it supposed to be.

http://mcforge.readthedocs.io/en/latest/datastorage/capabilities/#the-capability-system
 

This doesn't offer any documentation if you make a custom one. It doesn't even say you need to subscribe an event to be able to do it...

There is any good examples like really good working example or documentation on Capabilities?

Edited April 1, 20187 yr by Curly_dev

public class CommonProxy implements IProxy {
    
    public void preInit() {
        
    }

    public void init() {
        
    }

    public void postInit() {
        CapabilityManager.INSTANCE.register(Armor.class, new ArmorStorage(), Armor.class);
        MinecraftForge.EVENT_BUS.register(new EventEquipmentSets());
        MinecraftForge.EVENT_BUS.register(new ArmorHandler());
        
    }

And the null is the Armor, because of
 

public static final Capability<IArmor> Armor = null;

Perfect now it works.

Now i understand.

Regarding code style, where should i register if not in common Proxy? That's where most tutorials say to put it and didn't find anything else to help.

Thank you.

And another thing:
 

     public void attachCapability(AttachCapabilitiesEvent<Entity> event) {
        if (canHaveAttributes(event.getObject()))
        {
            EntityLivingBase ent = (EntityLivingBase)event.getObject();
    
            if (ent instanceof EntityPlayerMP)
                event.addCapability(Armor, new ArmorProvider());
        }
     }

There is any way better to put capabilities just on players? Because now it goes through all entities... and it takes a while.

From an instant spawning it now looks like this:
[19:57:06] [Server thread/INFO]: Preparing spawn area: 0%
[19:57:07] [Server thread/INFO]: Preparing spawn area: 1%
[19:57:08] [Server thread/INFO]: Preparing spawn area: 3%
[19:57:09] [Server thread/INFO]: Preparing spawn area: 5%
[19:57:10] [Server thread/INFO]: Preparing spawn area: 7%

For 2 minutes.

The idea was that i wanted some custom data for players... It works as intended once it loads. But it takes way too much.

     public static boolean canHaveAttributes(Entity entity)
     {
         if (entity instanceof EntityLivingBase)
             return true;
         return false;
     }

Yes if i comment the MinecraftForge.EVENT_BUS.register(new ArmorHandler()); it goes quick.

Edited April 1, 20187 yr by Curly_dev

34 minutes ago, diesieben07 said:

A "common proxy" does not make sense. @SidedProxy is by definition for side-specific operations, the opposite of "common". Common initialization code happens in your main mod class. There is no "common proxy", there should be an interface Proxy and two implementations: ClientProxy and ServerProxy.

The problem started with cpw actually recommending this ("common" proxy) in the comments for the @SidedProxy annotation. Here's what it actually says:

/**
 * Sided proxies are loaded based on the specific environment they find themselves loaded into.
 * They are used to ensure that client-specific code (such as GUIs) is only loaded into the game
 * on the client side.
 * It is applied to static fields of a class, anywhere in your mod code. FML will scan
 * and load any classes with this annotation at mod construction time.
 *
 * <p>
 * This example will load a CommonProxy on the server side, and a ClientProxy on the client side.
 *
 * <pre>{@code
 *  public class MySidedProxyHolder {
 *      {@literal @}SidedProxy(modId="MyModId",clientSide="mymod.ClientProxy", serverSide="mymod.CommonProxy")
 *      public static CommonProxy proxy;
 *  }
 *
 *  public class CommonProxy {
 *      // Common or server stuff here that needs to be overridden on the client
 *  }
 *
 *  public class ClientProxy extends CommonProxy {
 *      // Override common stuff with client specific stuff here
 *  }
 * }
 * </pre>
 * @author cpw
 *
 */

 

I know it "hurts" the brains for those people who have strict semantic thinking (and most coders should be strictly semantic), but it does work and lots of people used it that way for years.

 

But yeah it felt good to finally convert my mods over to a more semantically correct implementation.