Leaderboard

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.

Forge for 1.16.1 The first Forge build for 1.16.1 is now live thanks to the hard work of: covers, illy, jd, garrett, giga, and the rest of the forge crew. With their help we were also able to release the updates to MCPConfig for 1.16 and 1.16.1 the same day that vanilla did. The Nether Update has brought a lot of changes to many systems, and as with any update there are likely to be bugs. We are still evaluating and working on some of the systems like dimensions and trees to come up with the best system to allow for modders to integrate with vanilla’s new dimension system. We are also expecting Mojang to release a 1.16.2 fairly shortly and are prepared to work on updating to it as soon as they do. As with every update, there are bugs and other minor things to be expected. Please report them responsibly and have fun with the new version! Changes to the LTS There are a couple changes happening to the Long Term Support system originally introduced here. We are moving the LTS from 1.14.4 to 1.15.2 to reflect the community being more active and also changing how we chose what version the LTS will be to be more maintainable. We are now going to be supporting the latest (n) and second latest (n - 1) versions, with the reservation of potentially having the LTS being n - 2 if something is Mojang ends up really making a mess of a particular version. That being said we still will be providing critical fixes for all possible versions. Do not worry about 1.14 being instantly dropped while we are still working on updating 1.16, as we have a customary grace period for while everything is still in flux before we start strictly enforcing the LTS rules. New Team Members We are happy to announce we've added a few new members to the Forge team officially. These people have been a part of the community for a while and have been helping out a lot. The first two are new members of the 'Toolchain' team. Which is responsible for some of the backend tools, like the decompiler, update scripts, gradle and other internals. The others are joining our ever growing list of Triage team members. Who are responsible for managing the issues and pull requests on our github. They are the front line of bug reports and feature requests, treat them with respect and listen to what they tell you! Toolchain covers1624 JDLogic Triage AshersLab Curle OrionOnline pupnewfster

Forge Version: 31.1.0 Minecraft Version: 1.15.2 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Intro: This is the first recommended build for 1.15.x! This would of been out a few weeks ago, but Mojang decided to release 1.15.2, so we figured it'd be best to hold off until that version stabilized. As you may have read, we dropped 1.12 support a few weeks ago and now concentrate on 1.14.4 and 1.15.2 until 1.16 drops. 1.15.x brought many changes to the rendering engine and incorporated some parts of the new rendering engine known as "Blaze3D", but this release was still a lot faster than 1.14.x, thanks to the mod loading and launching rewrite we started in 1.13 being complete. Also thanks again through all the contributors for this release that helped to fix bugs and bring new features to forge. Changelog: New: Removed and cleaned up old code Remove third-party vecmath library in favor of using the new minecraft functionality Allow logos in the mod screen to be scaled differently Allow models to override be overridden when using OBJ models Make more Data Generator stuff usable by modders Add support for custom nether portal frame blocks Added new Click Input Event Added entity nameplate rendering event Added support for gui_light model option Re-implemented the ITeleporter interface to allow moders to control dimensional teleporting more easily Allow mods to more easily specify a custom texture for chests Add support for sending fluid stacks over the network more easily Add support for fluid overlay rendering for custom fluids Fixes: Fixed incorrect item lighting Fixed broken stairs and fence rendering Fixed keybindings not saving Fixed items being too small when dropped Fixed mod list screen Fixed capability data not being transferred when returning from the end Fixed incorrect warning screen caused by removed vanilla sounds Fixed game crash with modded entities Fixed bucket rendering Fixed crash when parsing custom obj models Fixed items not being colored correctly with custom colors Fixed items rendering too dark Fixed many other rendering related issues Fixed particles not rendering correctly due to wrong GL state Fixed incorrect item lighting Fixed crash when using certain fonts Fixed crash when building quads for rendering Fixed dyes tag not automatically finding new dyes Fixed Big Mushrooms not generating Fixed Raw Mouse Input Event Fixed fullbright lighting Fixed Fish Bucket not being usable by mods Fixed breaking overlay Fixed Widget Foreground Color not allowing pure black Fixed entities turning on a spot Fixed RenderType loosing it's mapping for registry replacements Fixed extended version of getLightValue not being used everywhere Fixed Wakeup Event not being called at the correct spot Fixed mod resources ordering Fixed Player Changed Dimension event providing the wrong dimension Fixed Keybinds modifier not working correctly Fixed Chunk Data Load Event not fireing Fixed small typos in forge config Fixed restoring blur mipmaps Fixed Right Click Block not being called on client and server Fixed crash on new java 8 versions in development environments Fixed a bunch of events not having the new rendering context Fixed Attacks/Punches not registering Fixed functionality for rails to have different maximum speeds Fixed registry desync, causing entities or sounds to be mixed up when connecting to a server Fixed compression system used by the installer to make downloads smaller.

