Multimc5: Forge on Minecraft 1.13 and newer requires build system functionality

[baka-gourd]

System Information

MultiMC version: 0.6.5-develop-1213

Operating System: Ubuntu18.04.2LTS

1.13.2 unable to install forge.

Issues:

When i create one 1.13.2 launcher and try to download Forge, It shows me that there is no Forge available for the version, but on the Forge site there is one for 1.13.2
How can i install it?
Maybe you should add the option to install forge from the official installer.

Logs/Screenshots:

[ppoozl]

Forge on 1.13.2 is still on developing. This is beta version.

[tehbasshunter]

As stated by Peterix here there are no current plans for when 1.13.X will be added.

[Josh74000]

1.13.2 modding could be the new 1.7.10 when forge exits beta

[peterix]

1.13 has a very limited shelf life. Forge took forever to update and 1.14 is going to get released in a few months.

[peterix]

And no, there is no Forge for 1.13 available. It is impossible to install the way MultiMC does it.

It might be there in time for 1.14, but no promises.

[Josh74000]

then explain this

[Josh74000]

there is forge for 1.13.2, it can be possible to install it using multimc if you download the universal file

[Josh74000]

this is an alternate way if it isn't available yet

[peterix]

It is not compatible.

[Josh74000]

lets just wait for it to exit beta then

[ppoozl]

Now if you want to launch a Forge client, you will need to pass some arguments to Launcher which is not supported by MultiMC now. If you really want to use MultiMC on 1.13.2 forge, You need to modify the code yourself.

[shedaniel]

Isn't that possible? But at last I can't get it to work so no

[ppoozl]

I think that is a legacy launcher arg. onesix launcher uses another one.

[ScottoMotto]

It is way more complex that simply editing json files. Come to the MMC Discord if you want to keep up with ongoing (often realtime) development.

[peterix]

So far, I got it to run, but installation will be a much harder problem than that.

It essentially involves:

• Designing a new metadata format that is more flexible and supports build rules (download is a build rule with an input of an URL and expected parameters and an output of a file on disk, for example).
• Reimplementing the internal representation of version metadata in MultiMC to reflect that.
• Rewriting all current json parsers to map the old metadata to this new internal representation.
• Implementing a build system good enough to produce the required files.

Everything marked as localBuild in this JSON is a product of a build process:
https://gist.github.com/peterix/304eab305f1f490308b05301ca0d7d2d

Given how complex all of these things already are in MultiMC (due to supporting legacy weirdness going back almost a decade), this is not a simple task.

[peterix]

What is not clear is if the files can be moved, or if forge can be told to load them from elsewhere. Anything that's marked as presenceOnly is not on the classpath and forge magically decides to load it from locations it was not told to look into by anything.

That is IMO a major issue.

[ppoozl]

I get it running by install forge on vanilla launcher, then copy libraries to MultiMC , modify json file and modify launcher args. At this stage, I think it's only simple way to use MMC on forge 1.13.2 as forge changed a lot, so it requires a lot of codes to be developed if you want to autoinstall.

[KabanFriends]

I tried to run 1.13.2 forge on MultiMC and I successfully did it, even with those arguments.
it might be exploitable use of other option so I WON'T tell how did I do it but its ACTUALLY possible to add custom arguments.

For people don't know how did I do it, you should just wait for an official update of MultiMC.

[BaxAndrei]

Any news? :(

[hron84]

@KabanFriends could you please share how you did the install itself? It seems MultiMC not wanting to add 1.13.2 support as they waiting for stable Forge release, which will happen only after 1.14 comes out.

[unnanimous]

@hron84 He's either lying or and **s lol. guess we're out of luck.

[hypehuman]

@peterix How can MultiMC and a particular version of Forge be incompatible? I believe you that they are, but I'm too ignorant to understand how. I thought MultiMC was just a way to keep track of different Minecraft folders. Shouldn't there be some way to manually apply the Forge 1.13.2 beta/daily to a minecraft folder? What if you install Forge 1.13.2 normally and then copy your main MC folder to a MultiMC folder? Actually, let me try that :)

[Dolphin2Point1]

@hypehuman the reason why it is incompatible is they rewrote some of the code, presumably to make it easier to develop for. Now, I need to try to get it running on my pc...

[smbarbour]

The biggest part of it is that certain things have been moved from being done during launch to being done during the Forge install process. This bit is what is pretty much making it a PITA for 3rd party launchers to support it.

[soraphis]

