Jump to content

Recommended Posts

Posted

Hey everyone,

I am trying to implement ForgeEnergy as a second energy system in addtion to RF (and later also TELSA). I want to implement it in an item class wich extends the ItemArmor class. The page on ReadTheDocs about capabilities only describes it for TEs and ItemStacks... I am completly new to the capability system so I have absolutly no plan what to do.

Maybe someone can explain it to me in a few sentences and can even provide an example.

If it helps, the class I am talking about is this one: https://github.com/CyberdyneCC/SimplyJetpacks-2/blob/TomsonDev/src/main/java/tonius/simplyjetpacks/item/rewrite/ItemFluxpack.java

 

Tomson124

Posted (edited)

Item capabilities are handled differently to Entity/TileEntity capabilities because Items are singletons, i.e. there's only one instance per item type.

 

Instead of Item implementing ICapabilityProvider directly, it has a method (Item#initCapabilities) that creates and returns a separate ICapabilityProvider instance. ItemStack (which implements ICapabilityProvider) calls this method from its constructors and stores the returned ICapabilityProvider, using it in its own implementation of the interface.

 

You can see some examples of items with capabilities here, here, here, here and here.

 

These all use one of two ICapabilityProvider implementations: CapabilityProviderSimple (only implements ICapabilityProvider, doesn't save/load capability data) and CapabilityProviderSerializable (implements both ICapabilityProvider and INBTSerialializable so it saves/loads capability data).

Edited by Choonster
  • Like 1

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Posted
  On 4/15/2017 at 1:02 PM, Choonster said:

These all use one of two ICapabilityProvider implementations: CapabilityProviderSimple (only implements ICapabilityProvider, doesn't save/load capability data) and CapabilityProviderSerializable (implements both ICapabilityProvider and INBTSerialializable so it saves/loads capability data).

Expand  

Thank you.

If I am right, I don't have to make my own ICapabilityProviders if I just use the default implementation from ForgeEnergy, right? Or do I need to do the exchange between ForgeEnergy and RF in the CapabilityProvider Implementation?

Posted
  On 4/16/2017 at 11:55 AM, Tomson124 said:

Thank you.

If I am right, I don't have to make my own ICapabilityProviders if I just use the default implementation from ForgeEnergy, right? Or do I need to do the exchange between ForgeEnergy and RF in the CapabilityProvider Implementation?

Expand  

 

The ICapabilityProvider is responsible for storing the IEnergyStorage instance and providing it to external code. The IEnergyStorage implementation should be a completely separate class that stores the energy value and allows interaction with it through the IEnergyStorage methods.

 

You will need to create your own ICapabilityProvider implementation, Forge doesn't provide a stand-alone implementation for your use-case. The only implementations apart from vanilla classes are CapabilityDispatcher, which is designed to wrap multiple ICapabilityProviders into one; and FluidHandlerItemStackFluidHandlerItemStackSimple and FluidBucketWrapper, which implement IFluidHandlerItem in various ways.

 

If you want the RF IEnergyContainerItem and Forge IEnergyStorage interfaces to interact with the same energy value, you'll need to implement that yourself. There are two ways to do this:

  • Keep the current IEnergyContainerItem implementation and create an IEnergyStorage implementation that delegates to it
  • Use the default IEnergyStorage implementation (EnergyStorage) and change the IEnergyContainerItem implementation to delegate to it

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Posted

So to sum this up, I have to create my own CapabilityProvider which is then used in initCapabilities and I have to make a custom implementation of IEnergyStorage (like EnergyStorage) which also includes interaction with IEngeryContainerItem. But how do I tell the ForgeEnergy Capability that it has to use my custom IEnergyStorage implementation instead of the default one?

Posted
  On 4/16/2017 at 8:10 PM, Tomson124 said:

So to sum this up, I have to create my own CapabilityProvider which is then used in initCapabilities and I have to make a custom implementation of IEnergyStorage (like EnergyStorage) which also includes interaction with IEngeryContainerItem. But how do I tell the ForgeEnergy Capability that it has to use my custom IEnergyStorage implementation instead of the default one?

Expand  

 

Your ICapabilityProvider class should store an instance of this custom IEnergyStorage implementation and return it from ICapabilityProvider#getCapability when the Capability argument is CapabilityEnergy.ENERGY. This is what allows other mods to access your IEnergyStorage instance.

 

You can either create the IEnergyStorage instance in the ICapabilityProvider or create it in the Item#initCapabilities override and pass it to the ICapabilityProvider's constructor.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Posted (edited)

So I think I got it right, at least I did so until I ran into the first errors :/

It currently looks like this:

  Reveal hidden contents

 

Edited by Tomson124
Adjusted Spoilers
Posted

The RF API requires you to implement IEnergyContainerItem on an Item, it doesn't support capabilities.

 

Why does EnergyConversionStorage have an IEnergyStorage field?

 

If you're delegating the IEnergyStorage methods to the IEnergyContainerItem methods, EnergyConversionStorage should only implement IEnergyStorage without extending EnergyStorage. It should have an ItemStack field so it can call the IEnergyContainerItem methods on the Item.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Posted
  On 4/17/2017 at 7:57 AM, Choonster said:

The RF API requires you to implement IEnergyContainerItem on an Item, it doesn't support capabilities.

 

Why does EnergyConversionStorage have an IEnergyStorage field?

 

If you're delegating the IEnergyStorage methods to the IEnergyContainerItem methods, EnergyConversionStorage should only implement IEnergyStorage without extending EnergyStorage. It should have an ItemStack field so it can call the IEnergyContainerItem methods on the Item.

Expand  

The field was just a remaing piece of code from an earlier attempt...

 

I now changed the EnergyConversionStorage like you said:

  Reveal hidden contents

And I adjusted the initCapabilities accordingly:

@Override
public ICapabilityProvider initCapabilities(ItemStack stack, NBTTagCompound nbt) {
	return new CapabilityProviderEnergy<>(new EnergyConversionStorage(this, stack), CapabilityEnergy.ENERGY, null);
}

But when I start minecraft, or more specifically when I load a world it crashes with the error:

  Reveal hidden contents

 

Posted (edited)
  On 4/17/2017 at 12:30 PM, Tomson124 said:
java.lang.IllegalArgumentException: Can not deserialize to an instance that isn't the default implementation
	at net.minecraftforge.energy.CapabilityEnergy$1.readNBT(CapabilityEnergy.java:30)
	at net.minecraftforge.energy.CapabilityEnergy$1.readNBT(CapabilityEnergy.java:19)
	at net.minecraftforge.common.capabilities.Capability.readNBT(Capability.java:99)
	at tonius.simplyjetpacks.capability.CapabilityProviderEnergy.deserializeNBT(CapabilityProviderEnergy.java:49)

 

Expand  

 

The IStorage for the energy capability (used by Capability#readNBT) can only desrialise from NBT into an instance of EnergyStorage. This is a general rule for most capabilities: The IStorage is only guaranteed to work with the capability's default implementation. If you're using a custom implementation, you'll need to read from/write to NBT yourself (or use that implementation's methods if it implements INBTSerializable).

 

Since your IEnergyStorage implementation isn't actually storing the energy value itself, the ICapabilityProvider doesn't need to implement INBTSerializable (or ICapabilitySerializable, which is simply a combination of the two interfaces).

Edited by Choonster
  • Like 1

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Posted

Thanks :) Now it works... kind of...

I did the Forge Energy implementation because EnderIO items can only be charged by Forge Energy or TESLA, even after the implementation my fluxpacks don't charge EnderIO items I don't know why... Is there a way to check if a capability is loaded correctly?

 

And I assume that I still can use the "normal" IEnergyContainerItem methods for energy usage, as I delegated them to the Capability in my EnergyConversionStorage

Posted (edited)
  On 4/17/2017 at 1:04 PM, Tomson124 said:

Thanks :) Now it works... kind of...

I did the Forge Energy implementation because EnderIO items can only be charged by Forge Energy or TESLA, even after the implementation my fluxpacks don't charge EnderIO items I don't know why... Is there a way to check if a capability is loaded correctly?

Expand  

 

You've exposed the IEnergyStorage capability on your own item, which allows other mods to insert/extract energy from it; but are you accessing the IEnergyStorage capability on the items you're trying to charge?

 

 

  Quote

And I assume that I still can use the "normal" IEnergyContainerItem methods for energy usage, as I delegated them to the Capability in my EnergyConversionStorage

Expand  

 

Yes, they'll still work.

Edited by Choonster

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Posted
  On 4/17/2017 at 1:13 PM, Choonster said:

You've exposed the IEnergyStorage capability on your own item, which allows other mods to insert/extract energy from it; but are you accessing the IEnergyStorage capability on the items you're trying to charge?

Expand  

I assume that I don't do that, as I did no changes to the Item classe except overriding the initCapabilities... I thought I access the IEnergyStorage through the IEnergyContainerItem methods as they are delegated to the ForgeEnergy Capability, but probably I am understanding something wrong here.

How would I access the IEnergyStorage then? By using the ForgeEnergy methods? If so, how would I use them? just returning the IEnergyContainerITem method or calculating it again?

Posted
  On 4/17/2017 at 1:20 PM, Tomson124 said:

I assume that I don't do that, as I did no changes to the Item classe except overriding the initCapabilities... I thought I access the IEnergyStorage through the IEnergyContainerItem methods as they are delegated to the ForgeEnergy Capability, but probably I am understanding something wrong here.

How would I access the IEnergyStorage then? By using the ForgeEnergy methods? If so, how would I use them? just returning the IEnergyContainerITem method or calculating it again?

Expand  

 

All you've done is expose your own item's energy storage through the Forge Energy API, with an IEnergyStorage that calls the IEnergyContainerItem methods. This doesn't affect the energy stored in other items.

 

When you charge another item, you'll need to get its IEnergyStorage through the ItemStack's ICapabilityProvider methods and use IEnergyStorage#receiveEnergy to add energy to it. If it doesn't have one, check if it's an instance of IEnergyContainerItem and use the corresponding method to add energy to it. If it doesn't implement IEnergyContainerItem,

 

To simplify your code, you may want to create a method to get an IEnergyStorage from an ItemStack that does what I said above but returns an instance of EnergyConversionStorage if the item doesn't have an IEnergyStorage and implements IEnergyContainerItem. This way you can use IEnergyStorage#receiveEnergy regardless of which API the item supports.

 

You can use either API to extract energy from the Flux Pack (since you know they both use the same value).

  • Like 1

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Posted

Thank you so much it is working now :)

I wrote a small method which returns the IEnergyStorage of the item which should be charged:

public IEnergyStorage getIEnergyStorage(ItemStack chargeItem) {

		if (chargeItem.hasCapability(CapabilityEnergy.ENERGY, null)) {
			return chargeItem.getCapability(CapabilityEnergy.ENERGY, null);
		}
		else if (chargeItem.getItem() instanceof IEnergyContainerItem) {
			return new EnergyConversionStorage((IEnergyContainerItem) chargeItem.getItem(), chargeItem);
		}

		return null;
}

I am reffering to that method when charging the Items, and it works perfectly fine. Just have to see if it also works with Items that do not implement ForgeEnergy, as I am not sure about that part:

else if (chargeItem.getItem() instanceof IEnergyContainerItem) {
	return new EnergyConversionStorage((IEnergyContainerItem) chargeItem.getItem(), chargeItem);
}

But thank you a lot, I now also have a much better knowledge of Capabilites, too. Thank you for your patience with me ^^

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.