Leaderboard

That's because installing forge is as follows: 1) Download installer 2) Run installer

Thanks for all the help, I've managed to resolve this by changing the blockstate to the following (the error was because I put "true" not true): { "multipart": [ { "when": { "type": "basic" }, "apply": { "model": "boe:energy_cell_centre_basic" } }, { "when": { "type": "basic", "north": true }, "apply": { "model": "boe:energy_cell_connection_basic" } }, { "when": { "type": "basic", "east": true }, "apply": { "model": "boe:energy_cell_connection_basic", "y": 90 } }, { "when": { "type": "basic", "south": true }, "apply": { "model": "boe:energy_cell_connection_basic", "y": 180 } }, { "when": { "type": "basic", "west": true }, "apply": { "model": "boe:energy_cell_connection_basic", "y": 270 } }, { "when": { "type": "basic", "up": true }, "apply": { "model": "boe:energy_cell_connection_basic", "x": 270 } }, { "when": { "type": "basic", "down": true }, "apply": { "model": "boe:energy_cell_connection_basic", "x": 90 } }, { "when": { "type": "advanced" }, "apply": { "model": "boe:energy_cell_centre_advanced" } }, { "when": { "type": "advanced", "north": true }, "apply": { "model": "boe:energy_cell_connection_advanced" } }, { "when": { "type": "advanced", "east": true }, "apply": { "model": "boe:energy_cell_connection_advanced", "y": 90 } }, { "when": { "type": "advanced", "south": true }, "apply": { "model": "boe:energy_cell_connection_advanced", "y": 180 } }, { "when": { "type": "advanced", "west": true }, "apply": { "model": "boe:energy_cell_connection_advanced", "y": 270 } }, { "when": { "type": "advanced", "up": true }, "apply": { "model": "boe:energy_cell_connection_advanced", "x": 270 } }, { "when": { "type": "advanced", "down": true }, "apply": { "model": "boe:energy_cell_connection_advanced", "x": 90 } } ] }

What tells you that the power is reset after one tick? Are the values different on the server and client? Edit: Actually this is probably because TEs are refreshed when the block state changes, which you do in your updateInventory method. To stop this from happening, you can override shouldRefresh in you TE to only return true if the block is different. Also, your getActualState method does nothing, it just sets the powered property to... the current value of the powered property. If you have a TE to store the power information of the block, it's best not to store that information in the block's state as well - that just leaves more likelihood of them becoming mismatched somehow. Instead you can simplify it by only setting the block's powered property in getActualState, by checking the TE's data. Then scrap the metadata methods (because the powered property doesn't need to be stored in the block as it's already stored in the TE), and the setBlockStates in the TE (because it's all calculated in getActualState whenever it's needed). On an unrelated note, your blocks are 'stringly typed'. You should use an enum for this purpose.

Are you registering your item models here? That is absolutely not how you should do it. 1. Use ModelLoader, not ItemModelMesher. 2. Model registration must be done during pre-init, not post-init. And not init, for that matter. Pre-init and pre-init only. That is if you are chosing to not use forge's registry events... 3. You must use proxies to access client from common classes. Your mod class is a common class, you can't call client-only methods from it, even if you do the side check first. Client-only methods and classes simply do not exist on the server so a check like the one you are performing will not save you. 4. Why are you using some getName() method to generate a resourcelocation of your items? Why can't you just use Item::getRegistryName as the first argument to your ModelResourceLocation? (see N6 for more clarification) 5. Your ItemGraphitePickaxe literally registers itself with the name "name". Not the name you've passed in it's constructor, but a literal "name" string. Same goes for it's unlocalized name. 6. You are also horribly misusing forge's registry system. You should not use GameRegistry.registerItem. Instead you should use Item::setRegistryName for your items and registering them via forge's registry events. Or at least with GameRegistry::register. Not registerItem, just register. 7. Register your recipes at one loading stage. At least just for consistency, of all the reasons there are. Why are some of your recipes registered in preinit and others in init? Bonus points for using Shaped/ShapelessOreRecipe instead of regular Shaped/Shapeless. Why are your java files and the crash report attachments of all the things? People do not want to download random files to their computers, there are plenty of online text hosting services out there. Use github to host your code and gists to link text files. Or at least pastebin or something like it. Edit: Oh, I just missed something. Your preinit method is using FMLInitializationEvent, not FMLPreInitializationEvent, and it is not annotated with EventHandler so it is not called. All your items are null, hence the crash.