It seems MultiMC not wanting to add 1.13.2 support as they waiting for stable Forge release, which will happen only after 1.14 comes out.

from the forge forum: http://www.minecraftforge.net/forum/topic/70205-before-114/?do=findComment&comment=339930

1.13.2 has been "ready" for quite some time.
It's solely waiting on modders to provide feedback and testing.
I've stated this MANY TIMES. 1.13.2 WILL NOT be getting a recommended build.

So MultiMC will never allow Forge 1.13.2

[peterix]

No. I just have to do the work necessary to include it.

Also, anything said on the forge forum has no effect on anything here, especially Lex being annoyed with people repeating the same kind of question for the N+1th time.

What he says makes sense - 1.13.2, when it comes to forge, and forge based modding, is a dead end. 1.14 is out already, and 1.13 mods didn't really have the time to take off because of all the delays. It will not need a 'stable' version, because the 1.13 ship has sailed.

[Claw256]

Any update to this?

[Josh74000]

Forge for 1.13.2 is still being updated, could be out of beta at some point, currently at v209

[hron84]

No, it will not come out from beta. Forge team clearly articulated they going forward to 1.14 which will be the new stable modded platform. Please don't spread misinformation.

[manawyddan227]

Are you saying MultiMC is now useless for modding the two latest version of Minecraft?

[peterix]

I would rephrase that and say that Forge is not installable in a sane way for the last two versions of Minecraft.

[manawyddan227]

OK, that was a bit harsh, I admit.
Is there any way to set the URL/folder where MultiMC gets the Forge package?
Has the Forge installer changed that much?

[peterix]

You would have to rehost the complete deobfuscated Minecraft jar.
And yes. It runs a whole build system.

[wlam02]

any workaround you can recommend? - thanks

[hron84]

@peterix is there any roadmap when MultiMC try to ship support for newer Forge? Or do you want to wait the official release of Forge 1.14?

[peterix]

I don't do roadmaps. They immediately become obsolete when I have to react to unexpected things.

There is no workaround that I'd be ok with being used. If you really need mods for the newer versions right now, check out fabric.

[hron84]

@peterix the problem is you also not support Fabric in a way you supported Forge (from the GUI). Not only downloading Fabric is not possible but - as far as I know - I have to create some JSON hacks to use Fabric on a non-prebuilt modpack. As a gamer, it's uncomfy for me and error-prone since I do not fully understand what's going on in these JSONs.

[mdcfe]

@hron84 Fabric is easier to set up with MultiMC than Forge ever was.

Just copy the appropriate link from https://fabricmc.net/use/ and MultiMC sets it up for you.

[wlam02]

Thanks md678685, how about one for 1.13.2?
Fabrik only support 1.14 and up.

[Josh74000]

Forge for 1.14.2 just entered beta, now we wait until stable release which will be a long way until it happens

[hron84]

@md678685 this is just partially true, Fabric provides a workaround to support MultiMC since MultiMC refused to provide an official support it. The author of Fabric, @asiekierka made an excellent work to provide a service for non-skilled players to make Fabric work in MultiMC and setup a service to help distributing it. MultiMC does nothing with "set it up for you" other than unzipping a ZIP file.

Setting up Forge is easy with using only MultiMC since the GUI itself has a button to select Forge version and makes the downloading/installing job automagically. I think we should fit a button to Fabric somehow too.

[Xalaxis]

Perhaps the Fabric issue should be split into it's own thread?

On Wed, 19 Jun 2019, 10:11 Gabor Garami, [e-mail] wrote:

@md678685 https://github.com/md678685 this is just partially true,
Fabric provides a workaround to support MultiMC since MultiMC refused
to provide an official support it. The author of Fabric, @asiekierka
https://github.com/asiekierka made an excellent work to provide a
service for non-skilled players to make Fabric work in MultiMC and setup a
service to help distributing it. MultiMC does nothing with "set it up for
you" other than unzipping a ZIP file.

Setting up Forge is easy with using only MultiMC since the GUI itself has
a button to select Forge version and makes the downloading/installing job
automagically. I think we should fit a button to Fabric somehow too.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/MultiMC/MultiMC5/issues/2544?email_source=notifications&email_token=ADCWV3DHQ4WFJWGBETLM4LTP3HZ35A5CNFSM4GX7U5RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYBHEUA#issuecomment-503476816,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADCWV3D7IDEDGPR2KOM37UDP3HZ35ANCNFSM4GX7U5RA
.

