Leviathan143

Is the file visible in Eclipse's Package Explorer? If it isn't, try refreshing the folder or the project. In my experience, Eclipse seems to cache the project. If you edit a file in Eclipse, the cache is updated and you don't notice anything. If you edit or create a file in the project folder with an external tool, the cache is not updated and the cached version of the file is used when running or debugging, leading to unexpected results.

Sorry, but 1.7.10 is no longer supported on these forums. A moderator will lock this thread.

By default, .lang files do not support escape characters. If you want escape characters to be parsed, you need to add #PARSE_ESCAPES to your lang file. #PARSE_ESCAPES should be the only thing on its line.

I believe item/block model registration needs to be done during preinit, you are doing it during init.

I'd recommend putting the files through a json validator(I use http://jsonlint.com/). It should point out the location of the error, from that you can usually find the issue within a few seconds.

You will need to refresh the project. Also, delete from where?

As far as I am aware, gradle should do this when you run the eclipse task. At least I'm sure I've had it do that before. If it doesn't delete the old versions, try running this command: gradlew cleanEclipse eclipse That'll clean all the Eclipse specific gradle stuff and set it up again, which should fix your issue.

That isn't the correct method to use. Block#getItemDropped() returns the Item the Block should drop. You want Block#getDrops(), which returns a List<ItemStack>. Block#getDrops() will work for all blocks, whereas using solely Block#getItemDropped() will only work for blocks that drop 1 of a single item type that does not use metadata. The Random parameter can be used to randomly return a different result. Generally you pass an existing Random like World#rand, rather than creating a new one. For future reference, you need to give more information than "it doesn't work". There are a number of ways something can not work. In this case it could be dropping an incorrect item, dropping too few of the correct item, or not dropping anything at all. Note: In case you haven't seen it before, class#method() is shorthand for the non-static method method of the class class. Similarly, class#field is shorthand for the non-static field field of the class class.Static methods and fields use a similar shorthand, but the '#' is replaced with a '.'

@larsgerrits Unfortunately the ench tag only takes shorts. You can't put a ResourceLocation in. @The_Wabbit You will have to create your own LootFunction. The closest thing to what you want is EnchantRandomly, which picks a random enchantment from a list and applies it to the ItemStack.

Can you post your code please?

larsgerrits method does allow pack stacking. Minecraft#defaultResourcePack should be Minecraft#defaultResourcePacks, it's a List, you can add any IResourcePack anywhere in it. Reflection is the only way to access Minecraft#defaultResourcePacks as it's private and has no methods for manipulating it.

Access Transformers don't require a coremod. You create a text file in a certain place, define the access transformations you want to make in it, add some lines to your build.gradle and run gradle setupDecompWorkspace. As far as I am aware access transformers are part of ForgeGradle, there is no coremod involved.

There's one important thing Choonster forgot. EntityLiving#getLootTable is protected, so you'll need to use Java Reflection or Forge Access Transformers to call it.

If you look in ModelBoat, you'll find a field called noWater of type ModelRenderer . This is rendered on another renderpass to the rest of the model, preventing fluids rendering inside the boat.

No, you need to override getContainerItem(ItemStack stack) to return the container item for the passed in ItemStack & hasContainerItem(ItemStack stack) to return true if the passed in ItemStack has a container item.

Health is a float, not an int. You can deal 0.0625 damage(1/16th of a heart) if you want, or any other amount that can be expressed by a float.

Capabilities are the wrong way to modify the health system. Vanilla has the attribute system, which allows modification of various attributes(Max health, movement speed, attack damage, etc) of any mob. Using events and attributes will work much better than using capabilities and events. Using both attributes is more compatible as all the health related methods and most damage related methods use them, so they will work properly without any extra work. The few edge cases(Such as directly causing damage with EntityLivingBase#attackEntityFrom() ) can be handled by events.

Can we please see the code you are using to render the baked model?

That tutorial looks fine to me. The Forge RTD SimplImpl tutorial has nicer formatting IMO though.

You usually need to use packets with keybinds. Keybinds are only client-side, so if you want to affect something on the server you need to send a packet. Keybinds should be registered client-side only during preinit. You call Keybinding#isKeyDown() on the client whenever you want to know if the bound key/s are pressed. @abused_master This will not work on a dedicated server, you need to use packets to turn the jetpack on/off server-side.

You can do both actually. Forge supports using static methods as event listeners ever since this commit.

The ResourceLocation is wrong. You use which points to The texture is located at The correct ResourceLocation would be

The OP doesn't want to rotate it from the blockstate though. The OP just wants to rotate the texture.

This can be done in the json model. You can write it manually, but it's easier to use MCMC. What you're looking for is Rotation, which can be found under Faces.

GL has a number of capabilities that can be enabled or disabled. Before you actually render anything you may need to change several of these. After you are done rendering, you should disable any capabilities you enabled and enable any capabilities you disabled. Doing this prevents strange behaviour when something else is rendered. The call to enableLighting() is present after OP finishes rendering because they called disbleLighting() before they started rendering.