Well if you put it like that sure, the client can load TE's data from an NBT but I ment from-disk loading getUpdatePacket and onDataPacket methods have existed for a while, but I can't tell you by how much. By default they do not do anything(onDataPacket is an empty method and getUpdatePacket returns null). They are needed for... erm, I would call it "on-demand tile entity changes". Basically if you look at PlayerChunkMapEntry::update method you will see that this packet gets sent in 2 cases(really it is more like 1 case with a sub-case ): 1. There has been a single change for the ChunkMapEntry involving a tileentity 2. There have been less than ForgeModContainer.clumpingThreshold(64) amount of block changes for the entry. Then every tile that got changed sends this packet. On the other hand, when the chunk data is fully sent to the client(a player loads a chunk) or there are a lot of changes within the chunk entry(>= 64) all tile data gets 'clumped' into a single NBT which is sent. That NBT is composed of TileEntity::getUpdateTag for each tile that gets synced that way. By default TileEntity::getUpdateTag writes tile's X/Y/Z, ID, extra data and all capabilities into the tag and handleUpdateTag simply invokes TileEntity::readFromNBT, thus deserializing all that data. As far as I can tell those are the only conditions for those two methods to be used, as getUpdateTag is only ever called while initializing a new SPacketChunkData packet. The changes are recorded to the chunk entry when the blockChanged method gets called and that gets called from ServerWorldEventHandler::notifyBlockUpdate which is a IWorldEventListener for the server. notifyBlockUpdate gets called when World::notifyBlockUpdate is called, respectively. That for example is called at World::addTileEntity, and under certain conditions when you invoke World::setBlockState. So long story short that keeps chunk data(blocks+tiles) in sync. You pretty much want to override both methods, although due to default implementation getUpdateTag and handleUpdateTag are optional and you might not need to override those. getUpdateTag/handleUpdateTag are for initial sync and big changes. getUpdatePacket/onDataPacket are for "on-demand" sync. You can still let vanilla handle everything. Just make getUpdatePacket return a packet that is your NBT data serialized and onDataPacket simply deserialize the data. After that you can still use World::notifyBlockUpdate/whatever you were using. I've had issues with that method being unreliable sometimes but I was unable to reliably debug it so i'd say that it should be safe to use it. A small disclamer: All that I have written above is something that I was able to trace with the debugger/code inspections, it might not actually be exactly the way things work. I also can't say anything about 1.10.x or lower as I've only started modding at 1.11 (all knowledge I have of previous versions is theoretical) and I do not know if those methods were changed at some point in the past.

Chiming in as one of the other leaders of Sponge, I've always believed that making heavy modifications to the game (as coremods sometimes do) would benefit from being viewed source, since often times debugging odd interactions between SpongeForge (and SpongeCommon as the larger part) have been often times difficult to say the least to work out where the issue lies. That being said, I strongly support the idea around coremods being viewed source for the sake of inter-coremod compatibility overall, as the goal with SpongeForge has always been about remaining compatible with as many mods as possible out of the box (even if the technological attempts at maintaining that compatibility is not as evident or thought up very fast). As @Zidane has mentioned, SpongeForge will be making the necessary changes in the very near future to abide by these requirements. As per usual, my goal with inter-mod compatibility is always to provide as much descriptive console spam error logs to help Sponge and/or the mod itself get a better fix and make the users happier overall.

I don't speak for the whole community but since I am a leader of Sponge, I'll throw my 2 cents in by first saying that yes, SpongeForge will be adjusted to comply. We find these changes to be a good-faith effort to make some wholesome changes to the ecosystem as an attempt at dealing with the elephant in the room: coremods. SpongeForge falls under a coremod which will not function at all without its core changes but, as Lex has mentioned above, we can simply make the core portion not function at all should the whole thing not be here and throw up a descriptive error to say why. Expect to see some changes land in the next couple of days (when someone gets some time) on Sponge's end to make this change.