LexManos

Since it's been brought up, gunna pimp out my Paetron for those who don't like the ads. Money is a necessary evil, sorry. Link in my signature.

Don't trust everything you read on the internet kid. Especially of it's a magic mod that suposidly increases MC performance. There is a reason why Speiger has been banned from not only Forge, but many other major MC projects. Yes, Forge keeps some extra data about the textures in memory. This is to speed up rendering, lighting, and the like. There is a triad off of some extra memory usage for massive decreases in cpu usage. And at the end of the day, RAM is cheap, CPUs are not. Also, The guy who wrote the changes Forge does is now actually employed at Mojang rewriting their rendering engine. So i'd trust his code over Speiger's. The same goes for any other "performance" mod you see out there. There are good reasons they arnt officially part of Forge. Most of those mods break other mods, simply because the deep level of control that mods have over their own data and MC.

Or if you dont want to use Twitch, just run the Forge installer from our site. Run install client for running client side/single player. And put mods from curse in the mods folder.

That what we will be doing for 1.13, the first few builds will only have the bare bones of what we have gotten done. But we arnt working on FORGE itself right now, we're finishing up the installer, gradle, building, etc... All the NON-Forge parts of the modding ecosystem. Once those are done and good to go, then we'll start forge builds and start working on Features. As it sits there are only a few things left, the most nosed being IntelliJ run configs and TESTING. I've been public about this on my twitter, so those who wanna help can help., if they know how.

And this kids, is how NOT to ask for help.

You can't get something that doesn't exist yet...

You must use java 8

Never gunna happen.

I have no sympathy for you players who use Netease, their entire business model is bad and abuses the hard work that we here at Forge, and other modders do. If they want to start complaining that I don't produce Forge fast enough, then they can start helping out. But no they just sit back, toss DRM onto things, and just rake it in. It'll be done when it's done.

If it was from our official site, then it's fine. Windows likes to say anything it detects as a executable file, that hasn't paid them a stupid amount of money to be on their whitelist, can harm your computer. Because it can, even stuff on their whitelist can, any executable code you download from the internet can harm your computer. But if you trust the people you're getting it from, then you just ignore that. Always be on your guard, make sure you're getting what you expect from the host you expect. We also provide the signatures of each file on the downloads page so people can verify that it didnt get corrupt while downloading.

Alright, i've skimmed this but the last part with recommending people use @Optional is just flat out wrong. It wouldn't 'not run' it would be stripped from the class. Thus any code calling it would error. Using ASM hacks is DISCOURAGED. At the end of the day all you have to do to make your code have a soft dependency on anything else, is simply not load the code with the hard dep unless you know the dep is satisfied. Have event handlers from other mods? if (Loader.isModLoaded(modid)) BUS.register(new DepSpecificEventHandler()); Have caps that could not exist at runtime? @CapHolder public static final CapabilityHolder<Foo> FOO_CAP; private Object myFoo = null; TEInit(){ if (FOO_CAP != null) myFoo = new Foo(); } It really isn't that difficult. The JVM doesn't know a class exists unless the code referencing is invoked/resolved. If statements are usually enough to prevent this, if that doesn't work {something deeply resolves the code} then you can hide it even more with a Supplier.

MCPConfig on the forge repo allows for viewable decompiled code. However it doesn't have the tools to reobfusicate/package jar mods because that era of Minecraft modding is dead. And we should not be supporting it. As for the FG side of things, getting a raw Minecraft deobfed jar to link against will be possible.

As far as I know, MCP 1.13 is not coming out. There is no need for it. And there is a replacement project that does things in a far better way.

We are currently working on 1.13.0, however, once that's done. 1.13.1 is a rather small update and will be released directly afterwords. Again, we are working on the toolchain re-writes first. Right now the stumbeing block is Ama.. I've been waiting for a week for him to sit down and atleast spec out the Userdev side of things but he likes to not communicate. Things are progressing on the other side tho. The installer is re-written to do install time deobfusication and other tasks. Forge now loads in the official launcher with our changes, and the new modloader system. A large chunk of our patches have been reviewed and reapplied. You can keep an eye on our progress on our Forge Github and ForgeGradle Github

