Programmable signals

[Gastje33]

I had an idea to make signal that can be programmed to listen to one or more events. With that we can make really complex track lay-outs and we don't need those unused tracks to 'connect' signals any more.

There are too many sorts of signals: normal, pre, exit, combo, PBS, NAND. It will be comfortable if those are combined in one signal. So that we have just normal signals and programmable ones.

I had in mind to make an extra button on the rail toolbar and an extra GUI for the button, so you can program the signal.

Unfortunatly my C is not very good. I messed around a bit today, but if I want to program this feature I would be busy for years! So can someone help me a bit?

[Invisble]

I admit I like the idea of prgramable signals, but I am wondering if you were thinking of just a single light design for all signals (i.e green & red) which would get confusing, or if you were thinking of being able to give each light a differant colour code (i.e red & green for normal, double red & green for NAND, Red & green with something for entrance/exit/combo pre-sigs and red & yellow for PBS).

If this were to happen, I would not be programming it as your skills probably outstrip mine by some distance (you can write my knowlage on the head of a pin), but I am asking questions that others would ask.

[Bjarni]

Such a change is really hard to do. Not only will we need more memory for each signal (off map memory most likely), we also need some sort of scripting language to tell how each signal should behave, like say it should be green if a certain signal is green and there is a clear path to that signal.. It's simple to say in human words, but we would need to tell which signal and some way to store which signal and it should be possible to say either one of two certain signals.
Also it would mean a change to the user interface as the player should be able to tell how it's programmed.

All in all, it's pretty hard to do (if not impossible) if we want the game to work at a decent speed and not too complex ways to set up signals. The game should be playable by non-experts as well.

[michael blunck]

Something like this is possible in TTDPatch.

I.e., currently implemented variables to base decision on are:

- number of train carriages
- maximum speed
- station of current order
- station of next order
- last visited station
- depot of current order
- depot of next order
- total train power
- total train weight
- train cargo
- number of tiles from signal
- signal status: SW, SE, NW, NE

regards
Michael

[Gastje33]

Something like this is possible in TTDPatch.

I.e., currently implemented variables to base decision on are:

- number of train carriages
- maximum speed
- station of current order
- station of next order
- last visited station
- depot of current order
- depot of next order
- total train power
- total train weight
- train cargo
- number of tiles from signal
- signal status: SW, SE, NW, NE

regards
Michael

That will be even better if it is implented in OpenTTD. I think it's also easier to program something like that.

[Bjarni]

Something like this is possible in TTDPatch

Looks interesting. I just did a quick search, but I failed to see how this is stored. Maybe it's not of such a great interest after all. We can always think of something. if/when we do this in OpenTTD, we will have to think of a fast way to access this info or it will really hurt performance on large maps.

Also nobody said that we should copy all ideas from the patch. We could actually think of something on our own

[DaleStan]

I just did a quick search, but I failed to see how this is stored.

Ask JGR, and/or check his changes.

[KUDr]

It sounds to me as good idea. I can imagine easily that new-signals (when they get implemented) would support some kind of script where player can write/specify the event handler for "incoming train" event, so the pathfinder and/or train controller can use the result returned by this handler to decide which way to go and/or whether to stop the train or not.

There are several options:

1) Technically it is not a problem to embed some light scripting engine into ottd. I already tried LUA script, that is very simple and light and works fine inside the game.
- But i can't imagine the regular user programing pascal-like script. This feature would be useful only to programmers that could then build very sophisticated rail networks.
- And it would be probably way too slow. Who knows.
- I was going to use this in the prototyping phase of new-signals development. So it can easily stay there as an option for advanced users running ottd on very powerful machines.
- I personally think that much better use of such scripting engine would be for example new AI. If someone understands asynchronous AI scripts of some RTS game, can and wants write such scripts for ottd and, has at least basic understanding of cooperative multi-threading, tell me and we can try to build team, that will work on new AI(s). I can support the team by supporting the embedded LUA script engine.

2) The way described by michael blunck (ttdp) sounds much more realistic. Easy for every user to select/define condition(s) for red/green/yellow state or so. I like that idea. What makes me bit scared is that the regular user will compose complicated boolean expressions that sometimes will be wrong and then he will come and complain, that it doesn't work at all. What makes me much more scared is that there will be at least one of them that will not be able to understand the feature at all, but will use it heavily. And because the human stupidity exceeds all possible limits, i don't want to be author or co-author of such publicly available feature. It would make me busy for all the rest of my life supporting such users. Use of such feature would be much more complex than for example using YAPF. And i can tell i am sometimes really angry about one user who thinks he understands how pathfinder(s) work / should work, but he doesn't.

