Choonster

Minecraft couldn't find your item model or blockstates file. Are you sure they're at src/main/resources/assets/lbm/models/item/blockbeef.json and src/main/resources/assets/lbm/blockstates/blockbeef.json respectively? Post a screenshot of one of these folders in File Explorer with the address bar visible. You should't be registering your models from a common class like ModBlocks or by calling ItemModelMesher#register. Instead, register them from a client-only class called from your client proxy by calling ModelLoader.setCustomModelResourceLocation/setCustomMeshDefinition (these take the same arguments as the two overloads of ItemModelMesher#register). Do this in preInit (if you register your Blocks and Items in preInit) or in ModelRegistryEvent (if you register your Blocks and Items in RegistryEvent.Register [this is the recommended way to register them]). You can read more about the registry events here.

Post the FML log (logs/fml-client-latest.log in the game directory), your JSON files (including their path relative to src/main/resources), the code where you register your models and the code that calls it (back to your @Mod class).

Your file isn't really following the format properly, you're treating the first part of the specifier as the mod name instead of the group ID. I explain each part of the specifier format in more detail here. Instead of Aroma1997s-Dimensional-World:1.9.4:1.2.0.6, use aroma1997:Aroma1997s-Dimensional-World:1.9.4-1.2.0.6. This will be mapped to <repositoryRoot>/aroma1997/Aroma1997s-Dimensional-World/1.9.4-1.2.0.6/Aroma1997s-Dimensional-World-1.9.4-1.2.0.6.jar.

Each specifier must be composed of either three or four parts separated by colons. The parts can contain any other character (that the OS allows in a file name). That exception means that you've got a specifier with less than three parts to it. Could you post the entire FML log and the mod list file that caused that error?

That's correct. Cables and machines acting on adjacent blocks generally use the EnumFacing they're attached to to ensure they get the right inventory, tank, energy storage, etc. If a block has an energy storage that can only be accessed from the bottom, you wouldn't expect a cable attached to the top or side to access it. If there's a block like the furnace that has different slot groups, you wouldn't expect a hopper on the side to put items into the bottom slot group.

Only expose it for the non-null EnumFacings that are appropriate for your block (e.g. only EnumFacing.DOWN), but also expose it for the null EnumFacing so it can be accessed by things that aren't directly interacting with a side of your block. Adjacent blocks like power cables or machines should only use the EnumFacing that they're attached to, they're not likely to use null. That's pretty much all there is to it.

Use IWailaDataAccessor#getTileEntity to get the TileEntity, then use either ICapabilityProvider#getCapability or your own method to get the Tesla/Forge energy storage from it. ICapabilityProvider defines an EnumFacing of null to represent "internal" or "self". Hwyla doesn't interact directly with any specific side of a block, so it uses null as the EnumFacing when getting capabilities. I recommend exposing your capabilities for the null EnumFacing (in addition to any existing non-null EnumFacings) and using this when getting them in the Hwyla HUD handlers.

If all of your energy-using blocks extend a common class or implement a common interface, you can pass this type as the second argument when calling IWailaRegistrar#register[Head/Body/Tail]Provider(IWailaDataProvider, Class). The IWailaDataProvider will be used for any block that extends/implements that type.

You're getting that error because the launcher is passing --modListFile as a JVM argument. On closer inspection, it looks like Mojang's launcher only lets you set the command-line options for the JVM but not for Minecraft. The only way to add command-line arguments for Minecraft seems to be to create a new version and specify them there. If you don't want to do this, you can save your file to one of the paths that FML automatically checks: mods/mod_list.json or mods/<minecraft_version>/mod_list.json.

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