More than three.

[NoQ]

The following patch adds support for more than three tilesets in skirmish. It also includes more minor fixes like allowing multiple different cliff textures and multiple different seabed textures in a single tileset.

• extended-tilesets-final.patch

How this works.
Suppose you want to add a 4th tileset. You add the new tileset descriptions to data/mp/addon.lev like this:

• extended-addon-lev.patch

Note: you can't add the same to the per-map addon.lev file instead, it'll crash.
Note: you need to follow the naming convention for the datasets (eg. MULTI_CAM_4 rather than WHATEVER_YOU_LIKE).

Then add the tileset data to the game, the following files:

Code: Select all

texpages/tertilesc4hw-*/tile-*.png
tileset/tileset4ground.txt
tileset/tertilesc4hwGtype.txt
tileset/tileset4decals.txt
tileset/tileset4_enum.txt
wrf/vidmem4.wrf

where you can have 4, 5, 6, etc. if you add this to addon.lev properly. The file internals need to be updated accordingly, terrain type naming convention is as follows: t4_cliff = cliff tiles, t4_water = water tiles, everything else can be arbitrary, and the first lines of some files need to be updated as well. vidmem4.wrf file must mention tertilesc4hw in its TERTILES line.

Here is an example of a map-mod that uses tileset 4 with all new data in place. This is pure proof-of-concept, nothing to look at, i'm just happy it loads and looks as i expect it to (if you apply both patches and try to play it).

[Andrie]

Sorry, but I don't under stand how it works.

[NoQ]

I guess i forgot to explain what is it good for. It allows community-created tilesets to be merged into the game [without replacing the old ones], allowing to eventually make maps for them. The support necessary on the map editor side is pretty trivial: only *.addon.lev file creation code needs to be modified to make use of the new tileset, in fact it can easily be modified manually.

This patch doens't affect the ability to use custom terrain textures via map-mods.

With some data update, it is possible to simplify the code to completely unify the original tileset support code as well.

I don't add new colors to the map preview yet, arizona preview is used for additional tilesets.

Is it worth it?
____________
Andrie: messages in this forum section are not meant for understanding, you'll get used to it.

[Goth Zagog-Thou]

I think it's worth it. Would we still need the terrain types modification to the code for Arizona?

[Andrie]

What must I do with the file.

[NoQ]

Would we still need the terrain types modification to the code for Arizona?

Emm, what sort of modification are you refering to?

[Goth Zagog-Thou]

The modification to the code that prefixes the tile types according to their original sets.

map.h so far:

Code: Select all

/* The different types of terrain as far as the game is concerned */
enum TYPE_OF_TERRAIN
{
	   TER_AZ_SAND,
   TER_AZ_SANDYBRUSH,
   TER_AZ_BAKEDEARTH,
   TER_AZ_GREENMUD,
   TER_AZ_REDBRUSH,
   TER_AZ_PINKROCK,
   TER_AZ_ROAD,
   TER_AZ_WATER,
   TER_AZ_CLIFFFACE,
   TER_AZ_RUBBLE,
   TER_AZ_SHEETICE,
   TER_AZ_SLUSH,
	TER_UR_SAND,
   TER_UR_SANDYBRUSH,
   TER_UR_BAKEDEARTH,
   TER_UR_GREENMUD,
   TER_UR_REDBRUSH,
   TER_UR_PINKROCK,
   TER_UR_ROAD,
   TER_UR_WATER,
   TER_UR_CLIFFFACE,
   TER_UR_RUBBLE,
   TER_UR_SHEETICE,
   TER_UR_SLUSH,
	TER_RO_SAND,
   TER_RO_SANDYBRUSH,
   TER_RO_BAKEDEARTH,
   TER_RO_GREENMUD,
   TER_RO_REDBRUSH,
   TER_RO_PINKROCK,
   TER_RO_ROAD,
   TER_RO_WATER,
   TER_RO_CLIFFFACE,
   TER_RO_RUBBLE,
   TER_RO_SHEETICE,
   TER_RO_SLUSH,

	TER_MAX,
};

#define TILESET_ARIZONA 0
#define TILESET_URBAN	1
#define TILESET_ROCKIES 2

[NoQ]

TILESET_ARIZONA etc. defines are pretty much not interesting (hardly ever used), i already worked with them.

Lol, i'm not sure what happens to the tile types, but i want to believe new tilesets don't require new tile types; we can just re-use the old ones. On the sample map above, tile types are exactly the same as on the original map (taken from the .ttp file that is present inside the map anyway), even though the tileset is different. So i think it is the map that is responsible for the tile types, not the tileset itself, and probably the items in this enum can be mixed freely on every map on every tileset.

[NoQ]

Upd. These definitions might be of not much importance to the tileset, but they are related to the map preview, which is something still to be fixed. The colorful map previews are now pretty much hard-coded need to have a closer look.

[Paul]

You are making it so we can load a unlimited number of textures now?

[NoQ]

Not textures but tilesets. I guess we need a dictionary, cause more and more misunderstandings show up >_< Also rather not for players to load, but mostly for the game to provide (:

[Paul]

I am just worried about how much texture memory this will use? My low end laptop can still play Warzone but it has a limit of 128megs vram.
Does the game load everything even if you don't use all the texture sets?

[NoQ]

The whole point of having more tilesets is to not load all textures at once into VRAM, but only a sensible part of them.

[Goth Zagog-Thou]

You probably won't notice much of a difference in memory use, except for maps that use a larger (read: varied) number of the tiles.

Alright NoQ, so we really don't need to mess with the tile types in the code then? Just assign them in FlaME and call it good?

Aside from upping the MAX_TERRAIN_TILES in map.cpp:132?

[NoQ]

Had a look. Of course you don't need new tile types! I'm not sure why the game has more than 3.5 tile types at all (cliff, water, ground, probably road).

upping the MAX_TERRAIN_TILES in map.cpp:132?

How much do you need? (: