Minecraftforge: Forge 2768 -> LiteLoader (latest), startup argument missing

[Dockter]

Client Side Startup using 2768 and latest LiteLoader:

Forge Commit: https://github.com/MinecraftForge/MinecraftForge/commit/8ace535995522bec0557d4217e0d98b3dc76cf1e

Error: https://gist.github.com/Dockter/e84e0067656bee3df0bea02b2fa1c178

Temp Fix: Remove liteloader, client starts fine.

Additional Information: http://develop.liteloader.com/liteloader/LiteLoader/issues/61

[bs2609]

Duplicate of #5130.

[liach]

5130 contains less information and is reported not as properly.

[Mumfrey]

The problem seems to have been created by this commit, specifically this line which clears the shared launch arguments when they are drained.

To explain why this is incorrect, some history as to why it's like that in the first place:

When the first version of the Tweaker system was released, there was only support for one tweaker. This meant that to accommodate multiple tweakers @cpw and I agreed between us to "cascade" and support a --cascadeTweaker argument which would be a list of other tweakers for the primary one to load. This worked well and everything was good. The tweaker which was loaded by LaunchWrapper was considered the primary tweaker and the others cascaded, the cascade code was copy/paste from one tweaker to the other so that we knew the contract was symmetric.

One duty of the primary tweaker was to ingest the launch args array supplied by the command-line, sanitise them as necessary, then emit them to Launch. In the cascade scenario this wasn't an issue because only the primary tweaker would have its getLaunchArguments() method called and since both tweakers did the same thing there wasn't a huge problem.

When cpw later added support for multiple tweakers the primary tweaker concept was preserved, encoded in the contract of Launch but mainly only with implications for which tweaker could choose the mainMethod, this meant that getLaunchArguments() was called for all tweakers and so now there was an issue with both tweakers needing to return a particular - sanitised - set of arguments but neither knowing who was responsible. Having the primary tweaker take responsibility for arguments alone could become asymmetric over time, so using cpw's handy blackboard feature, we simply handled the argument list co-operatively. Creating the following contract:

• Both tweakers ingest the launch argument list provided at startup
• Both tweakers place their processed args list in a "shared" (via blackboard) Map under the key launchArgs (you can see this symmetric behaviour here in LiteLoader and here in FML, note that the code is basically identical because it was developed at the same time).
• Both tweakers check that required args are placed in the map (here in LiteLoader and here in FML, again note the code is identical) which - because it's a map, doesn't matter which tweaker goes first, the overlap is avoided.
• The primary tweaker has its getLaunchArguments() method called, which drains the shared launchArgs map into an array and returns it (you can see this behaviour here in LiteLoader and here in FML)
• The tweaker later in the chain will see an empty launchArgs Map so the array it returns will be empty, everything wins.

So this isn't actually LiteLoader being broken, if LiteLoader was the primary tweaker in this scenario, then the shared launchArgs map would be cleared and FML would return nothing. Because FML is not clearing the launchArgs map when it's returned, it's breaking. The shared launchArgs map was a bit of functionality co-developed by myself and cpw to make this whole thing work properly, so basically all that needs to happen is that the launchArgs.clear() is restored in the FML tweaker.

The reason I explained all that is so that the contract of the shared launchArgs is clear and an alternative fix for whatever the original change was meant to address can take that into account. Hopefully @cpw will back me up on this.

[darthvader45]

Yes, and hopefully this can lead to an eventual fix. I've had so much fun with VoxelMap, I'd hate to have to give it up, especially with how useful the waypoint icons can be (mainly to distinguish waypoints by unique feature). Also, it seems ZeroMemes has suggested a potential alternative fix here: http://develop.liteloader.com/liteloader/LiteLoader/issues/61

[Mumfrey]

The ArgumentList key in Launch is where the emitted arguments are gathered. It's not suitable because it is, well, a List and is managed by Launch.

Honestly the simple fix is the reinstatement of the launchArgs.clear() in the tweaker, the whole point of launchArgs is that it's shared between FML and LiteLoader, it's why it was added in the first place. launchArgs gets drained by the getLaunchArguments() call to the primary tweaker.

The entire reason for this existing and being done in the way it is, was to make the behaviour of the tweakers symmetric. If LiteLoader's tweaker is primary then FML still works, and if Forge's tweaker is primary then LiteLoader still works. The above mentioned change accidentally broke this contract and thus caused the unintended behaviour. In fairness me and cpw should have documented this more explicitly (eg. at all).

[darthvader45]

Alrighty, as long as it can be reimplemented (i.e. it can be reinserted where it was deleted or something similar), then it should be rather easy to fix. In fact, if it can be reinserted, I might be able to get it slotted where it needs to go and make a pull request. That way, it fixes this problem in the short term, while cpw can get to the documentation so this removal won't happen again.

[cpw]

Heh. You need to look at the 1.13 code @mumfrey

[Zidane]

@cpw

That is fine but this is 1.12.2, not 1.13. Why was this breaking change made to an already released version?

[darthvader45]

Agreed, why make a change that breaks so many mods that rely on Liteloader to work? Who in their right mind would think that Liteloader was unneeded or dead or whatever?

[Dockter]

Agreed, why make a change that breaks so many mods that rely on Liteloader to work? Who in their right mind would think that Liteloader was unneeded or dead or whatever?

I don't think this was intended to break tweakers in general, more of an unexpected consequence.

[darthvader45]

Well, if it can be fixed, I believe it should. No sense leaving this in.

[illyohs]

Give it time it was probably unintentional

