Start of port to v1.12.2

[mikeprimm]

Folks,

I've started doing some non-trivial work towards moving us to be based off of Minecraft v1.12.2 (including the corresponding update of Forge, and migration to the Sponge 7 API). Not sure how long this will take to get to a production quality, but I figure we will want to keep ahead of the obsolescence curve - and v1.11.2 mod support is starting to ebb.

In any case, I'm hoping to have a test client and server together 'Really Soon Now(tm)' - this will definitely be 'alpha' level: something that works enough to figure out what is broken, versus being anywhere near ready for production. I'll definitely need some eyes on this, once we get there: the project will be less crazy than the last upgrade, but major version moves are always opportunities for lots of silly crap.

 

[mikeprimm]

OK - we've now got a proper test client and server for v1.12.2. You'll see a 3rd client in the launcher, which will take you to a test server running with essentially a clone of our current configuration and worlds. Give it a look, and let me know if you see anything particularly broken...

 

[Emoticone11]

Started testing. Just at a first glance, the major things I see are:

- CTM doesn't appear to be working for any of our custom blocks.
- Vanilla blocks (glass panes, etc.) aren't connecting to our custom blocks.
- Fence blocks are connecting to any block, whereas they should only connect to solid blocks:
https://puu.sh/zqrpJ/7791f63b85.png
https://puu.sh/zqrqn/5cdf5d9eb4.png
- Custom biome shading isn't working for any of our custom blocks.

- /ptime doesn't seem to be functional (although /pweather is).

Will test in more detail later, haven't looked at anything perms-wise, will need a test subject for that.

EDIT: Also, do you still have the list of things we had to fix during the 1.7.10 port compiled somewhere? It would be helpful I think to just run through that list again, but the 1.7.10 thread is on the old forums so I can't access it.

 

[mikeprimm]

Updated v1.12.2 server and client:

• Updated WB to include new blocks from Emot that are also on v1.11.2 test client and server
• Update OptiFine to D1 version - hoped this would fix CTM problem, but doesn't seem to have helped...
• Updated Forge in client to 2651
• Updated Sponge on server
• Updated RP to include new updates from Emot that are also on v1.12.2 test client and server

 

[mikeprimm]

Also, I put some work in on the CTM issue last night, and found a workaround (which, unfortunately, is all about using the 'old school' blockXXXX*.properties naming to drive CTM association with blocks (versus matchingBlocks=, which seems to NOT work at all - even for numbers - on OptiFine on 1.12.2....). I'm working on an RP update to handle this, but I've confirmed that it seems to work with everything I've tried so far, so expect another update tonight....

 

[mikeprimm]

OK - so just updated 1.12.2 server with both updated RP and WB (based on new block changes and other fixes from Emot, matching what is in test for 1.11.2), and with the workaround for the CTM issue. Please give it a look

 

[geeberry]

Had a look over a few days ago and didn't notice any glaring issues - but maybe @Emoticone11 can doublecheck?

 

[mikeprimm]

If we're looking good, I'd like to start working towards a migration plan. A lot of existing mod support for 1.11.2 is starting to sunset, and I'm hoping we can avoid getting as far behind the curve as we were back with 1.7.10.

 

[geeberry]

Sounds good!

 

[Emoticone11]

I'll give it a look in a bit, probably in a few days after I have my last exam.

Do you have the list of things we had to fix back in 1.7.10 compiled anywhere, @mikeprimm ? I unfortunately can't access the thread on the old forums ATM. But having that would help immensely with bug-testing.

 

[Emoticone11]

Alright, was able to access the 1.11.0 port thread since Pizza put the old website up for a few days. Compiled the list of bugs there to help give us some go-to testing points for future migrations.

http://www.westeroscraft.com/threads/version-migration-bug-testing-checklist.1167/

Will go through the list with the 1.12.2 client in a few days!

 

[Emoticone11]

Hey @mikeprimm , I tried to visit the 1.12.2 server today, but upon visiting I seemed to be hit with an unplayable amount of client-side lag. My memory is already set quite high (6G) and I've never had problems otherwise, so I'm not really sure why this would be the case. Do you have any idea?

 

[mikeprimm]

Not sure - I'm running with 3G on both min and max heap, and just logged on and was pretty clean while flying around King's Landing....

 

[Dan_Prime]

I could check if out if you could whitelist me (TheKraken7).

Side note, new launcher works well loading the 1.12 client.

 

[mikeprimm]

OK - long day of working on WC 1.12.2 - lots of progress, and I think I've licked the lag gremlins that @Emotione11 was seeing. Client and server are up to date - please give things a look!

@Dan_Prime You are on whitelist - if anyone else wants to be added, just ask.

Sorry that I've been off of this for the last few weeks - the Dynmap updates to support MC v1.13 were, frankly, HUGE. Very large rework of the guts of the system to support the new block model efficiently while still supporting older versions at least as well as before. I've also got a vanilla accurate model for water/lava now, so looking forward to deploying on WC and rerendering our water features

When the time comes, there definitely will be some compelling arguments to move to 1.13 - just understand it's probably the most technically disruptive release since the first Beta (even bigger than when they introduced the Anvil file format). Block IDs as we know them are now TRULY gone - not 'make pretend' gone like was the case for 1.11 and 1.12 (where they were there, same as even, but being blissfully ignored by folks because Mojang said to ignore them....), but the potential population of blocks is essentially open ended now, and things are generally a lot cleaner. That said, it's going to play havoc with the existing CTM stuff, as there are no block number equivalents anymore AND many of the vanilla blocks are refactored : for example, there aren't multiple types of slab in the same slab block, while single and double slabs of the same type are now combined into one block with 3 states; Stairs have 80 states, not 8 metadata values; fences have 32 states (all connection permutations) that are actually stored in the world data, vs 1 state stored with everything else run-time detected; etc. etc. That said, the support for things like 'waterlogged' (that is, immersed in water) blocks is some seriously cool stuff - partial blocks, like slabs, stairs, plants, and the like can be both in/under water as well as their normal in-air appearance: lots of fascinating creative potentials there!

 

[CashBanks]

Block IDs as we know them are now TRULY gone - not 'make pretend' gone like was the case for 1.11 and 1.12

Do you think the end of Block IDs is something we’d be able to overcome? Is there anyway we’d be able to retain our present World Edit and Vox abilities without them?

 

[Dan_Prime]

It's most likely not going to be an issue that we can't overcome. As far as I can tell from the direction Bukkit/Sponge has gone you will just use an enumeration (the actual material name). Forge has begun their 1.13 update process so you can always take a look into what they're planning https://github.com/MinecraftForge/MinecraftForge/tree/1.13-pre.

It will involve porting legacy ids over to whatever the new representation will be.


As far as the 1.12 update, the new launcher should be good to go. When porting to 1.13 is an active project I'll look into what needs to be done. I believe Forge 1.13 will support Java 11 (11 will be active by the time it's done, 9 is EOL and 10 is EOL in October). I will add support for Java 11 at that time.

 

