Leaderboard

Update Regarding LTS System: Please read The Big Forge Update Earlier this year, 1.13 was announced and the snapshots started coming out, the update was relatively small, but enough to be a hurdle for mod developers. This combined with 1.12 stabilizing, and a few fundamental Java changes that broke modding in general, made the Forge team decide to use this opportunity and work on cleaning the years of technical debt that Forge had accrued. During this time, it was discovered that a lot of things needed updating. In fact, well, everything did. And so, it was done, a full rewrite of practically everything Forge related. This took a long time, longer than originally anticipated. But what’s the outcome of this you might ask? A lot. cpw’s mod launching system (ModLauncher) allows for parallel mod loading and support for more modern Java versions. (Considering the original was written to target Java 6). The Forge installer now runs tasks at install time once, rather than doing it every time you run the game. These alone provide dramatic reduction in launch times. ForgeGradle, the “devkit” for creating mods, has been rewritten and is faster at, well, everything. It also integrates much better with IDEs. What does that mean, you ask? Simple. Mods are nicer to make. (Also 100% less setupDecompWorkspace.) MCPConfig allows for much easier MCP updates, and is public source too, so people can see exactly what's going on between updates. In short: There was a lot of work to do. And now that it's done, future updates will be much, much smoother. 1.14 and 1.15 The 1.14 release came around, just in time for the rewrite to be finished, so it was time to get the ball rolling again. The bulk of the restructure work was done through 1.13's life, so all that remained was actually seeing how it was to update all of it, and it went pretty well. A lot of improved systems exist now that make developing for these modern versions far easier and just better in general. The 1.15 release was relatively simple, even if Mojang decided to restructure everything and make changes to how the rendering works. (Taking some of our systems in the process, don't worry, this is a good thing.) 1.15's rendering changes were mostly a refactor, and we expect 1.16 to be a large update to rendering. This plus 1.14 seeing growth is why we chose 1.14 to be a candidate for LTS. (More on that further down.) Hopefully this kind of restructure from them is a rare thing in the future, but we welcome the change, since it often brings improvement. Although the rendering changes may pose a tough hurdle for some, the update for most should be relatively straight-forward. Forge support and LTS Forge's support for Minecraft versions will try to follow a predictable cycle, assuming Mojang also follows a predictable cycle. We will always actively target the latest Minecraft version, as ever. We will now also deem a previous major Minecraft version as "LTS" (Long Term Support). The LTS version will receive support for modders and players alike, however all new features must target the latest version first, and then may be backported. An LTS version differs slightly from the latest version, in that any new features you may want to add to it, must target the latest version, only once it has been merged in, can it be backported. (The exception to this is if the feature is non-applicable to the latest version.) The Forge Team will also mostly be focusing on the latest. This is so the community has time to stabilize a bit and gives modpack developers some time to create something special. But still have Forge running full steam ahead. Late last year (Happy 2020!) a vote was held privately with many developers of various Minecraft projects to determine which version will be LTS: Should 1.12 remain LTS or should 1.14? A vast majority chose 1.14, and so, from now on we are dropping 1.12 from support, and 1.14 is now LTS. What does this mean? 1.15 is latest. It will get full support. 1.14 is LTS. It will also get support, and new features, but new features must be made for 1.15 first. 1.12 is no longer supported on this forum, no new features, and no more bugfixes. All other versions are not supported. This means if you come to us for help with those, we will ask you to update. This includes crashes/bugs. To keep with Mojang's history of releases, we expect 1.14 to stay LTS for 12-18 months, giving plenty of time for modders and pack developers alike. However, this may change depending on what surprises Mojang has in store for us. Finally… Thank you. Thank you to all the modders/developers, all the players, and especially to all the contributors. The Minecraft modding community would not be what it is without you. You are responsible for the striving ecosystem we have today. We hope this new year brings you all you desire, and we look forward to seeing what you create. And now time for some shameless plugging, if you like Forge, please consider supporting us. http://www.patreon.com/lexmanos - The Forge Team.

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!

