Putting a <tileset> after a <layer> in a <map> element causes that tileset to be ignored

[RossBrunton]

To reproduce:

• In one of the test .tmx files, move the element after a element. For example:

  <?xml version="1.0" encoding="UTF-8"?>
  <!-- This is assets/tiled_flipped.tmx -->
  <map version="1.4" tiledversion="1.4.0" orientation="orthogonal" renderorder="right-down" width="2" height="2" tilewidth="32" tileheight="32" infinite="0" nextlayerid="2" nextobjectid="1">
  <layer id="1" name="Tile Layer 1" width="2" height="2">
  <data encoding="csv">
  3758096387,1073741827,
  2147483651,536870915
  </data>
  </layer>
  <tileset firstgid="1" source="tilesheet.tsx"/>
  </map>

• Run the tests, depending on the test, it may fail due to LayerTile information not being available. In the above example, making that change prints this fail:

  ---- test_flipped stdout ----
  thread 'test_flipped' panicked at 'called `Option::unwrap()` on a `None` value', tests/lib.rs:258:35
  stack backtrace:
  0: rust_begin_unwind
           at /rustc/0e07bcb68b82b54c0c4ec6fe076e9d75b02109cf/library/std/src/panicking.rs:498:5
  1: core::panicking::panic_fmt
           at /rustc/0e07bcb68b82b54c0c4ec6fe076e9d75b02109cf/library/core/src/panicking.rs:107:14
  2: core::panicking::panic
           at /rustc/0e07bcb68b82b54c0c4ec6fe076e9d75b02109cf/library/core/src/panicking.rs:48:5
  3: core::option::Option<T>::unwrap
           at /rustc/0e07bcb68b82b54c0c4ec6fe076e9d75b02109cf/library/core/src/option.rs:746:21
  4: lib::test_flipped
           at ./tests/lib.rs:258:14
  5: lib::test_flipped::{{closure}}
           at ./tests/lib.rs:252:1
  6: core::ops::function::FnOnce::call_once
           at /rustc/0e07bcb68b82b54c0c4ec6fe076e9d75b02109cf/library/core/src/ops/function.rs:227:5
  7: core::ops::function::FnOnce::call_once
           at /rustc/0e07bcb68b82b54c0c4ec6fe076e9d75b02109cf/library/core/src/ops/function.rs:227:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

As far as I can tell, the format for .tmx does not require the nodes to be in a specific order.

This is caused because nodes are parsed as we see them. When generating the tiles in a TileLayer, the list of already parsed tilesets is looked up to figure out which should be used. If this list is empty (if no tileset node is seen yet) or contains no elements for which first_gid < gid, it is interpreted as the tile being "empty" as if it were GID 0.

[aleokdev]

As far as I can tell, the format for .tmx does not require the nodes to be in a specific order.

It does, but it isn't documented. One second.

[aleokdev]

See https://github.com/mapeditor/rs-tiled/pull/135#discussion_r801650701. This is expected.

[bjorn]

• In one of the test .tmx files, move the element after a element. For example:

Just wondering, but why would you do such a thing?

I do need to remember to put a note about this in the documentation...