...The problem with tilesets and mods is this: A fish might be tile235 in pheobus, but is tile16 in ironhand. You can copy over the tileset, no problem. But the raw will still refer to the old location, and you get wierd things. Like mushroom walls.
Meph, (though everyone is free to poke holes in it or run with it)
I think I figured out a way to greatly simplify the process of adding support for additional tilesets (a little scripting skill is required, though). It's not fully fleshed out yet, but the basic idea is to make your working raws tileset-agnostic by using variables instead of references to specific tiles, then use a small map file to translate your variables into a tiles for a given tileset. When you are finished editing your working raws and want to either test them or generate a "final" copy for distribution, you'll run a small script (in the programming language of your choice) that just iterates over the raws, copies them to a new folder, then replaces your variables with the tiles from whatever map file you've used. After the initial (one-time) effort of making your working raws tileset-agnostic and writing the script to do the translation, adding support for further tilesets is as easy as making a map file for that tileset.
Here is an example using the Masterwork 0.8 raws:
In a greatly abbreviated form, this is an excerpt from inorganic_stone_gem (intended for Phoebus' tileset):
[INORGANIC:CITRINE]
... [TILE:169] ...
[INORGANIC:GOLD OPAL]
... [TILE:170] ...
[INORGANIC:RUBY]
... [TILE:171] ...
[INORGANIC:DIAMOND_CLEAR]
... [TILE:172] ...
After making it tileset-agnostic, it may look something like this:
[INORGANIC:CITRINE]
... [TILE:tile_gem_tier1] ...
[INORGANIC:GOLD OPAL]
... [TILE:tile_gem_tier2] ...
[INORGANIC:RUBY]
... [TILE:tile_gem_tier3] ...
[INORGANIC:DIAMOND_CLEAR]
... [TILE:tile_gem_tier4] ...
Not all tilesets are going to have 4 separate tiles for unmined gems like Phoebus', but, as you'll see, that's not going to be a problem.
Here's roughly what our map file template looks like with the few variables we've used:
tile_gem_tier1 =
tile_gem_tier2 =
tile_gem_tier3 =
tile_gem_tier4 =
Now a map file for the default Phoebus tileset in Masterwork 0.8:
tile_gem_tier1 = 169
tile_gem_tier2 = 170
tile_gem_tier3 = 171
tile_gem_tier4 = 172
Now a map file for Ironhand's tileset v0.60 (the latest one, not the one packed with Masterwork):
tile_gem_tier1 = 163
tile_gem_tier2 = 164
tile_gem_tier3 = 165
tile_gem_tier4 = 166
And finally a map file for vanilla (or "ASCII") tilesets:
tile_gem_tier1 = 15
tile_gem_tier2 = 15
tile_gem_tier3 = 15
tile_gem_tier4 = 15
So, you end up with a single set of raws that, via the use of a simple intermediary file for translation, can support even tilesets intended to be used with heavily edited raws. There's a not-insignificant amount of work front loaded with this method, but it should be smooth sailing after that. Even if you can automate the bulk of the work, there will still need to be a little manual editing. You still have to set the pillar tile in the init file to whatever is appropriate for the tileset. Also, the same colors for an object may not work well with all tilesets (especially something like Ironhand's with its color trickery, or there could even be color oddities from trying to support both transparent PNGs and classic BMPs.)