Forge for 1.16.1 The first Forge build for 1.16.1 is now live thanks to the hard work of: covers, illy, jd, garrett, giga, and the rest of the forge crew. With their help we were also able to release the updates to MCPConfig for 1.16 and 1.16.1 the same day that vanilla did. The Nether Update has brought a lot of changes to many systems, and as with any update there are likely to be bugs. We are still evaluating and working on some of the systems like dimensions and trees to come up with the best system to allow for modders to integrate with vanilla’s new dimension system. We are also expecting Mojang to release a 1.16.2 fairly shortly and are prepared to work on updating to it as soon as they do. As with every update, there are bugs and other minor things to be expected. Please report them responsibly and have fun with the new version! Changes to the LTS There are a couple changes happening to the Long Term Support system originally introduced here. We are moving the LTS from 1.14.4 to 1.15.2 to reflect the community being more active and also changing how we chose what version the LTS will be to be more maintainable. We are now going to be supporting the latest (n) and second latest (n - 1) versions, with the reservation of potentially having the LTS being n - 2 if something is Mojang ends up really making a mess of a particular version. That being said we still will be providing critical fixes for all possible versions. Do not worry about 1.14 being instantly dropped while we are still working on updating 1.16, as we have a customary grace period for while everything is still in flux before we start strictly enforcing the LTS rules. New Team Members We are happy to announce we've added a few new members to the Forge team officially. These people have been a part of the community for a while and have been helping out a lot. The first two are new members of the 'Toolchain' team. Which is responsible for some of the backend tools, like the decompiler, update scripts, gradle and other internals. The others are joining our ever growing list of Triage team members. Who are responsible for managing the issues and pull requests on our github. They are the front line of bug reports and feature requests, treat them with respect and listen to what they tell you! Toolchain covers1624 JDLogic Triage AshersLab Curle OrionOnline pupnewfster

Forge Version: 31.1.0 Minecraft Version: 1.15.2 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Intro: This is the first recommended build for 1.15.x! This would of been out a few weeks ago, but Mojang decided to release 1.15.2, so we figured it'd be best to hold off until that version stabilized. As you may have read, we dropped 1.12 support a few weeks ago and now concentrate on 1.14.4 and 1.15.2 until 1.16 drops. 1.15.x brought many changes to the rendering engine and incorporated some parts of the new rendering engine known as "Blaze3D", but this release was still a lot faster than 1.14.x, thanks to the mod loading and launching rewrite we started in 1.13 being complete. Also thanks again through all the contributors for this release that helped to fix bugs and bring new features to forge. Changelog: New: Removed and cleaned up old code Remove third-party vecmath library in favor of using the new minecraft functionality Allow logos in the mod screen to be scaled differently Allow models to override be overridden when using OBJ models Make more Data Generator stuff usable by modders Add support for custom nether portal frame blocks Added new Click Input Event Added entity nameplate rendering event Added support for gui_light model option Re-implemented the ITeleporter interface to allow moders to control dimensional teleporting more easily Allow mods to more easily specify a custom texture for chests Add support for sending fluid stacks over the network more easily Add support for fluid overlay rendering for custom fluids Fixes: Fixed incorrect item lighting Fixed broken stairs and fence rendering Fixed keybindings not saving Fixed items being too small when dropped Fixed mod list screen Fixed capability data not being transferred when returning from the end Fixed incorrect warning screen caused by removed vanilla sounds Fixed game crash with modded entities Fixed bucket rendering Fixed crash when parsing custom obj models Fixed items not being colored correctly with custom colors Fixed items rendering too dark Fixed many other rendering related issues Fixed particles not rendering correctly due to wrong GL state Fixed incorrect item lighting Fixed crash when using certain fonts Fixed crash when building quads for rendering Fixed dyes tag not automatically finding new dyes Fixed Big Mushrooms not generating Fixed Raw Mouse Input Event Fixed fullbright lighting Fixed Fish Bucket not being usable by mods Fixed breaking overlay Fixed Widget Foreground Color not allowing pure black Fixed entities turning on a spot Fixed RenderType loosing it's mapping for registry replacements Fixed extended version of getLightValue not being used everywhere Fixed Wakeup Event not being called at the correct spot Fixed mod resources ordering Fixed Player Changed Dimension event providing the wrong dimension Fixed Keybinds modifier not working correctly Fixed Chunk Data Load Event not fireing Fixed small typos in forge config Fixed restoring blur mipmaps Fixed Right Click Block not being called on client and server Fixed crash on new java 8 versions in development environments Fixed a bunch of events not having the new rendering context Fixed Attacks/Punches not registering Fixed functionality for rails to have different maximum speeds Fixed registry desync, causing entities or sounds to be mixed up when connecting to a server Fixed compression system used by the installer to make downloads smaller.

