Priority and other fancy signaling without "programmimg"

Got an idea for OpenTTD? Post it here!

Moderator: OpenTTD Developers

Eddi
Tycoon
Tycoon
Posts: 8289
Joined: 17 Jan 2007 00:14

Re: Priority and other fancy signaling without "programmimg"

Post by Eddi »

adf88 wrote:Nice points but you don't refer the main topic much. So what's your opinion?

To all of you, PLEASE, DON'T GO OFF-TOPIC. I remembering you this topic is about PREPROGRAMMED signals (like instead of programmable signals), and it's not about restrictive signals.

Litany, again.... :evil:
i do think this is exactly the topic that should be discussed.

my opinion on this matter is that the approach is backwards.

first you implement fully flexible programmable/restricted/whatever sigals
then you discuss offering "presets" that the user can choose (or leave out, or modify for his needs).
2457
Engineer
Engineer
Posts: 126
Joined: 06 Dec 2009 21:57

Re: Priority and other fancy signaling without "programmimg"

Post by 2457 »

i like programmable signals, but they are hard to use for many players.
there was a more or less claim against them, imagine a complex array of programmable signals, then accidently remove a key signal. result may be havoc, hard to trace the problem, hard to see what should had that signal be doing.
I do not mind them, but there are others, not just me.


that is why pre-programmed signals would be preferd.



At the moment many situations can be handled with the pre and pbs signals.
but, additional pre-programmed signals needs to be figured out, untill every "hard wired" (@ building tracks only to "emulate" a kind of signal behaviour needed) can be elliminated.
The Prophet -thx Pikka-
michael blunck
Tycoon
Tycoon
Posts: 5954
Joined: 27 Apr 2005 07:09
Contact:

Re: Priority and other fancy signaling without "programmimg"

Post by michael blunck »

2457 wrote: i like programmable signals, but they are hard to use for many players.
You´re talking about hat abandoned ProgSigs Patch?

regards
Michael
Image
kutagh
Engineer
Engineer
Posts: 17
Joined: 30 Aug 2013 09:01

Re: Priority and other fancy signaling without "programmimg"

Post by kutagh »

2457 wrote:i like programmable signals, but they are hard to use for many players.
there was a more or less claim against them, imagine a complex array of programmable signals, then accidently remove a key signal. result may be havoc, hard to trace the problem, hard to see what should had that signal be doing.
I do not mind them, but there are others, not just me.


that is why pre-programmed signals would be preferd.
And you cannot achieve the same problem with an extensive set of pre(-programmed) signals used? The main difference is that those pre(-programmed) signals show visually what their function is, removing one step per signal when debugging. You still have the same issue though, regardless of whether they're pre-programmed or the current pre-signals or only fully programmable signals doing magic with time: You still need to interpret the function of the one signal in a network of many signals.
User avatar
WWTBAM
Moderator
Moderator
Posts: 3689
Joined: 02 Apr 2005 07:01
Location: Sydney NSW Antipodea
Contact:

Re: Priority and other fancy signaling without "programmimg"

Post by WWTBAM »

Eddi wrote:
adf88 wrote:Nice points but you don't refer the main topic much. So what's your opinion?

To all of you, PLEASE, DON'T GO OFF-TOPIC. I remembering you this topic is about PREPROGRAMMED signals (like instead of programmable signals), and it's not about restrictive signals.

Litany, again.... :evil:
i do think this is exactly the topic that should be discussed.

my opinion on this matter is that the approach is backwards.

first you implement fully flexible programmable/restricted/whatever sigals
then you discuss offering "presets" that the user can choose (or leave out, or modify for his needs).
I agree. I also don't think adding new signal types at the build signal toolbar for common situations is the right way either. I would go for a setup like TTDPatch's with a preset button on the programming window.
Formerly known as r0b0t_b0y2003, robotboy, roboboy and beclawat. The best place to get the most recent nightly builds of TTDPatch is: http://roboboy.users.tt-forums.net/TTDPatch/nightlies/
michael blunck
Tycoon
Tycoon
Posts: 5954
Joined: 27 Apr 2005 07:09
Contact:

