ProgSigs - Programmable Signals patch

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Bus
Engineer
Engineer
Posts: 32
Joined: 19 May 2010 15:28

Re: ProgSigs - Programmable Signals patch

Post by Bus »

Could someone kindly link to or post a compiled version with the NAND signals patch? I did notice petert's post on the first page of this thread but the signals seem to be broken in that one.
Bus
Engineer
Engineer
Posts: 32
Joined: 19 May 2010 15:28

Re: ProgSigs - Programmable Signals patch

Post by Bus »

OK so I'm now completely convinced that the NAND signals in the NAND signal patch actually perform a NOR function. Is this the intended behavior? Does anyone have any idea how could I fix this in the source code if I want to have actual NAND signals?

EDIT: Also there's a bug if the NAND signal is bidirectional -- it will count its other direction as one of the exits because of an incorrect if condition.

EDIT2: OK I think I figured it out. If anyone's interested, I might be able to post the patch here.
Last edited by Bus on 27 May 2010 18:20, edited 1 time in total.
Vitus
Traffic Manager
Traffic Manager
Posts: 157
Joined: 11 Mar 2009 15:15

Re: ProgSigs - Programmable Signals patch

Post by Vitus »

That's pretty much possible. It all depends on what you choose to be 1 (true) or 0 (false). However, having red signal as 1 (true) is pretty common (because it goes well with the condition "Is train in the signal block?").
Attachments
nand.png
nand.png (17.08 KiB) Viewed 8781 times
Bus
Engineer
Engineer
Posts: 32
Joined: 19 May 2010 15:28

Re: ProgSigs - Programmable Signals patch

Post by Bus »