What is this? This is a collection of common issues and recommendations for the Modder Support subforum. Instead of repeating these things over and over again, a link to this thread can be used instead. This post will be updated as needed. Suggestions either via PM to me or in a separate thread to keep this topic clean.

I got into minecraft modding recently and was surprised by how hard it is to find useful up-to-date information. Because of that, I decided to document my learning journey and write a book about Minecraft modding for beginners. It applies to Minecraft 1.16.1 and the latest version of forge. Keep in mind it is still a work in progress. More chapters will be added in the coming days. Suggestions and questions also are welcomed. Link: https://thebookofmodding.ml/

Thanks for the amazing work, it was such a fast release!

I know this topic is a bit old, but I just had the same issue and a Google search points here. If your packet is working correctly, and its just the warning in the log, you've likely made the same mistake as me. Inside the "messageConsumer" you provided when registering your packet, you need to set the packet handled flag to true. "context.get().setPacketHandled(true);" If it isn't set to true, NetworkHooks.onCustomPayload will return false, and ClientPlayNetHandler.handleCustomPayload will post the warning

There may be a primer for 1.15 -> 1.16.1; however, in the current state of 1.16.2 onwards and with the release of 1.16.4 coming soon, I doubt you will be able to find one. Not many people understand the new system of world generation through data driven systems, so a primer will probably not be out for a while. However, since I'm not a fan of leaving any post unanswered, I'll try and take a basic stab at it. - Blocks have been abstracted even more (AbstractBlock). You'll find that the properties have been turned into functions of some kind to allow for even fewer blocks. For example, the blockstate can control how much light is emitted using a ToIntFunction. Also, for a tool to be required to mine a block, the setRequiresTool parameter must be set. - Block properties no longer have an interface IProperty. It has been relegated to just Property now. - Item properties have also been removed and isolated from the Item class. They are handled within ItemModelProperties and can be registered using the appropriately named methods there. - Rendering methods now take a MatrixStack parameter to correctly orientated it on the screen. If you find any unmapped methods, you will most likely need to stick a MatrixStack variable somewhere within there, nothing else. - Server reload listeners are added via AddReloadListenerEvent. Client reload listeners should still be handled either within your mod constructor or FMLConstructModEvent for better thread-safety. - DeferredWorkQueue is now officially deprecated. You should use the enqueueWork method provided in all parallel dispatch events. - Entities store attributes within GlobalEntityTypeAttributes. If your entity does not have a registered attribute within here, then it will most likely error. For reference, this is not thread-safe. - Models now take in a RenderType to define what layer they will render within. By default, they use a no cull cutout layer. - Every mods.toml must have a license entry. Otherwise, your mod will error and crash. - LazyOptionals have a few changes as defined in 33.0.21. LazyOptionals map to LazyOptionals now using lazyMap. map returns a regular Optional. Note that this Optional will throw an error if the map function somehow results in a null entry. filter also returns an Optional now. Finally, a new method called resolve has been added to convert to an Optional directly. - ExistingFileHelper is now required within tag providers. Existing mod resources can be attached using '--existing-mod <modid>' as of 35.1.3. - Finally, I will mention world generation. Currently, all of world gen has been delegated to a data driven system. This is a mixed point for some users. Currently, forge is working on a more dynamic system to allow all of world generation to be handled within JSON files; however, that is not completely possible yet. Therefore, there are a few workarounds to handle this via BiomeLoadingEvent. Here, you can add configured features and structures to already existing biomes along with some other details I'll let you explore for yourself. - Creating biomes can either be done one of two ways. You can either create one using BiomeMaker for the Biome builder itself in some fashion and register it using the RegistryEvent or you can initialize a dummy biome and create it via JSON. To get your biome to spawn in the world, this is still handled within BiomeManager instead taking a RegistryKey (a concatenation of the registry and the object name). To set it as a spawn biome, that is handled when you build the biome itself. - Features have been changed in an interesting way. Instead of having a Feature with a single Placement, features can now have multiple placements. This means a placement can determine the amount, the height, the spread, etc. The way placements are handled are similar to a stack. The first placement you attach will be the last to execute if you need an example. Therefore, when creating a ConfiguredFeature, things like a count placement should be handled as the last chained method. There are a few helper methods within that makes it easier to generate count placements, although they will most likely remain unmapped until the next mappings push. Cyborgmas pointed out something with registering these entries that non-registered ones causes an issue with the codec, so they should be handled and registered probably within your common setup or at the very earliest after placements have been registered. - If possible, you should try to create all your world generation edits within JSON files to better prepare yourself for when the system comes out of the experimental phase. However, that is currently optional until everything updates. Hopefully I covered the gist of the changes from 1.15 -> 1.16.3. There are definitely many more that I've missed such as background music or the brain system within entities. However, those topics are best explained in greater detail with more specific questions. Same goes for the information I missed within world generation JSONs. Good luck on your updates!

