[http://sourceforge.net/p/ufoai/bugs/2831 Item 2831] imported from sourceforge.net tracker on 2013-01-28 19:50:51

There is a big problem with random. May be it is win-only, may be it affects not only RMA.

If RMA-assembly contains «tileset», there will be only one tile on whole map.
There is a test-case in attachment. It is test RMA with 4 possible tiles.
Uncompress archive to base/maps directory, run the game and write "map day +test_rma xxx", where xxx is one of possible variants:
test: simple assembly with all frequencies set as +r "0 9"
test_1: the same but they set as +r "1 9"
test_tileset: it uses tilesets, tileset test "0 10"

In my case all map will have one color in last case, and CM_LoadMap will be something like
2011/03/18 17:08:55 CM_LoadMap: "-test_rma_rand/ +g +g +g +g +g +g +g +g +g" "8 -8 0 8 0 0 8 8 0 0 8 0 -8 8 0 0 0 0 -8 0 0 0 -8 0 -8 -8 0"
===== Comments Ported from Sourceforge =====

====== kildor (2011-03-18 11:21:23) ======

test-case
====== aduke1 (2011-03-18 19:28:25) ======

During work on the RMA2 algo, I noticed that, too.
So...confirmed.
====== tilmanuwe (2011-03-21 20:11:44) ======

yes that's true, found the same while working on the +forest
every time you call a tileset, just one tile is selected and put in the number specified
workaround
tileset aa "0 1"
tileset aa "0 1"
tileset aa "0 1"
instead of tileset aa "0 3"

tilli
====== darkrainx (2011-05-28 15:42:22) ======

Not really a problem with random SV_GetTileFromTileSet is designed to choose a single random tile from a tileset, which work pretty well for a fixed tile, also http://ufoai.ninex.info/wiki/index.php/Mapping/Random_map_assembly does not specifies which is the expected tileset behavior

That said something like https://sourceforge.net/tracker/?func=detail&aid=3308790&group_id=157793&atid=805244 could change this behavior to choosing random tiles from the tileset

====== tlh2000 (2011-06-05 12:17:29) ======

fixed in 6e24181798061c91196148d47793e230509cb2a9
====== aduke1 (2011-11-26 22:00:16) ======

This has also been fixed for RAM2.
Kildor, could you plz rerun your test and confirm ?
====== aduke1 (2012-09-17 21:19:02.739000) ======

- **status**: pending --> closed