Extra tiles.

[wzdev-ci]

type_patch (an actual patch, not a request for one) | by NoQ

---

Based on the discussion here: http://forums.wz2100.net/viewtopic.php?f=5&p=130849#p130848

Before we get the new map format done, i'd like to push the following quick fix. It's trivial enough to probably even go into the 3.1 branch; in fact it only touches a few lines of data, not even code.

---

The story so far: cliff decals were created in order to improve playability of old maps, clearly marking passable and unpassable areas in cases when the new renderer is ambigiously vague. Newly created maps, on the other hand, can be made to knowingly avoid this problem. Hence, it is a good idea to allow the map makers avoid using cliff decals on the new maps, or allow them to use cliff decals for only a few cliffs, and use bare cliff terrain texture for the rest. Right now this can only be achieved thourgh map-mod'ing, which is evil.

---

The patch solves the problem by adding two new tiles to each tileset, which is cliff-cliff-cliff-cliff texture without decals, and also an additional water-water-water-water texture for easier usage of seabed texture as normal terrain (which often looks very cool). For rockies, two cliff tiles are added, because there are two distinct cliff textures on rockies, and both of them are provided as decal-only.

This patch doesn't break support for old maps, be it campaign or skirmish maps. They are loaded correctly and work as expected.

New maps (which use extra tiles) are loaded by the unpatched game as well, without crashing, just terrain texture is broken for the old tiles (replaced with tileset's default texture, eg. red for arizona).

The map editor dataset is easily patched to make use of the new tiles, and the relevant update is provided on the forum.

A proof-of-concept map file is provided for testing.

---

Issue migrated from trac:4277 at 2022-04-16 11:49:16 -0700

[wzdev-ci]

NoQ uploaded file ExtraTiles-v1.patch (1.7 KiB)

[wzdev-ci]

NoQ uploaded file 4c-test.wz (2.5 KiB)

[wzdev-ci]

NoQ commented

---

New maps (which use extra tiles) are loaded by the unpatched game as well, without crashing

Emm, now that i think a bit deeper, no, not really, i think they don't, even though it worked for me, it does cause an out-of-bounds array access. We could make the new maps explicitly incompatible with the old game somehow, but map editor code needs to be changed for that.

On the other hand, same could be said about, say, maps made with new object data when loaded on an older game version, and no control on that has been imposed so far anywhere in the map editor. So i guess it's not a problem if we make the old versions crash a little bit with the new maps, right(?)

Old maps + New game work fine, of course.

---

Now i wonder how much further we can expand this idea. I could easily add all texutres from all tilesets to all tilesets as optional tiles. Unless video memory issues are of concern, it'd allow us easily make amazing maps, kinda yay. Should i try this as well / instead?

[wzdev-ci]

vexed changed blocking which not transferred by tractive

[wzdev-ci]

vexed changed blockedby which not transferred by tractive

[wzdev-ci]

vexed commented

---

I am wondering if this info should be in the map itself. In other words, update Flame/sharpFlame to handle it that way ?

[wzdev-ci]

NoQ commented

---

Yes, it is a good idea to put most of the tileset info into the map. This is called "the new map format". This fix is proposed as a short-term solution before we have one.

To avoid the crash described above, it is enough to bump map format version in the map headers produced by the map editor. For that we need to change the map editor (trivial) and release the updated new map editor (harder), and anyway we need to trust map makers to never use the new tileset data with the old editor (impossible). Note that trusting users to never load new maps into the old game might be actually not too much harder.

Also, the crash we're discussing here is a (minor?) security vulnerability (by hosting a game with a specifically crafted map, the attacker may cause out of bound array access on the client machine... just read though, not write). It's probably worth fixing on its own.