Forge Version: 34.1.0 Minecraft Version: 1.16.3 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Intro: Hello everyone, it's finally that time. A recommended 1.16 build is here. We had to wait longer then I wanted to because there were a lot of problems with the initial 1.16 release from Mojang, enough that it was obvious that a .1/.2 was needed. So we waited for Mojang to stabilize the 1.16 branch, out came .1, .2, and .3. Each one same with its own surprises, the main one we have to mention is 1.16.2's major re-write to biomes. Allowing them to now be data driven. This is a very powerful thing that moves Minecraft to a more flexible state, but it also meant all our old hooks had to be re-designed. Every Minecraft version moves towards a better engine, but unfortunately that means we have to work with the interim steps. So if there are any issues modders face with Biomes/Worlds now being mostly data driven, speak up an expect a few iterations of the tools Forge provides you for these things. But remember, now that we are in a Recommended Build it means Forge will stay stable API wise for the rest of the 1.16 lifecycle. Mod License: There has always been little skirmishes about what license a particular mod is released under. To try and help address that, we have now made it mandatory that mods specify a "license" value in their mods.toml. That is the text file containing metadata about the mod, such as version, name, author, etc. This is a simple text entry, it can be anything the modder wishes as long as it is present. The MDK ships with it filled in for you with "All Rights Reserved" which is the default copyright stance in almost every jurisdiction. I highly encourage modders to take a moment and think about how they want their mod to be used, modified, and distributed. And then pick a license that properly expresses their wishes. If you want a open source license https://choosealicense.com/ can help you pick. However, it is your mod, so whatever license you want is fine. Please do not take this as a push to one style or another. Simple as a reminder to choose something and let your users know. Support: With this being released, it officially triggers our support policies as described in the LTS post. This means that 1.14 is now EOL. It can still be used and developed for. It just means that we no longer provide active support for it. And we encourage all users/modders to update to a more modern version. Changelog: New: New model loading system with improved performance and functionality. Reorganized mod loading to increase loading speeds and better integrate with vanilla threading. New armor knockback resistance hooks Added custom item integration with Piglin trades. Added support for items to have pumpkin-enderman like behavior. Added build system verification tools. Added event for controlling data/asset reloading. Added hook to add modded Raid members. Added a dedicated event for registering commands. Added Mixin to the installer. Added event for entities leaving the world. Added IModBusEvent marker interface to all events that are fired on the ModEventBus vs the main Forge bus. Added mandatory (1.16.2+) license field in mods.toml Added support for modded elytra-like items. Added hook to allow Biomes to specify edges better. Added hook to allow better block control over tool-block interactions. Added hook for manipulating whether a fluid can create a source block. Added an EntitySizeEvent instead of EntityHeightEvent Added user friendly exceptions when config loading fails Added particle culling, which should increase performance by not rendering particles that are not on screen. Added better datagen validation for tags. Added dataprovider for global loot modifiers Added scaffolding movement hook Added support for custom tag types Added BiomeLoadingEvent, that allows for mods to edit biomes. Fixes: Fixed caching issue with mod manifest files. Improves starting times. Fixed vanilla models not correctly deferring to Forge's system. Fixed early load GUI showing when running data generators Fixed block update issues related to reverting with BlockSnapshot Fixed locate command patch. Fixed block drops not working in some cases. Fixed villager trades having non-applicable enchants Fixed tooltip rendering issues Fixed sneaking while swimming Fixed harvest level and harvest tool Fixed screen tooltip not displaying Fixed creative screen arrows Fixed attribute registration on modded entities Fixed block render types not being applied to block items Fixed swimming speed being too slow Fixed break speed event having null position Fixed tag issue when connect to vanilla server Fixed some classes being unsafe in concurrent loading Fixed capability data being null in player clone event Fixed double chests updating issues Fixed language parsing Fixed datagen crashing due to tags Fixed client chat received event not having the sender UUID Fixed loading screen color and text to match new Mojang Studio's colors. Fixed improper handling of baked lighting in forge light pipeline Fixed getQuads not having model data Fixed tooltip render events not having matrixstacks Fixed multi-layer item rendering Fixed stencil support initialization Fixed swap offhand keybinds not working in GUI Fixed null checks missing in ForgeIngameGUI Fixed incorrect keybind names Fixed LivingEquipmentChangeEvent not being posted Fixed canRepair not being true by default Fixed race condition for DeferredRegister with custom registries Fixed client world capabilities not being collected Fixed TagEmptyCondition using client tags and not server Fixed ExtendedButton using narrator text Fixed LivingJumpEvent for players on horses Fixed duplicate mod files from mod file scan causing objects to load twice. Fixed model & blockstate datagen inconsistencies Fixed datapacks being not loaded correctly in the Datapack menu screen Fixed soundloadevent being posted on the wrong bus Fixed chunkdataevents using different data tags Fixed patch for PlayerSetSpawnEvent Fixed custom burnable blocks. Fixed modded overworld biomes not generating Fixed ClimberPathNavigator spinning when mob width is small Fixed SleepingTimeCheckEvent not being fired in initial sleep test Fixed biome generation error Fixed cats not having the AnimalTameEvent fired Fixed rail rotations Fixed errors being hidden by mods not being shutdown Fixed rendertickevent using wrong partial ticks when game is paused Fixed missing outdated notification in the main menu “mod” button Fixed debug world not generating modded blocks Fixed hoes and new 1.16 blocks not having proper harvest levels Fixed dry farmland being destroyed even with crops into it Fixed handling of the ModelRegistryEvent Fixed InvalidModFileException not saying which mod was invalid Fixed the client rejecting the server, because of missing tags. Fixed config iteration order Fixed logging issues with pack.png loading for mod datapacks Fixed DelegatingResourcePack performance Fixed LazyOptional not being clear which operations were actually lazy. Fixed the HighlightEntity Event not being fired Fixed minor bugs with bamboos, enchantments, and conduits Fixed RenderNameplateEvent not having partial ticks Fixed duplicate tag wrappers causing a crash Fixed custom teleporters crashing Fixed zip paths crashes. Fixed modloading crash reports with QOL tweaks Fixed crashed with tile entities with no collision boxes Fixed forge tooltip util. Fixed model to baked model inconsistencies. Fixed json biomes not setting a registry name correctly. Fixed forge GuiUtils not using MatrixStacks Fixed fluid filling sounds Fixed some inner biome fields not being accessible Fixed world rendering potentially causing a crash Fixed CommandEvent’s result not being used Fixed container items being consumed in brewing stands Fixed forge light pipeline causing block offsets twice Fixed ToggleableKeyBinding’s differences with vanilla Fixed issues with custom tag types and optional tags. Fixed some inner biome fields still being immutable. Fixed grass disappearing when forge config alwaysSetupTerrainOffThread was true

