Ok. Was just a thought. But yeah, at the least it would be nice to have a single signon.
As for the image then not something I would worry about.
Same for the paint program.
As for the data and how the program handles it, I'm not exactly sure what our options are. I need a clearer picture of the program flow.
On the basic level I assume mapgenerator loads up the images, then compares what it finds to the terrain.xml and altitude.xml and processes that, then goes through the transitions and processes those, and finally on to the statics files and processes through those then gives you your finished product.
I guess what I need are extra fields in the files that the program can interpret. The thing is I don't want to add too much complexity to it because the program runs extremely well and seems to be nearly unbreakable and I don't want to lose either of those things.
For example, we have grass defined in terrain.xml.
Code:
<Terrain Name="Grass" ID="1" TileID="3" R="0" G="100" B="0" Base="88" Random="False" />
Which means the terrain name is grass. The hash id for grass tiles will be 01, the base terrain tile (which we get from insideuo) is 3, and the color we will use on the map to indicate we desire grass is a medium green, the base altitude to use (
Aha! this is where the altimageprep.exe knows what to assign it in the altitude map, key 88 in the altitude.xml which is land 0), do not randomize the altitude.
Then we have an entry for grass in common.xml
Code:
</TransInfo>
<TransInfo Description="Common - Grass" HashKey="010101010101010101" File="Grass.xml">
<MapTiles>
<MapTile TileID="3" AltIDMod="0" />
<MapTile TileID="4" AltIDMod="0" />
<MapTile TileID="5" AltIDMod="0" />
<MapTile TileID="6" AltIDMod="0" />
</MapTiles>
<StaticTiles />
Which says if it is a grass tile, surrounded by grass tiles, then randomly make it tile 3,4,5 or 6.
Moving right along we then have our various transitions, and because grass is higher up in the hierarchy, it transitions to most other terrains (as opposed to them transitioning to it) so there are a lot of files.
Now that's all well and fine, I think it is as simple a system as we can have that still gives us the power to do what we want to do.
Now along comes Joey Bagadonuts who wants to generate his grass in a green acres area without statics, but he still wants flowers and rocks and grass in the main map area. So we have to go into terrain.xml, copy the grass entry, giving it a different id and changing RGB values to make it its own color but otherwise keeping everything the same. Then onto common.xml where we duplicate that information, just changing the hashkey to our new id and removing the file call. Then (and here is where it gets ugly) we have to go through the transitions directorys and not only copy every grass to x file, renaming it and changing the hash key throughout the file, we also have to search for any files in other directorys that say x to grass (such as rough edge, water trans, ridges, specials, etc). All this work where the only difference is we want statics in some places and not in others.
Now along comes Vinnie Boombats who wants to generate uneven grass in a T2A area, but he still wants his normal grass in the rest and Joeys plain grass in green acres. So we go through all the steps we just did above, except the only difference here is we want to change random="Fales" to random="True".
We can go on and on and on now for different areas. Say we want 1 color rocks and type of flower in the south, another in the north, a 3rd in the east,etc,etc,etc. It is also great that we have the ability to do all this, and the room in the palette for it as well. However this is a hell of a lot of work from the development end to make it work and it is all to easy for the end-user to fuck the whole thing up (which is probably why Rich plans to go back to hardcoding everything)
While we can accomplish the same in Dragon on a regional basis, we had to plan where we wanted each area beforehand and box them out. It also got to be a lot of work when you had boxes in boxes so I don't think that is much better of a solution, but there must be some way we can consolidate the scripts. Say some other value, like a secondary hash that says, ok use the same transitions as grass but a different set of statics (or no statics, or make the ground uneven, etc).