Leaderboard

I've been there. My tablet doesn't know the word "do"

Since this is such a big update for forge, is there a way to keep more in the loop of updates of how far the team will be till done? Or any ways people can help, other than to not ask for 'when will it be done' threads? And I am not asking when it is is done, just how to be kept in the loop of how far you guys have been able to be with it.

The method has fixed the problem. Should I change the title to [Solved]... or something like that? I am new to the Minecraft Forge forums

Not now. I am currently trying to do so. This might solve the problem I will update my code and see if it does

Thanks! I will read through this and solve the problem...

Try removing All of these Edit: the offending core-mod appears to have been NotEnoughIDs

Forge Version: 1.12.2-14.23.5.2768 Minecraft Version: 1.12.2 Downloads: Changelog (Direct) Windows Installer (AdLink) (Direct) Other Installer (AdLink) (Direct) MDK (AdLink) (Direct) Universal (AdLink) (Direct) Alright boys and girls it's that time again. Even tho the Forge team is working hard on 1.13 development, which is going well, we have almost all the final tools finished and the installer working, we have not left 1.12 stagnate. There have been many bug fixes, features, and exploit fixes in this new version. Minecraft Forge 14.23.5 Changelog: ============================================================================ New: Cleaner error handling for mod exceptions thrown during loading. Stricter validation of recipes to prevent exceptions and issues on clients. Reworked server console and input handling. Cleaner dimension management code. Performance improvements. New Farmland Trample Event. New Fluid Place Block Event for when fluid changes blocks in world. Added support for FluidStack-dependant colouring to Forge bucket Allow configurations of log levels using system properties: forge.logging.console.level, forge.logging.file.level, forge.logging.debugFile.level Better rendering of models that use the Forge fluid model. Extended IItemHandler to better control what items can enter the inventory. Added custom background image support for creative tabs. Added swim speed attribute to living entities. New resource type sentitive resource reloading. This is disabled by default as it can break some mods that assume old behavior, however it can be enabled in the Forge config. Improved performance of FluidRegistry.getBucketFluids. New SleepingTimeCheckEvent to add yet another way to control sleeping. Removed BlamingTransformer, we run naively on Java 8 now so we do not need to track java version. Optimized some class transformers to improve loading times. Allowed the universal bucket item to update to new fluids when mods get swapped in and out. New event to handle game rule changes. Increased world gen entity spawning performance. Bug Fix: Fixed names in JSON annotation data not matching expected format. Fixed crash from search tree processing invalid recipes. Fixed black flickering on animated models by clamping max diffuse lighting multiplier to 1.0. Fixed scala mods crashing with the json annotation cache. Fixed structure template processors causing cascading world generation. Fixed vertex lighter using stale normal data. Fixed AutomaticEventSubscriber error message. Fixed memory issue related to missing/broken models. Fixed flickering leaves when mods break the blurMipmap settings. Fixed model loading issues when mods declare generic models AND specific models for the same item. Fixed vanilla issue with breaking animation. Fixed FML entity network spawning not using EntityBuilder's factory. Fixed NPE when sleeping in some custom beds. Fixed some ClassCastExceptions incorrectly being logged in FML handshake. Fixed ISpecialArmor to allow for "Unblockable" damage to be handled if the armor opts in. Fixed player movement status not syncing when traveling across worlds. Fixed ItemHandlerHelper.giveItemToPlayer creating item entities with incorrect contents. Fixed potential deadlock when chunkload raises non-IO exception Fixed onItemUseFirst being called when entire actions were canceled. Fixed color events not being fired for mesa and swamp biomes. Fixed received data for last vertex format element not being recorded. Fixed SlotItemHandler.isItemValid check. Fixed Redstone and RedstoneDiodes placement on modded blocks that use BlockFaceShape.SOLID for Top. Fixed loading languages with no underscore in the name. Fixed ModList cache never being updated. Fixed overworld spawn point reset when respawning in another dimension. Fixed modded packets not being able to be sent during ServerConnectionFromClientEvent. Fixed server watchdog thread occasionally crashing on first run. Fixed saved toolbars not working with non-vanilla items. Fixed class loader issue with some apache libraries used by mods. Fixed --mods and --modListFile arguments not making it past LaunchWrapper. Fixed vanilla chunk loading issue related to mounted entities. Fixed vanilla entity tracking issues that caused potential duping exploits. Thanks Aikar.

The getField method from Vanilla creates a level abstraction that I don’t think any Modder wants or needs. You should just use getCapability(ItemHandlerCapability) (read more about capabilities here https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/) or a method that returns your ItemStackHandler (you should still be using capabilities, use of a shorthand method is allowable for internal use though). For syncing you just need to override a couple of methods https://mcforge.readthedocs.io/en/latest/tileentities/tileentity/#synchronizing-the-data-to-the-client

That is exactly the case, The JRE that the Minecraft launcher installs does not actually inform the OS that it's installed anywhere. So running the jar normally, or through Launch4J has no idea that install even exists. We are working on a a new exe wrapper that is specifically tailored to Minecraft, and will check the known default Minecraft locations as well as the known installed JREs. But that's still in the works and needs a lot more testing. Until then, we're stuck with this.

Packets.

@johnpalladiniyt As stated above this is still Work in Progress but we try to finish version 0.4.2 to exit alpha and publish it. At the moment we're working at the Cooking_pot out of TLoZ:BotW. If you want to help you can provide textures for the Meals on this page.

You can view the entirety of Forge 1.13 here: https://github.com/MinecraftForge/MinecraftForge/tree/1.13-pre?files=1 I think that Forge 1.13 is 80-90% done based on: - Forge Gradle 3 is finished (this was the part that unexpectedly took the longest) - I believe the MCP mappings are pretty much done for 1.13 - From what I’ve seen on the comits they’ve managed to get Forge 1.13 (without all the patches) to compile and run (I’m traveling right now so I can’t test it and confirm it myself) - I judge that the rewriting of the mod loading system is probably more than half done as they’ve already merged Minecraft and MCP into 1 “mod” with the new loading system (I think the new loading system is amazing and is a massive upgrade from the previous system) - I think that the remaining 10-20% of work is going to be going through all the patches from 1.12.x and seeing if they still need to exist and if so what changes have to be made to them because of changes to the vanilla code. Here’s the list of patches to review https://github.com/MinecraftForge/MinecraftForge/issues/5162

I agree! A percentage of completion shown on the main download page would be great! Or just something to show people how far development is. If there's anything I've learnt in my career, it's that people don't like to be kept out of the loop or uninformed about something they invest a lot of time into. People like to see progress. This would be beneficial to people so they can clearly see progress, and it would be beneficial to the devs because it would lift a weight off of their shoulders by not having to deal with people constantly asking about progress or if it's done yet.

They'll tackle this in the 1.14 update.

Remove the "display" attributes and change the parent to "item/generated" instead of "builtin/generated" item/generated sets up all of the display tags you'd ever want (for tools/weapons, use item/handheld).