Re: Priority and other fancy signaling without "programmimg"

Post by michael blunck »

roboboy wrote: I would go for a setup like TTDPatch's with a preset button on the programming window
Somehow I get the feeling that mentioning "TTDPatch" too much would be counter-productive in getting implemented anything valuable in trunk ... :p

Apropos: Eddi also mentioned that interesting idea of "guiding signals" back in that thread pointed out above.

regards
Michael
Image
2457
Engineer
Engineer
Posts: 126
Joined: 06 Dec 2009 21:57

Re: Priority and other fancy signaling without "programmimg"

Post by 2457 »

every signal currently in ue in ottd IS pre-programmed.
and they do indeed solve many issues.

but there are situations where the current set of pre-programmed signals do not yield a solution,
those are the situations demanding signals with different programming.



a good example is the problem of priority tracks.
sure, it can be built with the PBS and pre-signal methood, but if the priority needs to be longer, than it ends up in hackish track construction.


but this would require a clever signal, something similar to pre-signals.
most probably the "exit" eqvivalent would not affect trains, placed only for detection.
the "entry" eqvivalent would be red if there is a train detected by the "exit" eqvivalent.
The Prophet -thx Pikka-
Alberth
OpenTTD Developer
OpenTTD Developer
Posts: 4766
Joined: 09 Sep 2007 05:03
Location: home

Re: Priority and other fancy signaling without "programmimg"

Post by Alberth »

michael blunck wrote:Somehow I get the feeling that mentioning "TTDPatch" too much would be counter-productive in getting implemented anything valuable in trunk ... :p
<rant>It's not just counter-productive, it's off-topic and disruptive to the discussion. You push the stuff in our face at every opportunity, and leave no room for discussion at all. It works for you, ergo it should be implemented in this way, and only this way. People that do not understand it, are too stupid to have a need for it. Any movement away from it is immediately killed by claiming it's a kludge, useless, and what not.</rant>


We know about programmable/restrictive signalling. We know about TTDPatch. It's documented what it does. Patches are floating around for OpenTTD. It's known, it can be done.

As I argued before, the main problem is user interface. Only a few users know bits and logical binary operators. The general audience cannot handle windows with an AND or XOR button.
Yet these people also have more advanced signaling needs. They want priority for some lines. They want unified speed at some track.
The question is thus how to make such features more readily available for a larger audience, (very much) preferable in a visual way, so you can see with screen shots what is happening.

Obviously, this is not about newbies that don't understand the basic block signal or the path signal. I am talking about the very big group of people that understand the signals, but don't have bits, bytes, and binary logic operators for breakfast.

I don't buy it that these signaling options should be available for the elite few. I believe many of these less elite users would already be very happy if you make a few of these options available in a way that's usable for them.
User avatar
Dave
Moderator
Moderator
Posts: 17249
Joined: 26 Dec 2005 20:19
Location: North London

Re: Priority and other fancy signaling without "programmimg"

Post by Dave »

Why the requirement for a full logic system? Why not just a list of conditions that you can set? An advanced setting would allow other operators.

Maybe a solution would be the ability to add a mixed signal-waypoint that you could select as a route for a train.

The complexity argument is a bit weird because you have implemented timetables - how well used is that feature? I've been playing for years and despite a strong understanding of timetabling in the real world it completely goes over my head. So I just don't use it.

Please don't think I'm being deliberately obtuse - i know the general answer is 'well go ahead and code it then' - but I'm just saying what I see!
Official TT-Dave Fan Club

Dave's Screenshot Thread! - Albion: A fictional Britain
Flickr


Why be a song when you can be a symphony? r is a...
Alberth
OpenTTD Developer
OpenTTD Developer
Posts: 4766
Joined: 09 Sep 2007 05:03
Location: home

Re: Priority and other fancy signaling without "programmimg"

Post by Alberth »

Dave wrote:Why the requirement for a full logic system? Why not just a list of conditions that you can set? An advanced setting would allow other operators.
Technically, signals are just logic operations, as proven by the fact that you can make an logic circuit for adding two numbers in OpenTTD.
From an implementation point of view, using logic to express the operation of signals is the only useful solution.