and because you use MCreator you got this far and are now bitching because you can't get something to work and you feel we should just do the work for you when you haven't even put in the effort to learn Java. There is a reason we dislike MCreator and you are only reinforcing that opinion. Learn Java.

Forge Version: 31.2.0 Minecraft Version: 1.15.2 Downloads: Changelog: (Direct) Installer: (AdFocus) (Direct) MDK: (AdFocus) (Direct) Intro: Here we go again for 1.15.2, this has a ton of bug fixes, developer improvements, as well as preliminary support for Java 13+ so we'll see how that goes. Changelog: New: Added hook to allow customized overlays when swimming in custom fluids. Added support for suppliers in FoodItem, allow easier modder extension. Added model data to BlockModelRenderer Added system for global loot functions, allowing modders to affect all loot tables using data. Added new early loading screen that shows before Vanilla even exists. Should seamlessly transition to vanilla. Can be disabled via config. Added new Data generation features. Revived the Forge lighting pipeline, to improve rendering performance. Disabled by default. Added hook to control hill biomes. Added PlantType to the extensible enums. Extended GUIUtils to be more useful. Added hook to override tool requirements when breaking blocks. Added hooks to allow buckets to be better used with custom fluids. Added hook to allow bees to use custom hives. Added ability to use stencil buffers for mods. Added constructor to Music Discs for easier modder extension. Fixes: Fixed lighting issue in GUIs for some models. Fixed bug causing equip tooltip to display when unnecessary. Fixed client desync when interact event is canceled on the client. Fixed invalid arguments passed to first person hand renderer. Fixed chunk watch and unwatch events not firing correctly. Fixed vanilla bug related to rendering states. Fixed error when players join servers in a dimension that doesn't exist. Fixed ItemStack TER not being called. Fixed custom teleporters not being used when moving from the end to overworld. Fixed custom teleporters triggering end game credits. Fixed set dimension command not setting position correctly. Fixed Conduit and Beacon activation on vanilla servers. Fixed potential issue with clients sending invalid data to server. Fixed javac compiling issues on some JDKs Fixed tps and gen commands not working. Fixed note blocks not changing state correctly. Fixed ownership leak in ItemStackHandler. Fixed server config loosing dimension type when using custom dimensions. Fixed vanilla bug that caused the byte order of buffers to be incorrect. Fixed buffer batching not copying all data correctly. Fixed tag serializing empty data. Fixed annotation processor skipping duplicate annotations. Fixed annotation processor incorrectly tagging child annotations. Fixed binary issues when using JDK 9+ and targeting J8. Fixed vanilla recursion issue in advancement loading. Fixed potential NPEs in RegistryObject. Fixed mod resource and data packs being sorted incorrectly. Fixed automatic event subscriber picking wrong mod id when in multi-mod sources. Fixed BackgroundScanHandler erroring on some servers. Fixed swim speed and reach distance not having localization info. Fixed milk buckets removing too many potion effects. Fixed chunk data save event being fired with null world in some cases. Fixed resource leak in vanilla loot table handler. Fixed hoppers not fully inserting into custom inventories with non-standard max stack values. Fixed null item stack being sent to player destroy item hook. Fixed some blocks being darker then they would be in vanilla. Fixed pressing escape not matching pressing done on the mod list screen. Fixed removedByPlayer not being called on the client when breaking blocks. Fixed infinite loading screen when mod resources error. Fixed fluid tanks calling changed events when simulating. Fixed tile entities persisting incorrectly when blockstate changes. Fixed CrowGrowEvents not firing for Bamboo Fixed vanilla screens where pressing escape doesn't match pressing done. Fixed mod duplication issue when using a symbolic links as your mods folder. Fixed server config directory remaining locked after server shutdown. Fixed level change event not firing during enchanting. Fixed duplicate call to chunk load events. Fixed typo in registry alias serialization causing infinite loop. Fixed particles not colliding with the ground correctly. Fixed model transformation ordering. Fixed OBJ models ignoring deffuseLighting setting. Fixed blockstate json serializer using incorrect string. Fixed incorrect argument passed in RenderPipeline potentially causing crash. Fixed FireBlock using flammability instead of spread speed when looking for places to spread.

