I did not want to interrupt the flow of the bus, so I built a traffic light and set "phases time" like this picture.
(https://simutrans-germany.com/files/upload/trafficlight_setting_window1.png)
However, rotating the map by 90(270) degrees, this brings a opposite effect!
When rotating the map by 90 degrees, the values of "North-South" and "East-West" are automatically switched like the following picture.
(https://simutrans-germany.com/files/upload/trafficlight_setting_rotate.gif)
However, signal behavior does not rotate.
This is an in-game picture that I made for explanation. The paved road is the heavy traffic route, and is made to flow almost without signal restriction. Dirt branch roads... I don't care. :p
(https://simutrans-germany.com/files/upload/flow_well.png)
However, rotating the map by 90(270) degrees, then traffic paralysis is caused immediately :'(
(https://simutrans-germany.com/files/upload/bunch_of_waiting_clearance.png)
This occurs on both Simutrans and Simutrans-Extended.
I tested on:
Simutrans r8387(windows) + pak.nippon v0.3
Simutrans r8424(windows) + pak.nippon v0.3
Simutrans-Extended-64 + pak128.britain
This has been broken (in the current manner) since 2011, when Prissi added code to swap ticks_os and ticks_nw on rotation. The trouble is that rotation was also explicitly checked for, so this effectively undoes the rotation.
I've pushed a fix for this issue in Extended to Github, and attached the diff. I imagine the same fix will apply to Standard, though I haven't checked. The fix also updates the offset on rotation, and to prevent overflow in this value it limits ticks_ns+ticks_ow to at most 256. (I imagine overflow could still occur on existing savegames, but at least we don't break anything new.)
@ACarlotti: I do not understand, why you did the changes to set_ticks_ow and _ns in roadsign.h
To maintain traffic light behaviour when rotating the map, it is necessary to adjust the offset. Since this is stored in a single byte, this could overflow if ticks_ns+ticks_ow>256 (offset needs to be able to take all values between 0 and (ticks_ns+ticks_ow-1) inclusive). I reckoned that an easy way of demonstrating this restriction without having to directly modify the number inputs would be to enforce ticks_ns+ticks_ow<=256 by decreasing on whenever the other would otherwise be increased too far. This (in my opinion) makes the behaviour more discoverable than attempting to increase a value too far had no effect. (Of course, being explicit about the limitation in the gui might be better; however, note that the gui doesn't even specify what the three numbers are at present.)
I do however feel that more robust design (from a ui perspective) would be to use a different set of three variables - namely the cycle length, and the points in the cycle at which the lights should switch to each phase (these last two numbers would need to be non-equal). This has two benefits that I see over the current approach - firstly, it becomes possible to tweak the balance of the two phases without temporarily changing the overall cycle length, and secondly, rotating the map involves simply swapping the two times for the phase change, rather than having to add a load of nonzero offsets in where they might previously have all been zero. This could be fairly easily coded, and could if desired remain (mostly) compatible with existing saves by continuing to use the current data in the backend and just modifying the frontend.
This issue does not appear to have been fixed yet.
Will not ACarlotti's patch be incorporated? (´・ω・｀)
Incorporated in r8603, thank you very much.