In my view, that does not mean a user should have to think in such operations. He just wants a number of building blocks with a function. How it works internally is not of interest.

Obviously, that means he won't get the full set of possibilities that exist if you switch to logic, but those users don't ever see that, since they don't understand logic in the first place; it's a bridge too far for them.
(Much like many users can install a compiler, and compile OpenTTD with a patch. If they would use programming, they could do much more, but they mostly have no desire to do that at all.)
Dave wrote:Maybe a solution would be the ability to add a mixed signal-waypoint that you could select as a route for a train.
Perhaps. I think a LOT of players would be very happy if they can code priority in the way shown by adf88. There are probably other desires too. We have to start thinking in ready-to-use building blocks that work out-of-the-box immediately after placement, instead of having to program them first.
Dave wrote:The complexity argument is a bit weird because you have implemented timetables - how well used is that feature? I've been playing for years and despite a strong understanding of timetabling in the real world it completely goes over my head. So I just don't use it.
It happened before I became dev. Like you, I totally fail to understand how to use them in my games. I think it's another fine example where the implementation drove the user interface, instead of the user needs.
Let's not make the same mistake here.
User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13235
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Re: Priority and other fancy signaling without "programmimg"

Post by Hyronymus »

Can you guys not make another mistake again too and stop accusing one another of TTDPatch vs. OpenTTD fanboyism? As if that ever helped to develop a solution...

Regardless of the "camp" you belong too, the desire is the same: one set of signals that allows rookie and advanced players to create realistic signal systems. I personally cba if that is based on TTDPatch or on (incomplete) OpenTTD patches, I just want them to become available.

In the mean time I can do with a clearer definition of what makes programmable signals programmable.
User avatar
planetmaker
OpenTTD Developer
OpenTTD Developer
Posts: 9432
Joined: 07 Nov 2007 22:44
Location: Sol d

Re: Priority and other fancy signaling without "programmimg"

Post by planetmaker »

Now that more than enough people had rants, more or mostly less less on-topic and less constructive, please continue the discussion *on-topic*. And that means discussing how to *make accessible* advanced signaling. All this 'do like here or do like there' is not to the point, as there's nowhere so far a decent user interface - the only thing which (nearly?) every suggestion so far lacked to address.

Back seat moderation is also not helpful ;-)
User avatar
WWTBAM
Moderator
Moderator
Posts: 3689
Joined: 02 Apr 2005 07:01
Location: Sydney NSW Antipodea
Contact:

Re: Priority and other fancy signaling without "programmimg"

Post by WWTBAM »

My main opposition to the proposed implementation is the cluttering of the signal GUI with types that don't need to be in the main signal GUI. What I would like to see is one signal type for Program(able|ed) signals. It should then somehow have a beginner/advanced toggle for going between a list of preprogrammed solutions or a TTDPatch STYLE window where a custom solution can be written.
Formerly known as r0b0t_b0y2003, robotboy, roboboy and beclawat. The best place to get the most recent nightly builds of TTDPatch is: http://roboboy.users.tt-forums.net/TTDPatch/nightlies/
User avatar
Expresso
Tycoon
Tycoon
Posts: 1760
Joined: 09 Aug 2004 00:14
Location: Gouda, the Netherlands

Re: Priority and other fancy signaling without "programmimg"

Post by Expresso »

Why not simplify it by simply placing a signal and then ctrl-clicking on it to open up the window to give it a program/restriction? An advanced setting could be created to give the user the simple or the complicated interface.

Signals which are programmed or have restrictions could then have an icon right next to them showing that they have a script, and of what type it is, next to them.
2457
Engineer
Engineer
Posts: 126
Joined: 06 Dec 2009 21:57

Re: Priority and other fancy signaling without "programmimg"

Post by 2457 »

that has been done allready.
not bad, actualy verry good.
I use that patch, but most probably only a few people are intrested only in that solution.