I'm trying to update my mod from 1.51.1 to 1.15.2 but I'm getting this error: Could not find net.minecraftforge:forge:1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1. Searched in the following locations: - file:/C:/Gradle/caches/forge_gradle/bundeled_repo/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.pom - file:/C:/Gradle/caches/forge_gradle/bundeled_repo/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.jar - https://files.minecraftforge.net/maven/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.pom - https://files.minecraftforge.net/maven/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.jar - https://libraries.minecraft.net/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.jar - https://repo.maven.apache.org/maven2/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.pom - https://repo.maven.apache.org/maven2/net/minecraftforge/forge/1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1/forge-1.15.2-31.0.1_mapped_snapshot_20200125-1.15.1.jar Possible solution: - Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html I've tried several mappings including: 20190719-1.14.3 which is included in the mdk download. I've also tried a fresh project from the mdk download and I get the same error (only with the 20190719-1.14.3 mappings of course). Dropping it back to 1.15.1 (1.15.1-30.0.51) works again and I can change mappings, etc so my gradle setup is working otherwise, just not for 1.15.2 versions (the 1.14.4 version of my mod is also working fine with gradle).

This appears to be fixed with version 2020.1.

Be honest with me... did you edit your error to replace 1.7.10 with 1.14.3 so your thread wouldn't be locked?