[Emoticone11]

Lag issue seems to be fixed as far as I can tell!

I'll run through the permissions tests as soon as I can find someone to help (any volunteers would be appreciated!), we should hopefully be good to go soon enough.

 

[mikeprimm]

Cool!! OK, I'm going to be traveling for two weeks, starting on Friday (9/14) - mostly on board a ship, so intermittent internet at best. I'll be in UK and Ireland, when on land (with a couple days in London next weekend before the ship heads out), so I'd like to shoot to deploy to 1.12.2 after I return - it just seems like a really bad idea to push for just ahead of me largely dropping off of the map (as far as being able to diagnose and fix stuff).

On a related note, I'll be going to the Victoria and Albert Museum in London to check out the "Videogames: Design/Play/Disrupt" exhibit (which includes WesterosCraft!!!!) - https://www.vam.ac.uk/exhibitions/videogames - so count on some pictures being posted from that as soon as I'm able (and everyone here should be crazy proud of being part of an exhibit at such a prestigious museum!).

 

[mikeprimm]

It's most likely not going to be an issue that we can't overcome. As far as I can tell from the direction Bukkit/Sponge has gone you will just use an enumeration (the actual material name). Forge has begun their 1.13 update process so you can always take a look into what they're planning https://github.com/MinecraftForge/MinecraftForge/tree/1.13-pre.

It will involve porting legacy ids over to whatever the new representation will be.


As far as the 1.12 update, the new launcher should be good to go. When porting to 1.13 is an active project I'll look into what needs to be done. I believe Forge 1.13 will support Java 11 (11 will be active by the time it's done, 9 is EOL and 10 is EOL in October). I will add support for Java 11 at that time.

The biggest issue is going to be the migration of existing block data to new blocks: the mapping isn't one to one, or even 1 to N or N to 1. Lots of shuffling even among vanilla-like blocks, and every reason to expect it to be tricky (since, for example, may of the states in 1.12.2 are runtime - not stored in world data, but derived from block code in 1.12.2 that produces the state by looking at the neighboring blocks and their associated code-based characteristics. Consequently, since the 1.13 versions of the blocks generally don't have the same run-time state determination, the 1.13 version of blocks will need to bring along some form of migration code - the vanilla 1.13 code did not provide this as a clean 'part of the block class' capability, and what they did is largely hard-coded).

As for Java 11 - I doubt it: Java 9 and 10 are EOL due to them being non LTS versions. That doesn't apply to Java 8, and Forge doesn't tend to deviate from the Java requirements for Vanilla (which are 8 for 1.13). Java 11 isn't even in the can, and as someone that's been developing for Java since 1.1, I can say that using a new Java major version in the first 12 months after GA is not optimal.... Java 8 is getting continued updates through end of 2020, in support until 2025, so that isn't gonna drive anything for a while. Oracle says Java 11 will be LTS, but also says they will not be doing 'Public Updates' and are being uncomfortable about their use of 'Personal Users' vs 'Commercial Users' - see http://www.oracle.com/technetwork/java/javase/eol-135779.html for what I mean (particularly under the 'Java SE Public Updates' - really looks like they are pulling Java back in from the being as public as it is, which suggests interesting future for OpenJDK and the rest, much less use of Java as free runtime supporting commercial products, like Minecraft).