Leaderboard

Minecraft 1.12: The newest version of Minecraft has been released. Forge has been updated to support this new version. However due to the way Mojang implemented the Recipe changes there are a lot of under the hood changes that we need to do. Most notably re-writing on of the largest/most intricate systems of Forge, The Registry system. This will take some time, so do not expect a recommended release quickly. However if you are a modder you can start using the current versions to build against. Some API's may change in the early days of Forge so be sure to be ready for that. I'm sorry, I usually try my best to maintain binary compatibility, but it's just what will need to happen. For users, you can use the current builds. But just be warned that things are actively being developed and we ask to please responsibly report issues on the forum. Once I finish the rewrite and get a stable recommended build of Forge out I will make a more detailed post listing all the major changes like I always do. New Policy on Coremods: Sadly core modding is still a thing. As always we request that you guys attempt to work with us to get changes into Forge instead of core modding it yourself. However, if you MUST we have decided to put forth to the community a few 'Best Practices' for core modding. The intention is that large communities such as FTB, Technic, and Curse work with us to promote these best practices. 1) Coremod must be the coremod only, and no extra library/features/apis/etc. There are far too many coremods in the community that package tons of classes that have nothing to do with the modifications they make to the game together so that people will be forced to use their coremod just because they want a utility. This is bad. So Coremods themselves should be limited to JUST the IFMLLoadingPlugin, and IClassTransformers, and as few utility methods needed to make those hooks run. 2) Coremod binaries must be signed. This is a very basic thing that just verifies the person/organization we think made the coremods actually did. It also verifies that the file that was downloaded has not been modified in any way. As it sits there will NOT be any central authority on the keys used to sign things. So Self-signing will be allowed as long as you provide the community your signature. Starting in 1.13, with the loading system rewrite, users will be prompted to accept signatures of coremods. It is our intention to work with people like FTB, Curse, and others to make these signatures easy to use and manage. For example a user would say they trust FTB, and wouldn't be prompted for every coremod that exists in a FTB modpack. For the technical side you can read more about Jar Signing here: https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html 3) Coremods should be visible source. This will be a controversial standard, but my thoughts on it is that if you're screwing with someone else's code (which is the only reason to ever write a coremod), then you should be willing to show what you are doing. It is stressed that this is VISIBLE SOURCE only. It is not a requirement that you allow others to use your code, or modify and distribute it. It's simply that we can see it. The signatures and visible source are NOT designed to be security measures. As there is nothing preventing malicious code from being signed and a user accepting it. This is just the risk you run with Minecraft modding as you're running compiled code from random people on the internet. This is however designed to make the community more open and try and stem the number of coremods out there that have no reason to be coremods. Major Policy change: I am happy to officially announce a new member of the Forge team. Everyone welcome Mezz. His official responsibilities are to be the Pull Request, and Issues manager. Basically, he's the guy you yell at if your PR/Issue is rotting on github. He's the guy who is tasked with reminding me that they exists. He will be the one responsible for filtering all the PRs/Issues before they get to me. So I don't have to deal with telling you guys to follow the standards like making a test mod, posting logs, etc.. In addition, he is also the one who decides if old versions will have PRs accepted. Yes this means there will be a limited development system for older versions. How far back that means is ENTIRELY up to Mezz. However the rules are that ANY pr adding features for a old version MUST be applied and accepted for the current version FIRST. Save for features that would have no place in the new version. Example being adding a new achievements hook when the new version removed achievements. It will still be our official stance on this forum to only provide support for the Current version, and the previous version. However, if the community wishes to have a few dedicated people step forward and become our Legacy support team them I am willing to work with them and see what we can set up. The main reason we do not provide support for old versions is simply we do not have the manpower. So start helping out! Response From Sponge:

You can view the entirety of Forge 1.13 here: https://github.com/MinecraftForge/MinecraftForge/tree/1.13-pre?files=1 I think that Forge 1.13 is 80-90% done based on: - Forge Gradle 3 is finished (this was the part that unexpectedly took the longest) - I believe the MCP mappings are pretty much done for 1.13 - From what I’ve seen on the comits they’ve managed to get Forge 1.13 (without all the patches) to compile and run (I’m traveling right now so I can’t test it and confirm it myself) - I judge that the rewriting of the mod loading system is probably more than half done as they’ve already merged Minecraft and MCP into 1 “mod” with the new loading system (I think the new loading system is amazing and is a massive upgrade from the previous system) - I think that the remaining 10-20% of work is going to be going through all the patches from 1.12.x and seeing if they still need to exist and if so what changes have to be made to them because of changes to the vanilla code. Here’s the list of patches to review https://github.com/MinecraftForge/MinecraftForge/issues/5162

First off, you can't even spell my name right, secondly for those who see this, this is the thread he got a warning for, specifically the post where he called us all assholes http://www.minecraftforge.net/forum/topic/65936-forge-server-error/ As you can see, nobody cussed at him. As for us being assholes, because we are blunt and have rules, and refuse to support older versions does NOT make us assholes. The analogy I like to take is you going to Microsoft, and asking for support with Windows 95. They will tell you to either sod off or pay them a ABSURD amount of money. As for the way we speak to you, like we know 'everything', it's because piratically we do. In regards to the software WE'VE WRITTEN and spent the last 5+ years supporting and developing! You coming in, and failing to follow our directions on the SIMPLEST of errors just shows your arrogance and stupidity. {Note, I used stupidity, and not ignorance, because ignorance implies a ability to update your thinking} As for the youtubers who still play 1.7.10, that's fine. People can PLAY whatever they want. Hell you can {tho its highly discouraged} develop for whatever you want. However the line is drawn with your trying to force US to develop/support the old versions. It's a simple concept, if you want our help, stay updated. If not you're on your own. So ya, your last ban was for a week, you obviously didn't learn your lesson, so now enjoy the lifetime.

Locked. JRed you are consistently coming around asking for help with your fucking coremod that I'm fairly sure every member of staff has asked you to stop using, yet you insist on hacking the shit out of everything because you think you know better yet you refuse to prove that your way is better by contributing to Forge directly. I will say this again, if you are having trouble with making a coremod maybe you shouldn't be hacking the shit out of other people's code.

