[Automated Testing] rotating the map breaks the script

[Yona-TYT]

You just have to rotate the map right at the start of the scenario.

[ceeac]

This is "intended" in the sense that the tests are supposed to be run without user interaction - there is just too many variables to consider if the map can be rotated at any time between squirrel calls. There should be tests that rotate the map via script and verify that objects are rotated correctly, but they are still missing.

[Dwachs]

I am trying to work on this. Not so easy. The behavior of many things depends on rotation (road at new townhalls, factory connections are not just rotated but transformed, etc).

Ideally scripts should not need to worry about rotation, and also the tests should on a rotated map.

[neroden]

I have a longstanding plan to eliminate the current bogus system of rotating the world, in favor of making map rotation strictly a "viewport" client-side thing.  (So different clients could view the same map from different rotations in a server game.)  Unfortunately I will not be able to get to this quickly.

[makie]

I have a longstanding plan to eliminate the current bogus system of rotating the world, in favor of making map rotation strictly a "viewport" client-side thing.  (So different clients could view the same map from different rotations in a server game.)  Unfortunately I will not be able to get to this quickly.

oh yes 
This is welcome

[ceeac]

I have a longstanding plan to eliminate the current bogus system of rotating the world, in favor of making map rotation strictly a "viewport" client-side thing.  (So different clients could view the same map from different rotations in a server game.)  Unfortunately I will not be able to get to this quickly.

There is also this thread from ~2 years ago:
https://forum.simutrans.com/index.php/topic,20724.msg194288.html
Since fixing vehicle alignments is a prerequisite for fixing the map rotation, I think the former should be done first.

[neroden]

That certainly should be fixed.  It is not a prerequisite for fixing the map rotation. 

To fix the map rotation, the following was my plan:
(1) the rotated mapping from viewport coordinates to tile coordinates
(2) an added parameter in every display routine for any obj , which says "which rotation to display", so it can grab the correct pre-rendered graphic
(3) for multi-tile objs, some fiddly bits
(4) for vehicles, where multiple may appear in one tile, some fiddly bits to get them to line up.  But the display routines should know which direction they're displaying (there are only 4 choices), and can therefore do the fiddling.

If viewport-based map rotation is implemented before the vehicle offsets are fixed, you'll basically end up with a few pieces of obnoxious code doing math for offsets in the display routines, and occasionally odd-looking movements.  Which is acceptable to me, though not ideal.  Fundamentally I don't mind a few graphical glitches.

I think the last suggestion in that other thread (moving all vehicles half a tile back so they're basically "centered") is probably the way to go.  I also don't think it's a prerequisite, though.  The key thing IMO is getting *an* implementation of a rotated display up and running, which displays tiles and buildings correctly, and displays vehicles in in the right orientation, the right order, and roughly the right location.  This makes rotation viable in a networked game, and eliminates the routine breakage coming from rotation of the world.  I'd rather have a few graphical glitches, which can be addressed later.

[prissi]

The display order and clipping is very dependent on the map rotation as well. Currently the vehicles are sorted and moved so that it works well. So indeed, this would greatly enhance the work of the display routines, i.e. resorting each elements before display and so on.