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:

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.

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.

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.

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....

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

@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.

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/

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.

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.

I agree! A percentage of completion shown on the main download page would be great! Or just something to show people how far development is. If there's anything I've learnt in my career, it's that people don't like to be kept out of the loop or uninformed about something they invest a lot of time into. People like to see progress. This would be beneficial to people so they can clearly see progress, and it would be beneficial to the devs because it would lift a weight off of their shoulders by not having to deal with people constantly asking about progress or if it's done yet.

http://howoldisminecraft1710.today/

@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.

100% wait. The fundamentals of the Minecraft codebase have changed quite a bit; as such, the Forge layer on top of it will need to change drastically. I'm almost certain that even those of us who have been using Forge for awhile will have to "re-learn" the 1.13 structure, as it were. So you may as well wait until then to start learning so you don't have to start all over

Dont do this. First off modders need to know the basics, and if they cant download a zip, and extract it they shouldn't be modding. Secondly, automated downloads of Forge is discouraged because the main source of revinue for Forge to pay our server costs and the like is the ads on the download page.

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

also works with assets\minecraft\textures\gui\mojang.png (but not in all forge versions)

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.

@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.

No no no, not-user-friendly is Blender. It took me 2 hours to move a camera and change the animation speed on an already complete scene. I lost track of the number of times I had to quit and start over.

IntelliJ isn't the only program that does it, I've run into a few others. But every time it's "undo, undo, undo...ok redo...fuck, why did that just delete a line? Oh, stupid keybinds. FINE, I GUESS I'LL RETYPE IT." I don't mind ctrl-shift-z being redo and not ctrl-y, it's the binding something destructive to ctrl-y that irks me. Yeah, just completely fuck with someone who's never used your software before so they can't fix the mistake because they didn't know what your keybinds were, that's just brilliant.

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

Chiming in as one of the other leaders of Sponge, I've always believed that making heavy modifications to the game (as coremods sometimes do) would benefit from being viewed source, since often times debugging odd interactions between SpongeForge (and SpongeCommon as the larger part) have been often times difficult to say the least to work out where the issue lies. That being said, I strongly support the idea around coremods being viewed source for the sake of inter-coremod compatibility overall, as the goal with SpongeForge has always been about remaining compatible with as many mods as possible out of the box (even if the technological attempts at maintaining that compatibility is not as evident or thought up very fast). As @Zidane has mentioned, SpongeForge will be making the necessary changes in the very near future to abide by these requirements. As per usual, my goal with inter-mod compatibility is always to provide as much descriptive console spam error logs to help Sponge and/or the mod itself get a better fix and make the users happier overall.

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.

You need to call World#notifyBlockUpdate from the TileEntity whenever a value used by Block#getActualState changes. This tells the server to send the TileEntity's update packet to any nearby clients as well as telling them to re-draw the chunk containing the block, using the new actual state to select the model. You also need to call World#notifyBlockUpdate from TileEntity#onDataPacket so that the client re-draws the chunk whenever it receives the TileEntity's update packet. You can see an example of a block that uses TileEntity data in Block#getActualState here: BlockColoredRotatable, TileEntityColoredRotatable

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.