Leaderboard

So I'm working on a DayZ styled mod and I want to add a thirst and blood. Can anyone help me do that?

Oh ok thanks, the closest thing I found was this public boolean func_226566_ei_() { if (!this.onGround && !this.isElytraFlying() && !this.isInWater()) { ItemStack itemstack = this.getItemStackFromSlot(EquipmentSlotType.CHEST); if (itemstack.getItem() == Items.ELYTRA && ElytraItem.isUsable(itemstack)) { this.func_226567_ej_(); return true; } } it is kinda hard to figure things out without mappings, but I'm trying my best lol

1.12.2 is no longer supported on the forums. You will need to update to a current version to receive support. See the LTS link at the top of every page for more information.

What: Not using static initialisers. Why: Using static initialisers does not allow you to control when your objects are created or the order in which your objects are created. Consequences: Using static initialisers prevents other mods from overriding your objects, prevents forge from being able to dynamically load/unload mods and can cause weird, unreproducible crashes. How: Use the @ObjectHolder annotation if you need static references to your objects and create & register your objects in the appropriate registry event. (Note: before registry events Modders created and registered their items in preInit. This practice became out of date in 1.7 with the introduction of registry events, and is no longer possible in 1.13). If you have a creative tab that uses an item for its icon & that item references that creative tab in its constructor, and both use static initialisers, they both depend on the other being loaded first to function properly. So whichever one actually gets loaded first will cause the other one to get loaded & the other one will use a null reference to the initial one. Since you don’t control the order in which classes are initialised this means that either the item or the creative tab will have a null creative tab/icon and you don’t know which it will be. This causes hard to track down bugs (if you don’t know about this behaviour as it will compile fine). Related: (trying to find SO article about how 3 classes that depend on eachother for a value will have the runtime value depend on the order in which they are loaded, will edit this to add the article if I find it)

@ObjectHolder(Main.MODID) public class ModEntityTypes{ public static EntityType<UnicornEntity> UNICORN = EntityType.Builder .create(UnicornEntity::new, EntityClassification.CREATURE) .size(5F, 7F) .build("unicorn_entity"); } Do not create your registerable stuff with static initializers. Honestly not 100% sure the reasoning, but everyone that knows what they're doing on here says not to, so I'm sure it's a good reason! You want to build/create your EntityType in the Item registration event, like I had previously said. DO NOT register it. Just create it, and assign it to ModEntityTypes.UNICORN. Then after it has been created, you can create/register your spawn egg within the Item registration event. Then register (no need to build/create) your UNICORN in the EntityType registration event, since it has already been created. If you get a crash after this, post updated code, as well as the crash report. Don't assume the crash report is the same as your original post. Also, please use spoiler tags or an external site (github gist, pastebin, etc) to post your logs so it's not a mile of scrolling to get to the bottom

Hey, I want to ask something about the older versins (1.7.10 in this case) I understand that you don't support people anymore, but now they shut down the maven repositories or something like that? At least I can't build / setupWorkspace anymore and that's not only me. Someone else made a thread about it like 8h ago too. Can someone explain me why? I was payed for a mod and used that version because the customer wanted me to and now I can't send the mod to the person I programmed it for and I'm probably losing money now because of that. Please don't just reply with "you won't get support on older versions" or something like that, I really want an answer. Robin

Well...

Update Regarding LTS System: Please read The Big Forge Update Earlier this year, 1.13 was announced and the snapshots started coming out, the update was relatively small, but enough to be a hurdle for mod developers. This combined with 1.12 stabilizing, and a few fundamental Java changes that broke modding in general, made the Forge team decide to use this opportunity and work on cleaning the years of technical debt that Forge had accrued. During this time, it was discovered that a lot of things needed updating. In fact, well, everything did. And so, it was done, a full rewrite of practically everything Forge related. This took a long time, longer than originally anticipated. But what’s the outcome of this you might ask? A lot. cpw’s mod launching system (ModLauncher) allows for parallel mod loading and support for more modern Java versions. (Considering the original was written to target Java 6). The Forge installer now runs tasks at install time once, rather than doing it every time you run the game. These alone provide dramatic reduction in launch times. ForgeGradle, the “devkit” for creating mods, has been rewritten and is faster at, well, everything. It also integrates much better with IDEs. What does that mean, you ask? Simple. Mods are nicer to make. (Also 100% less setupDecompWorkspace.) MCPConfig allows for much easier MCP updates, and is public source too, so people can see exactly what's going on between updates. In short: There was a lot of work to do. And now that it's done, future updates will be much, much smoother. 1.14 and 1.15 The 1.14 release came around, just in time for the rewrite to be finished, so it was time to get the ball rolling again. The bulk of the restructure work was done through 1.13's life, so all that remained was actually seeing how it was to update all of it, and it went pretty well. A lot of improved systems exist now that make developing for these modern versions far easier and just better in general. The 1.15 release was relatively simple, even if Mojang decided to restructure everything and make changes to how the rendering works. (Taking some of our systems in the process, don't worry, this is a good thing.) 1.15's rendering changes were mostly a refactor, and we expect 1.16 to be a large update to rendering. This plus 1.14 seeing growth is why we chose 1.14 to be a candidate for LTS. (More on that further down.) Hopefully this kind of restructure from them is a rare thing in the future, but we welcome the change, since it often brings improvement. Although the rendering changes may pose a tough hurdle for some, the update for most should be relatively straight-forward. Forge support and LTS Forge's support for Minecraft versions will try to follow a predictable cycle, assuming Mojang also follows a predictable cycle. We will always actively target the latest Minecraft version, as ever. We will now also deem a previous major Minecraft version as "LTS" (Long Term Support). The LTS version will receive support for modders and players alike, however all new features must target the latest version first, and then may be backported. An LTS version differs slightly from the latest version, in that any new features you may want to add to it, must target the latest version, only once it has been merged in, can it be backported. (The exception to this is if the feature is non-applicable to the latest version.) The Forge Team will also mostly be focusing on the latest. This is so the community has time to stabilize a bit and gives modpack developers some time to create something special. But still have Forge running full steam ahead. Late last year (Happy 2020!) a vote was held privately with many developers of various Minecraft projects to determine which version will be LTS: Should 1.12 remain LTS or should 1.14? A vast majority chose 1.14, and so, from now on we are dropping 1.12 from support, and 1.14 is now LTS. What does this mean? 1.15 is latest. It will get full support. 1.14 is LTS. It will also get support, and new features, but new features must be made for 1.15 first. 1.12 is no longer supported on this forum, no new features, and no more bugfixes. All other versions are not supported. This means if you come to us for help with those, we will ask you to update. This includes crashes/bugs. To keep with Mojang's history of releases, we expect 1.14 to stay LTS for 12-18 months, giving plenty of time for modders and pack developers alike. However, this may change depending on what surprises Mojang has in store for us. Finally… Thank you. Thank you to all the modders/developers, all the players, and especially to all the contributors. The Minecraft modding community would not be what it is without you. You are responsible for the striving ecosystem we have today. We hope this new year brings you all you desire, and we look forward to seeing what you create. And now time for some shameless plugging, if you like Forge, please consider supporting us. http://www.patreon.com/lexmanos - The Forge Team.