This issue was caused by the different ordering implementation for std::set iterators. On Windows, the set is ordered by insertion order while on Emscripten/Linux the iterators are sorted by name. In this scenario, the WORLD_MAP entry would load last, which had all connection points.
While this meant we had all connection points when loading all other levels, it also meant on the Linux/Emscripten build all other levels would be loaded first, and this means no connection points were updated correctly.
Deffering the connection point reading code until after all levels were loaded was the correct solution here.
This issue was caused by the different ordering implementation for `std::set` iterators. On Windows, the set is ordered by insertion order while on Emscripten/Linux the iterators are sorted by name. In this scenario, the `WORLD_MAP` entry would load last, which had all connection points.
While this meant we had all connection points when loading all other levels, it also meant on the Linux/Emscripten build all other levels would be loaded first, and this means no connection points were updated correctly.
Deffering the connection point reading code until after all levels were loaded was the correct solution here.
sigonasr2
The spawn lists for the emscripten and Linux builds of the game do not populate correctly for some bizarre reason. Need to debug on clang/gcc...
This issue was caused by the different ordering implementation for
std::setiterators. On Windows, the set is ordered by insertion order while on Emscripten/Linux the iterators are sorted by name. In this scenario, theWORLD_MAPentry would load last, which had all connection points.While this meant we had all connection points when loading all other levels, it also meant on the Linux/Emscripten build all other levels would be loaded first, and this means no connection points were updated correctly.
Deffering the connection point reading code until after all levels were loaded was the correct solution here.