Leaderboard

I was reading this post and it feels like core modding is something bad. What are core mods? Are they bad? Edit: Nevermind. I found a post with information on it. http://www.minecraftforge.net/forum/topic/62870-what-is-a-coremod-and-what-are-it-advantages-and-disadvantages/ I don't know how to delete my post. Although I still wonder if there is a way to identify which mod out there is a coremod.

I'm trying to get the senses of a mob to modify them and EntityLiving.class.getDeclaredField("senses") works untill I'm in the dev enviroment, but as mod, i get java.lang.NoSuchFieldException. I know I should change the "senses" string into the field_xxxxxx name, but how I can know the field's name?

you need to shadow org.slf4 into your jar can you post your mod jar here

http://imperceptiblethoughts.com/shadow/

I think I will somehow manage to prevent weird looks on my Gens, by checking corners and altering terrain. The only issue I really have problems with is lag prevention. Look at for example how my Fortress Generator works(I hope it is on Github). Thanks for all the replies

No you're hybridizing the Forge and Mojang JSON formats. In the mojang version you have to specify all full variants. The point of Forge's json is to build the permutations for you. So you can't nest them like that, you'd need: { "variants": { "variant": { "frozen_dirt_grassy": {}, "dia_dim_dirt": {} }, "snowy": { "true": {}, "false": {} } } } If you have a '=' ANYWHERE in your variant name it detects it as a normal Mojang variant and doesn't build the permutations for you. So ya... read the docs, and either use the Forge version, or Mojang's version. Don't mix the two.

When it comes to block states, if one variant has an extra value all others do as well. So you technically have a "variant=dia_dim_dirt,snowy=true" and "variant=dia_dim_dirt,snowy=false" You just don't do anything with them. But your JSON model still needs to specify them.

That is not the proper variant syntax. http://mcforge.readthedocs.io/en/latest/blockstates/forgeBlockstates/

I don't think it is really that costly for performance really. You only need to update the "map" when someone places a block and only check the map when someone tries to break a block. And booleans can be stored as a bit map if you need to keep things compressed (cause you probably need to store this as world save data). EDIT: of course you should keep track of breakable blocks, not unbreakable, since I would expect that the player-placed blocks would be much less than the naturally generated ones.

That's pretty much your only option, yes.