http://www.tt-forums.net/viewtopic.php?f=33&t=68436
[img]
http://www.tt-forums.net/download/file.php?id=173412[/img]

[youtube]http://www.youtube.com/watch?feature=pl ... k7MwKqYyxc[/youtube]
The Prophet -thx Pikka-
User avatar
Tafidis
Traffic Manager
Traffic Manager
Posts: 157
Joined: 19 Oct 2010 19:49

Re: Priority and other fancy signaling without "programmimg"

Post by Tafidis »

Having read the whole thread, I would like to add the following:

a) Restrictive signaling (allow/disallow a train to pass based on train properties:

Can be done perfectly using waypoints+conditional orders. Of course the problem is that these waypoints need to be in the orders and if they are deleted/moved it is a mess. So I propose to add a new signal for these. Bearing in mind that the signal GUI is cluttered, I propose to name this (these) not signals, but "gates" or "restrictions". They would be in a new menu which would be selected by holding down the mouse button after clicking on the signal icon (same as when selecting railtype). The GUI is basically like conditional orders, with selectable train properties, such as speed, cargo type (s), load percentage, etc.
Depending on the actual condition(s) this would place a sign, similar to those in the mockup further up the thread. E.g. a specific graphic for speed limits, another for cargo restriction, etc. Maybe one "combination sign" if several restrictions apply. Or only allow one restriction type per sign, so several signs can be placed one after the other. Space is not an issue here, because a sign can be placed anywhere on a track section, in order to make the pathfinder find an alternative route for a train that is not allowed there (similar to waypoints).

So, no red/green lights (easily confusable with signals) but signs, like read circle, or blue square (don't have to be realistic either). By looking at the map, one can see that there is a sign there that allows or forbids some trains based on some condition. You can see the condition(s) details by clicking on the sign, and you can remove any restrictions by deleting the sign.

One problem, is that when you use this mechanism to assign platforms, these signs have to be on a tile of their own, thus having same problem as waypoints for that (taking up space). I am assuming they need a tile of their own (cannot coexist with signals) because of map array storage rather than graphic issues, pls correct me.

b) Programmable signals:

As others mentioned, I see two essential functionalities: Priorities and flip-flops. Implementing programmable signals only for these seems like overkill. I agree people shouldn't have to learn Boolean Algebra to play the game (explicitly, as all humans know it implicitly). Nor should there be features for science major people to use, because other players may feel excluded and leave the game.
For priorities, I propose to use a special signal (like a 'look-ahead' as has been proposed). It works like a normal path signal, but reserves up to n more blocks (user can define n, perhaps it is visible on the map on top of the sign) In addition, one can implement mulit-aspect, depending on how many look-ahead reservations where successful. There is no simpler way to implement priorites, IMHO

For flip/flops we could have another special signal which looks like a Y or Ψ (for three-way or more) and works as a presignal, turning all signals on the branches (implictly) into exit signals. It then causes olny one of these to be on at any time. Either sends a train to each branch sequentially, or is timer based. The graphic is slightly different in each case. For example, the time-based could have a light flip-flopping on the Y, indicating the curretly active branch. The "loop" version would be the same, but the light would not change unless a train goes through.

I see also a problem here. Assuming the train has to travel through one of these signals, but only one of the branches leads to its destination. How can the train override such a signal?
Citizens Celebrate! First train arrives in <insert your favourite town/station name here>!
User avatar
adf88
Chief Executive
Chief Executive
Posts: 644
Joined: 14 Jan 2008 15:51
Location: PL

Re: Priority and other fancy signaling without "programmimg"

Post by adf88 »

Tafidis wrote:For priorities, I propose ... reserves up to n more blocks
I tried Long Reserve PBS signal and I must say that efficiency doesn't please me personally:
  • Two prioritized trains can't compete each other - the path is already reserved, long before they reach common junction.
  • If reservation fails for a high priority train (junction already occupied) the train won't get high priority. If other, low-priority train will reach the junction earlier - it will win.
I image a person who classifies these as bugs. They can be easily fixed (if at all).
:] don't worry, be happy and checkout my patches
CapnPipsqueak
Engineer
Engineer
Posts: 5
Joined: 18 Nov 2013 01:09