As there have been few attempts to create this functionality (that I can find) I decided that I'd have to do this myself. And seeing as it boodly doesn't exist anywhere, I thought I'd share. It does not extend GuiTextField, though it probably could, but it was easier to just take everything that was GuiTextField and make a new class and just make changes as needed, particularly as a lot of GuiTextField's fields were private and thus not visible to a subclass (using getters and setters was frustrating, as many setters either didn't exist or had annoying side effects, such as ignoring newlines and up/down arrow keys). https://gist.github.com/Draco18s/2b02762b597e67a9b887aed241f25077 Known issues: Minimum height of 2 lines enforced (are you really going to complain?) Does not support multi-line selections (they are trouble some to handle; rendering, copying, etc) Does not feature a scroll bar (yet) Mouse wheel scrolling clamped to range that keeps the cursor within the visible text box range (technical limitation; could be overcome, but the limitation relates to automatically scrolling the cursor into range when using the arrow keys) Page up/down not supported (yet) Sometimes the selection highlight appears in edge-case situations that cause the cursor to reposition due to another (e.g. moving from one line to another when pasting multi-line content, etc) Up/down arrow cursor movement is "by column" rather than "by rendered position" as I can't be arsed to figure out where the carat should go instead (my usage will be moving to a monospaced font, where those two values are the same).

I have no sympathy for you players who use Netease, their entire business model is bad and abuses the hard work that we here at Forge, and other modders do. If they want to start complaining that I don't produce Forge fast enough, then they can start helping out. But no they just sit back, toss DRM onto things, and just rake it in. It'll be done when it's done.

No

Hey Lex, all the words I have stated against you were a result of a long time of bearing a grudge against you. Now, I would like to make things right. When IItemRenderer was originally deprecated, I searched up real quick to see if anyone else was having an issue with the code not being called. I found a thread about it, with you replying to them with something along the lines of it won't be added back since copy-pasters constantly screw it up. At that moment, a grudge formed against you, from my eyes it looked like this: "Because you couldn't tolerate copy-pasters, you made us real programmers suffer too!!!" Since soon after 1.8's release until now I have had this grudge against you. But then this guy comes along asking me to update to 1.11.2. I say no, since IItemRenderer was removed by the forge devs.(As you already know, since he doesn't respect privacy and posts everything that I sent to him back here). After the discussion of this thread, he comes back to me and says all sorts of rude insults, such as lazy and stupid. I proceed to tell him something along the lines of "I make free content for fun, and you treat me this way? Ha! The only profit I have made from this mod was a couple people who love it so much they wanted to donate. I don't even use adf.ly! I haven't made enough from this mod to pay for a week's worth of groceries, I have an actual job for that! This is just for fun!" After sending him that, I started brushing my teeth, and then I started thinking. Your a free content maker too, just like me. You put up with ungrateful, rude people all the time, just as I do. The more I thought about it, the more glad I was that this situation happened. I literally started to smile when I realized I was finally free from my grudge against you, no longer had to carry those negative feelings on me(negative feelings are weighty, I'm sure you can agree.) I also started thinking back to that old thread that I read, and how much it would piss me off if I were you and copy-pasters caused tons of reports to come to you about the GL mess that they made. I completely understand your decision now. Whenever someone has asked me to update my mod, I used "IItemRenderer was removed by the forge devs" as an excuse, due to the grudge I bore against you. The real reason is because my goal is to make a World War 2 mod that stretches across all the theatres of WW2, something that no game has ever done. It is my dream to be able to play such a game, and updating my mod would cause a lot of hindrances to that dream. Of course, the removal of IItemRenderer did add to that a bit, but it was mainly the fact that because 1.7.10 is the currently the most used version by the community due to the wealth of mods for it(like 1.6.4 was for a long time), I would be forced to maintain multiple versions of the mod to satisfy both the majority and the minority, which is time consuming. Time is precious, and with a job having to maintain multiple versions would hinder my dream a ridiculous amount. Once my dream is realized, I will most likely update the mod. It was so much easier to just blame everything on you, than type out my complicated, emotional, real reason. Everyone else just accepted my answer. But then today all that changed through one very determined user.... I came here to make things right. I sincerely apologize for all this drama. Though you never knew it all this time, I also apologize for bearing a grudge against you. It was wrong of me. Will you forgive me for feeling that way? Side Note: Thank you Pop Cat, for indirectly making me realize the similarities I share with Lex, and how my grudge against him was wrong. If it weren't for you, I might have never let go....

I'm sure you'll figure it out!

@LenManos Your staff / mods / whoever works with you was complaining about my mod code and cussing at me as well, and even other people i know said the forge forms are assholes to everyone and idc if i get baned. because you cant speak to someone like that saying you know everything. & you all so stop saying well we dont support this version any more youtubers still play with 1.7.10 & above so you really need to think twice

It took me a single google search to find that Computercraft is now opensource on GitHub and has a 1.12.2 alpha build on CurseForge...

