ProgSigs - Programmable Signals patch

[romazoon]

hi guys

after behing routed to your thread, and after trying unsuccessfully to use the prog signal for what i want... i d like to get some help !

I m trying to make a siding(with a waypoint) giving the ability to stop a freight train when a faster train enter the parralel track of the siding... at the same time i d like to keep the fast trains running smooth by keeping the same signal distance on the fast lane (there is often two or more fast train following each other cause slowed down for a while by the slow freight train)...

Any hint on the programation i should set to get same result as in my exemple down there(link) would be very appreciated

this is my exemple(with path and normal signals), wich works perfectly but is very ugly. I d like to make it look more simple and realistic thanks the prog signals: http://www.tt-forums.net/viewtopic.php? ... &start=160


follow link and scroll down a little until you see this:
Coal train is in front (and enter the siding reserved for slow and unautomated timetabled trains).

Wali Transport, 20_08_1975.png [240.43 Kio]

The ICE train is entering the fast lane and by passing the first path signal make the simple signal go red at end of the slow lane... this signal willl stay red until the Ice trains is gone in front.

Wali Transport, 20_08_1975#1.png [240.91 Kio]

following moment where the ICE train is now way in front entering a tunnel, another ICE train following enough closely to keep the red signal on the slow lane... and you can even spot that a slow local passenger trains is also entering the fast lane and will keep the red signal for the coal train until its gone in front ... after the local train is gone the coal train will be able to keep going.

Wali Transport, 20_08_1975#3.png [241.11 Kio]


Thanks in advance
Romazoon

[maxiecool2]

a little help please
i am trying to figure out how to configure a programmable signal for an entry to a station and a depot that if the station is full then it is to enter the depot
there are no signals in between the programmable signal and the station or the depot
thanks mat

[adf88]

You don't need programmable signals for this. Checkout http://wiki.openttdcoop.org/Two-way_end_of_line

[SkullKrixzz]

im sorry if it has been mentioned before, aswell i have read the original post and have tried messing with it myself but am still kinda confused on this. first off if its actually possible i would like to have a two way single track section with signals for both ways, but i would like all signals for one way to be red if a train in the other direction start down that section, but i would also like all signals behind the train currently travelling that section to go back to green...is that possible? and would somebody be able to help or maybe show me somewhere that could help with stuff like this? the original game signals didnt work for that either, so thats why i think these ones could.

[drsid]

TS, can you help with this quest for programmable signals?
viewtopic.php?f=33&t=73469&start=780#p1186609

[agentw4b]

Why did not this patch appear in the normal game long ago? Creating a gate with logical trains is terrible.

[andythenorth]

Programmable signals are not a current goal for core OpenTTD

They might be available in patchpacks.

[kamnet]

Why did not this patch appear in the normal game long ago? Creating a gate with logical trains is terrible.

1. Its author hasn't been on the forums for 7 years
2. Its author hasn't been here to answer questions.
3. Its author did not submit it to be included.

It's extremely doubtful that the developers are going to include a patch when it wasn't asked to be reviewed, its author not available to work with the developers and who has effectively abandoned the OpenTTD community.

[andythenorth]

I wasn't just being flippant in my "it's not a current goal" reply btw

Currently we have:

• Block Signals
• Pre-signals
• Path Signals

This produces 6 types of signal to build, with semaphore and colour light eye-candy versions for each.

This is because of evolution over time, with new ideas, which is good. But the results can be confusing. Both to players, and in the code for signals and pathfinders.

Adding programmable signals to this isn't a good move. Maybe if there was some simplification first. But currently not a good move. Even if there was a proven patch with an active maintainer.

[kamnet]

Maybe if there was some simplification first. But currently not a good move. Even if there was a proven patch with an active maintainer.

It's included in the JGR Patch Pack (IMO the best way to play OpenTTD today), but I doubt JGR wants any responsibility for maintaining it and making it ready for trunk.

[JGR]

It's included in the JGR Patch Pack (IMO the best way to play OpenTTD today), but I doubt JGR wants any responsibility for maintaining it and making it ready for trunk.

No, I'm not interested in submitting it.

If I'd known then what I do now I probably wouldn't have included it in my patchpack TBH.

At the gameplay level, It's much less useful than routing restrictions in practice.
The code as in this thread has various major bugs, these are fixed in my patchpack repo (see the progsig-sx branch, older fixes are also back-ported to the progsig-rebase branch).

[andythenorth]

If I'd known then what I do now I probably wouldn't have included it in my patchpack TBH.

Shows how patchpacks serve a useful role trying out experimental things - both the concepts and the specific patch implementations.

[agentw4b]

Maybe if there was some simplification first. But currently not a good move. Even if there was a proven patch with an active maintainer.