Yes, I understand that. But I was following the convention from the original NAND patch thread where various people treated green as 1 and it seemed to work for them. (Or maybe I'm mistaken?)
Vitus
Traffic Manager
Traffic Manager
Posts: 157
Joined: 11 Mar 2009 15:15

Re: ProgSigs - Programmable Signals patch

Post by Vitus »

As I said, it's more common to use red as 1 nowadays. However, having it the other way around (i.e. NAND actually working as NOR in some sense), you still have universal logic gate, which allows you to construct the rest (of logic gates) with it.

See: NAND logic & NOR logic at Wikipedia
Bus
Engineer
Engineer
Posts: 32
Joined: 19 May 2010 15:28

Re: ProgSigs - Programmable Signals patch

Post by Bus »

Thank you for your help Vitus. I haven't really thought about using red = 1 since green seems to be so much more intuitive for logical "true". You're also right about NOR being an universal gate. But NAND is just more convenient for what I'm trying to do.

The current NAND signals simply negate the output of a regular combo signal. So no matter what interpretation we have for the red and green lights, one of the AND, OR logical gates will be complicated to build. If the NAND signal behaved the way I expected, building both AND and OR would require at most two signals (even the multi-input versions).
Estaf
Engineer
Engineer
Posts: 1
Joined: 20 Jun 2010 21:54

Re: ProgSigs - Programmable Signals patch

Post by Estaf »

Has anyone successfuly compiled this with the latest nightly? (like higher than r20000) ?? If so, could u please post binaries for win32? Or diff against newer release might help.

Thanks for help anyway.

EDIT: Ok, i've somehow managed to get binary (r20003) but i'm unable to load my last saves from r20001 :/ (I can load my older saves from 1.0.1 and 1.0.2RC1) Anyone any idea??
Kogut
Tycoon
Tycoon
Posts: 2493
Joined: 26 Aug 2009 06:33
Location: Poland

Re: ProgSigs - Programmable Signals patch

Post by Kogut »

It is likely to happen with pathed savegames.
Correct me If I am wrong - PM me if my English is bad
AIAI - AI for OpenTTD
2300
Engineer
Engineer
Posts: 5
Joined: 28 Jul 2005 23:22

Re: ProgSigs - Programmable Signals patch

Post by 2300 »

Eddi wrote:Or a one way path signal may be set to never be a safe waiting location, if it's in the middle of the junction [people request that fairly often].
This would be pretty useless just like this. If a train would want to reserve a path, the track all the way to the next save waiting location would need to be free, so you could just as well omit the signal in the middle of the junction. What would be needed is that a train can reserve a track to an unsave waiting location only if it can be sure it will be able to proceed further. However, AFAIR someone (Tekky or Michi_cc) said in the YAPP thread that implementing this would require substantial changes in the way pathfinding works.
Eddi
Tycoon
Tycoon
Posts: 8254
Joined: 17 Jan 2007 00:14

Re: ProgSigs - Programmable Signals patch

Post by Eddi »

2300 wrote:you could just as well omit the signal in the middle of the junction.
the point of the signal is to mark the track as one-way, without having a safe waiting location.
xZise
Engineer
Engineer
Posts: 57
Joined: 19 Mar 2009 16:52
Location: Bad Schwartau

Re: ProgSigs - Programmable Signals patch

Post by xZise »

Owen wrote:
Cadde wrote:[...]
  1. Learn to build rails, build one rail for every train. (The very beginner)
  2. Learn to put two way signals on rail to allow more trains on that rail at the same time.
  3. Learn to build double tracks for one way traffic.
  4. Learn to make junctions that doesn't needlessly cross tracks that wouldn't take a train going over/under it.
  5. Learn to build RoRo or other complex stations with path-based signals. (or if you are really fancy or started playing before working PBS, pre-signals, combo signals and exits)
  6. *Possibly* learning more advanced techniques such as load balancing (with signals) and priority tracks.
At this point in time, most people should have a fairly basic understanding of logical operation on train tracks. However, they might not know what IF, ELSE, AND, NOT, OR, XOR etc means.
Let's call those that do know this "conditional programmers" thus Programmable signals requires at least some knowledge of programming conditional statements... Right?
I think that the average person can understand the concept of "If number of green signals equals 3" pretty well. Perhaps the "Else" node should be relabeled as "Otherwise" though, but thats perhaps all.
And the reason i would rather have a text box to input my program to is because every time i see a need for ProgSigs i feel the work behind setting them up is quite tedious because of all the clicks all over the place.
Instead of just having a textbox where i can do:

Code: Select all

@inputs a b
@outputs c
if (a & b) { c = true }
Then it's just a matter of hooking up a and b to a source of data. Like clicking a button for input a and then clicking on a signal from where to get the data.
OpenTTD doesn't at present have a multi-line text editor. Implementing one would itself be a lot of work. Additionally, it doesn't at present have support for dynamically creating widgets (to my knowledge)

And if a person doesn't have a clue what "if" or "else" means, how the hell are they going to undertand "if (a & b)", boolean logic, and such?[...]
Why don't support both? For me it doesn't look usable to use the gui to "program" the signal behavior. For those who could write code can use the editor to implement cooler features. Those who can't only use the clickable interface but without the "features".

Sincerely
xZise
moorhs
Engineer
Engineer
Posts: 1
Joined: 01 Nov 2010 12:08

Re: ProgSigs - Programmable Signals patch

Post by moorhs »

Hi,

I have a problem with selecting signals in the signal gui when building from your source. I can't click on the Once-way pbs button (it just doesn't activate) & on most of the other buttons the button after the one I click on is activated (ie: clicking on the Entry Signal button activates the Exit signal button).

Any ideas?

Kind Regards
Kimby
Engineer
Engineer
Posts: 48
Joined: 02 Dec 2009 15:42

Re: ProgSigs - Programmable Signals patch

Post by Kimby »

@moorhs: sorry, I don't have a clue. You might want to specify what version of the game you're using when asking about a problem like that.

@Owen: great work :bow: I have some questions and suggestions tho :oops:

Let's start with some mostly cosmetic suggestions:
1) when you use a condition based on a signal state, you currently show either
- "unspecified signal" when it's not set or
- "specified signal" when it's set
I'd like to suggest a few changes:
- "invalid signal (X,Y)" when it points to a signal that's not an exit signal. I know you can't select one during programming,
but you can change the type of a signal you already used. This makes it easier to spot mistakes
- "specified signal (X,Y)", so with the coordinates visible.
2) if you really want to be nice, you might give us the option of naming signals used so a name can be shown instead of X,Y