As Draco18s is pointing out, you need to fully understand how Minecraft handles blocks. What you just said is closer to what you need to do, but we want to make sure you understand why. Basically, from a "normal" object-oriented sense you would have a Block class and you would create an instance of it every time you had a block placed in the world. Logically this is good, but it has a bad consequence for performance -- the number of instances gets very large very fast. In just one chunk there is 65k possible positions to place a block so a world of just 20 chunks is going to have 1.2 million possible blocks. So if there was a instance for every block placed in the world there would be a serious problem with memory. So instead, Minecraft decided to have a single instance of each block class and instead create a "map" of where they are placed. That works great if the blocks are simple and unchanging as it is a very compressed format. However, of course they then added the idea that some blocks might want to be varied. To do this they allowed a little bit more (just 4 bits) of data for each block position to allow variation -- this was called metadata. Some blocks used this for things like color (dyed wool), and some used it for direction, etc. But the key point is that the information that represented these things was stored in the "map" NOT in the block instance or class. There was no field in the wool class for the color, rather when the wool was rendered it looked up the data stored in the world data and applied the color then. Now, the block class code sometimes needs to behave differently based on the metadata. Originally that was literally a matter of decoding the 4-bit values (that is why various Minecraft wikis and such you'll still see tables showing the values). But eventually this got more advanced implementation using properties and block states. Basically every combination of values of the properties creates possible blockstate. But ultimately these are still stored in a limited 4-bit mapping. So putting it all together it means that you shouldn't confuse scope (like public or private or static or whatever) with this issue. Rather you must contain all your per-position information within a property, not within fields of the class itself. Okay, assuming you understand all this... just look at other blocks which already do similar things, like a furnace or torch or something, and adapt their code to your specific need.

williewillus is maintaining a primer on the 1.13 changes here: https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a It'll be significant work for modders but I'd say considerably easier than 1.7 -> 1.8 was.

Seriously, Use the event not the static registries. Timing of registration is important. So stop doing it in random places. I was tempted to name the event 'RegisterYourStuffHereAndStopBreakingEverythingElseSeriouslyStopRegisteringYourCrapInRandomPlacesItBreaksThingsAndHoldsUsBackFromBeingAbleToDoCoolThingsThatWeveBeenWantingToDoForFourYearsNow' but I decided against that as it was a bit long

In my case 'preview_OptiFine_1.12.2_HD_U_C8_pre' prior to 12-18-2017 was causing chests not to open. I DL'd the 12-18-2017 version that is compatible with forge 2577 and the chests open as before.

serverSideOnly just tells the client to skip loading the mod if it's installed, you need to set the acceptableRemoteVersions property to "*" as well. This tells it to accept any remote version, including none.

@DifferentiationIt is good that you understand the rules of the forum, and also nice that you're actively particpating and interested in modding. However, the only people that should enforce the rules are official moderators. It is even okay to suggest someone should spend time learning more Java, but some of your posts are literally telling people to "go away" or "we're not going to support that". No one except official moderators should ever tell someone to go away or try to draw a line over support. Now I often see people who post and I can tell that they're likely going to need a LOT of help, or want to do something they probably shouldn't. In those cases I simply don't respond. Sometimes other people will, sometimes not, but it is up to them if they want to spend the time supporting someone. One other thing to note is you never really know who the person posting is. Perhaps it is a younger kid. Perhaps it is someone with some special needs. So it is best to always err on the side of compassion and tolerance even if they seem a bit misguided. Anyway, please leave the rules to the moderators -- our moderators do a good job. If someone posting annoys you then just don't respond to their thread.

Jesus. This argument is pointless. What does it matter what they want to do? If you don't want to help someone, just ignore them. End of story. If other people decide not to help them based on reasons such as not knowing Java (and you really should learn basic Java in order to mod) then that's fine too. This argument is just cluttering up the forum with nonsense. I don't have anything else to say, but there's already an answer in this thread on how to track clicks per second, assuming that the MouseInputEvent exists on 1.8.9.

Forge Version: 1.12.1-14.22.1.2478 Minecraft Version: 1.12.1 Downloads: Changelog (Direct) Windows Installer (AdLink) (Direct) Other Installer (AdLink) (Direct) MDK (AdLink) (Direct) Universal (AdLink) (Direct) With 1.12.2 on the horizon, I figure its about time for a RB. We've done a few bug fixes, performance improvements, etc. We're still working on flushing out Mojang's JSON data system. But this is being held up by modder's not wanting to say what they need. So my hopes is that people will start testing out the changes and working with us to move the data system forward. I want to take this moment to re-iterate that we are proposing a new standard for the community in reguards to CoreMods. This standard has been agreed upon by most of the major players in the Minecraft community. You can read more in the announcement. These are proposed for technical reasons so that hopefully in the future we can start moving the engine/game forward. Minecraft Forge 14.22.1 Changelog: ============================================================================ New: Added @ObjectHolder scanning to vanilla MobEffects, Biomes, Enchantments, SoundEvents, and PotionTypes constants. Optimized ExtendedBlockState.getClean() speeding up block updates. Added rotation origin variable for animated models Added partialTick to RenderLivingEvent Improved Furnace fuel functionality and performance. Added spawner flag to CheckSpawn event. Added logging snitcher when using System.out/err Quieted down warning for missing translation files. Added support for custom FontRenderer for tooltips in Creative GUI Added support for NBT icons in Advancements Removed unnecessary maxStackSize restrictions on brewing potions. Optimized some patches for performance/cleanliness. Now firing RemapEvent when reverting to Frozen state. New Recipe Registry events after JSON recipes are loaded. Added support for vanilla "nbt strings" in json recipes Added logging for coremods that do not package separate Jars. Made Optional.Interface repeatable Added support for custom Shields and Shield disabling weapons. Added limiting to Server to Client capability packets. Added support for oredict dyes to Fireworks, Armors, and Shulker recipes. Added support for placing buttons and levers on modded blocks. Sneaking will now bypass villager interactions like other entities. Added pages to the advancements GUI to allow for unlimited root advancements. Added CriticalHitEvent to allow more control over whether a attack is a critical or not, and what damage it does. Cleaned up Forge config files. Increased performance of ticking tile entities. Added GuiContainer Foreground render event. Add smarter getter for block slipperiness Bug Fix: Fix BiomeDictionary not collecting it's list correctly. Fixed incorrect default resource location of potion registry Fixed missing messages of missing models Fixed unblockable damage being blocked by armor. Fixed log spam when creating dummy blocks. Fixed override duplication caused by bad comparison. Fixed getting missing models for overridden Item registry entries Fixed JOpt version on the dedicated server not matching client. Fixed packet encoding issues. Fixed Recipe Toast crash when granted more than 5000 recipes Fixed MC-68754, Screen is not resizeable after exiting fullscreen due to LWJGL bug Fixed crashes related to the RecipeBook and unknown Recipes. Fixed EnumHelper for CreatureTypes Fixed game freeze when resizing the window too small on the mods gui Fixed "Binary patch set is missing" error in dev environment Fixed issue where rendered held items wouldn't properly update when the reequip animations isnt shown. Fixed invalid erroring case during loading Advancements form mods that don't have advancements. Fixed tripwire statemap not being complete when mappings change. Fixed crops dropping incorrect items with fortune. Fixed server not handling item usage when client cancels it. Fixed death loop due to zero max health (MC-119183) Fixed FML handshake race condition Fixed overrides not being applied over the network. Fixed swapping of finite fluids with negative densities. Fixed the firing location of InputEvent.MouseInputEvent Fixed Armor bar disappear after changing dimension. MC-88179 Fixed bug where config categories errored if they contained regex special characters. Fixed issue where client comparators WOULD sync with server. {Vanilla bug we had to re-introduce because of vanilla mechanics =.=} Fixed vanilla server icon. Fixed stacked entity item rendering using the wrong transform for the extra items. Fixed Boats rubber banding when dismounted. MC-119811

I'm brand new to modding and a noob programmer. I learned the old way to register blocks and items using GameRegistry.register() then I found out there is actually a new, better way to register blocks, items, and even models. The new way is to use RegistryEvents and I'm a sucker for new and better things so I tried to figure out how it works. My goal with this post is to see if anything I did can be done better and whether or not this is correct. Just because it works doesn't mean it's correct. I want to have a solid base before I build on it too much. Here is what I came up with: RegistryEventHandler.java @Mod.EventBusSubscriber public class RegistryEventHandler { @SubscribeEvent public static void registerBlocks(RegistryEvent.Register<Block> event) { event.getRegistry().registerAll(ModBlocks.BLOCKS); Utils.getLogger().info("Registered blocks"); } @SubscribeEvent public static void registerItems(RegistryEvent.Register<Item> event) { event.getRegistry().registerAll(ModItems.ITEMS); for (Block block : ModBlocks.BLOCKS) { event.getRegistry().register(new ItemBlock(block).setRegistryName(block.getRegistryName())); } Utils.getLogger().info("Registered items"); } @SubscribeEvent public static void registerModels(ModelRegistryEvent event) { for (Block block: ModBlocks.BLOCKS) { ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), 0, new ModelResourceLocation(block.getRegistryName(), "inventory")); } for (Item item: ModItems.ITEMS) { ModelLoader.setCustomModelResourceLocation(item, 0, new ModelResourceLocation(item.getRegistryName(), "inventory")); } Utils.getLogger().info("Registered models"); } } ModBlocks.java public class ModBlocks { public static final Block[] BLOCKS = { new BlockTinOre("tin_ore", Material.ROCK), new BlockTinBlock("tin_block", Material.ROCK) }; } ModItems.java public class ModItems { public static final Item[] ITEMS = { new ItemTinIngot("tin_ingot") }; } BlockTinOre.java public class BlockTinOre extends BlockBase { public BlockTinOre(String name, Material material) { super(name, material); } } BlockTinBlock.java public class BlockTinBlock extends BlockBase { public BlockTinBlock(String name, Material material) { super(name, material); } } BlockBase.java public class BlockBase extends Block { BlockBase(String name, Material material) { super(material); this.setRegistryName(Reference.MODID, name); this.setUnlocalizedName(this.getRegistryName().toString()); } } ItemTinIngot.java public class ItemTinIngot extends ItemBase { public ItemTinIngot(String name) { super(name); } } ItemBase.java public class ItemBase extends Item { ItemBase(String name) { this.setRegistryName(new ResourceLocation(Reference.MODID, name)); this.setUnlocalizedName(this.getRegistryName().toString()); } }

