Draco18s

http://www.learnjavaonline.org/

Use your IDE's refactor tools. Eclipse and IntelliJ should both be smart enough to update all of those references at once.

Solution: Not being a fucking idiot. Step 1: get the TE Step 2: check for null Step 3: do your stuff And bonus step: Not doing your stuff by manipulating NBT data. Use Capabilities.

Try checking out this blockstate file: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/resources/assets/harderores/blockstates/ore_limonite.json

public boolean isOpaqueCube(IBlockState state) is not the same as public boolean isOpaqueCube() Minecraft uses the former. You have the latter, it will never be called. This is why you put @Override on it and Eclipse tells you to remove it. Removing it isn't the solution, fixing the method signature is.

Define "didn't work" because your method signatures are wrong. @Override public boolean isOpaqueCube(IBlockState state) { return false; } @Override public boolean isFullCube(IBlockState state) { return false; }

Exception loading model for variant crmblk:S_S_1#normal for blockstate "crmblk:S_S_1" Show your blockstate file. It doesn't have a normal variant.

World#rand is already initialized. Just call nextInt on it. If you want your OWN seed, then create a Random in your main mod class, if you're really super desparate, you could subscribe to the world-load event and initialize that Random to the world's seed. Like...what's your use-case here?

There are now 2 hands. getHeldItem(EnumHand)

I've got no idea.

RayTraceResult Which you could have found by looking for the method that you were using, which likely didn't have its name changed.

That's what I figured, thought I'd ask.

Indeed

I haven't seen anyone using that event yet, so I don't know. It seems to me that it's an extra "early" spot in case you need to do stuff before other mods start tossing stuff in during preInit (why, I am not sure).

Yeah that event is called preInit.

File reading? You'll have to explain what it is you're doing. You should be able to do them in preInit just fine. That event is just fired before preInit because that's when it becomes available. You can still use it after the event

Its the salt that's not working correctly, but I'll give that a shot. Faux Edit: Nope, that doesn't help either. :\

I do not.

1.8 to 1.10 isn't that big of a jump. There's a few changes, but they're much easier to handle than the changes from 1.7 to 1.8. I highly recommend grabbing my EasyRegistry classes: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/EasyRegistry.java https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java (They are effectively CommonProxy and ClientProxy respectively, but handled by a library mod so several mods can utilize it without code duplication). The methods must be called during preInit or things won't work properly (because blocks need to be registered during preInit and renderers have to be registered during preInit).

The only way to "fix" your method is for there to be some way to know if your reflective method needs to create an ItemBlock or not. Because it is, then the block is assumed to have an inventory variant. That's why I have several different registration methods: Block, Item, Block with Item, Block with custom ItemBlock implementation, Block with custom ItemBlock and StateMapper, and Item with variants.

Basically if I call sendUpdates() (see below) every so often, I can be reasonably assured that the renderer will update, just not instantly. e.g. I can create a timing variable and call the method every 100 ticks and that results in the model changing within 5 seconds of when it should. private void sendUpdates() { markDirty(); worldObj.markBlockRangeForRenderUpdate(pos, pos); worldObj.notifyBlockUpdate(pos, getState(), getState(), 3); } If I call this method both after any time the TE changes its own contents (i.e. "smelting" an item into another item or consuming "fuel") and not every few seconds, then it also seems to work and pretty much instantly. However, when inserting items via a hopper the update is not always applied. That is, for inserts from the sides into the input slot, the update is instant. When inserting from the top (for fuel) the update never occurs (unless the fuel is consumed, which also sends an update, and that one works). If I try to delay all updates by 1 tick (so that all methods that would send a synchronization packet merely flip a boolean and then at the end of onUpdate if that boolean is true, call sendUpdates() and set the bool to false), then I still get the same behavior: inserting from the sides updates instantly (1 tick delay) inserting from the top never updates (and in fact, fuel consumption doesn't update this time either). I don't get it. http://pastebin.com/PKMvsdJu

Golly gee. public static void registerBlock(Block block) { GameRegistry.register(block); ItemBlock item = new ItemBlock(block); item.setRegistryName(block.getRegistryName()); GameRegistry.register(item); } Every single one of your blocks gets an item by default with no ability to say "no plz." Also, seriously? Reflection? Someone is trying to be a lazy fuck and complains when doing it the lazy way doesn't do what they want it to do. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/EasyRegistry.java https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/client/ClientEasyRegistry.java Usage https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/OresBase.java#L153

Override protected BlockStateContainer createBlockState()