I would just add onto this with make sure you take breaks and get sleep before you post here too because honestly we all know that really helps you spot the logic mistakes.

Fun. /me leaves to go play with his Linux

That checks distribution (dedicated server vs client). Client in this context still includes the integrated server, which is not what you want. @ultra_reemun Please refer to the documentation article about sides. Also note that tick events always fire twice per tick, you must check TickEvent#phase.

Hello everyone ! Let me present you my Masks mod for Minecraft Forge ! This mod lets you craft masks that give you the powers of different Minecraft mobs. To craft a mask, you’ll need a life essence. This item has a 1% chance of being dropped every time you kill a mob. You can use a life essence to craft a raw clay mask: Cook it to get a stringless clay mask, add a couple strings to it, and voilà, you get a nice mask to wear! Now, this mask looks nice, but it gets even better when you use it to craft monster masks. Here is a list of the masks you can craft so far, and what they can do: Passive animal masks Neutral animal masks Sea mobs masks Overworld monster masks Nether monster masks That’s all there is for now, but I plan on adding more masks. Please note that the config file lets you: -enable and disable shaders for each mask -change the life essence drop rate -change the xp cost of some of the mask powers DOWNLOAD LINK (Mediafire)

This is why you always need to post your complete code and not just snippets of what you think is important. And what's especially bad is that you made those snippets look like they are the complete thing. DO NOT DO THIS. It doesn't help anything.

Don't tell ppl "do your research before posting here" as the README.txt file that comes with the MDK of Forge 1.13.2 25.0.9 and 25.0.10 says to use setupDecomWorkspace its obvious that the README.txt file was not updated but you don't have to be a dick.

No. Stop. writeToNbt and readFromNbt are for saving to disk. Server-side. If you want to sync stuff to the client (assuming you want to use the vanilla mechanic, which uses NBT), you need to override a couple of methods (warning, this is a giant mess): getUpdateTag - Returns the data that should be sent to the client on initial chunk load (i.e. when it gets into render distance, etc.). Call super here and put whatever data you need to have available on the client in the NBTTagCompound returned from super. Then return it. handleUpdateTag - Called on the client with whatever tag was returned from getUpdateTag. By default this calls readFromNbt, which is a terrible default, but oh well. getUpdatePacket - Called to produce a subsequent update packet. You should return a SPacketUpdateTileEntity here if you need the data on the client to be updated from time to time. In theory you can return a partial update here, but usually it is best to just call getUpdateTag and pass that NBTTagCompound to the packet. The int parameter of the packet constructor can be set to whatever unsigned byte you like best. onDataPacket - Called on the client when the packet produced by getUpdatePacket is received. Usually you just need to call handleUpdateTag with the NBT data from the packet (SPacketUpdateTileEntity::getNbtCompound). getUpdateTag will always be called and it's data sent when the chunk is initially transferred to the client. You cannot stop this. If you need to update the client-side data later (i.e. you need the packet produced by getUpdatePacket to be sent), call World::notifyBlockUpdate on the server. You should care about when you call markDirty. You should not care when writeToNbt and readFromNbt are called. Remember, these are for saving the world to disk. Minecraft will do that when it sees fit. You need to call markDirty after doing the changes (so Minecraft knows to save to disk) and then call notifyBlockUpdate to notify the client of these changes (assuming you are using the syncing mechanism described above). Both happens server-side. That was in the context of "NBT is only used for saving to disk". ItemStacks have the terrible habit of using NBT for runtime storage, which is ugly, cumbersome and inefficient.

Do not create a new LazyOptional every time. This defeats the entire purpose of LazyOptional.

Expanding on this: If you intend for your capability to ever be used by other mods (i.e. you're making it part of your mod's API) then using an interface is very strongly advised, simply as good programming practice (expose the interface, not the implementation). If you only ever intend for your capability to be used for storing data for your own purposes, an interface is very much optional. You might decide it's useful to have one, just for tidiness in your own code, but then again you're free just to use a class.

You're trying to use the vanilla crafting GUI. The vanilla crafting gui checks to see if the block being accessed is The One And Only Vanilla Crafting Table. Your block is not The One And Only Vanilla Crafting Table. Therefor the use of that gui is invalid and thus closed.

