Start of port to v1.12.2

[mikeprimm]

@Dan_Prime Nice job on running down the issue - I saw the commit activity around that issue, which was why I tried the latest build (2796) AND the build before the change Lex made in September (2759), but without good results.

I'll check the maven identifiers for the couple of new components that were needed (which, actually, included the maven-artifact JAR...), and adjust distribution.json appropriately.

The legacy launcher, like most other launchers I've seen, doesn't rely on the --modListFile parameter, instead just putting mods in the default directory structure (under ./mods), which is why we're not seeing any issues there. If the Forge guys are slow on accepting the fix, we'll probably need to consider working around this.

 

[mikeprimm]

I'm getting the impression that the requirement to match the Maven-Artifact field, at least for 1.12.2, isn't a concern - almost everything I've looked at (Optifine, BetterFoliage, JourneyMap, worldeditcuife) don't have it in their manifest. I'm pretty sure that field is only added if you go through the process of signing and publishing the artifact to a maven repo, which library writers tend to do but pretty much zero mod writers do.

 

[Dan_Prime]

Dynamic surroundings is the only issue I came across. They do declare an identifier, and it's different than the one we currently have declared. It's case sensitive as well.

 

[Dan_Prime]

Compatibility fixes released in v1.4.1 of the launcher.
https://github.com/WesterosCraftCode/ElectronLauncher/releases/tag/v1.4.1

 

[mikeprimm]

OK - nice! Just to be clear: with 1.4.1, we should be good for updating to the newer forge, yes? I'll give it a spin - thanks for the quick response!

Edit: Confirmed working - I've updated distribution.json, so we're all in sync with the current recommended Forge (2768).

 

[Dan_Prime]

@mikeprimm the affected forge versions will not work. Only the pre-rewrite version and any versions including my PR will work on the 1.12 client. Not working as of the update. Since we host forge forge we could just build it with the fix though.

The compatibility fix just allows our launch code to use the old and rewritten versions of the modList format. The old version crashes if you put absolute: before an absolute path. The new version crashes if you don't.

The argument itself isn't even being registered on the affected version, so there's no workaround other than not using the affected range of versions.

I can build the jar and upload it to git, just note the file will not be signed.

 

[mikeprimm]

