Start of port to v1.12.2

Dan_Prime

Dan_Prime

Emissary
Guest
The launcher will likely still download Java 8 by default, however the discovery code only supports Java 8 at this time. Should 1.13 and LaunchWrapper's successor allow the game to launch with an installation of Java 11, the discovery code will be updated to reflect that.

Of course that would be dependent on the game version the user has selected. Versions below 1.13 will require Java 8 only.
 
mikeprimm

mikeprimm

Playwright
Staff member
Admin
Yep - every mod we use, last I checked, is Java 8 only - we've only supported Java 8 since the 1.11.2 move, independent of whether 1.11.2 allowed Java 7 or not. Forge, as of as recently as May, only supported Java 8 (and specifically did not support Java 9 - some issues with launchwrapper, which isn't surprising since a large part of what Forge does is acts as a highly customized class loader, and so is very sensitive to any changes in the Java class and bytecode content and structure). They've been talking about a rewrite of that component in order to enable use of newer JVMs, but last I saw, it was slated as a 'post 1.13' thing (since 1.13 was gonna be Java 8, from Mojang, and was gonna be a nut-buster in general).
 
mikeprimm

mikeprimm

Playwright
Staff member
Admin
On the block ID question from earlier: the new blocks literally don't use a consistent number for how they are stored - internally, the data scheme is now a 'flattened' index space, which is just a fancy way of saying 'we used to have a 2 part number - and ID and a metadata value - and now each of those corresponds to a value of a single number'. BUT, whereas old blocks could only have 16 'meta' values, each block in 1.13 can have from 1 to 'a large number' of values in the new scheme - redstone wire has over 1000 (as it has one for each combination of direction and power state) - so, in many cases, there isn't one new value to go with a given old value. So, would it be possible to produce aliases for block names (which are the true identifiers for blocks now) that correspond to the numbers for the old blocks? Sometimes yes, often no - the log name corresponded to a single block in 1.12.2, but has been replaced with 4 different blocks in 1.13.x (oak_wood, spruce_wood, etc), so a legacy name (or ID) isn't enough to know which block you are talking about in 1.13. It'd be possible to come up with some sort of 'best effort' mapping : legacy blockID:meta -> best blockname:state, but this would not help with new blocks (no legacy id) or be supported by any tools you didn't handcraft to support your scheme (e.g. WorldEdit will not support it, unless we hack up our own WorldEdit version just for the sake of respecting our aliasing scheme).

For 1.13 Forge, it remains to be seen how state indexes will be managed - Forge stopped allowing mods to directly assign their block IDs a while ago, but I hacked around it in WesterosBlocks in order to continue to allow our guys to manage and control the assigned IDs (since CTM and other RP features are very block ID tied). Keeping an eye on what OptiFine does for 1.13 RP support - CTM and other features - is also something we need to do, in order to plan out our eventual move to 1.13. My own opinion? 1.13 isn't for us in 2018 (from a production server POV), but I do hope to be working on it before year end, with a goal of having the option to move to it in early 2019. As we learn more, I'll work with the other key folks on the server team to put a plan together.
 
  • Like
Reactions: lemonbear, CashBanks and Emoticone11
Dan_Prime

Dan_Prime