Use Minecraft's Structure Blocks to save a structure to NBT, which you can then use in code to load the structure. Create a new Template instance with the resource location of your structure.nbt file, and call Template#addBlocksToWorld to spawn the structure. You can do this in your WorldGenerator class.

Forge Version: 1.12-14.21.1.2387 Minecraft Version: 1.12 Downloads: Changelog (Direct) Windows Installer (AdLink) (Direct) Other Installer (AdLink) (Direct) MDK (AdLink) (Direct) Universal (AdLink) (Direct) Minecraft 1.12 has been released! And we have finally gotten the big breaking changes in and Forge should be in a fairly stable state! 1.12 has brought a lot of changes, most notably the new Json based recipe system. This was a major hurdle to get over as we had to expand this system to support modded recipes. And to support the many different ways modders interact with crafting. We also had to re-write a large section of internal Forge code due to how Mojang implemented the new crafting guide book. Mojang also is now forcing Java 8 in the vanilla client. Which broke quite a few things related to how we decompile Minecraft itself. Which required me to re-write large portions of the decompiler we use. Overall there was a lot of things changed and due to this there are no doubt still issues in these systems. However I am wanting to push out this release so that we can switch the official development to 1.12 versions. This is also a signal to modders who have already adopted 1.12 {There are a lot of you, this is very encouraging!} that we have stabilized our API. Which means no more intentionally breaking everyone's mods <3 So I hope you guys will stick with us, and I apologize for the delay in getting this first build out. The Recipe System: 1.12 introduced a new JSON based recipe system. Like all systems Forge has had to expand this to support the things that modders want to do. To that extent if you are a modder please read this gist. That is my initial comments and design ideas for the JSON based system. My intention is that someone from the community who is better at writing documentation then I am will come along and convert that to proper docs in our documentation repo. *Hint Hint* Registry Rewrite: One of the core feature of Forge has been the Block/Item registry system. This is what has allowed us to internally manage the ids, world saves, all that stuff. This system has expanded from it's original implementation of just Blocks/Items to a lot of things. Biomes, Entities, Potions, Enchantments, and now Recipes. This is the system that has allowed users and mod pack creators to not need to care about ID conflicts anymore. With recipes being added to this system it has required a MAJOR rewrite of how it works. However this re-write is for the better as it fleshes out and fixes some features that were not fully supported in the older version. There are however things people need to know. Users: Due to the re-write being a great time to delete old complicated, sadly we have had to remove support for updating <1.10 worlds. It is recommended that you load the world using 1.11.2 Forge so it can do the legacy upgrade and THEN load it with 1.12. And as always with anything related to updating worlds between Minecraft versions, we recommend that you make backups of your world before hand! Modders: It is now recommended and HIGHLY encouraged that you use the RegistryEvent.Register<T> functions when creating your block, items, potions, recipes, etc... These events have changed to being fired after pre-init. If you use these events you will better suited for the future when we introduce reloading mods dynamically at runtime. Basically.. use these events! Modders: Substitutions and @ObjectHolders have got a major enhancement, things should be a lot simpler to use now! Minecraft Forge 14.21.1 Changelog: ============================================================================ New: MAJOR rewrite of the Registry system Dropped world loading support for <1.10 worlds. Load them in 1.11.2 before updating to 1.12. New JSON recipe loading system enhancements. Added support to vanilla JSONS to specify NBT data in output. MissingMappingEvent is now fired for ALL registries @ObjectHolders and overriding should now be supported on ALL registries. Added AnimalTameEvent for Parrots. Forced Block/Item.getSubItems method to be available on the server side. Bug Fix: Fixed crash related to player names Fix NPE in config menu with custom keybinds. Fixed exception in ShapedOreRecipe.checkMatch for recipes that don't fill entire crafting grid Fixed bug SPacketLoginSuccess when in development environments. Fixed exception related to vanilla clients connecting to a Forge server. Fixed NoteBlockEvent not supporting new vanilla instruments. Fixed Universal bucket handling for Fluids with NBT Just wanted to reiterate this again, BACKUP your worlds! And to properly report any issues you run into. This means including your fml log!

I don't speak for the whole community but since I am a leader of Sponge, I'll throw my 2 cents in by first saying that yes, SpongeForge will be adjusted to comply. We find these changes to be a good-faith effort to make some wholesome changes to the ecosystem as an attempt at dealing with the elephant in the room: coremods. SpongeForge falls under a coremod which will not function at all without its core changes but, as Lex has mentioned above, we can simply make the core portion not function at all should the whole thing not be here and throw up a descriptive error to say why. Expect to see some changes land in the next couple of days (when someone gets some time) on Sponge's end to make this change.

The mesher is a tricky method called during init. Used by vanilla but now discouraged for mods, it's tricky because certain things need to be called in a certain order (and the client side-only proxy is involved, which separates some of those statements in code space). I believe that Forge created the custom location method because it's much less fragile. Note that it's called during preInit, not init. The threads discouraging mesher use run like a rash across this forum going back almost 2 years. Any modder facing any rendering problems should have come across them when searching for answers to avoid posting repeat questions. That's why Draco sounds frustrated: When someone shows up here using the mesher call, it means that the modder's scholarship stopped at a long obsolete tutorial without reading any threads written in the last 22 months.

Super duuuuper necro post, but for anyone who finds themselves here after trying the srgExtra line, it's been changed in newer versions of gradle (2.2-SNAPSHOT I know, but maybe even earlier). Now instead of doing: minecraft { ... srgExtra "PK: ..." } You have to do: reobf { jar { extraLine "PK: ..." } } Relevant XKCD: https://xkcd.com/979/

