DavidM

Post your code. 1.14 hasn’t changed much from 1.13.

If I understood correctly, I am pretty sure there is no way to achieve this. Block#onBlockActivated does 2 things: determine whether the block is “activatable” (indicated by the return value) and do stuff when the block is activated. Since these two things are packed together in one method, there is no way to prevent one from happening.

Your problem has nothing to do with this thread. Please make your own thread.

My apologies. Didn't realize the changes added to food and the new builder. In 1.14+ food is created with the food builder inside the Food class.

Please read the EAQ and post the appropiate log(s).

They are used to develop and distribute Forge. As a user of Forge you should not use such tasks. Check out how such behaviors are implemented in the player, then apply them to your entity via tasks. Users of Forge should not modify the Forge codebase at all, as doing so is fundamentally breaking Forge’s design, and will not work on any Forge versions. Even if Forge does not have hooks to features you wanted (which is not your case), it would be way better to submit a PR or use ASM.

Make your item class extend FoodItem.

Depending on how other mods implement their own form of messaging, this is probably impossible to do. A mod can simply pass on the message without using the default player chat, and there would be no way to distinguish this from a normal command execution. One way would be to disable all commands sent by the muted player, but this is probably not desired by the server owner.

1.14 mods will not work on Minecraft 1.15. Wait until the mod authors release versions for 1.15.

That is supposed to happen. Forge installers come in jars. If your computer associates the opening of jar files with other applications that are not Java, run the jar via command line or use JarFix.

1.8.9 is no longer supported on this forum. Update to a modern version of Minecraft to receive support.

Please note that you should not blindly reinstall Forge/Minecraft or allocate more RAM. Forge has logs, and the user should always act according to the log instead of guessing, as the latter can cause problems.

MoCreature's problem. Remove it and report to its author.

Remove mystical agriculture and report to its author.

Override Item#onItemRightClick.

Post log.

Your problem is not relevant to this thread. Please make your own thread.

In program design in languages like Java, try and catch should be avoided "at all costs". To illustrate, this: if (foo instanceof Bar) { Bar baz = (Bar) foo; } is much and always superior to this: try { Bar baz = (Bar) foo; } catch (ClassCatchException e) { // Do stuff. } both performance-wise and readability-wise. Unlike some dynamic languages nowadays which greatly encourage try-catch over anything else (*cough* python *cough*), try-catch carries special connotation in languages like Java, and should not be used to 1) silence an unexpected error 2) fix bad coding. Your usage of try and catch fall under both of those category, so in your case, there is no need for try and catch.

There is simply no need for try and catch. Try and catch should not be used as a fix for bad coding.

Climate Control's problem. Remove it and report to its author.

That is coremodding. It is not recommended on this forum. In fact, your problem does not need coremodding to solve.

It is not happening to you. Please make your own thread.

I misunderstood your question. Sorry. Since each character's width is obtained through IGlyph without regards to the font height of the FontRenderer, there is no built-in way to do this. You can however get the proportion of the altered height to the original height and apply that to the original string width. Basically something like: newWidth = MathHelper.ceil((double) originalWidth / originalHeight * newHeight);

Well... The method is called "getStringWidth". You can get the string height with FontRenderer::FONT_HEIGHT.