[tehbasshunter]

....Fabric provides a workaround to support MultiMC since MultiMC refused to provide an official support it.

I'm going to assume you aren't in the discord or haven't paid attention to commits to this repo. It was just recently added and partly because the dev of both were willing to work on something. Yes it's a very much WIP addition but it's there.

[hron84]

I like it. Sadly I cannot follow development of these projects as closely as I would because these are a busy times for me.

[JustJinxed]

Grief, we have a few modders pumping out mods for 1.14.3 now, using Forge only.
all well and good if you don't use an instance launcher I suppose.

It's obvious forge wants to do what Fabric is capable of, but they are going about it in the install process.. Making it a bit too difficult to drag it kicking and screaming into the launcher.

I haven't tried it yet for obvious reasons.. but can Forge and Fabric place nice together to begin with? Or is this going to be a huge $h!t show later?

[smbarbour]

According to LexManos, all launchers except the vanilla launcher should
die, including MultiMC, so it's up to us (the developers of 3rd party
launchers) to figure out how to install the new Forge versions on our own.
We will get no help from them.

On Wed, Jun 26, 2019, 3:37 PM Alex [e-mail] wrote:

Grief, we have a few modders pumping out mods for 1.14.3 now, using Forge
only.
all well and good if you don't use an instance launcher I suppose.

It's obvious forge wants to do what Fabric is capable of, but they are
going about it in the install process.. Making it a bit too difficult to
drag it kicking and screaming into the launcher.

I haven't tried it yet for obvious reasons.. but can Forge and Fabric
place nice together to begin with? Or is this going to be a huge $h!t show
later?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MultiMC/MultiMC5/issues/2544?email_source=notifications&email_token=AAKQ4EYKLNUVCJKWRQ4PTKTP4PHSPA5CNFSM4GX7U5RKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYUXZ4I#issuecomment-506035441,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKQ4EYRWUXWM3Y3ESPHCYLP4PHSPANCNFSM4GX7U5RA
.

[hron84]

Curse client already doing some patching job for it, but sadly AFAIK it's not opensource.

[peterix]

And whatever curse does is impossible to apply to MultiMC.

[hron84]

Not neccessarily. You probably can reproduce what Curse does and investigate you can work with that state or figure out what step you do not need for MultiMC. Anyway, I think you could learn from it if it would be even possible...

[peterix]

No, I cannot reproduce what curse is doing, because it simply should not work that way. It is not valuable to look at it, and there is nothing to learn form it. Actually, it has negative value.

[hron84]

@peterix but why? Just because Curse uses the vanilla launcher to launch Minecraft and MultiMC does it very differently? Sorry, but your words suggesting more prejudications than any objective reasons. I'm actually very curious what Curse does that wrong.

[peterix]

Dragging curse into this is not necessary, just looking at the sources of the Forge installer is more than enough.

Reusing the installer in MultiMC is out of the question.

[peterix]

I've done the investigation of this a long time ago, I know how these things work, I know what the solution should be.

The installer is basically a build system that bundles some data, and uses a manifest that says which maven artifacts are to be used as tools to process files using the data (name mappings, binary patches) and the Minecraft.jar.

What needs to be done in meta:

• Write a dissector for the installers that produces the data as a side result and hosts it somewhere (this may not be possible due to legal reasons, needs investigation. If impossible MultiMC will have to grab the installers whole and get the mappings out of them).
• Reprocess the manifests inside the installers into a new version of the MultiMC metadata format that allows separating classpath, remote artifacts and local artifacts into distinct groupings. It should also add build steps for artifacts.
• Introduce digital signing of metadata files. The build system feature should only ever be accessible to the meta system and files produced by it.

Changes in MultiMC:

• Complete overhaul of data internal structures related to versions in order to reflect the format changes.
• It needs to be able to run a build system based on the rules, and do a better job than the Forge installers. It needs to cache results, otherwise you will run a build system for a long time on each launch.
• Checking of metadata signatures needs to be put in place.

And I really, really don't care what curse does. It is most likely a hack.

[peterix]

That said, I don't want to do any of the above things. It introduces whole systems just to counteract even more overengineering in Forge, which is mostly a workaround for problems that should not exist introduced by vanilla obfuscation and weird things in the EULA.

[peterix]

And I am not interested in hacks and quick workarounds. I'd rather not have Forge support at all for the foreseeable future.

[hron84]