Emissary
Guest
I haven't done much development with Forge as of late, so I'm not sure what the exact implications are for custom blocks. I did however spend a non-trivial amount of time converting 1.12.2 alias data to 1.13 for spigot. The culmination of that effort is my alias library ItemCodexLib (https://github.com/dscalzi/ItemCodexLib). All of the conversion code is in ItemCodexConverters (https://github.com/dscalzi/ItemCodexConverters). Obviously this not directly applicable to what we face, as we are using Forge + Sponge, however it may be good for reference.

In essence, these are the steps I took for spigot:
  • 1.12.2 still supports legacy:data -> Load values using these deprecated values and convert to API-supported Material Enum. Store this value wherever the legacy:data is also present. (src)
  • Boot up with 1.13, load the material with a LEGACY prefix as supported by spigot's compatibility layer. Some items were broken with this (wool, spawn eggs, etc). Manually convert the broken items. Save the new 1.13 Material enum values. (src)
  • Good to go, just verify everything.
I'm not sure forge would support any type of compatibility layer for us to coerce, but they will certainly have some sort of article addressing the API breakages, update strategy, etc.
 
Last edited:
  • Like
Reactions: Marken
mikeprimm

mikeprimm

Playwright
Staff member
Admin
Yep - spigot port from 1.12.2 to 1.13 is trivial, relatively speaking: no custom blocks, and spigot worked pretty hard to try to preserve compatibility, when possible (big part of Bukkit/Spigot is the fact that it is even possible to have a plugin run on multiple versions - Forge rarely allows the same mod to run on different releases of the same version, much less different versions). Even so, I essentially had to rework the entire core of Dynmap to handle both 1.13+ and 1.12.2 and earlier spigot and forge versions in the same code base.
 
  • Like
Reactions: Dyvim
mikeprimm

mikeprimm

Playwright
Staff member
Admin
Nothing I know of - @illblew and I have discussed some potential migration plans (since we're also really in need of updating the linux distro on the main VM). Nothing else specifically to be done besides decision and approval from @pizzainacup and the key mods on going forward with the migration.
 
  • Like
Reactions: Dan_Prime
mikeprimm

mikeprimm

Playwright
Staff member
Admin
@Dan_Prime I'm hitting a problem with the new launcher on the current 1.12.2 test client, as far as updating. I'm not sure if I goofed up something in the json for it - could you give it a peek, if you have a chance? Is the Windows version updating successfully to the current 1.12.2 test client?

Edit: Just for context: nothing in the 1.12.2 portion of the client config has been updated since September. I zapped the client instance on my system, and reloaded clean on the 1.12.2 client, and still getting error. Not seeing problem with classic launcher - going to try to get a chance to try to fire up with Windows. I'm running the 1.10 mac launcher.
 
Last edited:
Dan_Prime

Dan_Prime

Emissary
Guest
I will take a look.

Edit: It's working fine for me. I tried a run with my existing configuration as well as wiping the files and running again. Both launched without issue. One thing though, there are a few small errors on the distribution:

d7da377c578475a49da3a305f68a4378.png


Most likely the distro was updated and a file wasn't, or vice-versa. I'll take a look and push a fix. None of these issues prevent launch at all though.

Edit2: With optifine, the file was updated to E1, but the distro was not. I'll update it to E3 (latest 1.12) on both. I've also updated dsurround.cfg at it was outdated and the mod was generating an updated one.
I've pushed both changes to the new launcher distro. Take a look and pull. Note, I didn't update the entries for the old launcher.

Perhaps you could send the console output and I can see what's doing wrong.
https://github.com/WesterosCraftCode/ElectronLauncher#console
 
Last edited:
Dan_Prime

Dan_Prime

Emissary
Guest
It also may be a good idea to start phasing out support for the older launcher. We can push out an update including an alert instructing the user to install the new launcher and provide a download link/upgrade guide (just my news post should suffice). We should also pick a date where updates stop for the old launcher.
 
mikeprimm

mikeprimm

Playwright
Staff member
Admin
No plans to phase it out, any more than I'll be phasing out support for the Technic packages or describing the custom deploy using the vanilla launcher.... essentially zero cost to keep it going, and (as I hit in this case), sometimes one works for folks while another doesn't.
 
  • Like
Reactions: Emoticone11
mikeprimm

mikeprimm

Playwright
Staff member
Admin
Still no luck with 1.12.2 launching on new launcher (I pulled down your updates this morning). Not seeing much detail on the particulars in the console - it's tripping on the versionData being null after 'validateEverything' returns with a result of 'Error during validation: Cannot read property 'replace' of undefined'. Here are cases I've tried now:
1) Pristine install of 1.20 launcher on Windows: 1.12.2 downloads and starts no problem
2) Updated 1.20 launcher on Mac: 1.12.2 throws error during validation
3) 1.20 launcher on Mac, started after zapping Library/Application Support/.westeroscraft: 1.12.2 throws error during validation
 
mikeprimm

mikeprimm

Playwright
Staff member
Admin
OK - v1.3.0 launcher is confirmed good for the issue I was seeing on Macs with the 1.12.2 client. I'm going to review over the 1.12.2 content, as far as 3rd party mods, in the next day or so, and bring the client and test server up to a current proposed release candidate. I'll post here when that is done. I suspect most of the updates are going to be server side only, but I do know the SEUS shaders that had been previously dropped in don't work on 1.12.2, so those will be updated, at the least.
 
  • Like
Reactions: Dan_Prime
mikeprimm

mikeprimm

Playwright
Staff member
Admin
OK - added SEUS-Reloaded to 1.12.2 client. As with the prior SEUS, SEUS-Reloaded works on Windows but has issues on Mac. I've found instructions for patching it for SEUS - the headache is that the license for SEUS specifically precludes redistribution of any modifications to SEUS, so I'm not technically allowed to do what I'd like to do (which is to include a modified-for-Mac SEUS shader pack with the Mac tweaks already in place...
 
mikeprimm

mikeprimm

Playwright
Staff member
Admin
OK - completed big round of mod refreshes for the 1.12.2 server and client:

On client:
  • Updated to Forge 2768 (on legacy launcher): still on Forge 2651 on new launcher due to problem (looks like Forge builds from the last few months aren't working with the --modListFile parameter the new launcher depends on) - we need to work this out, since the older Forge builds aren't really supported with the newer mods...
  • Updated BetterFoliage
  • Updated DynamicSurroundings
  • Updated JustEnoughItems
  • Updated JourneyMap
  • Updated WorldEdit CUI
On server:
  • Updated to Forge 2768
  • Updated SpongeForge
  • Updated FastAsyncWorldEdit
  • Updated LuckPerms
  • Updated griefprevention
  • Updated Nucleus
  • Updated DynamicSurroundings
 
  • Like
Reactions: CashBanks
Dan_Prime

Dan_Prime

Emissary
Guest
I'm not too familiar with forge's loading system, however I've narrowed down the problematic commits. Forge devs should take a look soon. If not, perhaps you may have some more insight for them.

https://github.com/MinecraftForge/MinecraftForge/issues/5315

Edit: I've identified the issue. Going to patch it, verify it, then submit a PR.

Edit 2: I've submitted a PR to fix the issue. When merged, I can configure the distribution.json to point to the new values. Forge rewrote their modList handling back in April in anticipation for the 1.13 changes. Among many things, they are now enforcing proper maven identifiers. If defined, our entry in the modList must match the Maven-Artifact defined in the mod's manifest. I'm not 100% sure if this is intended behavior, but my money is on yes since Lex has been talking about requiring mods to have identifiers going forward.

Also note I will need to push an update to the launcher to make this compatible. They've introduced an incompatible change where absolute paths now need to be prefixed absolute:. This does not work with the older forge nor 1.11.2, so I'll have to add a version check.

PR: https://github.com/MinecraftForge/MinecraftForge/pull/5316
 
Last edited:
  • Like
Reactions: mikeprimm
You must log in or register to reply here.
Top Bottom