Want to praise Simutrans?
Your feedback is important for us ;D.

Oneway Twoway Road Patch probrem: Destruction of traffic light function

Started by Ranran, September 26, 2020, 04:55:21 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


There are still a lot of issues with the Oneway Twoway Road Patch, but I make new threads to help track individual issues. But this thread is a newly discovered issue. (´・ω・`)

Click here for the original thread:,18073.0.html

He didn't explain to the forum people about the feature when it was about to be implemented. It can be hard to notice such features without explanation. There are several such things.
As a result, incomplete functions that did not check and functions that did not work were taken in as they were.
I think this is one of them.

Install a traffic light at the road intersection and open the dialog. A strange button has been added at the bottom.
James - Did you check the behavior of this button when incorporating it?
Did all you guys ever know about this feature? Have all you guys ever thought about the possibility of abuse?
Because THleaderH didn't mention this feature in the forum. I think this is very problematic. Because it makes the function of the traffic light completely destructible.
This can be exploited by players to place no-entry signs (for all direction) at intersections. It makes it easier to block public transportation. Traffic lights can be installed anywhere on public roads. In other words, players can easily place no-entry signs at intersections.
And this is not linked to the route search system. You can disconnect the route with a traffic light, but the route search cannot know the disconnection.

Display problem:
(1) I think the GUI is very confusing.
(2) Does not link to the appearance of the traffic light
(3) It's hard to understand what's happening on the game screen
For example, if a traffic light is always blocking intrusions from all directions, it is impossible to judge visually.
Traffic lights are fooling us or cars appear to be ignoring traffic lights.

I guess it would take a lot of effort to get this sane.
Features I think are the minimum required:
Match the appearance of the traffic light with the prohibited operation.
Set certain conditions for button on / off. For example, blocking from all directions is not allowed. Add the conditions for adjacent intersections and their traffic lights.

If it is possible to block in one direction, it should be linked to the route search. But that's the same problem that happened in one way, making it easy to cut roads without alternative roads. That is, it is difficult to link all functions well.

So I recommend removing this feature once.
This feature is not linked to the one way / two way feature. Therefore, I think there is no problem considering it as an individual function.
Certainly there are some issues with controlling consecutive intersections, but this adds to the problem.
And this is an independent feature and I think it's best to go with standard.


This feature is necessary in order to make 2x2 intersections work correctly. without this feature, the intersections may cause deadlocks.

Anyway, I agree with your opinion (2) and (3). However confusing things are from Standard. The traffic light images for an addon are consisted from: east(red and green), west(r/g), south(r/g), north(r/g), east+south, south+west, west+north, north+east. That is why the image is confusing since the combined images are mainly used for intersections. Alternatively, we can use only east/west/south/north images.

And in order to prevent from making traffic lights into no-entry signs, the two check button for the 2 phases in a direction must not be turned off at the same time. Probably this is the easiest solution.


QuoteThis feature is necessary in order to make 2x2 intersections work correctly. without this feature, the intersections may cause deadlocks.
What I mean is that this isn't the right way to do it, and it's causing a lot of bad effects. There is no countermeasure against the adverse effects caused by this. The fact that the traffic lights can block the route is very confusing to the route control code. I think this exacerbates the complexity of the mixture of road one-way attributes and one-way signs.
I think we needed to discuss it before implementing it. However, since it was not explained at all, I think that no check was done.
This feature is not needed at all, at least at non-contiguous intersections, and has only a negative effect.
Therefore, in such a case, it is necessary to set conditions such as not being able to operate this button.

And getting rid of that bad effect doesn't seem easy. (It's theoretically possible, but I think it's very troublesome.) And who handles it? It will be left in an exploitable state until it is fixed. (I think the abuse itself can be solved with Phystam's last idea.)

The operation of consecutive intersections has the logic that the next car cannot enter until the currently invading car has passed the intersection.(I reported it when observing the horse carriage.) I presume it is so to prevent deadlock.

I think it would be better to at least remove this current feature and then consider another method. For example, instead of letting the player control it, prevent the program from causing a deadlock. And I think it is desirable that it has the same specifications as standard. Do the two need to be different in terms of controlling consecutive intersections?
I think that is desirable from the viewpoint of code maintenance.
I don't know how well that intersection behavior works. Does this mean it's broken? Is it no longer possible to improve?

QuoteAnd in order to prevent from making traffic lights into no-entry signs, the two check button for the 2 phases in a direction must not be turned off at the same time. Probably this is the easiest solution.
This is the minimum required. However, the benefits of this feature are still not very visible, as none of the other issues are resolved.
What I'm saying is that it's better to control the flow of adjacent traffic lights programmatically rather than artificially. The cause of abuse is that it can be done artificially. It also makes it difficult to understand.

Also need to correct the direction indication "unknown".


Just memorandum.
The root of this problem has been resolved by standard, so this feature is removed.
It is included in the r8653 GUI-overhaul patch because it required a GUI change.
You need to be aware of extended revision conflicts when incorporating it. (in