Transport Tycoon Forums

The ProgSigs patch adds Programmable Signals to OpenTTD. Programmable signals are a special form of combo presignal, that can choose it's output dependent upon it's inputs in a way you control.
Creating a Programmable Signal
Programmable signals occupy the slot in between combo and PBS signals in the signal GUI.

Programming a Programmable Signal
The program button is the bottom-right of the signal GUI window; the one which (for now) shares it's icon with the settings button.

Finding a signal
If you've lost the signal the open window points to, the little right arrow will take you to it (Todo: Better icon)

Adding & Removing instructions
Select the instruction you want to insert the new instruction before and select the instruction to insert from the Insert dropdown list. To remove an instruction, select it and press remove. If this instruction is an If, then all of its children will be removed

Manipulating an instruction
The three buttons on the top row manipulate an instruction, and change depending upon its type.

Possible instructions

• If: Conditional branch upon a condition
• Set Signal: Set the signal's state to the selected value and terminate the program

Possible conditions

• Always: Always take the Then branch of an if
• Never: Always take the Else branch of an if
• Green Signals: Compare the number of green exit signals behind this signal to a value
• Red Signals: Compare the number of red exit signals behind this signal to a value
• Signal state: Look at the state of another exit signal that you own on the map

What's next?
Unless someone comes up with any compelling features, this patch will probably enter maintainance mode - that is, I now regard it as stable, and hope for it to be tested for inclusion in trunk

Where is the patch? (Updated 2010-04-02)
Find the latest diff here. Find the Git repository I use for development at Gitorious. (The updates are pushed to Gitorious by an automated script on my server every quater of an hour. There may be some lag with that.)

I found a bug!
Please, try and devise the minimum scenario to report it. Whenever possible, try without NewGRFs or other patches enabled. In particular, in the case of other patches, then I cannot always isolate the problem as belonging to ProgSigs or the other patch, and subtle interactions between them (As they are not expecting to be used together) can make debugging especially difficult.

If you are playing with a patch pack, please report the bug to the pack's maintainer. They can better isolate the bug, and then report it to the maintainer of the appropriate patch.

If you have found a bug, please help me out in tracking it down by

• Whenever possible, building in debug mode (Linux/OS X users, pass --enable-debug to configure)
• Running the game with misc debugging enabled with command line parameter "-dmisc10" or console command "debug-level misc=10"
• If the bug occurs while saving, additionally enable debugging for that: "-dsl10" or console command "debug-level sl=10"

If the bug causes a crash, please provide the generated crash.log, crash.png and crash.sav (if generated), plus the most recent save before the crash and, where applicable, instructions to reproduce it.

Providing this information is of great help for tracking down the bug quickly.

--------------------------------------------------------------------------
Old Content Alert! Old Content Alert! Old Content Alert!
From here down is old stuff kept for historic reasons
--------------------------------------------------------------------------

This patch adds a NAND-type combo signal to OpenTTD.

The behaviour of the NAND signal is quite simple, and will be familiar to anyone who is familiar with logic gates:

• The signal is red if, and only if, the signals behind it are all green
• Otherwise it is green

This signal type has an interesting consequence: Traditional combo signals cannot, however indirectly, change their own state by seeing themselves. NAND signals potentially can: The simplest example of this is a NAND on track which is a circle from front to back, which would, without limitation, continuously oscillate (And therefore cause OpenTTD to hang). A restriction is therefore in place: The number of NAND signals changes which may occur at once is capped, and can be set to any number between 64 and 4096, with the default being 256.