Some more involved suggestions:
1) when dragging logic signals, all new signals start with an empty program. Would it be possible to copy the program from the original signal ?
Maybe some other way exist to copy a signal with the programming intact ?
2) is it perhaps possible to add a a yellow state for signals with a configurable speed limit linked to it ?
A red sign reduces the trainspeed to zero, so I was hoping it was possible for a yellow sign to reduce it to some configurable higher speed.
I know, it's not exactly a goal you aimed for with this project, but I'm sure lots of players would love you for it.

Now the questions:
1) when exactly is the program of the signal executed ? My guess would be:
- when the following block changes between free and occupied
- when any of the signals mentioned in the program changes state
- maybe some kind of periodic evaluation, but that doesn't seem to match my observations
2) while under the assumption that the signal was periodically reevaluated, I created a setup that I hoped would be a presignal simulation.
It didn't work, but I found myself left with a result I couldn't explain.

Setup: straight line, programmable signal A followed a bit further with normal exit signal B
the program:

if signal B = green then
make signal green
else
if signal A = green then
make signal red
else
make signal green
endif
endif

I hoped that when signal green was red, signal A would be flashing green-red so it would slow down trains.
The result I got was that signal A became red when the train went by it and remained red until signal B became green.
When signal B became red again, signal A remained green, which I found hard to explain.
BTW: I used a logic train to get a flashing red/green light going, so it's not like I'm still looking for more then an explanation
syntax_error
Engineer
Engineer
Posts: 19
Joined: 10 Nov 2010 18:39

Re: ProgSigs - Programmable Signals patch

Post by syntax_error »

That framework rocks! Its like a revolution in train routing. After a little testing here are some basic user remarks (based on the r19638 win32 release I found up there ) :

* User interface:
- It would be good to have a way to know on wich signal we are working on, specialy when lots of signal windows are open. Maybe by coloring the tile where the signal is when the focus gets on its scripting window? Identification by number or coordinates seems less user friendly to me, and naming takes too much time. Same for the refering signals: coloring their tile when focus on the line would be fine.
- When a signal is selected with the editing tool, the signals gui window diseapears. It would be better if it stayed, so the user don't have to make one click to get the gui each time he want to check a signal code.
- In the scripting window dropboxes for a condition the top one has an instruction 'signal state' and the bottom one has an instruction 'set signal state': this can be a little confusing because the first one refers to a foreign signal as the second one refers to the current signal. Maybe changing the name of the first one for something like 'Foreign signal state' could help?
- Another detail: in the test line the color is writen in english, and in the set signal state line it is writen in local language. It would be better to unify this for the confort of reading.
- Duplicating a signal code apears to me too as a major saving time feature request.

* Scripting language:
- Implementation of the AND and OR instructions would really make the code writing more user friendly, I mean easier to understand.
- Implementation of the 'else if' instruction would give a more readable code as well.
- Why not to remove the 'end if' line and the 'else' when it is useless, just like in python style scripting? We already have the indentation. Less lines in the scripts, good for maintenance.
- In the set foreign signal test it would be nice to check if it is green or red directly, instead of always testing if it is green and using the else.
- Possibility for the user to set and use his global variables would be cool. This opens the way to setup our own events in the game and refer to it in scripts. Simply incrementing a counter and compare its value to something would permit some good load balancing or routing applications. Of course this supposes to have the math operators to process operations on numerical values to get good comparing data(ex: if this track is 50% more loaded than that one, do x). Possibility to print to the screen the current value of a variable could be good for debuging.

Questions:
- Are the lines processed in order? I canot make work a script with a signal state initialisation: A is a progsig, behind it B is an exit sign. If I script:
Make A green (my init of the signal state)
If B is green make A red (this line does not make the A signal red when the condition is met, why?)
- 'Always' and 'Never' instructions: I canot figure out how to use these things, it apears weard and not sexy at all to the user I am. What is that for?

And keep on going! Its just great.
Kimby
Engineer
Engineer
Posts: 48
Joined: 02 Dec 2009 15:42

Re: ProgSigs - Programmable Signals patch

Post by Kimby »