No problem, glad I could help!

First of all, the name you quoted is not something that comes from Mojang. It is Forge's intermediary mapping, called SRG names. It is used to (hopefully) stay the same between versions so that the already found mappings can be ported forward. In Mojang's release classes, fields and methods are just named after single letters, they have a tool that obfuscates the code. Parameter names (like the one you quoted) are like local variables and as such they are all called ☃. Yes, snowman.

Try deleting your build folder and %USERPROFILE%/.gradle/caches/forge_gradle/minecraft_user_repo/net/minecraftforge/forge/forge-1.15.2-31.2.0_mapped_snapshot_20200514-1.15.1

If blender is too hard for you, you may use Blockbench.

If you haven't already I would recommend giving these a read. They're just Forge Docs. but they explain most of it pretty well. Blender Addon: https://github.com/phonon/blender-minecraft-json Docs: https://mcforge.readthedocs.io/en/latest/models/files/#model-files https://mcforge.readthedocs.io/en/latest/animation/intro/

About Suppliers: https://thejavacult.com/supplier-interface-java-util-function/

You put a `@ObjectHolder` annotation on `ItemInit.example_item` without specifying a modid in either the annotation on the field or on the class (through @Mod or @ObjectHolder). See the documentation on @ObjectHolder for its rules and examples. (ignore the 1.14.x version, it is the same up to 1.16.+)

Assuming you are using ItemStackHandler (you should, change it if you are not!), override onContentsChanged. It will be called whenever the contents of a slot changes.

writeSpawnData only sometimes writes an int. readSpawnData always reads an int. The methods must be exactly symmetrical.

Then use the IFormattableTextComponent API, namely func_240701_a_ which applies a formatting to it.

It's a pretty complicated system to set up a custom village, but definitely do-able. The current Minecraft villages are created using a "Jigsaw" system. In order to do anything with custom villages, you need to understand how these function. This video is a really good explanation of the system, make sure to watch the whole thing. It's from 1.14, but for the most part the Jigsaw system hasn't changed much since then. The 1.15.2 mod "The Farlanders", which creates custom villages, has all of their code available on Github, so if you were to use that code as well as vanilla village files as reference, then you'd be in a pretty good spot. Not much more documentation exists out there regarding doing something like this, so past everything I've given you, there isn't much else available that can guide you in the process.

Decompiling and changing a mod without the author's permission is against our "code of conduct", and is not encouraged. There is a public git repo of MorePlayerModels here, but it is for 1.10.2 and you're on your own to update it.

You use @CapabilityInject to inject the other mod's capability. You can put this annotation on a method too (see the javadocs) and that method will then only be called if the other mod is present. In that method you can then enable your mod's compatibility features. If you put this method in a separate class that class will never load unless the other mod is present.

Block drops are done using loot tables, vanilla sources are a good reference, and the Minecraft wiki has a breakdown of the loot table json. Unfortunately the forge docs are out of date, I use Google and the forums search to get info on stuff I tinker with. Lots of vanilla sources and forums reading!

Jesus lord have mercy. DyeColor has instance fields that store the color values. Change them using reflection. Do not create new DyeColor instances, do not try to modify the code that uses DyeColor, do not pass go, do not collect $400.

Just a heads up, the isActiveItemStackBlocking method inside LivingEntity might be more useful for this case. As for the events not firing, I'm not sure. What is your code, and what are you doing to test it? In some cases, LivingAttackEvent doesn't always fire on players (like if a player is in creative, I think). In fact, it should actually be firing twice on players if I'm reading the code right... Wait nevermind, I think it only fires once. The code is just confusing.

You can learn about custom packets in the documentation. As for your capability data: Assuming it is attached to an arbitrary entity you need to send it as follows: PlayerEvent.StartTracking tells you when a client starts "seeing" (or "knowing about") an entity: they are now in tracking range and you need to send them the entity's data. When the data changes you can use PacketDistributor.TRACKING_ENTITY to send the updated data to all players "in range". Additional considerations need to be made if your data is attached to players: In PlayerLoggedInEvent, PlayerRespawnEvent and PlayerChangedDimensionEvent send the player their own data. When the data changes use PacketDistributor.TRACKING_ENTITY_AND_SELF instead.

So now we're getting into "How do I bypass mod blacklists" territory, I'm going to lock this dung pile.