@peterix If you do not want Forge support, you will lose players. Forge is the core of the modded Minecraft, despite it's overengineered or not. If ATLauncher or Technic will come out with Forge 1.13+ support and custom modpack features, they will beat out MultiMC from this market. Currently, MultiMC has the only power that supports both Windows and Linux/Mac players but this could change quickly. Especially since there is GDLauncher on the corner and while they still fighting with problems they are committed to supporting Curse-based packs, including 1.13+ ones.

[kb-1000]

It's not like he doesn't want 1.13/1.14 Forge.

[peterix]

And Forge can fix itself first. Because right now, it is not usable.

[RyanTheAllmighty]

@peterix If you do not want Forge support, you will lose players. Forge is the core of the modded Minecraft, despite it's overengineered or not. If ATLauncher or Technic will come out with Forge 1.13+ support and custom modpack features, they will beat out MultiMC from this market. Currently, MultiMC has the only power that supports both Windows and Linux/Mac players but this could change quickly. Especially since there is GDLauncher on the corner and while they still fighting with problems they are committed to supporting Curse-based packs, including 1.13+ ones.

ATLauncher has had support for Forge 1.13+ since May. I've implemented it, and it really is a headfuck and a complete change in the way Forge has run in the past. I get the feeling from the comments in here that Forge doesn't care about supporting any launcher other than Mojang's, so I'm guessing they will not back peddle on this, no matter what the community feedback from other launchers/tools is.

[peterix]

Anyway, the answer to the thread is: there is no Forge for 1.13+ in MultiMC. When there will be, it will show up in that dialog. @RyanTheAllmighty may be the only person here who can actually offer some input because of direct experience with implementing this.

@hron84 your arguments make me want to simply lock this issue and go on a long vacation.

[peterix]

As for there being a 'market' ... seriously?

[HeroCC]

@peterix would you accept bounties for this? Or a stretch goal on patreon? I don't have much but I'd be willing to put some cash as a bounty if you and others are interested.

[peterix]

Maybe? I've previously rejected Bountysource... mostly because they crawled github for projects and put them on their site without asking... I don't like money entering the equation in general. From my POV, this is still a personal project. I'm here because I believe a different launcher is needed.

In any case, I should explain just how wrong this whole thing is, and why it goes against what MultiMC is supposed to be.

1. Instances are always redistributable.
   That means they can't have external dependencies that are hard or impossible to replicate. The current meta system satisfies this by only requiring a uid/version reference in the instance and MultiMC handling the installation automatically. You can take the folder with an instance, move it to a different copy of MultiMC on a different OS, and it should launch with no user intervention.
   Requiring people to re-run installers directly opposes this goal.

2. It should be possible to make dependencies local.
   Making dependencies completely contained within the instance is necessary for archival purposes - current MultiMC design satisfies that for libraries, but not assets. It would be trivial to extend that to assets, going backwards and breaking this for libraries would be a major regression.
   I'm not 100% sure if this is attainable for libraries with new Forge. It would at the very least have to allow multiple maven repositories. And even then, I don't think the maven layout is user friendly.
   It should not be necessary to keep files in any specific layout.

3. All dependencies should always be possible to enumerate in order to clean up folders like libraries.
   While MultiMC currently doesn't have a button for it, it is always possible to delete the libraries folder (or any shared folder with resources shared between instances), and the launcher should automatically recover all missing files. This is obviously related to 1).
   The new Forge installer hides files from the user and makes them hard to track and recover.

Seeing any of these being violated is ... quite bad. It directly breaks the expected behavior of MultiMC.
I think 1. and 3 are possible to recover as long as none of the Forge design is allowed to affect MultiMC too badly. 2. may be a lost cause without changes to Forge.

[peterix]

I will consider anything that doesn't satisfy 1 and 3 a failure. They are quite closely related though :)

[RyanTheAllmighty]

Another thing about implementing the new loader format for Forge is that at any notice things can change.

Note https://github.com/MinecraftForge/InstallerTools/commit/aa056ae48e9797a1c529fb405811f78ef7135d3f which was released and included in a new Forge version, which changed the way that the processors that build the required files changed.