What is this? This is a collection of common issues and recommendations for the Modder Support subforum. Instead of repeating these things over and over again, a link to this thread can be used instead. This post will be updated as needed. Suggestions either via PM to me or in a separate thread to keep this topic clean.

In honor of this thread, Im going to quickly summarise what I have gathered about creating villagers professions in 1.14.4 (forge 28.1.109) as there is not really that much information about that available right now. If anyone sees me doing something wrong or saying bs, just let me know and I will fix it. Specifically the reflection fix I mention below. EDIT: Make sure you check the first couple replies as well. Source for all of this can be found specifically in this commit: https://github.com/CAS-ual-TY/GunCus/commit/817848784868f4e8362d4270be6f8fc19863dc42 Tho I have done a few extra things which are unrelated so dont wonder. PointOfInterestType If you check out the vanilla class, you could come to the conclusion, that these are generally types of points of interest for villagers. You have the blocks in there that give the villagers their professions (eg. the Armorer type has a Blast Furnace passed to the constructor), you have a Bed type for sleeping, Unemployed type, Meeting type, etc. (But most importantly you have all the professions). You make your POITypes in the forge registry event for that (Register<PointOfInterestType>) (dont forget to set the registry name). Constructor is: String name, Set<BlockState> blockStates, int maxFreeTickets, SoundEvent workSound, int something. Name seems to just be the lower case name (eg. "fletcher", "leatherworker" etc.), the blockStates are just all block states of the interest block. There is a helper method for this (unfortunately its private, so youll have to figure something out for yourself) which I will post below. Next you have what it seems to be the amount of villagers that can use this at once. All vanilla professions have this at 1. Next you have the work sound. I just use vanilla sounds here, so youll have to check yourself if your sound event public static final instances are populated already at this point. And finally you have another integer which I have no idea about. All vanilla professions have this at 1 too. VillagerProfession Now we create the villager profession. This is the type of profession a villager can have (eg. Flether, Weapon Smith etc.). We use the forge registry event for this again (Register<VillagerProfession>) (again, dont forget to set registry name). Constructor: String nameIn, PointOfInterestType pointOfInterestIn, ImmutableSet<Item> noIdea, ImmutableSet<Block> noIdeaAgain. The name is the lowercase name again (eg. "fisherman", "mason" etc.). This is needed for the texture and translation (see below). Next you pass the PointOfInterestType for this profession (read above that this is). Since P comes before V, these are already registered and object holders are populated, so you can just pass your static fields here. The 2 sets that come now I havent really looked into because all vanilla professions just pass an empty set here (ImmutableSet.of()). Profession Texture Location assets\MOD_ID\textures\entity\villager\profession\PROFESSION_NAME.png You just have to put the texture in the appropriate location. Rendering is done automatically. If you want to play around with the model a bit (eg. change the hat), check out the vanilla villagers. You can do that by adding extra PROFESSION_NAME.png.mcmeta files to the same location. Just check out vanilla for examples: assets\minecraft\textures\entity\villager\profession Profession Trading GUI Title Translation entity.minecraft.villager.MOD_ID.PROFESSION_NAME This is the key for your .lang file. Translate this to set the title of the trading GUI. At first I was confused, because there is 2 mod ids in there (mine and minecraft). But it makes sense because the villager is part of minecraft, but the professions part of *MOD_ID*. So ye. Adding Trades to Professions Forge has 2 events for that: VillagerTradesEvent, WandererTradesEvent. You can add trades to any profession here. 1st one allows to add trades to every profession and their levels (1-5, novice to master or smth). 2nd one allows to add generic or rare trades to the wanderer. I highly suggest checking out the vanilla trades to have an idea what (or how much) to set here for all the params: https://minecraft.gamepedia.com/Trading#Armorer - To do the first: Call event.getTrades().get(level).add(some_ITrade_instance_or_lamda_action). To do this for the profession you want, check if event.getType() == ModVillagerProfessions.YOUR_PROFESSION (this event gets called once for every profession). - To do the second: Just check out the event class. Pretty simple. Easy getters easy life I have made a helper class for this to allow easy trade creation. I will post it below. Example usage of this helper class (adds a trade to level 1; You can buy 2-4 (picked randomly per villager, but steady) acacia fences for 12 emeralds): event.getTrades().get(1).add(new RandomTradeBuilder(8, 10, 0.05F).setEmeraldPrice(12).setForSale(Items.ACACIA_FENCE, 2, 4).build()); Final Reflection Fix Im just going to quote what I have written on forge discord. See below for fix (in helper section, call for every POIType in your init): ------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------ Helper Stuff (use this as you please) Get all Block States static Set<BlockState> getAllStates(Block block) { return ImmutableSet.copyOf(block.getStateContainer().getValidStates()); } Easy/Random Trades Builder package here import java.util.Random; import java.util.function.Function; import net.minecraft.entity.merchant.villager.VillagerTrades.ITrade; import net.minecraft.item.Item; import net.minecraft.item.ItemStack; import net.minecraft.item.Items; import net.minecraft.item.MerchantOffer; public class RandomTradeBuilder { protected Function<Random, ItemStack> price; protected Function<Random, ItemStack> price2; protected Function<Random, ItemStack> forSale; protected final int maxTrades; protected final int xp; protected final float priceMult; public RandomTradeBuilder(int maxTrades, int xp, float priceMult) { this.price = null; this.price2 = (random) -> ItemStack.EMPTY; this.forSale = null; this.maxTrades = maxTrades; this.xp = xp; this.priceMult = priceMult; } public RandomTradeBuilder setPrice(Function<Random, ItemStack> price) { this.price = price; return this; } public RandomTradeBuilder setPrice(Item item, int min, int max) { return this.setPrice(RandomTradeBuilder.createFunction(item, min, max)); } public RandomTradeBuilder setPrice2(Function<Random, ItemStack> price2) { this.price2 = price2; return this; } public RandomTradeBuilder setPrice2(Item item, int min, int max) { return this.setPrice2(RandomTradeBuilder.createFunction(item, min, max)); } public RandomTradeBuilder setForSale(Function<Random, ItemStack> forSale) { this.forSale = forSale; return this; } public RandomTradeBuilder setForSale(Item item, int min, int max) { return this.setForSale(RandomTradeBuilder.createFunction(item, min, max)); } public RandomTradeBuilder setEmeraldPrice(int emeralds) { return this.setPrice((random) -> new ItemStack(Items.EMERALD, emeralds)); } public RandomTradeBuilder setEmeraldPriceFor(int emeralds, Item item, int amt) { this.setEmeraldPrice(emeralds); return this.setForSale((random) -> new ItemStack(item, amt)); } public RandomTradeBuilder setEmeraldPriceFor(int emeralds, Item item) { return this.setEmeraldPriceFor(emeralds, item, 1); } public RandomTradeBuilder setEmeraldPrice(int min, int max) { return this.setPrice(Items.EMERALD, min, max); } public RandomTradeBuilder setEmeraldPriceFor(int min, int max, Item item, int amt) { this.setEmeraldPrice(min, max); return this.setForSale((random) -> new ItemStack(item, amt)); } public RandomTradeBuilder setEmeraldPriceFor(int min, int max, Item item) { return this.setEmeraldPriceFor(min, max, item, 1); } public boolean canBuild() { return this.price != null && this.forSale != null; } public ITrade build() { return (entity, random) -> !this.canBuild() ? null : new MerchantOffer(this.price.apply(random), this.price2.apply(random), this.forSale.apply(random), this.maxTrades, this.xp, this.priceMult); } public static Function<Random, ItemStack> createFunction(Item item, int min, int max) { return (random) -> new ItemStack(item, random.nextInt(max) + min); } } Reflection Fix private static Method blockStatesInjector; static { try { blockStatesInjector = PointOfInterestType.class.getDeclaredMethod("func_221052_a", PointOfInterestType.class); blockStatesInjector.setAccessible(true); } catch (NoSuchMethodException | SecurityException e) { e.printStackTrace(); } } public static void fixPOITypeBlockStates(PointOfInterestType poiType) { try { blockStatesInjector.invoke(null, poiType); } catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException e) { e.printStackTrace(); } }

