After a serious interlocking data loss, a lot of routes on my
server work absolutely fine, setup correctly, but are blocked by
ghost trains.

I propose a simple fix: Whenever a train stops at a signal at
danger, check if the occupied section is //really// occupied or
it's just a ghost being annoying again.

Also, the same check occurs whenever right-clicking a signal or
a TCB.

> After a serious interlocking data loss, a lot of routes on my
> server work absolutely fine, setup correctly, but are blocked by
> ghost trains.

- Are you using savefiles from the same backup?
- How much does the world differ from the data in the backup? (i.e. how
much have you changed since the backup was created?)

> I propose a simple fix: Whenever a train stops at a signal at
> danger, check if the occupied section is //really// occupied or
> it's just a ghost being annoying again.
>
> Also, the same check occurs whenever right-clicking a signal or
> a TCB.

No.

Ghost sections are not supposed to exist in the first place, as a
section is only occupied when a train enters it and freed when the train
leaves it.

The presence of ghost sections may show various problems that needs to
be addressed, such as:
- bad setup, caused by (for example) a "flipped" TCB;
- savefiles that are corrupted or out of sync; or
- an bug or limitation in advtrains.

In any case, ignoring ghost sections does not fix the actual problem
and, in certain cases, can potentially make the problem worse.

> - Are you using savefiles from the same backup?
> - How much does the world differ from the data in the backup? (i.e. how
> much have you changed since the backup was created?)

Ah, the savefiles were taken from my sever around a week before the data was
lost.

What has changed was (obviously) the positions of the trains on the server,
meaning that there were trains on a different part of the map than where they
were saved.

Another thing that changed was a few junctions were added and bypassed aspects
of the train network which were no good (like trains going underground to a
junction to go back up again, which only existed because a now-derelict tunnel
was at the same level, so i bypassed that with a viaduct and slope). I also
interlocked an entire new tram system which was lost because of the
interlocking data being lost.

> No.
>
> Ghost sections are not supposed to exist in the first place, as a
> section is only occupied when a train enters it and freed when the train
> leaves it.
> The presence of ghost sections may show various problems that needs to
> be addressed, such as:
> - bad setup, caused by (for example) a "flipped" TCB;
> - savefiles that are corrupted or out of sync; or
> - an bug or limitation in advtrains.

But their existence happens. When programming, we must take into account all
edge cases. What if someone submits unicode into an ASCI textbox on an obscure
website and breaks the server? It's not the user's fault the server breaks.
Programmers need to ensure that they account for all edgecases.

Here, a user makes a broken interlocking setup. Oh no! Maybe instead, we notify
the user that there is a ghost train at x location and then the user has to
manually go out and fix it.

This is a compromise. But personally, I feel that the check needs to be done to
reset the section and make interlocking work.

Ghost trains might also occur in perfect interlocking setups. Say that a train
leaves a section at the instant that the server crashes, causing there to be a
ghost train as the train has passed the TCB, but the TCB is unable to register
that. This is hypothetical but should be taken as evidence.

Personally, I feel that we should reset ghost trains out of existence and log
the fact that it happens.

> In any case, ignoring ghost sections does not fix the actual problem
> and, in certain cases, can potentially make the problem worse.

Log the existence of ghost trains after a check, put it in the chat, and ensure
that the admin knows and can fix it before the problem goes worse.

> Ah, the savefiles were taken from my sever around a week before the data was
> lost.
>
> What has changed was (obviously) the positions of the trains on the server,
> meaning that there were trains on a different part of the map than where they
> were saved.
>
> Another thing that changed was a few junctions were added and bypassed aspects
> of the train network which were no good (like trains going underground to a
> junction to go back up again, which only existed because a now-derelict tunnel
> was at the same level, so i bypassed that with a viaduct and slope). I also
> interlocked an entire new tram system which was lost because of the
> interlocking data being lost.

If you have made changes to the interlocking system, then you likely
need to use the copy of the map that corresponds to the savefiles. I do
not think there is much you can do otherwise.

>> Ghost sections are not supposed to exist in the first place, as a
>> section is only occupied when a train enters it and freed when the train
>> leaves it.
>> The presence of ghost sections may show various problems that needs to
>> be addressed, such as:
>> - bad setup, caused by (for example) a "flipped" TCB;
>> - savefiles that are corrupted or out of sync; or
>> - an bug or limitation in advtrains.
>
> But their existence happens. When programming, we must take into account all
> edge cases. What if someone submits unicode into an ASCI textbox on an obscure
> website and breaks the server? It's not the user's fault the server breaks.
> Programmers need to ensure that they account for all edgecases.

I did not deny the existence of ghost trains.

There is a limit to the edge cases you can take into account. Handling
user input properly is obviously one of them, but there are also
problems that are mostly server-side, such as hardware failure or
software bugs. These are hard, if not impossible, to protect against,
and making the admin aware of such problems (which often results in a
backup being restored) is often better than trying to let the program
handle these problems.

For user errors, ghost trains are a consequence and indicate that the
particular setup is problematic.

> Here, a user makes a broken interlocking setup. Oh no! Maybe instead, we notify
> the user that there is a ghost train at x location and then the user has to
> manually go out and fix it.

I do not think advtrains is aware of ghost trains.

Regardless of that, you are aware that there is a ghost train there (and
therefore _some_ problem), so someone has to fix it. Removing ghost
trains is a problem in that it potentially leads to other results that
may appear (somewhat) normal. In the case of "flipped" TCBs (which is
something that has, if I recall correctly, caused some trouble with
ghost trains), for example, removing ghost trains can potentially leave
space for train collisions in the future, and it _still_ needs to be
fixed, only that the problem is delayed to a later point in time.

Back to the case of user errors:
- Who exactly should be notified about the ghost train? (and how?)
- Why should ghost trains be tolerated when it is known that these are a
source of problems?

> Ghost trains might also occur in perfect interlocking setups. Say that a train
> leaves a section at the instant that the server crashes, causing there to be a
> ghost train as the train has passed the TCB, but the TCB is unable to register
> that. This is hypothetical but should be taken as evidence.

That depends on how the server crashes.

In case of a shutdown caused by something running at Lua level, it is
extremely unlikely that this is caused by something other than
advtrains. I am currently unaware that this causes ghost trains to
appear, but in such cases, you likely need to clear ghost trains
yourself and observe the track section in question in case there are
other side effects. A bug report would also be appreciated.

In case of a shutdown caused by (e.g.) a segfault or OOM, the savefiles
are likely not written, in which case you can just restart the server if
you have not changed the track layout since the savefiles were not
written, or the savefiles are corrupt or out of sync, in which case you
should restore from a backup.

> Personally, I feel that we should reset ghost trains out of existence and log
> the fact that it happens.
>
>> In any case, ignoring ghost sections does not fix the actual problem
>> and, in certain cases, can potentially make the problem worse.
>
> Log the existence of ghost trains after a check, put it in the chat, and ensure
> that the admin knows and can fix it before the problem goes worse.

I am not sure why this makes sense. Like I wrote earlier, ghost trains
should not exist in the first place, so that fact that they exist _at
all_ indicates a problem that needs to be fixed, which is often a bad
setup. I am not sure why you are asking for a workaround that most
likely, if not always, delays the problem instead of actually looking
into what causes the ghost trains to appear in the first place.