3) is there some other way how to do it?

[skidd13]

I think the signals should kept simple as possible.

• The case of next/previous station could be solved with waypoints (thats why they exist! Or not?).
• The speed case could be solved with "speed signals" (I remember there was a patch). Maybe expand it with acceleration.

[WWTBAM]

I think the signals should kept simple as possible.

• The case of next/previous station could be solved with waypoints (thats why they exist! Or not?).
• The speed case could be solved with "speed signals" (I remember there was a patch). Maybe expand it with acceleration.

i would rather give one or two signals a restriction than multiple trains orders, especially if they dont all share the same route. And the speed signal patch was fixed as a global setting, so if you had two trains getting stuck behind each other in the same group, you couldnt change the speed restriction easily as it would affect the entire network. And these programable things wouldnt be in the main gui, they would be a sub gui that you dont need to open.

[Alski]

First up, I just want to appologise for making a dupelicate thread on this idea, I thought of my own version of it and never even saw this thread, so I’ll copy and paste the gist of my idea here, which was… basically using BASIC programming like statements such as IF, ELSE, ie:

IF signal #1 is Red, then make signal #2 Red
IF a train is waiting at signal #1, then make signal #2 red
IF a train is inside junction #1 then make signal #2 green, else signal #2 = Red
IF X number of trains are waiting to exit a station, make signal #’s 1,2,3,4,5 Red

(a junction in this case possibly being defined as either a section of track “closed” by a definable group of signals, Or a number of tiles of track that are set as “switch tiles” )

the purpose of all this being to enable us to have more control over redundant lines, controlling traffic levels, making sure secondary exits from stations remain clear when a train is waiting to exit, giving priority to certain lines, etc etc

[Zuu]

I could see that if creating and store junctions for future use is implemented this thing with programmable signals can add some more thrills for junction designers.

That is, if a junction-designer (as RCT2s RC-designer) would be created GUI/Editor for programmable signals could be made available only there, but not in the main game.

Then again the question is how much OpenTTD wants to focus on junction building, compared to other aspects of transportation and logistics.


Edit: Why is this thread not in sugestions-forum?

[richk67]

I havent done any work on it in quite a while, but this sounds similar to my Speed Signals work (which could have been extended easily to use any of the *v vehicle info).

To make the signals/signs simple, I was thinking of a scheme like this:

In a train's route info, choose a route colour for the train. You could have blue for freight, green for express passengers, white for local passengers, etc.

Then, the placed signal would just be one of the colours. In the pathfinder, it would give a positive weight to routes with the same colour as the train, a negative weight to routes different to the train's colour, and no weighting to a non-signed route. So trains should follow their colour-route, unless there is a significantly better other route.

This would go a long way to adding the fun of routing, without the nightmare of hard-to-debug/learn boolean logic. Keeping it simple is part of the ethos that makes OpenTTD != TTDPatch. I like it that way.

[Tekky]

I have the following idea, which would implement most of Alski's suggestions and do many other cool things:

A programmable signal should have the option of incrementing or decrementing a global integer variable, whenever a train passes this signal. The names of these global integer variables are defined by the user himself. For example, the user could use one such variable to keep track of the number of trains in a certain area, such as a junction, and give the variable the name 'MyJunction7'. He should be able to program the entry signals of the junction to increment the variable 'MyJunction7', whenever a train passes it. The exit signals are set in a similar fashion, but they decrement the variable instead of incrementing it. That way, the variable 'MyJunction7' will always contain the number of trains in the corresponding junction. Signals can then be programmed to always show red when a specific condition is met, for example all entry signals can be set to show red when MyJunction7 is greater than or equal 3. That way, only 3 trains will be allowed inside the junction at any one time. This would remove the problem of traffic jams in roundabout junctions. This methods can also be used for other purposes of load balancing inside the track network.

In the above example, one could also set most entry signals to only allow a very small number of trains into the junction, but set certain entry signals of the junction to allow a higher number of trains. Using this method, priority lines can be implemented when passing through roundabouts and possibly other types of junctions, too.

Also, with large junctions, one could use several variables, one for the whole junction and 4 for the indiviual parts of the junction, to prevent the individual parts of the junction from getting jammed.