This is indeed a very bad idea, because the IDs of data parameters depends on their registration order. Data parameters are purely a runtime feature, they are not saved to the world. NBT is for saving to disk. It is not for runtime storage. To add custom data to existing entities use capabilities. DataManager is used to sync a property to the client. If you do not need your custom property on the client, you don't need to do anything. If you do, you need to use custom packets.

The Potion constructor has a baseName parameter, you can use it to specify a custom translation key postfix and include your ModID there without affecting your registry name.

Forge still has to do work even without any mods installed. Arguments about efficiency are rarely fruitful, a few extra seconds of loading for hours of extra content shouldn't be a dealbreaker.

Please keep this forum in English. If it takes half an hour for you to launch the game you are doing something wrong or you have a potato for a computer (Aperture Science never finished that work unfortunately).

Nope. Which is why I don't bother replying to his threads any more.

You need to set the render layer using RenderTypeLookup#setRenderLayer within your FMLClientSetupEvent to make blocks transparent. It takes in two parameters: the block and the RenderType. The RenderTypes are as follows: Solid - field_228615_R_ Cutout Mipped - field_228616_S_ Cutout - field_228617_T_ Translucent - field_228618_U_ Translucent (No Crumbling) - field_228619_V_ Leash - field_228620_W_ Water Mask - field_228621_X_ Glint - field_228622_Y_ Entity Glint - field_228623_Z_ Lightning - field_228624_aa_ What you are looking for is either cutout mipped or cutout so use either RenderType#field_228616_S_ or RenderType#field_228617_T_ to accomplish this.

Some recent version seems to have changed the default way IntelliJ compiles Gradle project. It used to be that it still used the IntelliJ build system, which puts resources and classes in one folder. Now "Delegate to gradle" seems to be the default, and gradle puts resources and classes in two separate folders. Make sure to set IntelliJ to not delegate to Gradle (https://www.jetbrains.com/help/idea/work-with-gradle-projects.html#delegate_build_actions).

I cannot for the life of me understand how capabilities work. It may just be the way I'm needing to implement them, so I'll be talking about that specifically. I'm currently making a mod that adds a modifier to the player's health to allow for more than just the generic 20 max health. Previously I used a class that contained a player cache and had functions to store and modify the NBT data of said player. Well, I was recently told to use capabilities now, but I have absolutely no idea how to do that. From what I understand, capabilities are supposed to be an easy way to store data alongside Minecraft classes. For example, an easy way to store data for a furnace or something. What I don't understand is how the hell this is supposed to work; what is a capability? Is it a modification to the way things work? Or is it supposed to be an easy interface between NBT data and Minecraft objects? How the hell do you attach a capability to an Entity? Do I need to provide my own Capability Provider, or use one of Forge's? If I need to use one of Forge's, which one do i use? How do I provide my own, in the case I need to do that (the forge documentation is useless and outdated). What does it mean to "expose" a capability? What is a capability type? What does it mean to "attach" a capability? Capabilities do not make sense at all! I will attempt to break this down so you can understand what I don't: "In general terms, each capability provides a feature in the form of an interface, alongside with a default implementation which can be requested, and a storage handler for at least this default implementation. " "each capability provides a feature in the form of an interface," what does this even mean? I've completed my college course on Java and still have no idea what this implies. A Java interface is used to easily describe classes and provides a layer of abstraction, it is not supposed to provide features. You cannot "implement" a feature using an interface. "alongside with a default implementation which can be requested," what? A default implementation versus... what, a custom one? Someone else's? Why not just implement what you need instead of attempting to provide an interface? "a storage handler for at least this default implementation," again, what is this 'default implementation', and what other types of implementations are there? Also, what in the world is this implementation? I, alongside many others, learn best by example, but the examples on the Forge docs don't provide any context whatsoever. The text refers to things that haven't been talked about, and implies that you have already created things that you didn't even know existed. How am I supposed to have made an "instance of the underlying capability type" if I didn't even know I needed to make one? Maybe I'm just having a hard time understanding Forge's documentation, but I have no idea what capabilities are supposed to be, what they provide in functionality, and how they're supposed to be "easier" than just directly interfacing with a player's NBT data. And yes, I have looked in the source, and no, it doesn't help whatsoever because if I don't even know what they do in the first place how am I supposed to understand an implementation? Note: Once I truly understand the purpose of a capability and how to implement one, I would love to make a PR to help improve the wording of the docs.