Porting a *world* from 1.7.10 to 1.8

[jeffryfisher]

OK, I've finished upgrading my mods to 1.8. My server world is still running at 1.7.10 with my 1.7.10 version mods. I'm looking for discussion / tutorials / event handlers to help me learn how to detect and convert the world the first time a Forge 1.8 server opens it. I am having difficulty finding world conversion info in the haystack of mod conversion info. Is there even such a thing?

 

I've given it a blind jump just to see what the issues are. After backing up my multiplayer world, I installed and ran it in recommended Forge build 1450 server. I noticed the following issues:

 

1) FML loader complained about 13 vanilla items missing (but none of my mods' items or blocks -- I guess I preserved naming!). However, in the game, all seemed to have been converted correctly, even cocoa.

 

2) Several of my mods' blocks were replaced by blocks new to version 1.8 (e.g. all of my Anystone Walls became slime blocks, and all of my Moon-phase sensors became sea-lanterns). Some other blocks disappeared completely (e.g. all of my specialized pressure-plates vanished without a trace, not even an error message in the log). It seems that new blocks are claiming block ids that my mods had been using, so saved chunks came up with these new block types in place of  mine.

 

3) All of my mods' entities vanished.

 

4) Some of my mods' items were shifted by one: Ruby helm became ruby shears, ruby chestplate became ruby helm, ruby legs became ruby chestplate etc. It's like one item got deleted and then everything else was mistranslated by one.

 

Has anyone worked on a mod (or app) that can convert an entire world (all saved chunks) to remap all mod items, blocks and entities out of the way of incoming 1.8 things? Is there a recommended technique whereby each of my mods can detect the version change and remap itself (how do I dredge up a world full of chunks to fix?) Is it even worth discussing? Is it already a foregone conclusion that a world modded in 1.7 will stay in 1.7 forever (or suffer horrendous substitutions / deletions)?

 

As I indicated at the top, I am interested in reading about others' discussions and possible solutions, but I am (thus far) unable to find them in the haystack of mod upgrade threads. Any pointers would be much appreciated.

[jeffryfisher]

Well, I settled on upgrading my 1.7.10 world to the final recommended Forge build (1448) for that version, and I now think that it will never go to 1.8. It just is what it is. From my reading, I've gotten the sense that many long-standing worlds are in the same boat, so my "note to self" is to backport a few of my mods' improvements to their 1.7 incarnations. That could (for instance) add my second set of walls to my Anystone Walls mod in 1.7.10. I'll also keep back-ports in mind if/when I get around to adding more sets of paintings to my paintings mod.

 

That left me wanting a Forge server for mc 1.8, so I started a new world for friends and nephews. After using creative mode to finish testing the client-server operation of each mod (crafting, placing and activating items, blocks and entities), we're enjoying a return to the harrowing start-up phase of the game, naked and empty-handed in survival. It sure brings back memories (though not always as quickly as I need them).

 

Notes on adding a 2nd mc server:

 

A single host does seem to be able to run two incompatible minecraft-Forge instances without harm. In Linux, I installed each in its own subdirectory to keep their ops, whitelist etc files apart. After some aggressive chown'ing, their respective "universal" jars are humming contentedly. I don't know how java is managing the memory (since each java run statement claimed most of the RAM on the machine). Maybe things will get sticky if players log into both worlds at the same time (so far we've stayed together in one or the other).

 

Before launching, make sure to edit server.properties so that the 2nd mc will use a new port number. I recommend bumping the 1st server's port number by exactly one because...

 

One may also need to open the new port in the host's firewall. Depending on your machine's architecture, this can be as easy as changing the existing rule(s) to span a range of two ports instead of merely opening the 1st one.

 

And of course, if the host is serving from behind a router, then the router's port-forwarding should be updated to include the new port (another reason to make it contiguous with the 1st).

[jabelar]

I haven't done it but it seems to me the issue is mostly with the save data needing conversion. I would think that one approach would be to make a mod for 1.7.10 that does a special save (maybe initiated by a server command) that mimics 1.8 save format. So take the world save code from 1.8 and port that to 1.7.10 then just invoke it.

 

Just a thought...

[shadowfacts]

You could try using the FMLMissingMappings event to automatically replace any instances of your old blocks/items with the new ones.

[jeffryfisher]

You could try using the FMLMissingMappings event to automatically replace any instances of your old blocks/items with the new ones.

Indeed, I have already done that. I remapped each of my missing elements to its new object.

 

Unfortunately, while that can handled renaming among my mods, it did not help with when Minecraft itself grabbed some of the ids belonging to my blocks and items. When I tried loading my 1.7.10 world using 1.8, all of my mod elements were found, but then some of their ids shifted by one. In addition, many of my mods' blocks in the world had become new block types introduced in mc 1.8.

 

Maybe I didn't do enough. I wonder if it is even possible to rifle through all of the chunks in the world to replace all occurrences. If it hasn't already been solved by someone else, then I'll put my energy into my next mod.

[jabelar]

Again, I think you're going about it the wrong way by trying to use 1.8 to do an "active" correction of a 1.7.10 save that has difficulty loading. Instead you want to convert between save formats yourself. Instead I think you want to essentially process the first recreation of the world yourself. I could see several ways to do this:

1) create a mod for 1.7.10 that can save the world in 1.8 format

2) create a mod for 1.8 that reads a 1.7.10 save file and does its own loading (that works)

3) if there is difficult doing the above because of ID mismatches, then create an intermediate save format that helps with that. Like save some information like unlocalized name for each ID and use that to match things up.

 

Ultimately it is similar to how I do my own structures. I build something and have a mod that allows me to save a portion of a world in my own format. Then in my other mods I have ability to load that structure. You just need to do similar thing on much larger scale (which needs to be extremely efficient so needs to follow mostly how vanilla does the saves).

 

But I think trying to load 1.7.10 save directly into 1.8 and then trying to handle the errors is more difficult and maybe not really possible.

[jeffryfisher]

Again, I think you're going about it the wrong way by trying to use 1.8 to do an "active" correction of a 1.7.10 save that has difficulty loading. Instead you want to convert between save formats yourself...

I agree. I wonder if the correction is a general one that could someday become an FML "pull-request" for a "final" 1.7.10 version of Forge that would save worlds to be readable by 1.8. For instance, if there are certain block, item and entity IDs that are going to be claimed by 1.8, then mod objects having those IDs in 1.7.10 should be converted to non-conflict IDs. Forge's registration, mapping, and chunk-saving machinery, not every little mod, seems like the place where that knowledge would be coded. A nice added feature would be a server-console command to grind through all chunks in the world, perhaps with all player logins disabled.