Hemiptera Bugtracker at bugs.linux-forks.de

When chaining ATCs (eg: braking down for a station) the commands seem

to be overwritten with the next before execution.

old situation: trains runs with 2 wagons over the end of the platform

after the update

then: 1 ATC with B1 added in from of the complex platform command ATC

result: the trains runs 2.5 wagon over the end

then: an additonal ATC with B1 - now completly overshooting the

platform

I have the impression that the execution of the ATC commands was

fundamently changed in tss and ragarding braking utterly broken

This is not the only problem: The LZB (automatic braking in front of signals) also does not work as expected.

There was a change on how the ATC controls are applied, and it looks like there's a bug in this code. However, I can't reproduce it locally so far.

I'm currently working on this.

Am 23. Januar 2019 12:24:01 MEZ schrieb 89@bugs.linux-forks.de:

>When chaining ATCs (eg: braking down for a station) the commands seem

>to be overwritten with the next before execution.

>

>old situation: trains runs with 2 wagons over the end of the platform

>after the update

>

>then: 1 ATC with B1 added in from of the complex platform command ATC

>result: the trains runs 2.5 wagon over the end

>

>

>then: an additonal ATC with B1 - now completly overshooting the

>platform

>

>

>I have the impression that the execution of the ATC commands was

>fundamently changed in tss and ragarding braking utterly broken

What I think that happened: The ATC behavior wasn't changed: ATCs

already reset the commands in the master branch. If they would not do

this, this would lead to weird behaviour.

The bug: stopping distances have changed, so the trains overshoot the

station ATC controller and thus run into the "B1" controller, which

resets the train.

IMHO though, ATC rails should be considered deprecated for use as speed

restrictions. Use the "point speed restriction" rail instead, since it

should be train-independent, if you use ATC, the line will work

differently when using Japanese trains rather than subways, and it will

also work differently if you use long freight trains with just one

engine, since the braking distances are different, which the ATC cannot

take into account without highly overprovisioning braking space.

Related Bug: #100

On Thu, 7 Feb 2019 14:40:01 +0100 (CET)

89@bugs.linux-forks.de wrote:

> IMHO though, ATC rails should be considered deprecated for use as

> speed restrictions. Use the is also instead,

> since it should be train-independent, if you use ATC, the line will

> work differently when using Japanese trains rather than subways, and

> it will also work differently if you use long freight trains with

> just one engine, since the braking distances are different, which the

> ATC cannot take into account without highly overprovisioning braking

> space.

Using the "point speed restriction" rails as replacement is IMHO not

possible, at least not currently: they are not available (or craftable)

and - much more important - they need additional privileges.

The differences in the necessary distances to brake are obvious, but

there is something else: for a (semi-) realistic railroad line there

are parts of the tracks where reduced speed is needed (eg: bridges) and

stopping there is not wanted.

I think the "point speed restriction" rails are superfluous because an

additional ATC command could give the same result. The command would be

placed in an ATC at the stopping position and on saving the ATC command

string the advtrains system could identify the command and set up the

needed internal data.

I think that all speed-related commands need to be executed and may

*NEVER* be flushed/ignored.

If I remember right is the internal globalstep of advtrains now forced

to 0.2s, were it was before depending on the server setting.

So I think this is a grave change: before my ATC braking tracks were

executed (with a 0.1s globalstep of the server) and the distance is now

too short that they are executed.

I had at one place a sequence to slowly brake a train down, now all

braking commands in that sequence are ignored because of the increased

internal step and the flushing/deleting of commands. I think any speed

related command should be executed immediantly and not delayed until

the next (internal) globalstep.

The actual bug causing the ATC rails to not work has been fixed for a

long time now. Regarding some other points mentioned, I'll outline a

roadmap for an improved ATC system soon.