Yellow signal state

[MeusH]

When a train comes across a yellow signal, it will slow down to half its maximum speed. Now I'm wondering if maybe instead it should slow down to a fixed limit, say 60 km/h, or find the speed of the slowest train in the signal blocks causing this signal to be yellow and use that speed instead...

set train's speed to next train's speed (if it's possible)? This way train will travel at maximum speed required not to reach the red signal

So if train A goes 50 [unit]/h, and there is train B behind traveling 75 [unit]/h, B should slow down to 50 [unit]/h when passing yellow signal. Maximum speed should be restored after passing the green signal.

[csuke]

i'm not so sure about the speed limits, in order for them to work properly someone needs to write a patch which allows trains to slow down gradually towards a red signal, rather than stopping in the space of half a square like they do now, then to properly implement speed limits on yellow etc signals, the distance between the current signal and the red one needs to be worked out, and the train should slow down accordingly, and if/when the signal turns to yellow/green then the train should accelerate up to an appropriate maximum speed depending on what the signal after shows

but thats all waaay too complicated lol, and would take way too much cpu to implement

if anyone is interested in how i think that would work then read on, otherwise the rest is irrelevant to the thread

when a train enters a new square it checks if the next signal is not green. if green the it proceeds to accelerate to its max speed or the max line speed, if it is not, then it works out the distance to the next red signal, then calculates how long it would take to slow down (without causing discomfort to passengers) and if it has to, starts to brake, then at the next square it repeats everything

[webfreakz.nl]

Is the savegame affected by this patch?

[egladil]

Only if you activate the "Write the state of yellow signals to savegame" patch option. If you don't it's still compatible, but signals that were in the yellow state when saving will be green when loading.
The train speedlimit information is always written, but this does not affect compability. (At least not in my tests.)

[Bjarni]

The train speedlimit information is always written, but this does not affect compability. (At least not in my tests.)

well it works... except that if you update to the newest svn you will see that you picked the same two bytes as I did with the change in multiheaded engines
It would be a good idea to update your source and use the bytes that is free instead
Also those bytes are blank since savegame version 2, which is ok if your code want it to be 0 when loading old savegames, but if you read savegames older than that, you will not get it initilised. The solution is to change the savegame version in saveload.c (at the top) and write an init function if _sl_full_version < 0x1102 (that's one minor version higher than the current one, and that is likely the one you should use). You will see that there are plenty of those savegame "upgraders" already

[egladil]

I changed it to use the free bytes instead. And the value is fine being initialized to zero. But if the values is nonzero in earlier versions, then I'll have to do as you say and add a init function.

[Bjarni]

I changed it to use the free bytes instead. And the value is fine being initialized to zero. But if the values is nonzero in earlier versions, then I'll have to do as you say and add a init function.

it's worse than non-zero, it's not initilised at all. Right now it reads the savegame and if version is 2 or more, it sets the var you made to what it is in the savegame. It it's before 2, it will not set the var to anything and you will get a var used without being initilised error

[Gorfob]

* PBS pre-signals reenabled.

If you do, I WILL have your babies etc etc.

[Born Acorn]

The PBS in OTTD have presignals built in. No need for separate ones.

[Brianetta]

The PBS in OTTD have presignals built in. No need for separate ones.

No, they really don't. If you want a presignal block adjacent to a PBS block, you're stuffed - you have to have an empty block in between them, because BPS signals do not operate as presignals.

You can use PBS instead of presignals in most cases, but that has never been what people are asking for. People are asking for a signal which acts as a BPS block delimiter whilst at the same time acting as the entrance or exit to an adjacent pre-signal block.

[bobingabout]

how many times do we need to go over this. when feeding a PBS block into another Pre-signal block, having the exit PBS signal being an entrance Pre-signal would be Extreamly useful. I've already outlines numerous situation that can only be accomplished by combining PBS and Pre-signalling, which currently are impossable.

EDIT: like this.
P is PBS signal
S is a signal
X is an Pre-Signal Exit signal
Z is PBS-Pre-Signal-Entrance
E is a Pre-Signal-Entrance
C is a Pre-Signal-Combo
- is Track
< and > are junctions
= is a station
etc, etc, etc

tran will travel to the right
---P<>-Z-<-X===

---P<>P<>Z<X===
train will travel either direction

--P><>Z<X===X>Z><>P--
currently, the only alternative to this 1 is
--P><>PS===SP><>P--
which is Terrible, because its just as bad as
--P><>P===P<><P--
which causes jams at the station if 2 trains try to enter from both sides simultaniusly.

[egladil]

I changed it to use the free bytes instead. And the value is fine being initialized to zero. But if the values is nonzero in earlier versions, then I'll have to do as you say and add a init function.

it's worse than non-zero, it's not initilised at all. Right now it reads the savegame and if version is 2 or more, it sets the var you made to what it is in the savegame. It it's before 2, it will not set the var to anything and you will get a var used without being initilised error

I added some code to initialize it to zero if the savegame is older than version 2. Zero means full speed. (Or rather, it means ignore this variable and choose between acceleration and decceleration the normal way.)
I also added my own debug category instead of hijacking those that happened to be close at hand for a quick copy&paste.

[Bjarni]

I changed it to use the free bytes instead. And the value is fine being initialized to zero. But if the values is nonzero in earlier versions, then I'll have to do as you say and add a init function.

it's worse than non-zero, it's not initilised at all. Right now it reads the savegame and if version is 2 or more, it sets the var you made to what it is in the savegame. It it's before 2, it will not set the var to anything and you will get a var used without being initilised error

I added some code to initialize it to zero if the savegame is older than version 2. Zero means full speed. (Or rather, it means ignore this variable and choose between acceleration and decceleration the normal way.)
I also added my own debug category instead of hijacking those that happened to be close at hand for a quick copy&paste.

why not set it to something really high and then not allow the train to accelerate up to anything higher than this var?
This would mean that when it's higher than the max speed, it's the same as off. When a train passes a yellow signal, it get a new value for this var and it slows down. It is then set to the high value again when passing the next green signal

[egladil]

I added some code to initialize it to zero if the savegame is older than version 2. Zero means full speed. (Or rather, it means ignore this variable and choose between acceleration and decceleration the normal way.)
I also added my own debug category instead of hijacking those that happened to be close at hand for a quick copy&paste.

why not set it to something really high and then not allow the train to accelerate up to anything higher than this var?
This would mean that when it's higher than the max speed, it's the same as off. When a train passes a yellow signal, it get a new value for this var and it slows down. It is then set to the high value again when passing the next green signal

Thats how I did in the beginning, before the value was being saved. But when I wrote the code to save it, I didn't know how and where to add code to initialize it depending on savegame version, so it was easier just to use zero as that was what it would be if the savegame wasn't from my patch.
Now it probably would be better to do as you say and initialize it to something like 0xffff.

[Bjarni]

Thats how I did in the beginning, before the value was being saved. But when I wrote the code to save it, I didn't know how and where to add code to initialize it depending on savegame version, so it was easier just to use zero as that was what it would be if the savegame wasn't from my patch.
Now it probably would be better to do as you say and initialize it to something like 0xffff.

it's bad to use a wrong init value to save yourself from init the var when loading old savegames. The price will be that we will have to check for 0 each time it's checked in the future. When converting, we only have to check when loading an old savegame. Such checks with so little idea behind them tend to mess up the code and slow down the binary. Since it's called for each train each tick, making the code fast is an issue.
Also use

Code: Select all

#define NO_MAX_SPEED 0xffff

or something like that instead of just using 0xffff directly. It will be easier to read the code later on

[egladil]

Thats how I did in the beginning, before the value was being saved. But when I wrote the code to save it, I didn't know how and where to add code to initialize it depending on savegame version, so it was easier just to use zero as that was what it would be if the savegame wasn't from my patch.
Now it probably would be better to do as you say and initialize it to something like 0xffff.

it's bad to use a wrong init value to save yourself from init the var when loading old savegames. The price will be that we will have to check for 0 each time it's checked in the future. When converting, we only have to check when loading an old savegame. Such checks with so little idea behind them tend to mess up the code and slow down the binary. Since it's called for each train each tick, making the code fast is an issue.
Also use

Code: Select all

#define NO_MAX_SPEED 0xffff

or something like that instead of just using 0xffff directly. It will be easier to read the code later on

I agree with you. But the problem with this is that you can no longer open games saved with this patch in an unpatched version since _sl_full_version is incremented.
However, I did it like you said anyway since it's "the right way to do it"
The question now is if I should remove the option to disable saving of the yellow state since the savegame isn't compatible anyway?

[Bjarni]

The question now is if I should remove the option to disable saving of the yellow state since the savegame isn't compatible anyway?

I see no reason to keep something like that since the goal (compatible savegames) can't be gained anymore anyway

[egladil]

I removed the signal state save option since it's didn't help anymore. And I also fixed a problem with new trains having a max speed of zero. (Initialized it in the wrong function.)
Also, I added a grf file with danish signals. Hope you like it Bjarni

[egladil]

I added the option to turn off the pathfinding and speed limit parts separately.
And I noticed that the savegame versioning had changed? It was 18 now. Is it correct to asume as I did that I should use 19 then?

And after trying out both the danish and the "normal" signals, I must say the danish ones confuses the heck out of me

[egladil]

Minor update: It is now possible to choose if the normal signals, the semaphores or both should be used as yellow signals.