Leaderboard

Forge Version: 1.14.4-28.1.0 Minecraft Version: 1.14.4 Downloads: Changelog (Direct) Installer (Direct) MDK (Direct) Intro: Whelp, the time has finally come, we are ready to do our first Recommended Build for 1.14.4! I want to thank everyone who has helped work on this and get it ready to go. This has been a long road, and I admit it has been a lot longer than I wanted it to be. Unfortunately, some things went wrong, some aspects took way longer than they should have. But we move forward. This is one of the biggest updates to Forge that we have ever done. Everything has been re-written from the ground up to hopefully provide us a platform that will last the next 10 years. Here is a basic overview: Versioning: You may have noticed, that our version number has changed a little bit. This was done to cleanup some redundant information and more directly link our versions to our source code. Our versions are now in the format `{MinecraftVersion}-{ForgeVersion}.{RBNumber}.{CommitCount}`. Launcher: In order for Forge to modify the game, we have to use a system that allows us to modify the java code as it is loaded. Initially we created a system called LegacyLauncher, which we shared with Mojang this allowed them to load their old versions into their new multi-profile launcher. However Java9 was released, and broke it. This is a fundamental change in how Java works and required us to re-design our basic loading system. We now have a new loader called ModLauncher that is designed with Java9+ in mind. So hopefully it works for the next decade! Installer: There are a lot of things that Forge does at startup, some of them is to apply our patches to vanilla's code, and transform vanilla's code to SRG names so that mods can work between minor Minecraft versions. This used to be done every time you started the game. We now do this once, at install time. This will save a bit of time while starting the game. Mods: We have changed quite a bit about the mod loading system, basic mod life cycle events are now run in parallel during Minecraft start. This should help decrease the load time. We have also removed a lot of cruft that has existed since the Risugami ModLoader days. Which will allow for cleaner, more flexible code. Overall the mod dev experience should be a lot better. Coremods: As much as I hate it, mods that edit bytecode will always be a thing. LegacyLauncher had a system that allowed any mod to edit anything in anyway they wished. This has caused a lot of issues due to modders implementing them wrong. The new ModLauncher system has a similar thing in place, however we have also released a new `Coremod` project that is intended to be the default system anyone who was making a Coremod. This new system uses Java's JavaScript engine to isolate the coremod from the rest of the game. Which should solve the most common issues in existing coremods. MDK: We have completely re-written all of our build tools. The new system treats Minecraft and other Mod dependencies as normal gradle dependencies. This means you no longer need to use special 'setupWorkspace' tasks before being able to build your mod. It also means that more systems should be able to support the work space as it is more in line with a basic java work space. We are currently targeting Gradle 4.9, however we have reports that it works all the way up to 5.5. Data Generators: Minecraft uses many data files, typically in the form of a json file. These are used for Blocks, Models, Textures, Recipes, Tags, and so much more. There are some people in the community who think that this is bad because it is difficult to create that many data files. No programmer in their right mind would do that by hand. Mojang themselves have used data generators from the beginning. We finally convinced them to expose this to modders, and Forge has enhanced them for use by Modders. We plan on adding even more features to this system, so feedback is highly appreciated. MCPConfig: Minecraft is released in obfuscated names, since our inception we have use MCP to provide us with the information needed to turn the game into something we can work with. This project started off as a set of python scripts and tools. But now with ForgeGradle and other projects the python is no longer necessary. So we have moved to just providing the Mapping data. This is now a public project which allows more community interaction, and feedback. These mappings are published to Forge's maven, and can be used in any project you wish. The only restriction is that you can't re-distribute and create derivative works. This is purely a technical necessity. These mappings are designed to be stable and compatible across Minecraft versions as best as possible. If multiple mappings were released that conflicted with each other it would cause nothing but a headache. We also worked with the community to design some naming standards, you can view more information on that on github. Mojang's Official Mappings: Starting with Snapshot 19w36a, Mojang has started providing their obfuscation logs. Which in theory is a great asset to modding as it will help people understand the code. However, Mojang released these mappings as All Rights Reserved, which means we can't actually use them in any way. So until they clarify things we will continue to work on Forge and use SRG names for our development/publication. The hope is that Mojang gives us some limited rights so that Modders can use these names in their own mod code, as well as publishing on places like Github. But until that happens I advise anyone who looks at these mappings to be very careful to not use them in anything you publish to anywhere. This include in jar files of your mod, or in the source code you publish to your SCM. We will keep you informed when we get updates from Legal. Fluids: Minecraft introduced the concept of 'waterlogged' for things like stairs, fences, and slabs. This introduced a formalized 'Fluid' system in Minecraft. This has caused us to need to re-write our Fluid system. We are trying to work with Mojang to make the vanilla system more flexible for modders. We will continue to develop this system as modders give feedback and make it as best as possible. Changelog: As Forge and all of it's tools have basically been re-written from scratch, the changelog is huge. You can view the raw changelog here. For more information on all the other tools in the Forge ecosystem you can view our Github. Don't worry, more detailed lists will return in future RB, this one is just to large too aggregate properly. Closing Remarks: This has been a long time coming, to those who are concerned about the time it took. I would like to remind you that now that our major re-write is over, we should be back to our same-day update schedule we have achieved for the last several Minecraft versions. These are major changes, so I would suggest people join our Discord and work with each other to update, find bugs, etc. I fully expect, as with any software release that there will be bugs. Please report them so that we can fix. Some of you may also have noticed, that there are only the direct downloads at the top of this page. This is because we have reached our Patreon goal and removed ad links. Nobody likes ads, but running Forge costs money. We also have a merch store. If anyone is interested. [/shameless promotion] Lets get back to work!

You are literally amazing, i'll try this when I get back to my code later tonight, thanks!

Override onBlockDestroyed(ItemStack, World, BlockState, BlockPos, LivingEntity) in your hammer's class. You will need a custom class that extends PickaxeItem to do this. In that method figure out which Direction the player is looking and break all the blocks perpendicular to that vector.

Remove the REGISTRYDUMP log marker from your run configurations in the minecraft > runs section of build.gradle and then re-run the genIntellijRuns or genEclipseRuns task to re-generate the IDE run configurations. For a less-permanent option, you can edit your IDE's run configurations directly instead.

For the love of christ. Why are you storing this field in your Item class? This isnt possible Items are singletons. They only exist once. You need to use the ItemStack's NBT data. Look at the ItemStack class for the method names to get and set the NBT. Should be something like getTag or getTagCompound and for set just replace get with set.

Yes? Should look something like this. clientSetupEvent(FMLClientSetupEvent event) RenderingRegistry.registerEntityRenderingHandler(YourEntity.class, manager -> new SpriteRenderer<YourEntity>(manager, Minecraft.getInstance().getItemRenderer());