This solved the problem for me First register your entity with custom client factory like this .setCustomClientFactory((spawnEntity, world) -> new ExempleEntity(world)) And then use NetworkHooks#getEntitySpawningPacket to get Entity Spawning Packet @Override public IPacket<?> createSpawnPacket() { return NetworkHooks.getEntitySpawningPacket(this); } that's it ?

As anyone who's started porting to 1.14.2 is probably aware by now, container and GUI creation has changed... quite a bit. To summarise what I've gathered so far: Containers (more accurately: container types) are now registry objects and must be registered in a RegistryEvent.Register<ContainerType<?>> event handler. Container objects themselves must provide a constructor of the form MyContainer(int windowId, PlayerInventory inv, PacketBuffer extraData). This will be used to instantiate the client-side container. Your container's constructor must call the super Container constructor with your registered container type and the windowId parameter (this int parameter is not used in any other way - just pass it along to the superclass constructor and forget about it) You can use the extraData parameter to pass... extra data! to your container. This PacketBuffer parameter is built server-side when you call NetworkHooks.openGui(); see below. Typically, your container will have (at least) two constructors; the factory constructor described above which is used for client-side construction, and a constructor taking whatever parameters you need to pass to set up your server-side container object. Container-based GUI's are now associated with a container type with the ScreenManager.registerFactory() method, which takes a registered ContainerType and a ScreenManager.IFactory to construct your GUI object. Call that in your client-side init code. ExtensionPoint.GUIFACTORY is gone, no longer needed, as is the old IGuiHandler system. ScreenManager does all that work now. While there must be a one-to-one mapping from ContainerType to each GUI, also remember that you can happily re-use the same container class for multiple container types if you need to; just pass the container type as a parameter to your constructor and up along to the Container constructor. All container-based GUI's must provide a constructor taking(T, PlayerInventory, ITextComponent), where the generic T is the type of your container object. Container-based GUI objects are now generified (is that a word?) on the container's class, e.g. public class MyGui extends ContainerScreen<MyContainer> IInteractionObject is gone; instead your tile entity should implement INamedContainerProvider: the createMenu() method is where you create and return your server-side container object. (I believe getDisplayName() is only used to initialize the title field of your GUI object). To open a container-based GUI on the tile entity (server-side), call NetworkHooks.OpenGui(player, myTileEntity, pos) or player.openContainer(myTileEntity) That would typically be called from Block#onBlockActivated() If you want to create a container-based GUI for an item, create a class implementing INamedContainerProvider (a static inner class of the item makes sense, or perhaps an anonymous implementation), implementing createMenu() and getDisplayName() to create and return the container object as above. That would typically be called as something like NetworkHooks.OpenGui(player, new MyItemContainerProvider(stack), pos) or player.openContainer(new MyItemContainerProvider(stack)) from Item#onItemRightClick() or Item#onItemUse() player.openContainer() can be used if you have no need to pass any extra data to the client, e.g. your GUI is just displaying container slots, like a chest. But if your client GUI needs access to the client-side tile entity, use NetworkHooks.openGui() and pass at least the tile entity's blockpos so the client container can get the GUI object. Syncing any necessary TE data to the client-side TE needs to be done separately by whatever means you choose. Note that NetworkHooks.openGui() has a couple of variants to allow extra data to be passed to the client-side container object: a simple pos argument if you just need to pass the blockpos of your TE, or a more flexible Consumer<PacketBuffer> if you have more complex data to pass to the client. The simple pos variant just calls the full-blooded Consumer<PacketBuffer> variant in any case. It's this packet buffer that is received by the client-side container constructor.