Since Forge seem to only want to support the vanilla launcher (https://github.com/MultiMC/MultiMC5/issues/2544#issuecomment-506078819) and we're on our own, breaking changes can come at anytime if you don't follow the vanilla launcher spec exactly, and then more and more 'edge cases' need to start being accounted for. Maybe this is mainly due to Forge being in beta still, or in this case may specifically be at the mercy of how Mojang implement Realms, but still something that needs to be kept in mind to anyone implementing support.

It's entirely not a simple process to 'just implement 1.13.2 forge', especially if you wish to keep software quality in mind.

[peterix]

I am fine with waiting for the dust to settle.
We'll be getting 1.14.4 where that realms change is obsolete.

[peterix]

Anyway, the correct abstraction level to integrate with the install process is to write the equivalent of make for those commands the installer runs. It is a decent design, just needs to be adapted for non-vanilla and made resumable/caching.

[peterix]

I just wish we could have a non-obfuscated version of Minecraft as the official release of it. And then to skip everything Forge did in the past year in order to deal with obfuscation and deployment issues with vanilla launcher. It's all very ugly workarounds for problems that shouldn't exist.

[cpw]

Hey @peterix let's go over this list:

1. Instances are always redistributable.

This is impossible without breaking copyright law. You have to generate the runtime code at some time. We used to do it during game startup, which resulted in packs often taking more than 30 minutes to start. This is patently ridiculous. By moving 100% identical operations to install time, we have saved everyone about 30-50% of the _entire_ startup time, before we even look at other improvements. There is no way we will regress that.
To support generating at runtime now, we would need either a) to ship every copy of forge with all the data required to generate the runtime code (this is about 10mb of stuffs per download) or b) illegally allow redistribution of the deobfuscated and patched minecraft jars we generate.

1. It should be possible to make dependencies local.

This is 100% true today. You can point forge at any location contain "libraries" and it'll run, assuming it can find the libraries in that location.

1. All dependencies should always be possible to enumerate in order to clean up folders like libraries.

Agree, and this should be doable today. The generated JARs we create are always specific to "net.minecraft" at runtime (be careful not to evaluate what we generate at mod development time - there is a slightly different set of dependencies generated there to support the decompiled state of MC at that time).

In general, I am pretty disappointed you've gotten so wedged on this problem. We've talked about this endlessly over the past year or more and we still seem to have made no progress. I was really hopeful we could have had this sorted before we even released a forge distribution, but sadly that was not to be.