Also be SURE you ONLY ever get it from Forge's official download site: https://files.minecraftforge.net/ There are MANY sites out there that are pretending to be us, and paying Google to be at the top of the search results that are nothing but malware. Anything that you get from our official site is safe, as Umbra pointed out, the source is publicly available to view on Github for everything we make.

Any coremod that breaks is on them to fix. Optifine has a highly targeted compatibility range with Forge so you have to refer to them on what version works. We do not support or endorse coremods because 9 times out of 10 they are doing things wrong that actively break the game and other mods for thing that Forge already supports without breaking things. Lets take 'Obfuscate' for an example. First off the name is very poorly chosen for this type of environment, as it means to hide/bewilder/obscure something, so right there he's admitting to doing things he doesn't want you to know about. Secondly: EntityLivingInitEvent, he touts this as the best way to attach extra DataParameters to entities, Except, if you do this to someone else entity, then it breaks the networking syncing as these values are synced by ID number, and that ID number is the order in which the parameters were registered, with values that overlap for subclasses if the parent gets a new value added after a subclass is created. This is better done using the Capability system that Forge has to attach random data to entities. Third: ModelPlayerEvent. VANILLA already has an extensible system for managing the player's model, as well as rendering extra things related to entities and models. Why does this need to be a separate coremod? And lastly: RenderItemEvent. This is a event that used to be in Forge. It was removed with the adoption of the vanilla model system. Which can do anything that you need it to do in a safe, controlled, efficient manor. There have been many people requesting that we re-add this hook. But their requests usually go like this: "Gimmie Render hook!" "Ok, what does the new system not allow you to do? Maybe we can design something that can suit your needs." "GIMMIE THE RENDER HOOK!" Which obviously, with the performance issues, compatibility issues, and rendering issues that this hook allows/encourages, is not a valid argument. Ya, you remember the days when 1/2 your screen would go darker then the other half. Or trees would wobble around spastically, or entity models would disappear depending on what items you had in your hand? Ya that's all caused by this style of hook. So, basically, Coremods break, real mods don't. And you should not be using coremods, or any mod that relies on such coremods. Its up tot he community to tell the mod authors that coremods are unacceptable by refusing to use any mod that forces them to use one. Until then you will get no support for them here. You have to go directly to the coremods that break things.

Boys and girls, Don't be like Zim, he has received a 24 hour ban for being an ass. He had to come in here getting offended on behalf of Fandomaniac, for a simple exchange that we resolved in one post. As for his accusations that I am a crap programmer who breaks mods on purpose, No. These are COREMODS that are breaking. And as everyone knows COREMODS are mods that are explicitly designed to screw with the internals of Minecraft/other mods in unknown ways. By default being prone to breaking, and as such unsupported on these forums. This is why the crash log says go to them BEFORE coming to Forge. Which is what my original post pointed out, and this whole thing could of been avoided if more people read their log files.

don't ping me, and your issue is the same you have a crapload of coremods installed that are breaking things.

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.

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.

That is incorrect, due to Mojang's re-write of the recipe system, the wildcard is just a shortcut to for(ItemStack subitem : item.getSubItems()) Damageable items do not work in simple recipes as the auto fill and matching system Mojang wrote doesn't support them. Recipes have to explicitly state they want to use a damageable item.

Forge has never provided a mac specific download. Only OS specific version is the windows installer as many people have issues running java applications on misconfigured windows. Just as many have issues running the jar on macs, but there isn't a convenient slim native wrapper for macs.

This is the prime example of why a cutom ingredients, and constants are a thing in the Forge system.

Its a library, you can use it like a normal library. However you SHOULDN'T use it in Minecraft because it is already in Minecraft. Once 1.13 Forge gets released you'll have Brigadier at your disposal. You can take a look at how Forge uses it here: https://github.com/MinecraftForge/MinecraftForge/tree/1.13-pre/src/main/java/net/minecraftforge/server/command