Choonster

Are you asking about the annotation-based config system or the recent addition of the config GUI compatible with it? If it's the former, create a class to hold your config options and annotate it with @Config. This class should have a static field for each option or sub-category. These fields can be one of the following types: Any primitive or primitive wrapper class or array of primitives/wrappers. This will be mapped to single value or list property of the corresponding type in the config file. String or String[]. This will be mapped to string or string list property. An enum. This will be mapped to a string property, but will throw an error if set to an invalid value. Map<String, T>, or any class that implements it. T may be any of the previous types. This will be mapped to a category containing a property for each key/value pair in the Map. Any class that directly extends Object. These will be mapped to a category containing a property for each of the class's non-static fields. The fields can be any of these types, including another class that directly extends Object. You can use the sub-annotations of @Config to set the lang key (for the config GUI), comment (used in the config file, also in the config GUI if there's no translation for langKey + ".tooltip"), value range (for numeric properties), property/category name and whether changing the property's value requires restarting Minecraft or the world. To use the config GUI with this system, all you need to do is subscribe to ConfigChangedEvent.OnConfigChangedEvent. If the event's mod ID is your mod ID, call ConfigManager.sync with your mod ID and Config.Type.INSTANCE. You can see a basic implementation of this here. The translations for this can be found here.

It's a command-line option, add it to the command-line options in your launcher profile. The path you use as the value of this option can either be an absolute path (in which case you need to prefix it with absolute:) or a path relative to the game directory.

I found the issue: Only the class for the top-level category (i.e. the one annotated with @Config) can have static fields, all other category classes must use non-static fields. I've fixed this and pushed the fix to a fork of your repository. You can view the changes and/or merge them here.

Use World Saved Data or World Capabilities to store data per-dimension or per-save.

Post your build.gradle file in a code block. I recommend against using the setupDevWorkspace or idea Gradle tasks. I suggest you follow this guide (specifically the "Terminal-free IntelliJ IDEA configuration" section) to set up your workspace.

I suggest using a series of if statements here, it will be easier to read than three nested ternary statements.

What exactly do you mean by "not working"?

Are you definitely using Forge? That's on line 2462 in my workspace. Which Forge version are you using? Are you definitely registering an instance of this class? Post your code.

Item#getNBTShareTag is called by PacketBuffer#writeItemStack, which is called by every packet that sends an ItemStack. The main one is SPacketSetSlot, which is sent by EntityPlayerMP#sendSlotContents (which implements IContainerListener#sendSlotContents); this is called by Container#detectAndSendChanges, which first checks if the current and previous ItemStack for the slot aren't equal using ItemStack.areItemStacksEqual. ItemStack.areItemStacksEqual checks the Item, metadata, NBT and capabilities of the two ItemStacks. Container#detectAndSendChanges is called on EntityPlayer#openContainer from various places, including EntityPlayerMP#onUpdate (called every tick). In general, you shouldn't need to manually send packets.

There are two main ways to sync item capability data: Override Item#getNBTShareTag, as suggested in this PR and various other issues. Register an IContainerListener for EntityPlayer#inventoryContainer on PlayerLoggedInEvent and PlayerEvent.Clone and for PlayerContainerEvent#getContainer on PlayerContainerEvent.Open. I use the latter in my mod. This class is responsible for registering the IContainerListener instances with each Container, this is the base class for the IContainerListener implementations. The implementations are here, here, here and here.

It does. It starts on line 1228 in my workspace.

That thread is about making a custom resource pack for vanilla, which doesn't let you change the culling properties of the block. When you're creating your own Block with Forge, you can either override Block#isOpaqueCube to return false to allow all adjacent block faces to be rendered; or you can override Block#doesSideBlockRendering to control this for each face of the block. Several other things depend on Block#isOpaqueCube, so it's probably best to override it even if you override Block#doesSideBlockRendering as well.

First you need to get the IBlockState at the current position, this will usually be supplied as an argument. If it's not, you'll usually have a World/IBlockAccess and a BlockPos to get it from. If you don't, you probably don't have access to the state or the value of the FACING property. Then you can get the value of the FACING property using IBlockState#getValue. You may find it helpful to read this introduction to block states.

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).

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? Yes, they'll still work.

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).

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.

"creativemd" is broken, report it to the author. Include the link to your FML log in the report. Edit: I misread, as diesieben07 pointed out below.

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.

Subscribe to TickEvent.PlayerTickEvent, it will be fired twice per tick per player per side: once at the start of the tick with TickEvent.Phase.START and once at the end of the tick with TickEvent.Phase.END.

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 FluidHandlerItemStack, FluidHandlerItemStackSimple 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

1.7.10 is no longer supported on this forum, you won't get any help with it.

You can find the FML log at logs/fml-client-latest.log in the game directory. Post it in a spoiler here or upload it to Gist/Pastebin and link it here.

Did you contact the Lucraft author(s) before posting here? Lucraft is using an invalid character (U+0131 LATIN SMALL LETTER DOTLESS I) in a property name, report this to the author along with the crash report.

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).