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.

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

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

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/

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

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

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

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.

Things are going to change. And people will complain about it. There isn't anything that can be done about it so threads like these are useless.

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.

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.

Okay, except comparing your code to the vanilla Overworld chunk it seems you have some relevant changes. I expect that many of these are changes you've done while debugging but I just want to make sure. Some things that are different from vanilla: - in the generateChunk() method you have removed all the parts where it generates most features like caves, ravines, villages, monuments, mineshafts, etc. - in the populate() method you have removed the woodland mansion generation. - your code has a method called getScatteredFeatureSpawnList() which in my Forge Reference Library seems to now be getMonsters(). I guess they changed that between your version of 1.12.2 and mine. None of the above should be an issue and I assume you probably did the removing of features as part of the debug, right? Okay, looking further at your code, in your WPMedieval class you are associating a biome provider for a single biome that is your custom Generizer.MEDIEVAL. Since that isn't a copy of vanilla I wonder if your problem is actually with your biome stuff. I'm not that experienced in custom biomes, but I'd suggest greatly simplifying that as a debug step. Only register one biome and don't remove any vanilla, or maybe even just do nothing in terms of new biomes, and see if the problem still exists. Now one thing that I always run into trouble with regarding world gen is that the relationship between classes is very convoluted. It is possible you're running into such trouble. For example in your WPMedieval you specify that the DimensionType is OVERWORLD, but if you look at OVERWORLD it is defined to have a WorldProviderSurface. In other words your world provider is pointing to a dimension type that says it has a different world provider. I have no idea if that is an actual problem, but doesn't seem "healthy". Frankly the way that the world gen classes over-reference each other can cause some weird things like that. You might want to try creating a custom DimensionType that properly points to your world provider and clean up any other such things you might find. Similarly you might want to try making a custom WorldType instead of using the vanilla one because again it might have references to a different IChunkGenerator or other stuff that conflicts with your stuff. You also have two custom IWorldGenerator classes registered. Have you tried isolating to see if they are causing trouble? -- like don't register them and see if issue goes away. Also, in your IWorldGenerator classes you end up calling the CustomGenMinable class which extends the WorldGenerator class. So you're kind of mixing the Forge IWorldGenerator class with the vanilla WorldGenerator class. I don't know if that is a problem, but I think the idea is modders should use IWorldGenerator purely. Just some ideas. -

Override Block::onBlockPlacedBy to set the TileEntity values.

@diesieben07 Sounds like another one for the common issues thread. We've had this one about three times in the last week.

Also no. ModelLoader is correct.

Mm, you don't say.

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

Technically there are 4 different names: The original source (only Mojang has this) The obfuscated names, aka Notch names (these are generated by the compile process and look like aa.bbcfa, you would see these if you opened the vanilla jar in JD-GUI, these will be arbitrary as source code changes) The SRG names (these are the ones you're seeing, generated by the decompile process with names like p_12345_c and func_765432_f and are generally stable as the source code changes and new versions are released) The MCP names (these are community supplied via MCPbot, mapped to SRG names)

Minecraft offers an option to reload resource packs while using the key combination SHIFT + F3 + T. In many cases one wants to adjust how the model looks in any of the rendering types (firstperson_righthand, gui, etc). If one modifies the original JSON file that has the transform information in the IDE and presses SHIFT + F3 + T in Minecraft, nothing happens. One has to recompile everything and start again Minecraft to see the changes. But that is only because one is modifying the source and not the resource JSON that Minecraft is loading into memory. If you modify the one that is being loaded into memory, the changes will be displayed once you press SHIFT + F3 + T in the game. Eclipse: Modify your JSON file containing the transformations and copy paste it in its respective place under classes/production/[YOURPROJECTNAME]_main/assets. Overwrite the existing one. Press SHIFT + F3 + T in the game to reload the resource pack. For example, let's say I am making a mod whose root directory is named Tutorial. I have an item whose model is located in Tutorial/src/main/resources/assets/tutorialmodid/blockstates/item3dmodel.json. I would modify that file and while the game is running I would copy paste it in Tutorial/classes/production/Tutorial_main/assets/tutorialmodid/blockstates/item3dmodel.json. Then I would press SHIFT + F3 + T in the game to reload the resource pack which would show my changes. IntelliJ IDEA: Modify your JSON file containing the transformations, go to the Build menu, and click Recompile '[nameofyourmodel.json]'. Press SHIFT + F3 + T in the game to reload the resource pack. Alternatively you can right click the JSON file either at the project view or in the tabs and hit Recompile.

For future reference If I understand this correctly, we would be allowed to put the coremod into its own jar and put that jar into the actual mod jar. While this might not be very useful for modders that use a coremod in multiple mods, it might be useful if its only a change for a single mod. Question I have: could you point me and others to the jar extraction mechanic FML provides? I dont intend on using a coremod at all, but just in case.

yes

Because Windows 7 is still better than literally any other version of Windows?

You know the day is good when you beat one of design problems. GL11.glEnable(GL11.GL_STENCIL_TEST); // Turn on da test GL11.glClear(GL11.GL_STENCIL_BUFFER_BIT); // Flush old data GL11.glStencilMask(0xFF); // Writing = ON GL11.glStencilFunc(GL11.GL_ALWAYS, 1, 0xFF); // Always "add" to frame GL11.glStencilOp(GL11.GL_KEEP, GL11.GL_KEEP, GL11.GL_REPLACE); // Replace on success //Anything rendered here becomes "cut" frame. GL11.glStencilMask(0x00); // Writing = OFF GL11.glStencilFunc(GL11.GL_NOTEQUAL, 0, 0xFF); // Anything that wasn't defined above will not be rendered. //Anything rendered here will be cut if goes beyond frame defined before. GL11.glDisable(GL11.GL_STENCIL_TEST); // Turn this shit off! EDIT: Edited code to more universal.