Yes you do. Writing a computer program in a computer programming language by definition makes you a computer programmer. Modifying another application - making a "mod" - is a pretty advanced thing for a computer programmer to do. Forge, FML etc. take care of 99.9% of this, including the ASM, loading your mod and deobfuscating MC. Therefore what you are making isn't really a "mod" at all, its more of an add-on. There are other "mods" out there that allow you to write your add-on in another computer programming language. For example these "mods" allow you to write your "mod" in Skript, JavaScript, Scala, Kotlin or even whatever Scratch-based language MCreator uses. However, doing this is inherently writing "code" to make a computer do something, which makes you a computer programmer. In future if you want help on this forum I would recommend being more polite. It may be hard for beginners who haven't done the appropriate pre-requisite background stuff (learning how to write code in the language you've decided to make your mod in, learning the basics of setting up gradle from the command line - or using the command line at all, learning the basics of git etc.), however beginners should have done their research and learned how to do these things. Learning by example is great, and it's how I've learned 95% of everything programming related, but the key part of it is learning, not just copy pasting code. This is why posting ready-made code snippets is discouraged on these forums. The question you asked was pretty simple and you got a quick answer. After that, you could have googled what a "counter" is in programming and how to make one that increments. The basic idea of it (in this scenario) is to have a variable (an instance field in this case) that you increment (pre-increment would be perfect for a tiny performance gain in this case) every "tick" (in your onUpdate method in your TileEntity in this case) and, if the value is the desired one, reset the variable and execute your logic that should only happen every several ticks.

Since this is such a big update for forge, is there a way to keep more in the loop of updates of how far the team will be till done? Or any ways people can help, other than to not ask for 'when will it be done' threads? And I am not asking when it is is done, just how to be kept in the loop of how far you guys have been able to be with it.

And another reason to hate MCreator: it generates code using ItemModelMesher, which is outdated and very bad practice (use Item#setCustomModelResourceLocation).

If you create a new entity, you may have stumbled across the Attribute System, for example if you want a custom max. health value. Now a detailed explanation on what the Attribute System actually is can be found here: http://minecraft.gamepedia.com/Attribute Here I will show you how to create your own Attributes for your entity and modify all of them in code. NOTE: all attribute classes mentioned in this tutorial can be found in the package net.minecraft.entity.ai.attributes. Create a new Attribute Step 1: To create a new attribute, you first need to create a new IAttribute instance (preferably static final in your entity registry class or somewhere). Now you don't need to make a new class which implements that interface! Minecraft provides us with a standard class currently used for all its own Attributes called RangedAttribute. The constructor of that has the following parameters: IAttribute parentIn - a parent attribute if available, can be null String unlocalizedNameIn - the unlocalized name of the attribute. You can't add an attribute with the same name to an entity, so I usually precede the name with my Mod ID separated with a dot like TurretMod.MOD_ID + ".maxAmmoCapacity" double defaultValue - the default value of the attribute. This value is set as base value when the entity is first created. It can't be lower than the minimum nor higher than the maximum value or else it will throw an IllegalArgumentException double minimumValueIn - the minimum value of the attribute. This value is usually 0.0D. If the entity's attribute value falls below that, this value is used for it instead. It can't be bigger than the maximum value or else it will throw an IllegalArgumentException double maximumValueIn - the maximum value of the attribute. This value is usually Double.MAX_VALUE. If the entity's attribute value falls above that, this value is used for it instead. It can't be smaller than the minimum value or else it will throw an IllegalArgumentException Now at the end, my IAttribute instance variable looks like this: public static final IAttribute MAX_AMMO_CAPACITY = new RangedAttribute(null, TurretMod.MOD_ID + ".maxAmmoCapacity", 256.0D, 0.0D, Double.MAX_VALUE); But wait! If you want to share the attribute value and modifiers with the client, you'll need to call setShouldWatch(true) on that variable. The same way you can disable it, for whatever reason, with false instead of true as the parameter value. Conveniently it returns itself, so you can make a neat one-liner like this: public static final IAttribute MAX_AMMO_CAPACITY = new RangedAttribute(null, TurretMod.MOD_ID + ".maxAmmoCapacity", 256.0D, 0.0D, Double.MAX_VALUE).setShouldWatch(true); Step 2: Great, now you have this useless variable the entity doesn't know about. To make it useful and working with the entity, you first need to register it to the entity's attribute list. To do so, override applyEntityAttributes()(if you've not already done so while changing the entity's max. health) and call this.getAttributeMap().registerAttribute(MY_OWN_ATTRIBUTE_VARIABLE), where MY_OWN_ATTRIBUTE_VARIABLE is firstly an overly long name, but more importantly your variable of your attribute instance created in Step 1. Here's an example from my mod: @Override protected void applyEntityAttributes() { super.applyEntityAttributes(); // Make sure to ALWAYS call the super method, or else max. health and other attributes from Minecraft aren't registered!!! this.getAttributeMap().registerAttribute(TurretAttributes.MAX_AMMO_CAPACITY); } Step 3: The attribute is now instanciated and registered, but how do I use its value? Simple! Just call this.getEntityAttribute(MY_OWN_ATTRIBUTE_VARIABLE).getAttributeValue(). It returns a double. If you want it to be an int, just use the MathHelper from Minecraft, for example MathHelper.ceiling_double_int(doubleVal) Modify an Attribute Now, to modify an attribute, there are 2 ways of doing so: 1. modify its base value This is simple and straight forward, and as mentioned 2 times here so far, you may have already done this via the entity's max. health attribute. But to be complete, here's how you change the base value of an attribute with the example on the max. health: this.getEntityAttribute(SharedMonsterAttributes.maxHealth).setBaseValue(40.0D); //sets the entity max. health to 40 HP (20 hearts) Please note: this does NOT get synched with the client! If you need to edit the base value, make sure you use packets if you want it to be shared (or change it on both sides). Otherwise use modifiers! 2. add modifiers to the attribute This is a "reversable" way of changing the attribute value w/o messing with the base value. What we will do here is essentally this: http://minecraft.gamepedia.com/Attribute#Modifiers That said, much like the Attribute Instance, we need to create our own AttributeModifier instance variable. Conveniently, there is already a class for us to use called AttributeModifier. It's constructor parameters are as follows: UUID idIn - the UUID of this modifier, much like the Attribute name, this needs to be unique per Attribute. I usually give it a pre-defined, hardcoded Ver. 4 UUID via UUID.fromString("MY-UUID"), which was generated on this site. Mine looks like this: UUID.fromString("e6107045-134f-4c54-a645-75c3ae5c7a27") String nameIn - the Modifier name, can be anything except empty, preferably readable and unique for the Attribute. Since the "uniqueness" of the modifier is already defined in the UUID, you can have duplicate names. double amountIn - the Modifier value, can be anything. Note that the attribute, as prevously explained, has a min/max value and it can't get past that! int operationIn - the Operation of the Modifier (careful, magic numbers over here!). Have a direct quote from the Minecraft Wiki: Brief explanation: Operation number is the value you feed the parameter. I also made an enum for it complete with javadoc for you to copy (with credits of course) if you want: https://github.com/SanAndreasP/SAPManagerPack/blob/master/java/de/sanandrew/core/manpack/util/EnumAttrModifierOperation.java Now I've covered the parameters, it's time to make a new instance like this: MY_CUSTOM_MODIFIER = new AttributeModifier(UUID.fromString("e6107045-134f-4c54-a645-75c3ae5c7a27"), "myCustomModifier420BlazeIt", 0.360D, EnumAttrModifierOperation.ADD_PERC_VAL_TO_SUM.ordinal()); You have the new modifier instance, but what do do with it? You can add or remove modifiers from an attribute like this (method names are self-explanatory): entity.getEntityAttribute(MY_ATTRIBUTE_INSTANCE).applyModifier(MY_CUSTOM_MODIFIER); entity.getEntityAttribute(MY_ATTRIBUTE_INSTANCE).removeModifier(MY_CUSTOM_MODIFIER); Alright, you know now everything there is to know about attributes... wait, there's one more thing: attributes are saved and loaded automatically by the entity, no need to do that manually! Just make sure the client knows about the Attribute (register it properly as I've shown).

As someone who has been in a Programming Apprenticeship for nearly a year now, I agree with this statement but it is missing one important piece of information: clear aspirations, concrete goals and knowing what you need to learn (understanding of the domain you are about to dabble in). There have been many instances where I have tried to learn something on my own but I have not had a solid goal in mind. However, in this entire (nearly) year, I have learned 200% the amount of stuff I learned in the ~3 years prior. And no, that isn't entirely an exaggeration. I am just as shocked as you all will be at the sheer volume of stuff I have learned. But that is the effect that having concrete goals and sources of Domain Knowledge can (and will) have on your learning. Clear Aspirations just help you along in order to keep focused rather than fall into a Rabbit Hole (genuine technical term) and not make much progress. In terms of resources, you have these forums (for Domain Knowledge regarding Minecraft Forge), r/learnjava (for Domain Knowledge regarding Java) and you have so many sources of goals. Go ahead and try re-creating existing mods. If you spend an entire day struggling to figure out how to implement a specific piece of functionality for a mod, that's an indicator that you should leave it until you have more experience. All in all, if you have the determination to learn, there are plenty of resources out there on the internet. You only need to fire up Google and search for those resources.

Those are builds for 1.3.2 from 2014, they're not for 1.13.2.

mY cOREMOD iSNT wORKING yOU nEED tOO hELP mE hERES mY cODE gIVE mE cODE aND rEWRITE iT fOR mE yOU nEED tO import java.util.Iterator; import org.objectweb.asm.*; import net.minecraft.launchwrapper.IClassTransformer; public class null implements IClassTransformer { public static final int ALOAD = Opcodes.ALOAD; public static final int INVOKESTATIC = Opcodes.INVOKESTATIC; public static final int GETFIELD = Opcodes.GETFIELD; public static final int FLOAD = Opcodes.FLOAD; public static final int INVOKEVIRTUAL = Opcodes.INVOKEVIRTUAL; public static final int IFEQ = Opcodes.IFEQ; public static final int RETURN = Opcodes.RETURN; public static final int F_SAME = Opcodes.F_SAME; public static final int GETSTATIC = Opcodes.GETSTATIC; @Override public byte[] transform(final String name, final String transformedName, final byte[] basicClass) { if (name.equals("net.minecraft.client.renderer.chunk.Minecraft")) { System.out.println("********* INSIDE DEOBFUSCATED MinecRaft TRANSFORMER ABOUT TO PATCH: " + name); final byte[] undefined = vent(name, basicClass, true); final byte[] null = this.at(name, hookRebuildChunkEvent, true); return hook.null; } return basicClass; }package asm.net.minecraft.client.renderer.chunk; import java.util.*; import org.objectweb.asm.*; public class RenderChunkDump implements Opcodes { public static byte[] dump() throws Exception { final ClassWriter cw=new ClassWriter(0);FieldVisitor fv;MethodVisitor mv;AnnotationVisitor av0; cw.visit(V1_8,ACC_PUBLIC+ACC_SUPER,"net/minecraft/client/renderer/chunk/RenderChunk",null,"java/lang/Object",null); cw.visitSource("RenderChunk.java",null); {av0=cw.visitAnnotation("Lnet/minecraftforge/fml/relauncher/SideOnly;",true);av0.visitEnum("value","Lnet/minecraftforge/fml/relauncher/Side;","CLIENT");av0.visitEnd();}cw.visitInnerClass("net/minecraft/util/math/BlockPos$MutableBlockPos","net/minecraft/util/math/BlockPos","MutableBlockPos",ACC_PUBLIC+ACC_STATIC); cw.visitInnerClass("net/minecraft/client/renderer/BufferBuilder$State","net/minecraft/client/renderer/BufferBuilder","State",ACC_PUBLIC); cw.visitInnerClass("net/minecraft/client/renderer/chunk/ChunkCompileTaskGenerator$Status","net/minecraft/client/renderer/chunk/ChunkCompileTaskGenerator","Status",ACC_PUBLIC+ACC()V",false);mv.visitLabel(l6);mv.visitLineNumber(398,l6);mv.visitFrame(Opcodes.F_SAME,0,null,0,null);mv.visitIincInsn(1,1);mv.visitJumpInsn(GOTO,l3);mv.visitLabel(l4);mv.visitLineNumber(405,l4);mv.visitFrame(Opcodes.F_CHOP,1,null,0,null);mv.visitInsn(this.RETURN);final Label l8=new Label();mv.visitLabel(l8);mv.visitLocalVariable("i","I",null,l3,l4,1);mv.visitLEvent(final String name, final byte[] bytes, final boolean deobfuscated) { final String targetMethodName; if (deobfuscated == false) {targetMethodName = "NULL"; } else {targetMethodName = "minecraft.Getminecraft()"; } final ClassNode classNodeRenderChunk = new ClassNode(); final ClassReader classReader = new ClassReader(bytes); classReader.accept(classNodeRenderChunk, 0); final Iterator<MethodNode> methods = classNodeRenderChunk.methods.iterator(); while (methods.hasNext()) {final MethodNode methodRebuildChunk = methods.next();if (!methodRebuildChunk.name.equals(targetMethodName)) { continue;}if (!methodRebuildChunk.desc.equals("(FFFLnet/minecraft//renderer/chunk/Minecraft;)V")) { continue;}System.out.println("********* Inside target method! " + targetMethodName + " | " + methodRebuildChunk.name);AbstractInsnNode targetNode = null;final Iterator<AbstractInsnNode> iter = methodRebuildChunk.instructions.iterator();iter.next();iter.next();iter.next();iter.next();iter.next();iter.next();while (iter.hasNext()) { final AbstractInsnNode currentNode = iter.next(); if (true && currentNode.getOpcode() == Opcodes.NEW && true) { targetNode = currentNode.getPrevious().getPrevious(); break; }} 147 - } 148 - 149 - VisGraph this.lvt_9_1_ = new VisGraph(); 147 - }148-if(net.minecraftforge.client.ForgeHooksClient.onRebuildChunkEvent(field_178589_e,field_189564_r,p_178581_4_,compiledchunk,this.field_178586_f,p_178581_1_,p_178581_2_,p_178581_3_).isCanceled())return;149- VisGraph lvt_9_1_ = new VisGraph(); L16 LINENUMBER 145 L16 ALOAD 0 GETFIELD net/minecraft/client/renderer/chunk/RenderChunk.renderGlobal:Lnet/minecraft/client/renderer/RenderGlobal;ALOAD 0 GETFIELD net/minecraft/client/renderer/chunk/RenderChunk.worldView:Lnet/minecraft/world/ChunkCache;ALOAD 4 ALOAD 5 ALOAD 0 GETFIELD net/minecraft/client/renderer/chunk/RenderChunk.position:Lnet/minecraft/util/math/BlockPos$MutableBlockPos;FLOAD 1 FLOAD 2 FLOAD 3 INVOKESTATIC net/minecraftforge/client/ForgeHooksClient.onRebuildChunkEvent(Lnet/minecraft/client/renderer/RenderGlobal;Lnet/minecraft/world/ChunkCache;Lnet/minecraft/client/renderer/chunk/ChunkCompileTaskGenerator;Lnet/minecraft/client/renderer/chunk/CompiledChunk;Lnet/minecraft/util/math/BlockPos$MutableBlockPos;FFF)Lnet/minecraftforge/client/event/RebuildChunkEvent; INVOKEVIRTUAL net/minecraftforge/client/event/RebuildChunkEvent.isCanceled()Z IFEQ L17 RETURN L17System.out.println("********* PATCHING"); final InsnList toInject = new InsnList(); final Label l16 = new Label();toInject.add(new Label(l16));toInject.add(new LineNumberNode(145+3,l16));toInject.add(new VarInsnNode(ALOAD,0);toInject.add(new FieldInsnNode(GETFIELD,"net/minecraft/client/renderer/chunk/RenderChunk","renderGlobal","Lnet/minecraft/client/renderer/RenderGlobal;");toInject.add(new VarInsnNode(ALOAD,0);toInject.add(new FieldInsnNode(GETFIELD,"net/minecraft/client/renderer/chunk/RenderChunk","worldView","Lnet/minecraft/world/ChunkCache;");toInject.add(new VarInsnNode(ALOAD,4);toInject.add(new VarInsnNode(ALOAD,5);toInject.add(new VarInsnNode(ALOAD,0);toInject.add(new FieldInsnNode(GETFIELD,"net/minecraft/client/renderer/chunk/RenderChunk","position","Lnet/minecraft/util/math/BlockPos$MutableBlockPos;");toInject.add(new VarInsnNode(FLOAD,1);toInject.add(new VarInsnNode(FLOAD,2);toInject.add(new VarInsnNode(FLOAD,3);toInject.add(new MethodInsnNode(INVOKESTATIC,"cadiboo/renderchunkrebuildchunkhooks/hooks/RenderChunkRebuildChunkHooksHooks","onRebuildChunkEvent","(Lnet/minecraft/client/renderer/RenderGlobal;Lnet/minecraft/world/ChunkCache;Lnet/minecraft/client/renderer/chunk/ChunkCompileTaskGenerator;Lnet/minecraft/client/renderer/chunk/CompiledChunk;Lnet/minecraft/util/math/BlockPos$MutableBlockPos;FFF)Lnet/minecraftforge/client/event/RebuildChunkEvent;",false);toInject.add(new MethodInsnNode(INVOKEVIRTUAL,"cadiboo/renderchunkrebuildchunkhooks/event/RebuildChunkEvent","isCanceled","()Z",false); final Label l17 = new Label();toInject.add(new JumpInsnNode(IFEQ,l17);toInject.add(new InsnNode(RETURN); final Label l17 = new Label(); final LabelNode l17node = new LabelNode(this.l17);toInject.add(l17node);toInject.add(new LineNumberNode(148,l17node));toInject.add(new FrameNode(F_SAME,0,null,0,null));toInject.add(new FieldInsnNode(GETSTATIC,"java/lang/System","out","Ljava/io/PrintStream;"));toInject.add(new LdcInsnNode("fuk"));toInject.add(new MethodInsnNode(INVOKEVIRTUAL,"java/io/PrintStream","println","(Ljava/lang/String;)V",false)); // inject new instruction list into method instruction list iT uSED tO wORK iTS aLL yOUR fAULT fOR bREAKING eVERYTHING wITH tHE nEW fORGE uPDATE I didn't getEnoGH tIME tO upDatE aND teST mY mOD yOU havE tO help MEEEE!!!

https://github.com/ichttt/MCLang2Json

@Spaceboy Ross You're at a very important point in your programming/modding learning and my main advice is "slow down and understand". You're jumping around across a number of advanced modding topics while missing some fundamental skills related to Java programming as well as setting up your mod. Cutting and pasting and guessing at changing values is not a good way to develop your ability and will lead to weirder and weirder bugs in your code. Now you certainly SHOULD use vanilla code as a reference, even copying portions of it, but you also MUST understand what the code is doing. So if you have a parameter name that is something like p_191986_1_ in the vanilla code you should rename it according to what it actually does. Your code will become much more readable, and your ability to modify it properly will improve. If you don't understand Java well enough to know that you can rename the parameters then you really need to practice getting stronger in Java as well. For parameters passed into a method, the name of the method and the TYPE and order of the parameters must match the call, but the name can be anything you want (and should be meaningful). In order to figure out what the parameters really mean (so you can name them correctly) you should look at the Call Hierarchy (right-click on method name in Eclipse and it will give you that option) to see where other code that uses the method is. You can look at that and it is usually pretty obvious then what the fields represent. Then, regarding debugging you have not followed my suggestion regarding adding lots of console print statements through your code. You should be able to identify what is wrong with almost any code within 10 minutes if you print out the right info to trace the execution. In your case you keep saying "it doesn't work" but that isn't helpful. You need to figure out if your method isn't being called at all versus whether it is being called and executing differently than you expect. I don't personally use debug mode much (I find console statements work for most cases) but if you're going to do that then you need to learn how to do that properly -- setting breakpoints, ensuring the thread settings are correct (so other threads don't time out), and learn the various ways to step through (or into) the code. There are lots of tutorials for that. The reason why we're all jumping in on this thread is because you're showing a lot of potential and obviously have a passion for modding, but you're missing some important lessons you need to learn in order to really progress. So, simply (a) figure out what the code is supposed to do (b) trace the execution.

Do Not EVER download anything that isn't from the MinecraftForge.net domain. EVER. If it comes with a fancy looking installer, or any bundeled software then it's not Forge. People should feel free to file reports with google about these malicious/abusive website: https://support.google.com/groups/answer/81275?hl=en

I believe we as the users are grateful for the work that the developers do. Without them I don't believe that we'd be able to enjoy Minecraft in such a huge way as we do now. Many of us do not have the talent or even the attention span to do what they do. I made this account just to say thank you to the developers of this amazing tool. Thank you!

iT makeS youR postS neaR impossiblE tO reaD. herE, i'lL dO thE lasT letteR. iT iS noT betteR, it'S wronG anD noT propeR englisH.

A stack of size 0 (but still with some other item) won't == ItemStack.EMPTY but it will still resolve .isEmpty() as true.

Although there are ways of generating structures from NBT files Minecraft uses min and max x, y, and z coordinates to decide which blocks go where. The StructureVillagePieces class is an example of this. In order to create a new village component (building) create a class that extends StructureVillagePieces.Village which will be your code for the building itself. An example of this can be found here. You will also need to create a handler the implements IVillageCreationHandler in which you will refer to your new village component class. In your main class preInit you will then need to use VillagerRegistry.instance().registerVillageCreationHandler(); to register your handler and MapGenStructureIO.registerStructureComponent(); to register the component itself. If you want to create an entirely new village instead of single buildings I recommend looking at Galacticraft's code for Moon Villages. Although I haven't look into them much I imagine End Cities and Woodlands are similar to this.

You need to have a TileEntity constructor without any arguments (and calling super()), as that's used for instantiating a TileEntity when the world's getting loaded. My advice: don't use custom TileEntity constructors. Instead, use setters as it removes any confusion with constructors.

That tutorial is dumb. It's close, but dumb. Extract the MDK to whatever folder you want your project in. Run gradlew setupDecompWorkspace eclipse In eclipse File -> Import -> Existing Project -> Your folder. There is no special 'Forge' folder or anything. Your project is your project.

Alright, this is stupid. Jred you're a fucking moron. First you have no idea what a Eula is. Second you have no idea how to actually read and comprehend the Best practices that you're referring to. Yes, there is a group of people out there who are in a circle jerk of misunderstanding and misinformation. People don't like working together, people don't like change. It's just how it is. The basic gist of it is that if you're screwing around with SOMEONE ELSES CODE. Which is LITERALLY the only reason to write a coremod, then you should be open to showing what you're doing. You're say you are doing vanilla and forge bug fixes. THEN SEND US THR BUG REPORTS SO WE CAN FIX THEM! As for the packaging, you can have whatever the he'll you want in a single download. End use wise this changes NOTHING. Download one jar file. Put it in your mods folder. DONE. The point is to structure what's IN that jar file so that Forge or any other loader out there can separate things out and manage things properly so that the crap we have been dealin with for the last 4 years can end. I could go on about the entire premis of the first post being stupid and clearly showing you lack of understanding of vanilla or forges code. But I neither have the time or the crayons to explain it to you. seriously this is nothing but you showing that you have no idea what the he'll you're talking about. This is done. PS: it's been a long time seince I've done a rant like this. Guys I've tried to behave but seriously this fucking guy...

i would suggest going to 1.11.2 and then later when many people will be playing 1.12 upgrade again

Here I'll show the final code that definitly works for me: //spawn structure if (!worldIn.isRemote) { WorldServer worldserver = (WorldServer) worldIn; MinecraftServer minecraftserver = worldIn.getMinecraftServer(); TemplateManager templatemanager = worldserver.getStructureTemplateManager(); ResourceLocation loc = new ResourceLocation(Reference.MOD_ID,"t1"); Template template = templatemanager.getTemplate(minecraftserver, loc); Utils.getLogger().info("=======0======="+template); if (template != null) { worldIn.notifyBlockUpdate(pos, iblockstate, iblockstate, 3); PlacementSettings placementsettings = (new PlacementSettings()).setMirror(Mirror.NONE) .setRotation(Rotation.NONE).setIgnoreEntities(false).setChunk((ChunkPos) null) .setReplacedBlock((Block) null).setIgnoreStructureBlock(false); Utils.getLogger().info("=======1======="+loc); template.addBlocksToWorld(worldIn, pos, placementsettings); Utils.getLogger().info("========2======="+pos); } }

Do you have a pack.mcmeta file in src/main/resources with pack_format set to 3? If you don't, Forge will load your mod's resources using the LegacyV2Adapter IResourcePack wrapper. This means that your lang files will be loaded with the old mixed-case names (e.g. en_US.lang) rather than the new lower-case names (e.g. en_us.lang). If you do, your lang files should be loaded with lower-case names. Try refreshing your IDE project (i.e. click the "Refresh all Gradle projects" button in IDEA's Gradle window or re-run the eclipse Gradle task) and/or rebuilding it.

Minecraft.getMinecraft().entityRenderer.enableLightmap(); You are enabling it(even though it should aready be) but not doing anything with it at all. If you are going to work with the lightmap - do so, set it's coordinates. Your issue is that you are using too much GL and not enough tessellator. tessellator.getBuffer().begin(GL11.GL_QUADS, DefaultVertexFormats.POSITION_TEX) -> tessellator.getBuffer().begin(GL11.GL_QUADS, DefaultVertexFormats.POSITION_TEX_LMAP_COLOR) And then you can simply have the lightmap coordinates in your VertexBuffer vertices. Or even better use a FastTESR. It's format is BLOCK([3]f pos, [1]hex color, [2]f uv, [2]s lightmap) so it already has the format that is fine for your cause. That is the preferred solution as if you do it correctly(and it is pretty easy to do so) you will achieve exactly what you need without any need for GL calls at all and will gain a significant performance boost.

I have already updated our internal tools to support the last few snapshots, its not that big of a deal. It'll be some work but it shouldn't take to long. Just waiting on 1.12's official drop.

If you already understand Java (and it's painfully obvious that you don't), you would know exactly what you need to replace null with. This forum is for help with Minecraft and Forge, what you are asking for help with is Java, which is neither of the above. So before you keep whining about how nobody will help you, realize that you're in the wrong place. As is stated on this forum all the time, this is not a forum for teaching Java because you should already have a reasonable understanding of Java before you start trying to make mods. You'll find that everyone on here is perfectly helpful, you're just not listening to us.