Re: Priority and other fancy signaling without "programmimg"

Post by CapnPipsqueak »

adf88 wrote:Mockup:priority_signs.png
This could actually work rather well.

You could add the priority to existing combination signals or path signals.

Code: Select all

Combination Priority Signal:

Train reaches a prioitized entry signal.
Train adopts the priority (Low, Medium or High)
A number of checks follow:
Is there a train inside the block?
 -- If true, wait until this is false
Is there a green exit (or combo) signal in the block I want to enter?
 -- If false, wait until this is true
Is there a higher priority train waiting at an entry signal?
 -- If true, wait until this is false
Then use the default behaviour for multiple trains waiting at signals, for waiting identical priority trains
The same basic checks apply to path based signals. Before a path is reserved the signal checks if higher-priority trains are trying to resevre a path, then it goes back to default behaviour.

Now to take the above pic and add some trains to it.
There is already a train in the block, and a high-priority waiting on the north mainline.

A low-priority train reaches the entry signal. It sees there is already a train within the block, so it waits (default block signal behaviour)
The train clears the block through the south exit.
Both the high-priority signal and the low-priority signal see a valid exit.
The high priority signal has a train waiting, so it goes through the checks first. The low-priority signal waits.
The high priority sees nothing else waiting, so it enters the black and heads for the green exit.
Finally, the low priority train goesthrouh the block when it sees a green exit.

There is one way this can backfire. If high-priority trains keep arriving before the low-priority train can get through, it may never get to leave, causing a massive backlog on that line.

A solution to this is adding an extra check: How many higher-priority trains have gone through the block?
A parameter to the options menu could control this. Say you set it to 5. This means that when 5 higher priority trains have gone before the waiting train (counted from when the low priority train starts waiting) the low priority train gets to 'queuejump', increasing it's priority by one (low>med>high). Once it reaches equal priority than the other waiting trains the signals go to the default behaviour, which is 'first-come-first-served'.

So, changing our example, the low-priority train can't go because high-priority trains keep arriving. It waits until5 trains have passed, the increases it's priority to medium. It still can't go because the priority for the other lines is 'high', so it waits for another 5 trains to go past before increasing it's priority again.
Now, because all three lines are (temporarily) the same priority, the signals revert to default behaviour. The sideline train has been waiting for the longest time, so it now gets to enter the block.
Note that the priority only changes for one train, any subsequent low-priority trains arriving at the same signal will still have to wait.
Mister_X
Engineer
Engineer
Posts: 54
Joined: 27 Apr 2005 18:40
Location: The Netherlands

Re: Priority and other fancy signaling without "programmimg"

Post by Mister_X »

I like the idea for better "advanced" signals without programming or complex constructions which is consuming a lot of time.

I'll do some suggestions for signals also:
  • An "exit"-signal which will be green when the complete train could pass the signal. (For usage after switches to prevent blocking other trains.)
  • When two railway tracks will lead to the same station, the signals at the beginning the railway tracks should have a small train-counter internally. The two signals could devide the trains proportionally over the two railway tracks and prevents a traffic jam at one railway track while the other one is free.
  • When multiple trains are waiting for a junction, the light trains with more power should have a priority to heavy trains with less power automatically.
  • In the future, the trains should have a normal braking distance instead of one tile which is used in the current versions.
I won't go off-topic, but it's all related to signals. :)

But we need to remember that new players which are learning to play OpenTTD should use and understand the different signals easily.
Eddi
Tycoon
Tycoon
Posts: 8289
Joined: 17 Jan 2007 00:14

Re: Priority and other fancy signaling without "programmimg"

Post by Eddi »

Mister_X wrote:
    that's exactly my point. your wishes are so niche and specific that no amount of "unprogrammable advanced signals" will ever cover them properly.

    that's why there should be programmable signals once and for all.
    Post Reply

    Return to “OpenTTD Suggestions”

    Who is online

    Users browsing this forum: No registered users and 6 guests