LexManos

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

And this boys and girls is why you don't use internal packages. Either way, update your mods.

Things have to break in order to get better. Its just something that people have to deal with. Objectively the java Minecraft engine has gotten better in all the recent updates. There is a reason why Forge doesn't port old things to the new versions even tho tons of people complain. Because once they see the changes they realize they are good. Mojang is not concerned with the between-version updating. They are concerned with the engine itself. Holding themselves back because it might inconvenience modders is not what they should be doing. Anyways, at the end of the day people can write for whatever they want, but the community AS A WHOLE, should move forward and keep up with the current version. 1.13 is being a major challenge, but hey it's worth it.

First off, you can't even spell my name right, secondly for those who see this, this is the thread he got a warning for, specifically the post where he called us all assholes http://www.minecraftforge.net/forum/topic/65936-forge-server-error/ As you can see, nobody cussed at him. As for us being assholes, because we are blunt and have rules, and refuse to support older versions does NOT make us assholes. The analogy I like to take is you going to Microsoft, and asking for support with Windows 95. They will tell you to either sod off or pay them a ABSURD amount of money. As for the way we speak to you, like we know 'everything', it's because piratically we do. In regards to the software WE'VE WRITTEN and spent the last 5+ years supporting and developing! You coming in, and failing to follow our directions on the SIMPLEST of errors just shows your arrogance and stupidity. {Note, I used stupidity, and not ignorance, because ignorance implies a ability to update your thinking} As for the youtubers who still play 1.7.10, that's fine. People can PLAY whatever they want. Hell you can {tho its highly discouraged} develop for whatever you want. However the line is drawn with your trying to force US to develop/support the old versions. It's a simple concept, if you want our help, stay updated. If not you're on your own. So ya, your last ban was for a week, you obviously didn't learn your lesson, so now enjoy the lifetime.

Short answer: No Long Answer: All of this fluf just causes modders to do things incorrectly. All your default values are wrong, and nobody will change them thus causing duplicated defaults all over the place. Auto-magical registration is just ASKING for things to be statically initialized which your examples are showing are the case. Which is something we've been crusading against for years because it one of the things that prevents mods from being hot swapable. Not to mention your little hack to swap the current mod for registration is bad. As it screws up override tracking as well as bypasses the warning about invalid registry names. At the end of the day, you are not saving any time/code. As you still have to initalize your mods SOMEWHERE {you're doing it in preinit, you SHOULD be doing it in the Register event} and your method promotes way to many bad habits and technical issues that we've been trying to get modders to fix for years.

something is causing the extra --version argument to be passed in. As its not something that happens on our end alone I must assume that its LiteLoader adding the extra argument. Not sure why. Also, don't post basic tech crap on our issue tracker. Thats for confirmed issues only.

Honestly none of that needs to be done. The loading screen is supposed to be somewhat simple. As for rotation, you can animate your image however you want. And no, it is intentionally designed to not add extra massive textures. You have the animation, use that.

Quick glance seems to be that it just needs to have someone write a mod to sync ban lists and the like. Nothing that we need to do on our end. You have to ask them to write a mod version of the plugin.

Re-download/update Forge.

@jredfox Please stop spouting your ignorant nonsense. this is not the place for basic java tutorials. @diesieben07 This thread is over. The re-written forge will load on j8+ It has J9+ in mind but due to Minecraft currently targeting J8 it must maintain compatibility. This is a tricky thing due to a lot of java's refactors in J9. But we are confident we can get everything working.

There may be a build or two for 1.13.0 but once the fundementals are in place we'll be updating to 1.13.Whatever. Things are still being re-written. We're not to worried about the minor changes in MC versions. It's the major ones that are gunna take some time.

Update, its a simple concept. You can still play whatever you want, but if you want support for it update. Think of it like any other piece of software, nobody is gunna stop you from booting up a Windows 3.11 machine. But do you expect to go to Microsoft and have them actively supporting you?