In fairness me and cpw should have documented this more explicitly (eg. at all).

Demanding that things be fixed at this very moment wont get it done any faster, when cpw or lex have the time (or someone makes a PR) it will be fixed.

[Dockter]

I can PR the fix though everyone knows its likely only 1 line.

[tterrag1098]

Clearly anyone could make the change, that much is obvious. We are waiting for the fix to be verified by someone with the background knowledge to do so.

[Dockter]

I'll work on it later tonight.

[darthvader45]

Cool, lemme know if it goes through. I'd love to have VoxelMap work again.

On Wed, Oct 31, 2018 at 5:40 PM Dockter [e-mail] wrote:

I'll work on it later tonight.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MinecraftForge/MinecraftForge/issues/5207#issuecomment-434857646,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACr5pKu8Wm5U7AWlL-ye7CLubVZ5c_tcks5uqhjmgaJpZM4X-RCI
.

[LexManos]

Honestly, This type of backroom undocumented behavior is why LaunchWrapper needed to be re-written.
As it sits, whatever the intention of this was, it wasn't working correctly.
The entire issue was that the mod/modList arguments {and many other random ones I tested} were not making it into the child class loader so our entire mod/modlist functionality was broken.
I don't care how it's fixed. As long as it's fixed and the original issue I fixed is fixed as well.
So if anyone wants to attempt a PR make sure you have tests showing as many edge cases as you can and that the custom arguments are making it past the child classloader.

[Ryudragon2]

i have the same issue please let me know too when a fix is out

[Tsoccerguy3]

Having Forge b2759 + , load Liteloader as a Forge Mod does fail because of the conflict with launchArgs .
Create a Liteloader Profile and Chain Forge , then run Profile 1.12.2-LiteLoader1.12.2-1.12.2-forge1.12.2-14.23.5.2768 does work .
To get Liteloader to work with Forge b2759 + , you can create a " Liteloader Profile " and Chain Forge b2759+ to Liteloader . Liteloader 1.12.2 will resolve launchArgs and proceed to load Forge , Optifine and all Forge mods . This will fix the issue .

[darthvader45]

Unfortunately that's only a temporary workaround. We need a permanent fix,
and until one is found, we can't do much. Especially us MultiMC users, who
can't just chain Forge to Liteloader. Unless some special pre-launch
argument can be used to force Forge to load AFTER Liteloader or something.

On Fri, Nov 9, 2018 at 9:49 AM Tsoccerguy3 [e-mail] wrote:

Having Forge b2759 + , load Liteloader as a Forge Mod does fail because of
the conflict with launchArgs .
Create a Liteloader Profile and Chain Forge , then run Profile
1.12.2-LiteLoader1.12.2-1.12.2-forge1.12.2-14.23.5.2768 does work .
To get Liteloader to work with Forge b2759 + , you can create a "
Liteloader Profile " and Chain Forge b2759+ to Liteloader . Liteloader
1.12.2 will resolve launchArgs and proceed to load Forge , Optifine and all
Forge mods . This will fix the issue .

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MinecraftForge/MinecraftForge/issues/5207#issuecomment-437381549,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACr5pMdGw191jaQt7hhiuNZhZBmrPSIwks5utZXjgaJpZM4X-RCI
.

[Tsoccerguy3]

I just created a MultiMC instance in version 0.6.2-develop 1256 , works perfectly fine .

[darthvader45]

How'd ya do it?

On Sat, Nov 10, 2018 at 1:38 AM Tsoccerguy3 [e-mail]
wrote:

I just created a MultiMC instance in version 0.6.2-develop 1256 , works
perfectly fine .

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/MinecraftForge/MinecraftForge/issues/5207#issuecomment-437562718,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACr5pMjngF201nvwyZJP0g2uTBzfn5CNks5utnSCgaJpZM4X-RCI
.

[Tsoccerguy3]

Hi Darth , The whole idea of putting up the pictures , A picture is worth a thousand words , 6 pictures = 6000 words , that's a essay! .Someone added support for chaining a while ago in develop version .
That is using default out of box settings , so create a instance from .12.2 , add liteloader 1.12.2 it will download , add Forge b2759+ it also downloads , then add in all your mods from browse . You can rename the instance to anything , i just left it as 1.12.2 .

[Tsoccerguy3]

I already made Mumfrey aware that Liteloader is working as intended . As for Liteloader as a mod , That is up to Forge coders wither they want to support it as a mod . Mumfrey did an excellent job of coding this LiteModloader and it does a great job of loading everything and resolving everything .

[darthvader45]

I have the same installation order of Liteloader and Forge and for some reason it still crashes with the same error as here. Btw, what the heck is LitemodWDL?

[Tsoccerguy3]

LitemodWDL = A custom build of , World Downloader for Liteloader

Make sure you remove Liteloader.jar from the Directory that you keep your 1.12.2 mods in , or its going to get loaded by Forge . Same rules apply about out dated mods , mod conflicts .

Start with just adding Optifine (current version) and your Litemods to a empty directory for your MultiMC mods , Test . Add more mods and Fire up MultiMC . Then start adding in your mods and testing your modpack . I'm sure order may be important but I just dumped all my mods i was using into a Directory .

I've Tested in Linux Mint and Windows 10 x64 build 1809
Oracle Java 8 jdk1.8.0_192 64bit Open Java 8 sdk

I've tried to make it crash , It just would not . lol

[LexManos]

Since nobody has bothered to actually try and fix this, i've done a hacky solution for now.
The 1.13 system should solve this properly, without any backroom/undocumented requirements.