These signals open many possibilities: While many (#openttdcoop being most notable) have created logic gates in OpenTTD, they have done so using trains, which implies that there are propagation delays. NAND signals sidestep this issue.

Using NAND signals, you should be able to build logical constructions as complex as your heart's desire; theoretically, one could even implement a small-ish processor. Flip-flops are certainly possible.

Notes:

• We need a proper NAND signal graphic. At present, the patch uses the PBS-exit graphic, which is unused in OpenTTD, but potentially confusing
• OpenGFX users take note: OpenGFX does not include said PBS-exit graphic for electric signals; instead, it includes a duplication of the normal PBS graphic. Undoubtedly this could be confusing. Semaphores are unaffected (OpenGFX and the default graphics both use the same semaphores)

The patch is attached; diff is against r19495.

Looks interesting, may I request a windows exe file from someone who can compile it?

<PeterT> OwenS: what do I write in the post?
<OwenS> PeterT: I dunno
...
<OwenS> Whatever you want
<OwenS> Even something as simple as "Win32 binary"
<PeterT> http://www.tt-forums.net/viewtopic.php?p=865792#p865792
<PeterT> No, posts must be at least 3 words long
<OwenS> People are gonna see that and get confused

Update

• Signal cycling was broken. Fixed
  • CmdBuildSingleSignal called NextSignalType with (cur_type + 1), rather than cur_type. Would advance two signals, oops.
  • NextSignalType assumed the wrong ordering for the cycle_signal_types setting
• Speaking of settings, the maximum changes setting has moved to the Signals settings group. You know, where it belongs

NANDNG revision c8dcfad, diff against r19495

With 'signals behind it' you mean signals the train already passed?

Hyronymus wrote:With 'signals behind it' you mean signals the train already passed?

No. I suppose I should have worded that as "signals in front of it". Because a NAND inverts its inputs, it can cause a series of signal updates which could continuously cycle and therefore hang the game (That is, signal A changes, possibly some other signals change, it changes again, causing others to change, causing it to change again, etc). The limit provides an upper bound on the number of times this could happen.

The ideal solution might be to store the number of times a signal changes somewhere rather than the number of NANDs evaluated, but for something so rare in practice (but quite easy to do while building), it's probably a waste of map bits

I was thinking you worded it differently then common sense but then I have a question: if all signals ahead are green I like my train to move on. Why show a red signal then, or am I completely misunderstanding your patch feature?!

Hyronymus wrote:I was thinking you worded it differently then common sense but then I have a question: if all signals ahead are green I like my train to move on. Why show a red signal then, or am I completely misunderstanding your patch feature?!

It is not useful for constructing regular train networks. Its only purpose is in building complex logical circuitry, which is too slow if you use "logic trains".

The simplest example is using a NAND as a not gate. For example, you might want to permit a train down a track only if another one is red. In this case, you would feed the NAND with the signal on that other track. A picture of how you would do it is attached.

In general, NAND signal use tends to require signalling-only track, which is somewhat unfortunate, but by using it complex constructions can be produced. For example, it is possible to with it build a perfect balancer (i.e. one which will split a set of trains exactly in half)

This patch helped me design the reset-line in this memory cell.

very nice patch. this or programmable signals.

one sprite for "NAND is broken" instead of cryptic error message (could make things easier to spot on on map, too)?

I have created a savegame which contains the most efficient logic gates I could come up with aswell as 8 of these memory cells with both central aswell as individual resets.

The Nand::NG patch is morphing into the Programmable Signals patch.

This is quite a complex patch, so it's coming in stages, as follows:

• VM and simple instructions
• Programming GUI
• More complex instructions

This is just the first stage - that is, you can't program any signals yet! This version is being released for two reasons:

1. To allow the technically inclined to have a look at the VM's workings
2. To get a bit more testing of the patch

Ok, you may be wondering, if I can't program the signal, what use is it to me? And the answer to that is as follows: It automatically programs itself to be a NAND

I'm about to start work on the GUI for programming these things, so next release will be when thats done

What kind of programmable signals exactly?

We now have an interface for viewing code. You can't do any programming yet, however.

Does this patch use the VM that you have been speaking about at IRC?


Now comes the fun of either using the edit box as a line editor and use arrow up/down to move between lines or creating a multi line edit box widget. If that is going to hit trunk you probably need a solution that work towards decoupling the data storage of edit boxes from the window class so that multiple edit boxes per window can be used as well as in your case also multiple types of edit boxes.

No, that VM is a non-OpenTTD-related project for a scripting language. Programmable Signals uses an altogether different design.

Also, the code will be entered in a graphical way similar to how orders are programmed

FHS wrote:What kind of programmable signals exactly?

As far as i have been thinking about the matter, there are three different kinds of programming that signals could use:

1. Programmable (in the TTDP sense) Signals can be forced to red when certain conditions are met, usually the state of other surrounding signals. This includes the NAND signal. To make this part useful for Path Signals, one of the conditions should be "Tile <X,Y> is [not] reserved". This method cannot use train properties.
2. Restrictive Signals add a pathfinder penalty on certain conditions to influence whether a train considers to go through this signal. The current behaviour is that there is a penalty when the signal is red or when this is the back side of a path signal. Useful conditions here are train properties like cargo, loading state, speed, etc.
3. Guiding Signals force a train to take a certain route. This is done by reserving a path before invoking the pathfinder; trains will always take the reserved path. Conditions here can be the same as for restrictive signals

count this as a suggestion.

The signals are TTDP-style programmable. For now, they do not interact with pathfinding any differently from combos, and do not interact with PBS. Thats not to say they cannot; they just don't for now.

I'm hoping to make them more resilient; for example, it should be possible to look at the state of any signal on the map.

Restrictive/guiding signals are quite a different kettle of fish. Thats not to say they couldn't be implemented (Or even share code), just that they're not currently.

Is it possible to make conditional train orders based on state of signal?
For example:
- wait for full load but leave if X signal is red (potential use: no more than n trains loading on one station)
- stop loading only if X signal is green (potential use: leave station only if mainline is empty)
etc
It require a lot of work but results may be great!