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:

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

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.

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()); } }

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!

No

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.

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

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.

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.

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.

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.

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.

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/

"I want to make a block that works like the log works..." Normal person: "Let me go look at the log class, oh hey, BlockLogNew extends BlockLogBase!"

the JSON system is considered the proper modern way to do it. One advantage is that it will be able to be replaced in resource packs rather than "hard coded" into your mod. Unless you're doing something very unusual with recipes (in which case you might implement your own IRecipe class) you should use the JSON along with the registry event system.

Nvm I see the problem. In your EnumHandler your not setting the name of the Enums to the value of name. Your not setting the size either, just the I'd.

Fixed: https://github.com/MinecraftForge/MinecraftForge/commit/52702e5cc9c629b3b2baff6a726aabb168aced16

Also no. ModelLoader is correct.

Mm, you don't say.

Many Block methods (like Block#isOpaqueCube) have been deprecated by Mojang to signal that they should be overridden but not called; the corresponding IBlockProperties methods (inherited by IBlockState) should be called instead. Other methods have been deprecated by Forge to signal that they shouldn't be used at all, these usually include a comment explaining which method to use instead.

TLDR: You can't. And when you could you shouldn't.

Minecraft is a tag on Stack Overflow (so is Minecraft Forge) and when Documentation happened I was all "yes, this would be a nice thing to have" so that there was a community managed*, central repository of Minecraft modding examples. Documentation (as a feature) has (largely) failed, but those articles I wrote are still there. *Pull Requests to Read the Docs don't count: if the owner(s) of the git repo disappears for any reason, they can't accept the PRs. Not to mention the fact that the Read the Docs doesn't even mention json models and a whole slew of other topics. Like a page on how to get started, which has an existing PR that has had no action in six months.

How to be got at texturing in a Minecraft style: 1) find an existing Minecraft texture that's similar to what you want. Like the hay bale 2) extract it from the Minecraft jar file 3) open in GIMP 4) use the hue saturation brightness tool to make it a different color (brown) 5) yer an artist now, Harry

This post also gives another example using the newer registration events and a couple simple items and blocks.

Personally I use custom packets more because I find it easier to understand what's going on when I've created it from scratch, rather than adapting vanilla things.

Best thing to do is upload your code to a github repository, it's much easier for people to see when you do so. It's free, and quite helpful. http://www.github.com For ore generation, I just went to google and typed in "minecraft forge 1.11.2 ore generation". You basically need to implement an IWorldGenerator. http://www.minecraftforge.net/forum/topic/53563-111-world-generation/ looks like it has some info you could use.

There are three main editions of Minecraft: Computer (which I previously referred to as Desktop), Pocket and Console. Computer Edition is the original and runs on most PC operating systems (including Windows, OS X and Linux). It can be modded with Forge and other types of mods. Pocket Edition is a rewritten implementation of Minecraft for mobile devices. Windows 10 Edition is a port of Pocket Edition to the Windows 10 platform. It can be modded on some mobile platforms (e.g. Android), but I don't know of any mods for the Windows 10 Edition. The Minecraft Marketplace will allow you to buy additional content for Pocket Edition/Windows 10 Edition. Console Edition is a rewritten implementation of Minecraft for consoles. It can't be legitimately modded. There's no way to run Forge or other Computer Edition mods on the Windows 10 Edition, but there's nothing stopping you from running the Computer Edition on Windows 10.

See if you can find the source for the Morph Mod

And this is how retardedly easy it is to do what we were asking you to do: https://dl.dropboxusercontent.com/u/7950499/2017-02-08 12-09-43.mp4 It's literally "right click, open type hierarchy." Which I even told you. THIS is why I keep bashing my face into my desk and making snarky comments. It's that fucking easy.

the last time i downloaded forge, i catched a cold. i dont know if that was accidental. but that can happen... last time i downloaded minecraft i got diarrhea... viruses everywhere...