It's included in the JGR Patch Pack (IMO the best way to play OpenTTD today), but I doubt JGR wants any responsibility for maintaining it and making it ready for trunk.

I think, that in JGR Patch pack is other version of the programmable signal. There are not functions as XOR, NOT, OR and AND.

I saw Joker's patch pack and this version of Progsig patch have logic functions AND, XOR, NOT, OR.

Sorry, my english language is not good. I use Google translate...

[michael blunck]

If I'd known then what I do now I probably wouldn't have included it in my patchpack TBH.

May I ask what it is what you know now? Apart from your following sentence?

Granted, programmable signals are occupying a very narrow niche in game, and they might be tricky to use for the unexperienced. But there are cases where they´re to be used, where routing restrictions can´t be of any help.

IMO, the most superfluous signals meanwhile are pre-signals.

regards
Michael

[agentw4b]

Maybe if there was some simplification first. But currently not a good move. Even if there was a proven patch with an active maintainer.

It's included in the JGR Patch Pack (IMO the best way to play OpenTTD today), but I doubt JGR wants any responsibility for maintaining it and making it ready for trunk.

I think, that in JGR Patch pack is other version of the programmable signal. There are not functions as XOR, NOT, OR and AND.

I saw Joker's patch pack and this version of Progsig patch have logic functions AND, XOR, NOT, OR.

Sorry, my english language is not good. I use Google translate...

Maybe this patch is not the patch I used, but the patch in the Joker's patch set is good.

[kamnet]

I think, that in JGR Patch pack is other version of the programmable signal.

JGR uses this ProgSig patch. He may be using an earlier version of the patch. He also uses modifications from Pi1985's Spring 2013 Patch Pack.

[JGR]

May I ask what it is what you know now? Apart from your following sentence?

Granted, programmable signals are occupying a very narrow niche in game, and they might be tricky to use for the unexperienced. But there are cases where they´re to be used, where routing restrictions can´t be of any help.

IMO, the most superfluous signals meanwhile are pre-signals.

regards
Michael

Programmable signals are really a type of fancy pre-signal, and so share most of the problems associated with them.
Pre and programmable signals are useful for things like track-based logic gates, but these are not especially useful for normal operation of trains.
In most cases, path signals, with routing restrictions if necessary, is better and simpler.

JGR uses this ProgSig patch. He may be using an earlier version of the patch. He also uses modifications from Pi1985's Spring 2013 Patch Pack.

I started from the patch in this post, which still looks to be the most recent one: viewtopic.php?p=926682#p926682
There are changes from SpringPP as well, unfortunately they're not clearly separated in my commit history, I may look at this in more detail later.

In terms of bugs, these are mostly around multiplayer, and removing programmable signals or signals being pointed to by programmable signals.

[SimYouLater]

May I ask what it is what you know now? Apart from your following sentence?

Granted, programmable signals are occupying a very narrow niche in game, and they might be tricky to use for the unexperienced. But there are cases where they´re to be used, where routing restrictions can´t be of any help.

IMO, the most superfluous signals meanwhile are pre-signals.

regards
Michael

Programmable signals are really a type of fancy pre-signal, and so share most of the problems associated with them.
Pre and programmable signals are useful for things like track-based logic gates, but these are not especially useful for normal operation of trains.
In most cases, path signals, with routing restrictions if necessary, is better and simpler.

JGR uses this ProgSig patch. He may be using an earlier version of the patch. He also uses modifications from Pi1985's Spring 2013 Patch Pack.

I started from the patch in this post, which still looks to be the most recent one: viewtopic.php?p=926682#p926682
There are changes from SpringPP as well, unfortunately they're not clearly separated in my commit history, I may look at this in more detail later.

In terms of bugs, these are mostly around multiplayer, and removing programmable signals or signals being pointed to by programmable signals.

Getting ready to go into lurker mode, but I figure I should ask... How do I set up a routing restriction?

[Gwyd]

If you have JGRpp installed, then on the signalling window there should be a couple of settings icons at the end. If you click the top one, then on the signal you wish to modify, it will bring up a menu where you can set routing restrictions.

[agentw4b]

Maybe if there was some simplification first. But currently not a good move. Even if there was a proven patch with an active maintainer.

It's included in the JGR Patch Pack (IMO the best way to play OpenTTD today), but I doubt JGR wants any responsibility for maintaining it and making it ready for trunk.

I think, that in JGR Patch pack is other version of the programmable signal. There are not functions as XOR, NOT, OR and AND.

I saw Joker's patch pack and this version of Progsig patch have logic functions AND, XOR, NOT, OR.

Sorry, my english language is not good. I use Google translate...

Patch with logic function AND, XOR, OR, NOT (I think that is same as in Joker's patch pack ...) : viewtopic.php?f=33&t=68436 there is other graphic for logic signal.