My suggestion also puts only very little additional load on the CPU. Whenever a train passes a programmable signal, the game must increment/decrement all variables attached to the signal. Then, the game must update all signals which are dependant on these variables. If the game maintains a list of all signals that are dependant on a certain variable, this should cost very little performance.

I think my suggestion is a good compromise between flexibility and ease of use. In particular, my suggestion does not require any scripting language. It requires only a user interface in which the user can apply a few settings to the signal, for example which variables should be incremented/decremented when a train passes the signal and when the signal should display red, i.e. MyJunction7 >= 3.

Of course, the user will require the possiblity to manually change the variables, when the variable for some reason no longer contains the intended value. The user must also always be able to view the values of all variables, for debugging purposes. This can all be accomplished by an additional window. Maybe the console window could also be used for this.

[Dissy]

My idea would be, to create groupes of signals. Thus signals are no more connected via rails only but by another value, the group.

[Brianetta]

I think that Rich has hit upon a pure gold idea here. A coloured route is easy to understand, easy to code (just plain old penalties) and uncomplicated. The standard eight colours within the game would do fine - there's no logical reason why two routes which don't ever meet shouldn't share a colour.

It could even be optionally tied to the company colours. Route colour could be assigned as the primary or secondary colour, given a couple of tick boxes. Then you'd be able to watch the red trains on their route, and the blue ones on theirs, and easily spot the interloping green train that's clearly a bit lost...

[NukeBuster]

The only downside would be, that you would still not be able to make logical descisions.

[jungle]

I think that Rich has hit upon a pure gold idea here. A coloured route is easy to understand, easy to code (just plain old penalties) and uncomplicated. The standard eight colours within the game would do fine - there's no logical reason why two routes which don't ever meet shouldn't share a colour.

I agree it's a good plan - although I could still imagine some players running out of colours for their ultra-complex layouts.

Whatever, I don't think making it so the player has to write program-style script is a good idea - it might be very flexible but it could also be very off-putting and confusing to new players, and difficult to program because of all the possibilities of players setting up impossible conflicting instructions. If at all possible it should be done graphically (point and click).

A back-of-the-envelope idea for doing conditional signals could be like this: have it so that if you right-click (or shift-click) on any signal you get a small window coming up with 'NOT', 'AND' and 'OR' buttons, and perhaps 'NAND' and 'NOR' too, if the junction design junkies can think of a use for them beyond crashing the game by giving signals contradictory instructions

To program a signal, you would bring up this window, click one of the buttons, and then click on the other signal(s) on the screen you wanted that signal to be dependent on. Once you had done this, these links would show up on the main display - whenever any signal window was displayed - as coloured lines between the signals (say red for 'NOT', green for 'AND', and white for 'OR').

This would be at comprehensible (if not obvious) to non-programmers and yet still reasonably flexible - and would replace the obscure shift-clicking system the game currently has.

Unfortunately I'm not a C programmer so I can't volunteer to help here...

[Mlynki]

I think that control of signals by simple scripts is not much of a problem. It is always possible to create a GUI for those users, which prefer simplicity over control and that GUI can generate script, which can be hand-edited by anyone who wants total control (after hand editing, the simple GUI option could be disabled so that the program doesn't have to reverse-engineer the script).

However, the script should be kept simple if possible. It must be kept in mind that there are hundreds of semaphores around the map and literally programming each one is a lot of work (and time, which sometimes you don't have if you need to manage a large network). Not to mention - programming is error prone and there is no way you can make sure you have no errors, only make sure you HAVE errors (by finding one). In other words, I can imagine that you could produce a subtle error and not be able to find it.

[blaaat]

Hello,

I saw that when i had a route with multiple trains behind each others, and some other train wanted to join, all the trains on the route stopped to let that train go.

I was thinking of let te train decide at every signal, how many cargo stops if i go.. and how many stops when i stop, and then choose the right thing.
But i think this is a bit cpu intensive. So it might be an idea to make pre-triggering of the signals for loaded trains.

ex: a fully loaded train comes, X tiles before #1, this train is loaded and has priority, so all the other signals to #1 show red BEFORE the train is in #1.
if there is already a train in #1, the train just drives until he stops at the signal near #1. And only do this with loaded trains. and give full loaded trains priority over half-loaded trains.

My programming skills are not high enough, so i can't make it myself.