You need to set the render layer using RenderTypeLookup#setRenderLayer within your FMLClientSetupEvent to make blocks transparent. It takes in two parameters: the block and the RenderType. The RenderTypes are as follows: Solid - field_228615_R_ Cutout Mipped - field_228616_S_ Cutout - field_228617_T_ Translucent - field_228618_U_ Translucent (No Crumbling) - field_228619_V_ Leash - field_228620_W_ Water Mask - field_228621_X_ Glint - field_228622_Y_ Entity Glint - field_228623_Z_ Lightning - field_228624_aa_ What you are looking for is either cutout mipped or cutout so use either RenderType#field_228616_S_ or RenderType#field_228617_T_ to accomplish this.

One way is to use a method that always returns null but suppresses IDEA's warnings, like this: method, usage The newer way is to use the DeferredRegister system that was introduced relatively recently. I've started updating to this, but it doesn't look like I've pushed any of my changes to GitHub.

I want to say thank you to everyone here who helps with modder support. Just having you around is really encouraging, so I always know there's someone to turn to if I get myself stuck. Three times now I've solved a problem I thought I couldn't fix on my own while writing a post to ask for help, and without y'all I'd probably just have given up. So, thank you for helping, even if you didn't know you were

and because you use MCreator you got this far and are now bitching because you can't get something to work and you feel we should just do the work for you when you haven't even put in the effort to learn Java. There is a reason we dislike MCreator and you are only reinforcing that opinion. Learn Java.

