coolAlias

There is no event that exactly fits your very specific needs, but you can use the current events to piece together working code. For example, you could probably listen to ChunkEvent.Load, get the biome for the coordinates being loaded and check against a custom Collection (Set would be good here) to see if that particular biome has been loaded before. If not, there you go: spawn entity and add biome to your set of previously loaded biomes. Disclaimer: I've never personally used ChunkEvent.Load before, so I am not 100% sure if it the world will know what biome exists at the chunk's coordinates at this point, but you should get the idea.

What he means by that is that you should register your packets only to the side on which it will be handled, not both (unless it can be handled on both, but 99% of the time it won't be).

It may make the code nominally cleaner, but it clutters up the project with redundant json files that could have all been handled by a single (and simple) IItemRenderer in the past. So no one knows of any way to disable the ModelBakery from trying to find a json for every single Item that is registered to the GameRegistry?

I have an item that is using a vanilla texture / model and I don't want to register a custom one; this works, but the ModelBakery still tries to load an item model based on my item's unlocalized name, spamming my console with messages like this: I made a little interface that I use in my item classes to register textures: @Override @SideOnly(Side.CLIENT) public void registerRenderer(ItemModelMesher mesher) { // textureName in this particular instance is a vanilla texture's name such as 'wooden_sword', but could also be mymodid:sometexture ModelBakery.addVariantName(this, textureName); mesher.register(this, 0, new ModelResourceLocation(textureName, "inventory")); } I had to add a 'variant name' even for a single item as well, otherwise it would give me the exact same message as above a second time which I suspect is when I register the item model myself with a different name than that found in the item registry. I wonder if there is a way to avoid having to do that, too. So basically I don't want Minecraft / Forge to load default models for me, because they are not correct and even when the default names are used, I still have to explicitly register model resource locations. I really dislike this new resource management system, probably because I'm not clever enough to see how it is an improvement in any way...

The lighting is already be taken care of for you by GuiContainer, so I wouldn't mess with it unless you know exactly what you are doing. Try removing that line. For rendering the model on the screen, you can actually use GuiInventory.func_147046_a (aka drawEntityOnScreen) - it can render any EntityLivingBase. It's possible you made some mistakes or changes copying this code that are affecting the lighting. The only other thing I can think of is that there is something in your InvisibleButton class that is causing the lighting issue. Post that class if the above two changes don't fix it for you.

If your game crashes, ALWAYS post the crash log.

I can't imagine that they changed the method from public to protected, but perhaps they did. Try using the recommended build 1230 (it's what I used for my test example). If that works, then the problem is Forge changed the method visibility, and you'll have to put it inside your block class. public class YourBlock extends Block { public YourBlock() { super(Material.rock); setBlockTextureName("stone"); } } If it still doesn't work using the recommended build, then the problem is somehow with your workspace, in which case you should re-run 'gradlew --refresh-dependencies setupDecompWorkspace'.

Then there is a problem with your workspace or Forge version or both. What version of Forge are you using?

Can you at least post your block class, then? You are clearly doing something wrong, which you can prove to yourself by trying this simple test: // in your main mod class, add these lines of code: public static Block test; @Mod.EventHandler public void preInit(FMLPreInitializationEvent event) { // I would have used Block(Material), but it is protected test = new BlockObsidian().setBlockName("test").setBlockTextureName("stone").setCreativeTab(CreativeTabs.tabBlock); GameRegistry.registerBlock(test, test.getUnlocalizedName()); } You will now have a 'tile.test.name' block in your creative tab that is textured like vanilla smooth stone. Ergo, the problem is somewhere specifically in your code and has nothing to do with lack of access to setBlockTextureName.

Well it has everything to do with it if you claim it has an empty constructor, but look at your own code: tBlock = new tBlock(Material.ground) // <-- that is NOT empty! .setBlockName("tBlock").setCreativeTab(CreativeTabs.tabBlock); I can tell you with 100% certainty that 'someBlock = new Block(Material.ground).setBlockTextureName("whatever")' works just fine. It is a public method, so whatever you are doing elsewhere in your code, it is wrong.

Lol, well it is, kind of. The condition is checked every single iteration, so think of it more like 'run as long as this condition is true' - once 'i' reaches 100, it WILL stop. You can have all sorts of conditions, initial states, etc., though a single incrementing integer is by far the most common. I highly recommend you find do some further reading / practice with for loops - they are very useful and one of the most basic features of probably every programming language.

And where is your 'tBlock' class? Is that even a class? Each word in a class name should begin with an uppercase letter, so 'TBlock' is a proper class name, but 'tBlock' is not. This is important for readability and to avoid ambiguity: does 'tBlock' refer to the class or the Block instance you created earlier (that's rhetorical)?

Block#setBlockTextureName is a public method, so if you are having trouble using it, the problem is likely a failure in Java syntax: post your code.

'Seen' and 'read carefully and then applied' are not equivalent The for loop in your code above doesn't work because the condition is 'i == 100', but when you start the loop i is 0, so your condition immediately fails and the loop exits. Try 'i < 100' as the condition.

For loop documentation. Now you CAN do for loops.

Yep, and for some strange reason Decorate.Pre and Decorate.Post fire on a different event bus (the normal one) than Decorate itself does (the terrain gen one), which explains why the OP was not getting anywhere with those.

So what exactly is it you are wanting to do, fly? KeyInputEvent fires once when a key is pressed and once when it is released, but not at all in between, so you'll need to set some variable somewhere like 'isBoosting' then add player.motionY += 0.15D or whatever each tick if it's true. You could of course just check if the key is still pressed using the keybinding instance, but that is client side only.

Can you show us what you have so far?

Correction: You want to do it on both. If you do it client-side-only then the server will go "hey buddy, you're over here" and rubber band you back. If you do it server-side-only the client will lag-behind and you'll rubber band the other way. The rubber-band effect typically happens if you use setPosition type methods on the client, but changing motion actually works just fine. You can still get an 'illegal stance' warning if player's total motion is too high, though, whether or not you set it on the server, the client, or both. Generally it is better to do things on both sides if possible, but in this case I don't think it really matters that much since the client is sending motion updates to the server anyway (see EntityClientPlayerMP#sendMotionUpdates).

You can also change the player's motionX/Y/Z fields directly on the server, but it is usually better to handle player motion on the client.

In your entity's onUpdate, you can also add something like this (in 1.7.x, at least): int x = MathHelper.floor_double(lastTickPosX); int y = MathHelper.floor_double(lastTickPosY); int z = MathHelper.floor_double(lastTickPosZ); worldObj.updateLightByType(EnumSkyBlock.Block, x, y, z); worldObj.setLightValue(EnumSkyBlock.Block, x, y, z, 15); worldObj.markBlockRangeForRenderUpdate(x, y, z, 12, 12, 12); It works for the most part, but like the others have said before me, it's far from ideal in the performance realm.

WorldServer#pendingTickListEntriesThisTick is a collection of all pending blocks needing updating, calling Block#updateTick on each one as their time comes. Now, this may not help directly, since the collection is cleared each time and there is no hook at any time during the process, but there is WorldServer#getPendingBlockUpdates(Chunk, boolean) which could give you what you need. I've never tried messing with it myself, so I can't say for sure. Alternatively, you could use ASM to patch Block#updateTick to fire an event, which you could then listen for and, if it's lava, check the surrounding area, preferably not too often.

100% agree. I mean, I guess that it's cool someone can come along and edit the .json file and bam, suddenly your sword is 10x bigger and renders backwards, but I much preferred handling everything directly in code. Blocks are a complete nightmare now, and certainly do not appear 'optimized' - arguably the exact opposite of optimized. I'm hoping that we will see a return to common sense sometime in the future, but I fear we will be stuck with this nonsense...

@SanAndreasP Yes, that's what I've done. I suspect that liteloader is doing something fishy, but I haven't downloaded it yet to try it myself. My mod has had almost an entire year with that particular code in place and this is the first crash report I've received that has just totally perplexed me as to the cause, since it seems to be completely unrelated to what my mod is doing (though it must be, I suppose). Anyway, I've solved the immediate issue by changing my instanceof checks to EntityPlayerMP instead of just EntityPlayer, though I am still curious as to how that became necessary in this case.

Here's what you need to know: 1. NBT tags can be made to store pretty much anything - use your IDE to check out NBTTagCompound's class methods and you should get a pretty good idea. 2. To access an 'Item' NBT, you need an ItemStack, because ItemStacks are what actually store the individual 'Item' data (such as current item damage). 3. ItemStack has class methods that allow you to create, modify and access a class field which stores an NBTTagCompound Thus, all you need to do is use your ItemStack instance (which is provided as a parameter in pretty much every single class method of Item), get the tag compound from it (or create one if it does not yet exist), then access and modify as needed whatever tags you have stored in there. It's as simple as that. If you don't understand how to use class methods and fields, you should take some time to brush up on Java basics. If you don't understand what we mean by nbt tags, just look at vanilla code for a second.