Elyon

EntityLiving#setCustomNameTag seems to do what you want.

The ModID used is not all lowercase Vanilla code is obviously just being written into setDefaultDirection (have a look at BlockFurnace.java), with no thought or critical thinking. While being inspired by vanilla code is acceptable, you must keep in mind that vanilla code is not always perfect and can often times be written more concise or performant byte b0 in setDefaultDirection is the metadata, but the person talking in the video seems oblivious to this and just copies the code from BlockFurnace.java verbatim, save for variable names The person talking in the video seems to have little to no idea the reason for what they are actually doing most of the time, and as such doesn't explain it, either Vanilla code is also being copied into onBlockPlacedBy . This code in particular also suffers from terrible redundancies, but the person talking in the video probably has no idea about this, either If you're going to outright copy so much from the vanilla furnace anyway, you might as well extend BlockFurnace and just override the methods that differ This list is not exhaustive. I had a look at the next video in the series, and the quality of the code as well as the educational content does not improve.

I watched it. Do you want a list?

You should not use the video tutorial you linked. It is riddled with errors, bad practices and faulty logic.

Have a look at EntityLivingBase#onItemPickup , that seems to be related. If it is, either leave it as it is or @Override it for custom behaviour. EntityLivingBase#onItemPickup is called from within EntityLiving#onLivingUpdate , among other places. You will very likely want to @Override the latter.

Welcome to the forums.

No comment on the purpose of this mod. assets folder goes into src/main/resources, not src/main/java.

The method name shouldRender3DInInventory really says it all, though, doesn't it?

Lines 25 and 26 of this file don't have a hardcoded value, but instead a value based on the resolution of the buffered image. That seems modified to me

Metadata is only a nibble (4 bits), meaning 16 possible combinations. Only 0-15 are valid metadata values, any larger values will overflow or probably just get truncated to 4 bits.

I stripped everything from the main mod class to see if I could reproduce the issue. I was able to reproduce the issue without any code in any of my files, as well, so I dare say the contents of my mod class is irrelevant. Nevertheless, thank you for your input!

Using a very basic main mod class, I get warnings from the server thread, saying "Something's taking too long!". This happens in a development environment, and it happens seemingly at random every 5-15 seconds - much more if I fly around in creative, forcing chunks. Is this normal? It doesn't happen if I comment out the entire file. I am using Minecraft 1.7.10, as well as Forge 10.13.0.1160. Granted, these are not the largest of lag incidents, but I would still like to get to the root of the problem before I develop further EDIT: I have commented out everything in every java file I have written for the mod, including the main mod, and it still happens. Is this an issue with Minecraft, with Forge, or with my setup?

What happens when you press CTRL+F11 in Eclipse?

You should be calling registerBlock somewhere else. In preinit or - I believe I heard this was better - the constructor of your block? It is pretty basic Java knowledge not to write (most) code directly in your class, but write it in methods instead, which are then called. I suggest you start writing a few programs like Hello World, a banking simulator, a number guessing game etc. From there, you can move to modding. Or you could just jump into it - expect harsh remarks when your issue is not with your code but your basic understanding of programming, though. Either way, if you run into any Minecraft- or Forge-related issues, we are here to help. If you run into any programming issues in general, you could always throw me a PM and I will have a look at it I almost have zero experience working with Minecraft and even less with Forge, but I do consider myself a fairly experienced programmer.

It seems the mod in question in this topic is modifying the source code rather than the bytecode. I have had a look at modifying bytecode - it seemed approachable, but reflection is less of a hassle for now, with what I am trying to do. The information on coremods is absolutely valued and appreciated though, as many of the ideas I have for mods probably require coremods. Thank you!

Ah. Well, that makes sense - but it seems a dangerous and incompatible way to go about it. Nevertheless, depending on the circumstances I can see that being useful.

Use [ spoiler ] tags for posting error logs. It is generally bad practice to write comments in anything but English if you expect anyone else to have to look at your code. You are modifying vanilla code. I could be wrong, but I don't believe that will work. Additionally ... 1.6.4?

What is your intended behaviour?

Write down a design document, and start implementing things one at a time. We will be happy to help you if you have any issues.

Your block won't tick more often just because you run a loop 97 times. Besides, since you're not using l , all 97 iterations are identical, with no change to the state of the world between them - the iterations are moot. Also, you are comparing the light value of the block above your block.

What is l ? Where is this code run? Context would be nice, preferably the entire method or class

Small moves. Implement features and test them out one by one. What you are describing is a fairly large-scale mod. First, I suggest trying to just add +1 attack damage to a sword. Or just add a sword, first.

Currently, your texture namespace is "BOW". If I recall correctly, that gets noisily changed to the lowercase "bow", and as such will look for textures in assets/bow/textures/blocks/codePortal.png. You might as well change your texture namespace to "bow", as this happens regardless. Do yourself a favour and use a lowercase ModID anyway.

The error log should tell you what is wrong. I believe you can't have your texture namespace in anything but lowercase. Also, don't have your variable the same name and capitalisation as your class.

Why not use setBlockTextureName ?