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

Jump to bottom

different behavior on ctrl-drag/drag'n'drop signals #4378

Closed
DorpsGek opened this issue Jan 4, 2011 · 4 comments
Closed

different behavior on ctrl-drag/drag'n'drop signals #4378

DorpsGek opened this issue Jan 4, 2011 · 4 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 Jan 4, 2011

djnekkid opened the ticket and wrote:

If I ctrl-drag or drag'n'drop signals along a piece of track the behavor is different with block signals and path signals.

With 'normal' block signals does it give 'normal' block signals, as it should
This part is ok, however
With pre/exit/combo signals does it give 'normal' block signals, and not the kind that is dragged, because with path signals (both kinds) does it give a path signal.

What behavor that is correct or not am I not sure of, but it is rather inconsistent.

Reported version: 1.1.0-beta2
Operating system: Windows

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

DorpsGek commented Jan 4, 2011

Rubidium wrote:

Yes, it's inconsistent... but multiple exist or entrance signals following eachother makes no sense whatsoever, however multiple path signals makes sense. Especially for the kind that can be traversed from the back.

This comment was imported from FlySpray: https://bugs.openttd.org/task/4378#comment9413

@DorpsGek
Copy link
Member Author

DorpsGek commented Jan 4, 2011

djnekkid wrote:

But multiple combo singnals quite make sense (when building a "prio" for example) :) But multiple one-way path signals dont really make sense, atleast when its claimed (perhaps you can confirm that?) that PBS' signals use more CPU-power then normal ones

This comment was imported from FlySpray: https://bugs.openttd.org/task/4378#comment9414

@DorpsGek
Copy link
Member Author

DorpsGek commented Jan 5, 2011

michi_cc wrote:

People claim many things independent of truthfulness. While it is probably possible
to construct situations where either path signals or block signals need more power,
path signals do not need more power in the general case.

This comment was imported from FlySpray: https://bugs.openttd.org/task/4378#comment9415

@DorpsGek
Copy link
Member Author

planetmaker closed the ticket.

Reason for closing: Implemented

In r21816. Dragging entry and exit signals serves little purpose while continuing with normal ones is the more comfortable solution there. Combo signals can now be dragged (again), even though it may remain somewhat inconsistent, it's more convenient.

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

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

No branches or pull requests
1 participant
@DorpsGek