Well, sort of. It is more about the editor adapting to the changes in data rather than adding new features to the editor.
Mod structure on the file system
It is finally time to set into stone a fixed structure on the file system. But before, let me explain how you will get a mod. When you download a mod, you will be downloading a standard ZIP file. You can unpack it manually, but the editor will also be a mod manger, where you can install, uninstall or manage the load order of mods (not implemented yet, so you need to unpack it right now manually). The name of the mod will be its future identifier. Right now I have no plans to allow you to install two separate version of the mod, but if you really wish to, you can cheat the system and give different names to different versions of the same mod.
In your game folder you will have a folder called "content". In this folder, you will have a sub folder for every mod that you have installed. The default content is no different than any other content, so it is also a mod. The default content is called "core". If I ever release and expansion, it will have a new name. So in the folder "content/core" (and every single folder associated to a mod), you will find a "data.xml" file, containing the entire content offered by the mod and a bunch of raw image files, offering the tiles used by the content. I say raw, because these files will be loaded by the editor, converted to textures optimal for loading in the GPU and cache the results, so you don't need to do this every time you launch the game (not that it is an involved process; it is done transparently without user intervention). I have files called "core.plants.png" and "core.tree.birch.png". This is just a convention and may not be needed, since files are in their own folder.
And while the editor will handle mod uninstalling, simply deleting the folder will also do it. What happens if you also delete "core"? Your computer well explode, triggering a massive and catastrophic chain reaction, but only if you do it after the 21st of May 2011.
Identifier IDs for all items
In the past I introduced IDs for every object. Unfortunately, I was unconsciously influenced by years of data base experience and I realized that numerical IDs that have some set ranges are really not a human friendly system. When you have 50 mods good luck remembering what ID 12583 was.
A identifier system is a lot better and it can greatly help you recognize and memorize item names. So an apple tree will have the ID "core.tree.apple", it will have leaves called "core.leaf.apple", fruit "core.fruit.apple" and seeds called "core.seed.apple". These values are based on pure convention. You can name them absolutely everything, but all my items will use these conventions and if you want to change one of my objects you also need to adopt this convention only for that particular item. So I can call something "core.fruit.foo", even if foo does not have a fruit, but it is cone or something. Calling it fruit I set a convention, allowing me to realize how that thing is introduced in the world (grows from a plant) and giving me a general idea of its properties (it will probably have seeds).
When the scripting language is introduced, these IDs will be used as variable anmes, so it is important to keep them unique. This is why I prefix them with the mod name. When you write your "catheaven" mod, introducing a series of luxury cat furniture and care products, it would help if you would follow this convention and call things "catheaven.bed.expensive" or "catheaven.desease.toxoplasmosis".
Animal and animal products tabs merged
I find it hard to edit animals, since I am constantly changing between the two tabs. I ran into this problem with trees, so I used the same solution: split the tab in two sections, with the bottom one showing items that belong to the item selected in the top one.
The animal list has suffered intense "data rot" that I am yet to recuperate.
Plant products no longer belong to plants
I had this small problem with the plant system: plant products were not items just existing in the "world" or "ruleset", they belonged to the parent plant definition. This made it hard to add things that were actually self sufficient items, like rocks. So it made very hard to make a plant that grows animals :). Now, all items are self sufficient and if there is relationship between different items, these items will only reference each other. This means that when you want to add a product to a plant, you will have to enter the ID of that product. You will be able to edit the product in place if you wish, or got to its own tab based on category. But if you edit it in place, you will be able to get some properties that you don't normally get, like when adding a inorganic product to an organic.
New editor tab for tile sheets
Pretty straight forward: a new tab with two columns, allowing you to add a filename and a number of tiles. This must be done for all the PNG files that a mod is containing.
Tile conversion function
I have added a new function to the editor, that allows you to take an isometric tile sheet representing block like objects and convert these to a 2D textures. This will allow you to texture something made out of a material and make that object actually look like it is made out of that material. And did I mention that the textures tile properly. Maybe not always. Or other uses. I am getting really good at foreshadowing.
Great work! Definitely look forward to more news on development. There's a lot more people watching this than you would think.
ReplyDeleteMore than a week without news on development... I hope this is dued to a future big update....
ReplyDeleteKeep the hard work!