syntax_error wrote: Questions:
- Are the lines processed in order? I canot make work a script with a signal state initialisation: A is a progsig, behind it B is an exit sign. If I script:
Make A green (my init of the signal state)
If B is green make A red (this line does not make the A signal red when the condition is met, why?)
From my experience it looks like setting the light to either red or green terminated the script. I also thought that the whole script would be evaluated and the end result used, but experience seems to indicate that's not how it works
maddy_
Engineer
Engineer
Posts: 20
Joined: 24 Jan 2011 19:08

Re: ProgSigs - Programmable Signals patch

Post by maddy_ »

Hi folks.

Newbie to openttd and openttd development. I decided to try to add this patch to a more current revision. May contains bugs etc. so try it carefully. I did also make a few changes as well.
  • I set the save game version to 200 (wasn't sure about what I should do with this)
  • Signal GUI doesn't close when opening the Program GUI (will close when you use the "select signal" tool of the program GUI)
  • Program-button of signal GUI is ignored if you're not clicking on a programmable signal (you can add non-programmable signals normally)
moorhs wrote: Hi,

I have a problem with selecting signals in the signal gui when building from your source. I can't click on the Once-way pbs button (it just doesn't activate) & on most of the other buttons the button after the one I click on is activated (ie: clicking on the Entry Signal button activates the Exit signal button).

Any ideas?

Kind Regards
This was due to SIGTYPE_END defined in signal_type.h, the programmable signals patch defined it to same value as the last signal type, but it needed to be last signal type + 1. Just in case anyone else runs to this problem.

-Maddy
Attachments
ProgSig_maddy_r21905.diff
Patch made with TortoiseSVN
(144.7 KiB) Downloaded 214 times
Cadde
Transport Coordinator
Transport Coordinator
Posts: 290
Joined: 07 Oct 2004 12:51

Re: ProgSigs - Programmable Signals patch

Post by Cadde »

Unless things have changed recently i think Chills patch pack keeps this compatible with trunk.
maddy_
Engineer
Engineer
Posts: 20
Joined: 24 Jan 2011 19:08

Re: ProgSigs - Programmable Signals patch

Post by maddy_ »

Last version had a nasty bug which could crash the game when saving, no idea what caused it, but this is sort of a workaround.
Attachments
ProgSig_maddy_r21907.diff
TortoiseSVN patch
(144.74 KiB) Downloaded 268 times
User avatar
JacobD88
Chief Executive
Chief Executive
Posts: 708
Joined: 16 Aug 2008 17:51
Location: Long Eaton, Nottinghamshire. UK
Contact:

Re: ProgSigs - Programmable Signals patch

Post by JacobD88 »

Thanks maddy_, I appreciate you keeping this patch alive :bow:
pongi
Engineer
Engineer
Posts: 12
Joined: 15 Apr 2011 11:24

Re: ProgSigs - Programmable Signals patch

Post by pongi »

I have been using the programmable signals a lot lately (actually from the Chilli's patchpack but nonetheless). It's a wonderful feature.

A few things I noticed:
* It would be better to set the default "make signal" state to green since the signal is red anyway if it doesn't specifically encounter a make green order.
* As stated previously I don't see the reason for the never and always commands.
* With a few signals it is important that they preserve the state that they are in even if they encounter no "make xxx". I've solved this by cycling back to them with a "if specified signal is green make green". But an inbuilt feature like this might be better. (Reminder: no order results in red state)
* I don't know if this is possible (or how hard it might be) but connected programmable signals might be useful. "Connected" entry signals share a state meaning that if 1 train enters a track segment the other entry signals are red automatically which means that only 1 train can enter at the same time. With programmable signals the state only changes with the next calculation which might cause several trains to enter. As far as I've been able to establish connected means for the game a track with only enter-exit signals on the way. (I know, a pretty weird scenario. But trust me it has been a major headache for me to limit the entering trains to 1.)

Since all other suggestions have been made I think that's all. I would love to see the patch in the trunk version of OpenTTD. It would be great if somebody removes all the bugs for it to go trunk. (I've had several crashes with the chilli patchpack but I don't know which have already been fixed. Let's just say that demolishing the signals is a pain in the ass.)
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: No registered users and 4 guests