I'm trying to update my mod from 1.51.1 to 1.15.2 but I'm getting this error: Could not find net.minecraftforge:forge:1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1. Searched in the following locations: - file:/C:/Gradle/caches/forge_gradle/bundeled_repo/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.pom - file:/C:/Gradle/caches/forge_gradle/bundeled_repo/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.jar - https://files.minecraftforge.net/maven/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.pom - https://files.minecraftforge.net/maven/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.jar - https://libraries.minecraft.net/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.jar - https://repo.maven.apache.org/maven2/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.pom - https://repo.maven.apache.org/maven2/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.jar Possible solution: - Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html I've tried several mappings including: 20190719-1.14.3 which is included in the mdk download. I've also tried a fresh project from the mdk download and I get the same error (only with the 20190719-1.14.3 mappings of course). Dropping it back to 1.15.1 (1.15.1-30.0.51) works again and I can change mappings, etc so my gradle setup is working otherwise, just not for 1.15.2 versions (the 1.14.4 version of my mod is also working fine with gradle).

This appears to be fixed with version 2020.1.

Be honest with me... did you edit your error to replace 1.7.10 with 1.14.3 so your thread wouldn't be locked?

I would just add onto this with make sure you take breaks and get sleep before you post here too because honestly we all know that really helps you spot the logic mistakes.

Fun. /me leaves to go play with his Linux

That checks distribution (dedicated server vs client). Client in this context still includes the integrated server, which is not what you want. @ultra_reemun Please refer to the documentation article about sides. Also note that tick events always fire twice per tick, you must check TickEvent#phase.

Hello everyone ! Let me present you my Masks mod for Minecraft Forge ! This mod lets you craft masks that give you the powers of different Minecraft mobs. To craft a mask, you’ll need a life essence. This item has a 1% chance of being dropped every time you kill a mob. You can use a life essence to craft a raw clay mask: Cook it to get a stringless clay mask, add a couple strings to it, and voilà, you get a nice mask to wear! Now, this mask looks nice, but it gets even better when you use it to craft monster masks. Here is a list of the masks you can craft so far, and what they can do: Passive animal masks Neutral animal masks Sea mobs masks Overworld monster masks Nether monster masks That’s all there is for now, but I plan on adding more masks. Please note that the config file lets you: -enable and disable shaders for each mask -change the life essence drop rate -change the xp cost of some of the mask powers DOWNLOAD LINK (Mediafire)

This is why you always need to post your complete code and not just snippets of what you think is important. And what's especially bad is that you made those snippets look like they are the complete thing. DO NOT DO THIS. It doesn't help anything.

1.15 has been more challenging then previously expected. Instead of just being adding bees, and fixing bugs as reported by Mojang. They decided to take this release to re-write most of the rendering engine. Unfortunately, they also took the rendering guy from the Forge team. And my weakest point has always been, you guessed it, rendering. So it's being quite difficult to sort through all the changes, and update our massive changes to reflect the new stuff. gigaherz, tterrag, and unneon are trying to get up to speed and sort through all the rendering changes. So far, we've processed 512 out of the 520 patch files Forge does. As well as brought the compile errors down from >1400, to 161. So, progress is being made. Unfortunately, not publicly as before we get it compiling the repo we're working in contains the full MC decompiled codebase. And we do not have legal authority to redistribute that, so we're working on it privately. Hopefully, we'll have a build working and published here shortly, we're hoping that it won't be as broken as it could be. We'll keep you informed when there is something to inform. As for the mapping data, we've already answered this, Mojang's release under the license you quoted does NOTHING to help us and only helps those who do not respect their license {Hacks/pirate clients/malware}. We are STILL holding out hope that Mojang's lawyers will come back with a new license that actually allows us to use this data.

While you can do that, there is a much simpler way to just get the block position "below": BlockPos#down(). There are many more helper methods like this on the BlockPos class which make your code more understandable.

