Closed VictorPhilipp closed 5 years ago
Would have to be stored as a n-m mapping from lanes to other lanes, otherwise #31 gets broken permanently.
The Custom*AI classes already query timed traffic light states by lane index (CustomSegmentLights.GetCustomLight(byte laneIndex)). However, the given lane index is then mapped to a set of (extended) vehicle types and the traffic light state is then retrieved.
However, implementing this feature would require a complete rework of the timed traffic light UI (TBH, I would have already redone the TimedTrafficLightsTool and ManualTrafficLightsTool classes if there was a working testing environment, but without debugging tools working on UI is merely a pain in the neck).
Duplicate of #8
Currently traffic lights can only be set for what the game (resp. TMPE) thinks is a separate direction. This limits creation of complex intersections. Consider for example a double-intersection like this, that I want to equip with a group of TTLs:
(ignore for now the fact that two lanes are not connected at all, only the connected lanes are relevant)
In real life the right crossing may have two traffic lights, depending on what direction vehicles want to take at the next one:![lane conn real mock](https://user-images.githubusercontent.com/209929/34341901-b1ed90f6-e9a1-11e7-8ca5-0e0083452139.jpg)
Currently not possible to model this in the game, because at the right crossing, all lanes are considered forward lanes which can only be controlled all at once. So it's not possible to have one TTL step where the real-world "left" direction - and also the two left lanes of the right crossing - show red while the other two pairs show green.
UI suggestion: like the small circles of the lane connector. High quality Paint mockup:
(could show lane connections semi-transparently, or render lane arrows instead, in case a vehicle on the crossing is standing on the road marking)
I understand this is a somewhat bigger change, touches a lot of code (though most of it only in the TTL I think - the code in CustomRoadAI wouldn't change much, and where it does it would get simpler because it would only have to query for its current lane and not for several lights depending on what vehicle type it is). However, it would also remove the three special cases (ICustomSegmentLight.LightLeft/Main/Right) and probably more. So it touches a lot of code because it removes so much code
Additional special case that would be eliminated would be the different traffic lights for special vehicle lanes (it'd be just another lane that can be separately switched, together with per-lane vehicle restrictions that already exist).
It wouldn't be necessary to have different traffic lights per direction on any single lane - a vehicle on a green-lighted lane should be able to leave into any direction no matter what. I think in real life this wouldn't work anyway (imagine a lane has a green light, two vehicles pass, the third one suddenly stops at the green, because it wants to go left not straight and gets rear-ended by the other 100 straight vehicles behind it) / Or rather, there's no use in allowing some vehicles to cross using a lane while others don't, because the former are able to block the latter
Regarding user interface in case some user doesn't want to fine-tune all 12 lights of a crossing of two 3+3 roads: toggling one lane of a direction could toggle all lanes of the same direction by default. Or the UI can be switched between current mode and full-lane-control mode, but stores each lane separately in all cases.
https://github.com/VictorPhilipp/Cities-Skylines-Traffic-Manager-President-Edition/issues/90