Special Green Signal

[Aphid]

I have a suggestion for a sixth standard signal. Really simple too, and it will allow you to effectively have signals on bridges/in tunnels.

The 'extra green' signal. It will always allow a train to pass it. It also counts as a signal block end like any other signal.
The first exception is if a train is below top speed in its block, or up to one block ahead. You would need to check all trains in the block though.
The second exception would be if there are trains in both its block and the block ahead.
Like a normal combo signal, there are three variations.

Top speed is defined as min(V1, V2, V3), where
V1 = Top speed of the engine.
V2 = Top speed as allowed by it's current order
V3 = min(W1, ..., Wn).
Wi = Top speed of the i'th carriage.

Place one of these in front of a tunnel entrance and you have signals in it. The EGS will work correctly iff:

(1) Train speeds in the tunnel are restricted to the speed of the slowest train passing it
(2) Breakdowns are set to None.
(3) There is a normal signal in front of the EGS.
(4) The AGS is not used with severely underpowered trains and steep climbs after the tunnel.

Since with default gameplay settings (1) tends to be true anyway, (2) is probably a prerequisite for building them.

Uses include:

(1) Eliminating double or triple tunnels and bridges.
(2) Making logic circuits more compact
(3) Using less signals on simple straight track layouts. (If all the trains maintain top speed)
(4) Building intersections where a signal loops into itself.
(5) Using diagonal tracks with long, powerful trains.

Unwanted side-effects include:

(1) Stopping or reversing a train might cause trains behind it to crash into it.
(2) Heavy climbs and other slowdowns might cause crashes in certain situations, esp. when the climb / slowdown is some distance after the EGS.

In the end, it's simpler to implement, less buggy, and slightly more user-friendly than the patch for signals in tunnels/bridges. However, you need to be careful using this wherever.

EDITS: Added extra clause to fix some side-effects.

[Alberth]

The only exception is if a train is below top speed in its block, or up to one block ahead. You would need to check all trains in the block though.

My trains usually don't run at top-speed, unless they are empty.
Also, they break down every now and then.


Even if they would run at top-speed and do not break down, how do you enter the block eg with a merge?

How do you auto-replace to a faster vehicle model without crashing?

[Aphid]

1: If trains aren't running at top speed, this signal behaves like a combo signal. That's on purpose, so you don't get trains crashing into eachother on hills etc.
Use more powerful trains, or use timetable to limit top speed to use these. They're mainly for superdense networks.

2: With breakdowns on, these should probably be disabled. They wouldn't work with it.

3: Suppose there is a merge up ahead.

-s-s-s-s-E========s-M

Would be an example track layout that would work well with 4-tile trains. (= is a bridge tile).

If a train is stopped before the merge, the E signal will be green. (because there's nothing on the bridge). Trains will pass it.
If a train is on the bridge, moving about, and there is no train stopped before M, it will also allow a pass.
However, if both cases are true, then it's red, as there's a train both in its block and ahead of that.

With a longer bridge, you would want two E-sections, like this:

-s-s-s-s-E============E------s-M.
Since the first E-signal allows up to three trains to pass, that means you need the second E-signal to stop the third train from crashing into the second.
Alternatively, I suppose you could limit it to two trains, as that's enough for most purposes.

4: What if you want to autoreplace?
There are some ways out here. 1: Limit the speed of your trains while autoreplace is going on, using the train's schedule. A global limit could come in handy, but is not necessary.
2: Use the lowest top speed among all top speeds as the green/red criterion.

[YNM]

I thought generally the global speed limit isn't too hard to apply, but you know, the whole thing would exist from a start of an autoreplace. Often they don't start quickly, but waiting for some time (likely). Thats a problem if, say, if theres a really slow engine we have (for eye candy preservation or for shunting) and you also run HS services.

Regarding the problem of a junction after a bridge, how about if its just a short line but contains a lot of traffic, joined by the track from bridge ? The train would stop for a long time, but imagine another train coming from its behind (and you're not there).

Also variable train length would be another problem (I often have a service from, say a coal mine to a power station in the middle of nowhere with only 1 really long train, and it joins the logically nearest mainline to cut cost)

What can I think instead : a special signal that can make the next n bridge tiles reserved (depends on condition) with another requirement that each bridge tile must have an electric signal system unseen. (I know the last is hard

[Aphid]

This suggestion is a 'workaround' of sorts, like the current patch. It's more than an order of magnitude simpler than truly solving the problem but far from perfect. A true solution would require a recoding of the bridge and/or tunnel spec, but that isn't easy.
Alternatively, you could keep the current bridges in the game, and make a second 'bridge v2' type. V2 bridges would be fully capable of crossing eachother, signals on them,etc.
Since there's no newGRF spec for them, one can do what one likes. The two types of bridges coexist for some time.

By the way, two trains ain't a problem, since I was smart enough to suggest scanning one block ahead. But three might be.

Actually... why not go with true. I might try after finishing my script

[YNM]

Ah, some nice answers.

OK, i realized my suggestion is just a workaround, but I think its actually common to see such things. (Loco is the most strongest sample)
Maybe another workaround is yellow state signal and intelligent track reserve varied by speed and TE (length won't be a problem as thats viable in the current version)

Bridge V2 ??!?? That would overkill me ! Congrats if you could make that ! (Or an elevated way, saying alternatively)

Yes, 2 trains is OK in most cases. (unless you build a 100 tile long bridge)

And good luck with your script ! (I just learned C++ a little, still have no idea how to make the UI and other such things)