Choonster

I'd recommend creating an enum to describe the possible metal types, storing the metadata, name and colour of each one (as well as any other required properties). Create a single Item for each metal form (ingot, dust, plate, etc.), using the metadata to store the metal type. Create a singe Block per 16 metal types and metal form (ore, block, etc.), using a PropertyEnum to store the metal type. Look at BlockOldLog and BlockNewLog to see how vanilla does something similar (one enum across multiple Block s). Map each Block and Item (including ItemBlock ) to a single model with the appropriate texture, then register an IBlockColor / IItemColor implementation for each one that uses the colour from the metal type enum.

Use a string list/array getter for the property, then create a Set<String> from the String[] using ImmutableSet.copyOf .

Yes, mobs and dropped items are both entities. You could debug this by running the server from the development environment and putting some breakpoints in EntityTracker that check which thread the methods are being called from. Mods will be deobfuscated at runtime by FML, so there's no need to use dev builds like in older versions. Unfortunately EnderCore didn't work properly in the development environment last time I tried to use it. It looks like it's an issue with Tinkers Construct, so report it to them first.

Tinkers Construct is throwing an exception while trying to send a packet. Make sure you're using the latest version, then report this to the authors. In future, you can use Gist to post large logs.

Yes and yes I'm not too sure what's going wrong. Is the breakpoint definitely configured to suspend? If you set a breakpoint in the EntityGrotKokkie constructor, is it hit?

Do any other Minecraft classes exist? Are you sure your project is using 1.10.2?

Are you running Minecraft in debug mode? Are the entities being spawned anywhere?

Damage Indicators is broken. 1.7.10 is no longer supported here, your thread will probably be locked.

Yes, I pointed this out in the OP's thread on Minecraft Forum.

Again, breakpoints are a feature of your IDE. There is documentation available in your IDE or on the Internet, find it and read it.

Use your search engine of choice to find documentation/tutorials on how to use the debugger in your IDE.

That looks like it should work, you'll need to debug this yourself. Set a breakpoint in EntityGrotKokkie#getCanSpawnHere and run Minecraft in debug mode. When the breakpoint is hit, look at the entity's position in the debugger and then step through the method to see the result of each check. For debugging purposes, you may want to split each check onto its own line and assign the result to a local variable.

Potions like Poison and Regeneration only apply their effect every X ticks, determined by Potion#isReady . I suggest you look at this method to see the minimum duration required for the effect to be applied. Nausea requires the duration to be greater than 60 for the wobbling effect to start rendering. Potion effects should only be added on the server (when World#isRemote is false ). PlayerTickEvent and all other subclasses of TickEvent are fired twice per tick of their corresponding system: once at the start with Phase.START and once at the end with Phase.END . Always check the event's Phase to ensure you're not running your code twice per tick.

The EntityThrowable.func_189661_a method (a.k.a registerFixesThrowable in newer mappings) does absolutely nothing. Adding a static method will also do absolutely nothing unless you call it from somewhere.

Post your new code. I suspect you've negated the y-level check as well as the sky check.

It sounds like you're adding the potion effects on the client instead of the server, but I'd have to see more of your code (specifically the full method containing the call to utils.addPotionEffect ) to be sure. Do not use numeric IDs for potions or anything else, these are automatically assigned and can change between saves. Vanilla stores its Potion instances in the MobEffects class, use these.

That will allow the entity to spawn if the block it's in can see the sky and the y coordinate is less than 64. You want it to spawn when the block can't see the sky, so negate the return value of World#canBlockSeeSky .

The code where you tell Minecraft which models to use for your Item s. You should be calling ModelLoader.setCustomModelResourceLocation or ModelLoader.setCustomMeshDefinition in preInit on the client side only. You're telling Minecraft to use the tutorial:itemRegid model, which doesn't exist. To use the assets/rm/models/item/itemRegid.json model file, pass rm:itemRegid as the domain/path component of the ModelResourceLocation . I have an explanation of the model loading process and how model locations are mapped to model files here, you may find it useful. 1.11 will require all asset file names (and probably registry names) to be lowercase. I'd recommend using lowercase names now to avoid having to rename things when updating. In future when someone asks for the FML log, please post the logs/fml-client-latest.log file rather than the console output. This contains some additional information that's useful in some cases (though not required in this case).

Post your model registration code and the FML log.

ModelLoader methods must be called in preInit. Does your code do this? Post the FML log, it should say exactly what went wrong.

Have you set the module for each run configuration? I'd recommend following to set up your IDEA project.

Define "not working". Are there any errors? What actually happens?

For a block model to be rendered with transparency, you need to override Block#getBlockLayer to return CUTOUT , CUTOUT_MIPPED or TRANSLUCENT as appropriate. The Grey Ghost has an explanation of these layers here.

This does seem like a bug in Forge. It should probably be firing the event for both SHROOM and BIG_SHROOM and determining which mushroom types to generate based on this.

I don't know... getActualState would be more accurate and cleaner since I wouldn't need to deal with neighbors changing in my TileEntity, but do you think it's worth the overhead? How expensive is the check? If you're just calling ICapabilityProvider#hasCapability for each neighbouring TileEntity , it shouldn't be all that expensive.