In my opinion, the solution is simple: just run the downloaded install package. It can be run from the command line and directed to a specific output location. Running 100% headless can easily be added. Those files can be cached for a specific forge version, and are explicitly identified such, additionally, we don't re-deobfuscate the minecraft jar files - they're typically only done once per version (it's dependent on the MCP specifics actually).

As such, I don't see any specific roadblock hurdles other than a philosophical problem with the change we've made with the explicit goal of fixing one of the very worst problems of modded.

[peterix]

I am never going to run installers from MultiMC, nor will I support running them on top of MultiMC. I will happily break anything that attempts to do that, because the existence of such things forces the design of the launcher to never change.

[peterix]

... I guess I could elaborate upon that quite a bit, but I think you can follow the implications of that statement. I don't want to end up in the same bad situation as vanilla here.

[kb-1000]

Well, if Forge requires some libraries folder to run, you'll either have non-redistributable instances or highly duplicated files. Both are in my opinion bad.

[peterix]

As far as I am concerned (I'm most likely repeating myself, but ... whatever):

• The installer runs a primitive build system.
• The build system is fairly slow even when it doesn't have anything to do.
• I'm not going to let anything else have control over libraries. That is the launcher's responsibility. For that reason and others, the direct use of the installer is out of question.
  
  
  
  • It is necessary that the libraries folder can be entirely removed by the user without adverse effect or anything breaking. This is a MultiMC feature. It breaking is a major regression.
  
  
  • The above is a primitive form of 'garbage collection' for the libraries folder, but it should be possible to expand upon it in the future and have an intelligent cleanup functionality in the launcher.
  
  
  • Instances are possible to be made self-contained. This is necessary for archival, reliability, and other such reasons. Up until 1.13, you can take an instance with Forge and make it into a completely self-contained thing that won't download any libraries anymore. This has other uses than 'redistribution', but I call it 'being redistributable' in general. This property should be preserved if at all possible. Such things keep working when the Forge infrastructure is down and you misplaced your global libraries or never had them in the first place. Dragging maven or other assumptions about the location(s) of things into the picture didn't help, but I guess we'll have to live with the mistakes.
  
  
• Therefore the launcher needs to implement a good build system, which does file hash/timestamp and input variable based caching. This is because it needs to run before every launch of every instance that needs it. It must be deterministic, extremely fast when there's no actual work to do and (ideally) resilient to superficial change in order not to break easily in offline scenarios.
• The manifests should be signed by the system that produces them, and only verified manifests will be executed. I do not want this to be exposed as an integration point, because it might have to drastically change in the future, and if I let anyone build upon it, I will be forced to break their things.

Effectively, you exposed the problem by moving it from inside Forge. You solved a subset of the problem for yourself with an installer on top of vanilla only. The real solution from my POV is a more general system.

The amount of time I can dedicate to this is limited. I no longer work 16 hours a day like a madman. So, the above will happen at a pace I'm comfortable with.

[hron84]

@cpw I agree with @peterix in two points that you seem never considered:

• CurseForge systems can be down. Anytime. As far as I saw, there is little or no duplication in these systems and if it's down, there will be no way to install/startup an imported modpack. This is a key point with MultiMC as it's redistributable modpack system produces basically instantly usable Minecraft instances, the only service it relies on is Mojang Auth Services - but it basically a Minecraft base game requirement.
• You just changed how Forge installer works right now (kinda). What's the guarantee you will not decide again to change it? What guarantees the CLI/Java interface will never change? How do you plan to support/deprecate API/CLI API interfaces? How do you guarantee which Java versions will be supported by the installer itself (since it's written in Java?) Without this, there is no way to reliable develop on top of the installer. As an experienced developer you should understand it's quite hard to develop on a quickly and unexpectedly moving target.

Honestly, I'd more than happy to break copyright laws if they're not connected to the real world uses. At some point, Mojang/Microsoft should decide if they consider modded community existing or not. You can not be part-time pregnant.

[peterix]

The big problem is that vanilla doesn't provide well defined integration points. A lot of the things are implied... and when you don't follow the implications, you end up with something brittle, while tying down vanilla even more.

I'm kinda on both sides of the problem now. It's like watching an explosion in slow motion. Too late to avoid it.

[hron84]

From player perspective, I honestly really do not care how do you solve this.

But previously CurseForge had serious issues with reliability and usability and I do not expect any changes in the future. I use Twitch client and CF API often refuses to serve one or more files without any reasons. Since Twitch modpack strategy based on that every files at every time accessible from CF, this effectively ruin my gaming experience for the unspecified time while the CF API is down or misbehaving. CF is also not too honest about these outages, there is no monitoring for it, like how GitHub Status or Travis announces every single downtime. There is a huge room for improvement.

Also, as a player, I want to quickly build a modpack and share with my friends saying "Just load this zip with MultiMC and press play button" to play together without any issues, regardless if Forge installer could or could not work, CF API is online and working properly or not, etc. Mojang Auth API is enough POF for the gamers we should not involve any other online service into this. It maybe could not work with Vanilla or Twitch but I don't care. You should definitely support 3rdparty launchers to make modern 1.13+ modpacks playable.

Please guys, start talking. Seriously. Yelling over fences will not solve any problems. I know vanilla is a piece of scrap and you have to fight with it and I understand it as a person, but I don't care as a regular player. Please, please start figuring out some reliable solution :-(

[cpw]

@peterix so how do we distribute pre-patched minecraft? Are you saying we should go ahead and just ignore the well established copyright to the game?

[kb-1000]

Minecraft JARs are already downloaded by MultiMC though.

[cpw]

@peterix the other alternative is to revert everything done in 1.13 and up. That seems like a huge amount of work.

[cpw]

@hron84

Also, as a player, I want to quickly build a modpack and share with my friends saying "Just load this zip with MultiMC and press play button" to play together without any issues, regardless if Forge installer could or could not work, CF API is online and working properly or not, etc. Mojang Auth API is enough POF for the gamers we should not involve any other online service into this. It maybe could not work with Vanilla or Twitch but I don't care. You should definitely support 3rdparty launchers.

You would be violating the minecraft copyright to do this. Don't do this.

[peterix]

Dragging CurseForge and modpacks into this is seriously off-topic.

[kb-1000]

No. Instances do not include Minecraft binaries. Just metadata which version it uses.

[hron84]

@cpw

Honestly, I'd more than happy to break copyright laws if they're not connected to the real world uses. At some point, Mojang/Microsoft should decide if they consider modded community existing or not. You can not be part-time pregnant.

[cpw]

So is this an impasse @peterix ? I can't reasonably be expected to revert all the 1.13 changes. It sounds like you won't budge on your "no installer" philosophy. So I guess this is the end of forge in multimc?

[hron84]

@kb-1000 you're true. I always mess them up with server packs because mostly I use that to build a MultiMC instance and it does have a libraries folder that MultiMC keep.

[peterix]

Is there some sort of deadline?

[peterix]

And yes, there will be no installers.

[cpw]

You tell me? I would dearly love to have multimc support forge 1.14. I use it daily. But it seems that is not to be.

[cpw]

You may as well close this issue then. Because without an installer step, we can't work.

[kb-1000]

You definitely can work without an installer step. I even heard older Forge versions were as simple as a JAR mod and nothing else. Nowadays, you try to require such things...

[peterix]

I described the constraints and general design for a system that would work here. I think it shouldn't be required, and that most of it is forced by some really poor decisions noone here could affect.

[cpw]

@kb-1000 we would need to ship the installer in the forge jar, so every jar is now 10mb bigger. That's about 100TB/month of additional bandwidth to forge. Are you paying? And run it every time it starts. so it would add at least 1-2 minutes to every single forge start. The whole point was that everything run in the installer is _one time only_ and should be cached and stored for reuse. Hence, the installer.

[peterix]

Other than that, it's just a big pile of work added to the other big piles of work...

[kb-1000]

Well, why did it work back then then?

[peterix]

@kb-1000 I don't think this is helping...

The fact is, the installer step just has to be a lot better than it is, and I will not let it be what it is - not in MultiMC.

[cpw]

@kb-1000 Because it took on average 15 minutes to start a modpack. If it went wrong, you could often waste hours waiting for it to start.

[cpw]

@peterix tell me what's wrong? You're saying "no installer", not "let's fix what's wrong with the installer".

[peterix]

The presence of an installer is what's wrong with the installer. It's not a package. It is not deterministic. It's arbitrary code execution before each launch.

No installer = no third party binary assumes that the environment around it is X. Don't assume the environment. Write a manifest that says what the result should be. Let others do the work.

That's what I'm after here. I can always adapt the manifest in the metadata repo (it's an online service) and I can always change how the manifest is interpreted in the client. This provides plenty of room for fixing future issues, unlike having a big library of installers that assume nothing ever changes.

[kb-1000]

Can you please tell me where to find the code of that installer? I searched it a bit on the MinecraftForge organization on GitHub, but I had no luck.

[peterix]

Like this thing? https://github.com/MinecraftForge/Installer

[kb-1000]

Yes, probably, thanks. I didn't look at it because the date seemed to be too old.

[hron84]

@cpw let me ask a dumb question: why this whole installer thingie become required? Why Forge could not work same like how it worked in 1.12? AFAIK it patched everything in memory (or something similar to that) and it worked like a charm.

Also you say you have to patch every single start. I slightly disagree. As far as I see, you can store the patch result within the instance folder (for example in mods//forge) and re-use it when the instance itself starts just how MultiMC plans to work with it. If you chose a binary diff format you can store the result of the bytecode patching rather than the whole patched bytecode and therefore you would not have to break copyright rules. That diff would be specific to the MC version of the instance but it's less likely to someone want to change an MC version on a running instance... Forge version changes more often.

[cpw]

"Arbitrary code execution before each launch" is precisely what the installer is not.

It is performing deobfuscation and patching of the client JAR file. It performs deobfuscation once per minecraft version (typically). It performs patching by extracting the deobfuscated code and patching it into a "sidecar" jar, once per forge version. Both these steps are done to remove a huge mess of nasty code that was attempting to do this task every single startup.

Currently, we've extended the deobfuscation step to cover the realms jar, since obfuscated symbols have crept in there. Not sure if that will be kept long term.

[cpw]

@hron84 we do store the cached result in the libraries folder, alongside all the other libraries. That's why you don't need to run the installer every single launch. To adapt to @peterix requirement "no installer" I would have to change that. Why did it work before? It worked before by sucking. You know that 30 minute startup time for sevtech ages? This is why.

[peterix]

The problem is not linear, and the options are not black & white...

[kb-1000]

I also know that this sounds like "sorry, no core mods anymore", since that'd then have to be run by the installer too.

[peterix]

By saying no installer, I mean that you don't get to write an installer for MultiMC. It is off limits, to preserve my sanity and my ability to maintain the project in the future.

[cpw]

@kb-1000 nope. Not at all. And completely off topic for this discussion.

[peterix]

MultiMC is the ~installer~ package manager.

[cpw]

@peterix i don't think we ever asked to make multimc need an installer step _itself_. The ask is simple: when a _new_ forge version is requested, run the installer that forge provides. I can make it headless and basically invisible. I can make it output the result to wherever you want.
Edit: also, you can cache the result as well. Hell, I can probably make it so you feed it the MC jar, and it'll spit out the result on stdout, if that's how you want to handle it.

[peterix]

I don't want you to do anything.

[peterix]

Hell, the less this thing changes, the less time it will take me to fix all of the breakage...

[kb-1000]

What about making a plugin API for MultiMC for this purpose? It would then be the task of the Forge devs to update that plugin. You (@peterix) wouldn't have to do anything when they change Forge then

[peterix]

Plugin API = no. This has been brought up numerous times, and the answer will be always no.

[peterix]

I think adapting the current metadata format to allow for build steps is reasonable. It would clear up some of the old Forge hacks (unpacking pack200+lzma files) if they were expressed as build steps.

[peterix]

Also, declaring files as required without them being on the classpath needs to be a thing. Current vanilla can't do it, but prototyping it here should be fine...

[peterix]

And yes, I absolutely can go back and rewrite history when it comes to how things work in MultiMC, as long as things stay declarative.

Need to push an update to fix for some random build of Forge for 1.7.10? Perfectly doable.
Want to fix dependencies of a thing because it stopped working because of a Java update? It's 2 lines of python in a cron job.
That pile of old code that assumes things work in some way, baked into a 1000 installers? Not a problem.

Keeping the system working is certainly more work, but it makes so many problems simply not exist...

[cplir-c]

What if you load and run the installer as a [core?]mod only when the forge version changes?
More parts of mod startup could probably be cached anyway.

[peterix]

This is really more of a tangent, but if you wanted to dig into that...

Caching the intermediate results of deobf/pathcing/asm/whatever makes sense to me.

I would think that this needs to happen through the whole chain, not just at the beginning that the installer can access, because there are other things messing with the game bytecode after that.

I would also think that the performance impact of the installer doing some part of it would be relatively small.

I haven't measured any of this, but:

• Take vanilla 1.12.2, launch it, see how fast it can get into a world with a predetermined seed.
• Take vanilla 1.14.3, launch it, see how fast it can get into a world with the same predetermined seed.
• Do the same with just Forge added to both.
• Do the same with Forge and the 'same' or as close to the 'same' set of mods applied on top. About how many you would expect to be in the average modpack.

I would expect 1.12.2 vanilla to be the fastest.
I would expect 1.14.3 to be slower overall, no matter what.
I would expect the time added by launching with just Forge to be a small-ish O(1) kind of deal in all modded cases.
I would expect the mods to be responsible for the bulk of the load time.

I don't know how much the deobf/patch process changed between old Forge and current Forge. I haven't ever looked at Forge in that much detail, so I am assuming that the process was just moved elsewhere with minimal changes.

[Unnoen]

I don't know how much the deobf/patch process changed between old Forge and current Forge.

The patch/deobf process in "old" Forge was: Deobfuscate and patch at every run.
The process in "new" Forge is: Run once at install.

Take a fresh installer for 1.14 Forge and run it, see how long it takes? Imagine having to do that for every game launch (and that's without mods). That was what old Forge was doing every time you ran the game, new Forge does this at install time.

[hron84]

Plugin API = no

Why? With a working plugin API, you could support anything that comes along/instead of Forge: Rift, Fabric, SpongeClient, whatever.

[peterix]

I do not want to maintain one. I don't want to be in the same stupid situation vanilla launcher is in either, where everyone piled garbage on top of what clearly isn't an interface, forcefully turned it into an interface, and are preventing it from improving in any meaningful way.

In short: I don't want to deal with garbage or even more long term API maintenance than I currently am. It is a waste of time for me, and I will make sure it is a waste of time for you if you try to force it upon me.

The interface you get to interact with is a declarative only manifest with no direct code execution capabilities.

[peterix]

Deterministic, provably safe, declarative packages are OK.
Installers, plugins and similar crapware are not.

[peterix]

Anything you might want to put in a plugin should be in MultiMC's codebase instead. You are free to contribute instead of creating timebombs in the form of unmaintained plugins.

[peterix]

That said, plugins are off-topic. I'm pretty sure what the design for this should be at this point - and it doesn't change compared to existing Forge support. Same approach, expanded vocabulary.

If you have other unrelated suggestions, please open new issues for them.

[peterix]

For extended discussion, come to the discord server. This is the equivalent of a post-it note for me, and it's getting awfully crowded.

[peterix]

Done.