Really don't want to get into building a custom Forge for any reason.... if they don't accept the fix quickly, we can work around it without corrupting our ongoing ability to have a Forge supported by other modders (none of who will give us the time of day if we aren't working with an official Forge build).

I was able to run successfully with your updated launcher, so I'm not sure I understand your statements - it's now working fine for 2768, and it wasn't before your launcher change.

 

[Dan_Prime]

The argument does not work in that build at all, how exactly is it working for you? Are you sure you're running the 1.12 client?

Spoiler: issue

As a side note, I'm not too concerned about the time for this to be merged. It's a very simple fix, literally 2 lines of code to review. It's just a matter of the devs bothering to look at the issues/PR tab. I have no problem @mentioning one of them after a week, but any sooner and I'm sure to get the good old "be patient" rant.

 

[Dan_Prime]

@mikeprimm the fix was merged, I updated the file on bitbucket.

Also, I did try the old configuration on a new computer and it worked. I then tried it again on the other one and it still failed. Then I deleted the client files and it still failed.

The new version works on both.

 

[mikeprimm]

Cool - pleasant surprise I definitely know you don't want to 'poke the bear' over on Forge: didn't know whether they're so tied up in trying to move 1.13.x forward that they were gonna be slow on looking at non-1.13 work!

 

[mikeprimm]

OK - so, 1.12.2 test client and server are all up to date and ready for final testing! Please give it a look, so that we can prep for deploying it to production 'soon'

 

[Emoticone11]

I’ll check it out soon, when I get home. A lab rat volunteer to help with perms testing would be helpful!

 

[CashBanks]

Add me to the white-list and I'll take a look!

 

[Emoticone11]

Did some bug-testing with @CashBanks the other day.

Everything seems fine and good to go, only noticed a couple very small issues:

* All groups seem to have access to "/spawn #minecraft:the_end" -> this should be disabled for everyone.

* No groups have perms for "/gm" -> this should be enabled for everyone.

* One particular block (Dreadfort Skeleton Sconce Left/Right) seems to have a broken model/texture; I'm pretty sure this is just because we gave it a custom model file which was overridden by the JSON entry in the update. Is there any way to enter a line in the JSON preventing this from happening for a particular ID?

 

[CashBanks]

* All groups seem to have access to "/spawn #minecraft:the_end" -> this should be disabled for everyone

That command also works in the 1.11 server and you can also use it to take you to the Nether (where Blazes, Skeletons etc still spawn).

 

[Dan_Prime]

Forge just started pushing 1.13.2 to their main download page. AFAIK, they're still working on it a lot, but are close to where they want it to be.

I think I'll have to make some changes to the launcher to have it run 1.13.2. May be a good idea to setup a bare minumum 1.13 configuration (no mods, just forge) so that I can get things moving on that front.

 

[Dan_Prime]

So cpw from forge just mentioned that there is no direct reimplementation of the modListFile argument on 1.13, which is what we use to load our mods. This is going to complicate things a lot, because it essentially means that our entire mod management system on the new launcher is completely nerfed. If there is truly no similar feature, we can no longer cleanly support "drop-in mods" the entire mod handling system will have to be rewritten.

Really unhappy about this decision. Not sure if they would consider re-implementing the feature if we put an issue up on GitHub. Let me know what you think.

 

[Dan_Prime]

I posted a feature request. https://github.com/MinecraftForge/MinecraftForge/issues/5495

Guys, please give it a thumbs up. It will show that this feature has a larger impact than just one person.

 

[Dan_Prime]

I just pushed a commit completing the first phase of the launcher's update to support 1.13. Many things have changed, especially in regard to launching forge. I'll give a quick rundown here.

• The 1.13 version manifest has changed format, mainly in regard to the client launch arguments. Some arguments are now wrapped in "rules" and require special handling.
• Forge is no longer a single jar file. Forge's installer will now generate patches, etc and install them into the game files. All of these files are required to run. The version manifest can no longer be extracted from the universal jar, as it is only present in the installer. In total, we will need to host at least 7 additional forge files for 1.13.

In addition, forge will look for these generated files at a path determined by its maven identifier. This is no problem, as the launcher was designed to store files in a maven-style repository. In contrast, the old launcher puts all libraries into a single folder. Forge will crash if the files are not at the expected location, so that system will no longer work.

The old launcher would require some significant updates if it is to be continued beyond our move to 1.12. Preferably, it should be deprecated and all users should move to the new launcher.

An example configuration for 1.13 can be found here https://github.com/WesterosCraftCode/ElectronLauncher/blob/master/app/assets/distribution.json#L1273.

Changes so far can be found here https://github.com/WesterosCraftCod...mmit/81367bc6198f6cc4b0ef39824f1d2112ca40d3c3

As it stands, the new launcher can launch Forge 1.13. Mods are not supported through the distribution file yet. I'm still looking at our options given the revelations in my previous two posts.

 

[Dan_Prime]

Good news, Forge 1.13 actually does have a feature providing the same functionality of --modListFile, but in a different (and arguably better) way. Rather than constructing the mods into a json array, saving that, and passing the path to forge, everything is handled from the command line. The two new arguments are just --fml.mavenRepo and --fml.mods.

See more here: https://github.com/MinecraftForge/MinecraftForge/issues/5495#issuecomment-464916093

This feature will always be present and working, since it's how forge loads itself. We no longer have to worry about using some neglected feature, as --modListFile was at times in 1.11/1.12.

I've added the required changes to the launcher, we can now load mods through the distribution again. Now all that's left is waiting for the mods to update haha. Changeset here https://github.com/WesterosCraftCod...mmit/e08c3a903aad1f2d0a996ab9958c1b6eedd546f6

As it stands, the launcher now fully supports Forge 1.13. Just note that forge is currently in beta, and things are likely to change. I expect that to be largely limited to their library list and not the actual means by which we launch. Liteloader 1.13 is not out, so that's obviously not supported yet. As soon as we get word from liteloader, I'll make the required updates.