[1.8] The Ultimate Version of 1.8

[jeffryfisher]

I'm looking to update my mods from mc 1.8 (Forge 1450) without crossing a line that would break an existing server world. Some upgrades break worlds. Others don't. My server has been running Forge b1450 (mc 1.8 ) since summer. I'd like to top it out at (and upgrade my mods to) the highest recommended Forge build that won't break things (e.g. interpret my mods' blocks as new vanilla types).

 

Looking at the files area here, I see two candidates. Build 1563 is the highest recommended for "mc 1.8", and build 1722 is the highest recommended for "mc 1.8.9". What I don't know is if it is safe to open a 1.8 world using a 1.8.9 server. I've searched, but the haystack of new features and bug-fixes is too deep to find a clear compatibility answer. I know that 1.8.9 clients can enter 1.8 servers, but I can't see that a 1.8.9 server can open a world saved by an earlier 1.8 server.

 

Can I jump my mods and world to mc 1.8.9 and Forge 1722 without gross glitching? Have any of you upgraded last year's 1.8 worlds up to 1.8.9 without serious incident? In other words, does mc 1.8.9 play nice with earlier subversions of 1.8?

 

If I can get clarity, then I can plan my project to upgrade my mods.

[Choonster]

Have you tried opening a copy of your world in 1.8.9 to see if anything breaks? Some 1.8 mods may work in 1.8.9.

[jeffryfisher]

I haven't yet because I was at the choice between versions to try. I was hoping that the compatibility was better known, but I guess I'll have to setup b1722 first and try it myself on one of my expendable SP test-worlds. Then I might find out that I need to use b1563 instead as the final resting place for my 1.8 worlds.

 

Has anyone here upgraded to 1.8.9 on a world that created in an earlier 1.8 version? Were there any issues, or did mods' blocks survive intact?

[Ernio]

Everything works fine as long as modders followed good modding practices and didn't fuck with data, especially manipulating things per-ID (where per-instance is preferred since 1.7).

 

This question is too broad to be answered without actually testing it, so my answer is:

Update to latest and work with that.

Even if there are errors - they can be fixed with Events and if not with events - you can manipulate world data on loading.

[jeffryfisher]

Everything works fine as long as modders followed good modding practices...

Since I style myself as a professional who follows "best practices", I'll proceed as if my 1.8 world and mods can (probably) survive the upgrade. Of course, best practices include backing up the world before such an upgrade. I'll report back on any issues / workarounds.

[jeffryfisher]

My 1st discovery is that a 1.8.9 client can log into a 1.8.1 server, so that's a good sign. I also found Lex's message announcing the 1st recommended Forge build for mc 1.8.9, and that says it should work with all versions of 1.8.

 

Upgrading my mods, I've encountered two minor issues so far:

 

1) The BlockCompressed class has vanished, so my block of ruby now extends the Block class itself. Block has two constructors, so I chose the one passing both material and map color.

 

2) In class Achievement, a srg-named method has acquired a real name:

    func_180788_c() becomes registerStat()

 

In a separate issue, my early-iron-age server crashed when it attempted to load a 1.8.9 Forge server that has newly integrated jline console support. Adding -Djline.enable=false before the -jar argument in my command line bypassed the problem.

 

EDIT (addenda):

 

3) StateMap.Builder ().addPropertiesToIgnore has shortened its name to "ignore".

 

4) Agh! Fence gate class now assumes that it is made of planks, demanding a BlockPlanks.EnumType in its constructor. After my iron fence gate supplies a bogus BIRCH value, it fights back by overriding getMaterial and getMapColor methods.

 

The only purpose of the plank type was to acquire the map color. Therefore, the fence gate constructor should be generalized to take exactly that, not bothering with the assumed intermediate plank type. Arrgh!

 

EDIT (more addenda):

 

5) World.func_175674_a() method has gained the name getEntitiesInAABBexcluding()

 

6) EntityHanging class has named func_174859_a() as updateFacingWithBoundingBox(...)

 

7) ... and EntityHanging.field_174860_b has become facingDirection

 

8 ) RenderPainting's getEntityTexture method changed its parameter type from Entity to EntityPainting

 

and OMG, the renderer is a completely new paradigm