Some recent version seems to have changed the default way IntelliJ compiles Gradle project. It used to be that it still used the IntelliJ build system, which puts resources and classes in one folder. Now "Delegate to gradle" seems to be the default, and gradle puts resources and classes in two separate folders. Make sure to set IntelliJ to not delegate to Gradle (https://www.jetbrains.com/help/idea/work-with-gradle-projects.html#delegate_build_actions).

I found the solution, you need a music in MONO not in STEREO ... @kaydogz

We will be making an announcement about it when we can. The current state is that it means almost nothing for us. As the license doesn't allow for us to actually USE this information. We are waiting to hear back from Mojang's legal team {This is all stuff they could of answered before the public announcement by asking us, but whatever} Keep an eye on Github/Twitter and we'll keep you updated.

I wouldn't say I know enough Java to pr Forge, so I will instead make my suggestion here. I think it would be useful if there was a ShieldBlockEvent of some sort, which is fired when an an attack is blocked by a shield. I would assume you could get the DamageSource of the attack along with the shield item from the event.

com.google.common.base.Supplier is not java.util.function.Supplier.

Code-Style The concept of a "common proxy" does not make sense. The whole point of @SidedProxy is to abstract over client specific and server specific behavior, the opposite of "common". Common code should go in your main mod class. Use @Override when you intend to override methods. This helps tremendously when updating your code for new versions of Minecraft, but in general is good practice. Read this Stack Overflow answer for an explanation. Using an interface (usually called IHasModel) on your Item and/or Block classes to denote that they are capable of registering a model is an anti-pattern and not necessary. All items require a model to be registered for them and usually no type-specific information from the item is needed, only the registry name, which is accessible for all items by default. Do not abuse inheritance for code-reuse. This often manifests in classes like ItemBase, BaseItem or ItemExampleMod. Using this pattern prevents you from extending other essential classes, such as ItemFood and in that case requires code duplication. Prefer composition or utility methods instead to reuse code.

Problematic Code Please use the registry events to register your blocks, items and other registry entries. Use ModelLoader.setCustomModelResourceLocation in ModelRegistryEvent to register your item models. Do not use the ItemModelMesher. Do not use methods that are deprecated in Forge or vanilla Minecraft. Usually there will be an explanatory method next to the method explaining what to use instead. There is an exception for methods in the Block class, these may be overridden. Instead of calling them, use the one in IBlockState resp. it's supertypes. Do not use ITileEntityProvider or BlockContainer. These classes are legacy vanilla code. To add a TileEntity to your Block, override hasTileEntity and createTileEntity in your Block class. Do not use IInventory. Use the capability API with IItemHandler. Do not reach across logical sides. This will cause subtle and not-so-subtle issues that may occur randomly and very rarely. Read and understand the documentation about sides to understand why this is a bad idea. Do not use the unlocalized names for things other than displaying the name of a block/item. If you want to access the registry name for a registry entry, use IForgeRegistryEntry::getRegistryName. Do not use numerical IDs for registry entries. They can and will change. Use the static references in e.g. the Items class or use textual IDs (e.g. minecraft:stone) if you need dynamic references. Any IForgeRegistryEntry (commonly items and blocks) is singleton-like. That means that there is only once instance of your block class. There is not a new Block instance for every position in the world and there is not a new Item instance for every ItemStack. This means that you cannot store position-related things as instance fields in your block class, etc. You must use a TileEntity resp. the NBT data on ItemStack. Unlocalized names, TileEntity registration names and enum entries added using EnumHelper should contain your ModID to avoid collisions between mods. Note: This also applies to the unlocalized name for entities (set by EntityEntryBuilder::name resp. the entityName parameter of EntityRegistry.registerModEntity). A TileEntity class must have a no-argument constructor. As a general recommendation a TileEntity should not have more than this one constructor, to avoid confusion. An ItemStack variable should never be null and all of vanilla and Forge code expects this to be the case. Use ItemStack.EMPTY instead of null and ItemStack::isEmpty to check for empty stacks. Do not compare against ItemStack.EMPTY. Registry names and asset file names must be completely lowercase. Do not create registry entries (anything implementing IForgeRegistryEntry, like blocks and items) in a static initializer. Use the proper events. Do not access client-only code from common code, use the @SidedProxy system. See the documentation about sides (in particular the section about @SidedProxy) for more information. Do not implement IMessage and IMessageHandler on the same class. It does not make logical sense and leads to confusion and hard to trace bugs. Handle exceptions properly. Do not avoid a game crash at all costs, sometimes it is okay to crash the game. Read this article for more information.

Watch this: https://www.youtube.com/watch?v=FyCYva9DhsI

Thanks for the amazing work, it was such a fast release!

Forge 1.16.1 32.0.7 just dropped and that *does* use vertical biome detection (visible in the nether from the vanilla F3 screen). Doubt many people know much about this right now... Time to investigate...

Use Entity#getEntityId and World#getEntityByID instead of UUIDs for syncing.

Ah sorry! I somehow forgot to push to remote for quite a while. Anyways, here is the blockstate file. (Note that by item_pipe I meant the model of the pipe that transfers item, as opposed to the item model of a pipe) In addition, SixWayBlock can handles almost everything about the blockstate and collision boxes of a block that can connect to 6 directions (i.e. pipes). Check out the vanilla chorus plant for usage.

There is no reason to use the marker. It does not save you from accessing client only code. Take the following scenario: Class A accesses Minecraft (a client only class). So you mark Class A with @OnlyIn. But now Class A is client only as well, and you have just pushed the problem to a different place. The proper way to access dist-only classes is (imho) @EventBusSubscriber with a Dist parameter. There is DistExecutor, but it's usage requires intricate knowledge of how javac compiles lambdas, how the JDK runtime loads them and it relies on an optimization implementation detail in the bytecode verifier to work at all (and very common code patterns make it fall on its face). There is one scenario where @OnlyIn is required to be used: You have a class that extends / implements a common (not annotated) Minecraft class and you need to override / implement a method that is marked @OnlyIn. In this case you should annotate your overriding method as well.

Have an example usage https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/item/ModItemTier.java Just be aware that the suppliers are absolutely required.

You need to create your own class (preferably enum, it’ll be easier) and let it implement IItemTier as an interface. You’ll need to override all the methods of IItemTier in your new class - look at what the vanilla one does, and just replicate its functionality. Then you can just use your MyModItemTier.SOME_MATERIAL in the constructor of your new tool Items.

Nothing about the quoted post was rude. You are mistaking being factual for rudeness.

The event is added by Forge. Vanilla's HUD is in the IngameGui class. Forge has a custom version of this class called ForgeIngameGui which adds the events.

Use Java 8 for modding.

For a start, Biome#addFeature is not threadsafe. So you cannot call that method in FMLCommonSetupEvent or any other parallel-mod-loading event. It must be delayed using DeferredWorkQueue.

Nope. Which is why I don't bother replying to his threads any more.

Its logical server side (per-world) and syncs to the client on connection. You register it on all distributions. Using a "proxy" or "baked" value is much better. You can see and/or profile the performance of the get method yourself. It's (possibly nested) Map#get calls so isn't extremely slow but is a lot slower than direct field access. Forge registers its client & server configs on all distributions, however they only use simple config values like booleans and numbers. If you're using a class that only exists on a specific distribution (for example an enum) you might want to look into only registering that config on that distribution. The config types contain some documentation. I've got a tutorial on configs here if you'd like some info. It's not very in-depth though (yet).

Can you please stop making your posts entirely unreadable? Thanks.

This is why TextComponentTranslation is a thing...

Yeah, I love that, too. But what's the problem to have both things at once? Just install Forge and put Optifine into the mods folder.

If you want a continuous right-click action you have to: Override getMaxItemUseDuration in your Item class to specify the maximum amount of ticks the right-click can be performed. Call EntityPlayer#setActiveHand in onItemRightClick. Item#onUsingTick will be called every tick while right-click is being held. Item#canContinueUsing will be queried to determine if the action should stop. Item#onItemUseFinish will be called once the action finishes (i.e. it was used for getMaxItemUseDuration ticks). Item#onPlayerStoppedUsing will be called if the action is aborted by the player (stopped holding right-click before getMaxItemUseDuration was reached).

Isn't it just like --username and --password?

Create new class which extends WorldType and call it's constructor during one event (preInitialization/initialization/..) - That will register it. Then you can override some methods like getChunkGenerator if you want to change the world gen

General issues Do not use the "export" or "create jar file" functionalities of your IDE or other means to create your final mod file. You must use the Gradle build task. See the documentation for more info. When creating a Git repository for your mod, the repository root should be where your build.gradle file is. The MDK ships with a default .gitignore file so that only the necessary files will be added to version control.