![]() ![]() What this boils down to is that the positions of transfer offers can be materially misstated. I point out that if just one extra bit was allocated in that field (and there are spare bits there), then the entire map could've been covered by the 38m resolution, with no need for dual modes, removing all problems caused by the lower-resolution mode, and slightly improving performance by removing the conditional checks currently required by the TransferOffer.Position getter and setter. The positions, as well as the flag FLAG_LARGE_POS (to indicate which of the two "resolutions" are encoded) are stored in the m_flags field of the TransferOffer. As TransferOffers can happen anywhere on the map, even without using 81 Tiles, there's a second positional mode that uses a much lower resolution to cover the whole map this has a resolution of 270m. Within the 25-tile area the game records coordinates in squares of approximately 38m per side (aligning with the DistrictGrid). It generally only affects districts outside of the 81 tile area, but will be pseudo-random as to which specific buildings it affects.īasically, the game is using an unusal method of recording TransferOffer positions. ![]() After testing and analysis of the game's code, I can confirm that there's an issue with the way the game records coordinates for TransferOffers, which appears to be causing the issues with pedestrian districts. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |