Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Directional autosignal #2203

Closed
DorpsGek opened this issue Aug 7, 2008 · 9 comments
Closed

Directional autosignal #2203

DorpsGek opened this issue Aug 7, 2008 · 9 comments
Labels
component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

DorpsGek commented Aug 7, 2008

mattventura opened the ticket and wrote:

When a train turns around after being stuck (see #1750), and it does not hit a one-way signal, it influences other trains to also turn around, and can cause a deadlock if the chain reaction of turned-around trains never hits a one-way signal. It is very time consuming to place one-way signals frequently on a mainline spanning a 2048x2048 map with 3 or 4 lanes on each side, allowing for easy deadlocks when trains take a long time to load/unload in a station, or if one of the mainline lanes never must wait for an extended period of time before a train enters the station.

An addition to the signal GUI would be a button to place one-way signals in the direction you are using the auto-signal tool, similar to the one-way road toggle.

The attached save simulates what would happen if the track was a massive mainline and either the station was moving very slowly or one of the mainline lanes had to wait for a long time before going, possibly due to the other lanes being selected to go, or if there were simply so many lanes that all of the lanes move very slowly. The screenshot demonstrates a deadlock created by such a scenario.

The screenshot demonstrates a setup in which the train turned around behind the one-way signal, thus ingoring it. Even if you go through the trouble to place somewhat frequent one-way signals on a mainline, backup-induced jams such as this one can still happen, which is why a more convenient and faster was to place mass amounts of one-way signals is necessary.

Note-this happens to me with both NPF and YAPF. Also, the real version is 0.6.1, because 0.6.2 doesn't appear to be in the Debian repos yet.

Attachments

Reported version: 0.6.2
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/2203
@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 7, 2008

mattventura wrote:

Sorry, the part about the train turning around behind the signal is not in that screenshot. It is possible, though, for a train to turn around at a one-way signal and get stuck behind it, still rendering it useless.


This comment was imported from FlySpray: https://bugs.openttd.org/task/2203#comment4557

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 7, 2008

Yexo wrote:

"An addition to the signal GUI would be a button to place one-way signals in the direction you are using the auto-signal tool, similar to the one-way road toggle."

The autosignal tool can already do this. First place a one-way signal in the correct direction, and then start dragging starting at the tile with the one-way signal. It'll then add one-way signals instead of two-way signals.


This comment was imported from FlySpray: https://bugs.openttd.org/task/2203#comment4558

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 7, 2008

mattventura wrote:

But thats hard to do when you're zoomed out. Like I said, if it's a long mainline, it's very time consuming since you have to zoom in to see them, so you can only do a small section of the track at a time.


This comment was imported from FlySpray: https://bugs.openttd.org/task/2203#comment4561

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 7, 2008

mattventura wrote:

Adding on to my original suggestion, a converter would be nice, like how you can already use the directional drag to convert to one-way signals, but you simply drag over an area (as a grid, like the rail convert tool) and it searches for one-way signals in the selected area, then converts all the other signals in the affected area. This would eliminate the need to do each lane on a wide mainline independently.


This comment was imported from FlySpray: https://bugs.openttd.org/task/2203#comment4564

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 8, 2008

yorick wrote:

You can currently press ctrl with the autosignal tool to signal the whole mainline, drag from an existent signal to get them of a specific type.


This comment was imported from FlySpray: https://bugs.openttd.org/task/2203#comment4568

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 8, 2008

mattventura wrote:

I know you can do that, but on say, a PDA or other touchscreen/stylus based device with limited input capabilities, you can't just start signaling and drag it across the whole mainline, because there is no way to be dragging the autosignal tool while clicking the "zoom out" button. Using the "pan map when cursor is at edge of window" patch not only takes too long, but becomes an annoyance. This feature request is mainly just to make it easier, it is not an important feature, which is why I put it on "low severity". This is more of a convenience than a necessity.

Also, the other problem with the existing tool is that it will turn affected tiles into one-way signals regardless or type, for example, on one of my tracks, I have a compact right-of-way merge from a depot onto the mainline. If I tried to use the existing way of doing it, I might turn the two-way exit signal into a one-way exit signal, which would not work for it.


This comment was imported from FlySpray: https://bugs.openttd.org/task/2203#comment4569

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 9, 2008

yorick wrote:

I just said that when you hold ctrl while dragging, it signals the whole lane for you...


This comment was imported from FlySpray: https://bugs.openttd.org/task/2203#comment4578

@DorpsGek
Copy link
Member Author

mattventura wrote:

The problem is that none of the currently in place systems are perfect.

Putting in signals manually takes more time, but you never mess up, unless you mid-click.

Dragging(without control) on a device without the + and - keys is tedious.

Dragging with control held down can place signals where you don't want then.

My proposed system is not tedious, does not require zooming out, does not require a control key, and will not put signals where you don't want them.

Also, since you can place semaphores with the ctrl key anyway, and they have dedicated signal GUI buttons, why would you oppose a button for directional autosignals?


This comment was imported from FlySpray: https://bugs.openttd.org/task/2203#comment4579

@DorpsGek
Copy link
Member Author

andythenorth closed the ticket.

Reason for closing: Won't implement

Flyspray clean up: more than 5 years old, and not obvious what should be done with this next, so closing. If this offends, discuss with andythenorth in irc. Thanks.


This comment was imported from FlySpray: https://bugs.openttd.org/task/2203

@DorpsGek DorpsGek added component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) enhancement labels Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: interface This is an interface issue flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

1 participant