Leaderboard

Is there any way that I can update mods without going to Curse every single day to download the latest version of that mod?

Well... good Evening? I was drawn here because I might be too stupid to understand this Doc of yours: Doc about Registries. And while I do know a tiny bit about Java (at least Oracle thinks so), I feel pretty confused at the moment (see nickname *cough*) Thing is.... all guides out there are for older or outright ancient versions of Minecraft - following them step by step does work to a given degree, but as soon as they start registering their Tutorial-Object and blocks and whatnots, they use GameRegistry.registerItem() to do so. But I'm afraid that option is no longer valid. I got the forge beta for 1.12 (because, I'm feeling like that Minecraft 1.14 will be released more early than everything I could do, and I need to learn this sooner or later anyway), had some "fun" setting up IntelliJ (until I found a topic form Mr diesieben07 here out of the forum) and then... well... Minecraft starts, my empty mod shows up inside the mods list (yay) but then... one might want to have his mod do more than just showing up in a list. So I got a dumb Item that needs to get registered. At the moment its just this: import net.minecraft.creativetab.CreativeTabs; import net.minecraft.item.Item; import net.minecraftforge.event.RegistryEvent; /** * Created by Seine Eiligkeit on 27.06.2017. */ public final class ModItem extends Item { public static Item tutorialItem; public static final void init(){ tutorialItem = new Item(); tutorialItem.setUnlocalizedName("tutorialItem"); tutorialItem.setRegistryName("tutorialItem"); tutorialItem.setCreativeTab(CreativeTabs.MISC); Item. } } I know, some stuff still is missing (or needs to get removed, like the orphan "Item" I forget to delete), but anyway: Where Item. is placed at, all Tutorials I found went strait for GameRegistry.registerItem(). And now... lets see... I may need to do this, according to the Doc you wrote down: @SubscribeEvent public void registerItem(RegistryEvent.Register<Item> event) { event.getRegistry().register(tutorialItem); } But WHERE do I put this? I'm a bit certain that it need to be placed somewhere in the commonproxy (because all participants need to get it registered), or am I wrong? Is it a method like the pre-, past- and -init() Methods one should put there? I tried this, having my ModItem return itself as a Singleton when called using init(), but is that correct? At least minecraft didn't crash, or throw an exception and a infinite loop wasn't created either (the only thing I can do is creating unexpected infinite loops). So did I use the correct approach, or am I wrong? You know, there was a System.out.println("wuhu") inside the registerItem() some time ago, but it didn't show up in the console anyway. I looked for code examples, but all I found was using the GameRegistry.registerwhatever(), and non of these where about 1.12. So my options came down to ask someone who actually does know how to do this. And, I feel sorry to say this, but your Doc looks a bit like the stuff my boss at work usually creates for documentation purposes: great for people which actually did this somehow many times and need a mind lift to get on track. But I didn't see a minecraft-mod from the inside until now...and I'm pretty confused. So: Where do I need to put this, and what's up with with the @ObjectHolder I red about? Greetings, Confused Merlin

Good Evening, the last time to...night. Thank both of you for pointing out whats wrong with my texturing. It was the "all" that was missing; I'm sure I overlooked this in the tutorial I had the instructions from. Oh,And @Jay Avery, ianusinchq is the correct name I changed it in the grand classes post because I was wondering what a troubled junior mod maker may think if he reads this. Maybe something like "what is that ianus thing?" and "do I need this too?" When its "modclass" chances seem to be higher the one realize "oh, so thats the point where I put my mods name into!" Now... I think this has been resolved. Should I change the Title to (solved) or something like this? Or is there anything anyone might want to add? (can I change the title anyway?) Now have a nice day / night and see u the next time I get confused. Greetings, (not so) ConfusedMerlin EDiT: and here we go - purple blocks, but this time in a less disco-ish look

Assuming that your TE's code had not changed I think you are missing a super call here. You at the very least need to know the position of TE from the NBT so it can be loaded into the world properly.

You already have a much more convenient way of finding out if your code still has problems: try it and see what happens!

NBT is for storing data when the world is saved, it's not relevant to this issue. When the block is placed, you need to store the placing player in the tileentity. You have access to the block and the placing player in onBlockPlacedBy, you just need to get the tileentity and store the information in there. Then when someone tries to activate the block, you check the tileentity to see if they are the allowed player. You have access to the block and the activating player in onBlockActivated, so you just need to get the tileentity and check the information to respond accordingly.

We know what you're trying to do. We're trying to tell you that you're doing it wrong and how to fix it, but you keep taking that advice and not doing it.

Something is adding -Xmx512M to your JVM options, probably through the JAVA_OPTIONS environment variable. Remove it.

Which Minecraft version are you using? 1.11+ requires all resource file names to be lowercase. If you don't have a pack.mcmeta file or you do and it sets pack_format to 2, lang files will be loaded with the old mixed-case names (e.g. en_US.lang) because Forge wraps your mod's IResourcePack in a LegacyV2Adapter. If you have a pack.mcmeta file that sets pack_format to 3 (the current resource pack version), lang files will be loaded with the new lower-case names (e.g. en_us.lang). It's best to convert to pack_format 3 and lowercase names now in case Forge stops special-casingpack_format 2 resource packs in a future version.

The registry system has been overhauled in 1.12, you need to use registry events. Forge's documentation explains them here. You can see some examples in my mod's init classes. Unlocalised names should not be used for anything except display/translation purposes, use the Item's registry name (IForgeRegistryEntry#getRegistryName) as the default model location (since it's the default model that vanilla loads for every Item). Use ModelLoader.setCustomModelResourceLocation/setCustomMeshDefinition rather than ItemModelMesher#register to register Item models. Do this in ModelRegistryEvent. The tutorial you followed is outdated and poorly written. None of this is new to 1.12; ModelLoader was introduced in 1.8, registry names were introduced in 1.8.9, IForgeRegistryEntry was introduced in 1.9, registry events were introduced towards the end of 1.10.2.

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!

Well, I can tell you to stop using ITileEntityProvider because it is old and unnecessary. Just override hasTE and getTE in the block class. Won't solve your problem, though.