Inactive world converter/updater?

[nodots]

When there are incompatibilities between stable versions, it would be sweet to have a world updater that converts a world for use with the updated stable. That way I can keep my data without having to maintain different versions... Also, the ability to convert a world between single/multiplayer and between survival/free mode with all blocks given.

I would love to have other stuff first, like multiplayer over ethernet (internet or not, even on loop-back address) with a couple of server type options. I may bump this post to remind you, but only after the other stuff first - the multiplayer stuff IS more important. Of course, the add-ons and file format may have reached maturity by then negating this suggestion, I'm sure. Just a thought.

 

[Cervator]

Absolutely agreed

Compatibility and conversion when needed is on a list somewhere, but yeah, probably after multiplayer and the major pending chunk changes like vertically layered chunks and finding a way to attach block-level data via modules (somewhere between alpha and beta?). Do bump this thread when the time seems right, if we don't catch it!

 

[Skaldarnar]

This may fit perfectly to the launcher tasks that should be added in the future. You may want to create a new issue as a reminder on github. Maybe someone will catch it up soon

 

[nodots]

Well, if I wasn't teaching myself Python right now I would give Java a try. Is there a list/standard somewhere for non-java guys to read the world file format? Maybe I could try something in Python, then someone else could port it to Java? I could do quite a bit of sweetness with the file format...

I would also like to know the binary format for the files in the mods. Rather than use tools made by others, I like to make my own. I know my tools and can explain them (I also comment my code well) and I would license them the same as, for distribution with, Terasology. There may be many reasons for making any number of possible tools that someone who make this game may not need, therefore may not think of. (Necessity being the mother of invention.) I get more fun out of making my things "not retail" than I get from using them as intended. I hack code, crack code, and eat my peas with honey (so they stick to the knife). Point me in the right direction, and away I go!

 

[Cervator]

nodots - that sounds plenty cool, and then we could hopefully convert the gothic village world from Skaldarnar to the latest version!

Immortius would probably be your best resource for storage format. Panserbjoern probably knows too, but is low on time.

Unsure what sort of impact the two big coming-changes I mentioned above (vertically stacked chunks and block-level new data types) would have on the storage format

 

[Immortius]

It is certainly my desire that the world and all our data be stored in a well described format that can be manipulated by tools in other languages. Unfortunately the world data is still being wrapped in a java class which is serialized using Java serialization. This should be pretty easy to change now though. Of course, changing this will break all existing saved worlds, but that is the nature of pre-alpha.

 

[nodots]

Immortius: since the file format of the world is probably going to change, what about the file format of the binary files (non-text) in the mods? I am working with binary files already, and I think it would be interesting to have a mod maker that you could download and use on all systems with minimal fuss (Python for now, Java when I learn that). Also nice, would be to know precisely how to write in how something works in the text files.

If the file format is dependent on a Java function and not set specifically, then my chances of making a converter in Python are probably slim. If the mod files are pretty set for the moment, maybe I could get something done with pygame to make 3D stuff and paint it.

 

[Immortius]

We sort of have a system for making mods as is - the terasology project off of github. The gradle build script has a number of tasks that can be run to generate the skeleton of a mod, and to build it into the final distributable. It also can generate an Eclipse or IntelliJ project to do the mod coding with. But perhaps you'll be able to think of some tools that can help, so I'll elaborate.

The module format is simple enough. They are packaged as jars - java archives, which are just zips. These can simply be unzipped into a folder of the same name and used in that state, with the small proviso that the compiled code (which is in a directory structure corresponding to java package names) is moved into a classes directory. This allows development to be done without having to package the modules.

Ignoring the compiled code, the other contents of a module are:

• A mod.txt file in JSON format that contains a few details of the module - its id, displayName, description and a list of modules it depends on.
• Any assets, in a type-dependent subdirectory under the assets subdirectory.

The types of assets are:

• Block definitions, in a JSON format. Largely described here.
• Block tiles - 16x16 png files
• Fonts - see http://www.angelcode.com/products/bmfont/
• Texturres - once again png, with an optional json file to provide some additional settings (filter mode and wrap mode)
• Shaders - glsl vert and frag shaders with a json info file that describes the shader params (this could be done better)
• Materials - JSON format files that combine shaders with their settings, typically textures.
• Mesh - Wavefront obj files ( http://en.wikipedia.org/wiki/Wavefront_.obj_file )
• Music - Large ogg files
• Prefabs - JSON files that are recipes for entities, describing what components they use and their settings.
• Block Shapes - JSON mesh files, typically generated using our blender plugin
• Sounds - Smaller ogg files
• Animations and skeletal mesh - in MD5 format

I think that is everything.