[Request]:NearestTrainFilter

[ginga81]

Description

Relative #1007
Crosshatch's
https://kanakyusubway.web.fc2.com/bve/route/chiba/
I heard from Crosshatch about how NearestTrainFilter works.
According to it, previously, trackDistance and Doors only responded to the train that is in operation, but by using this command, it will be possible to know the TFO's trackDistance and Doors.
Therefore, I would like you to implement this command, and I would like to make a proposal.
I think this command was probably used when S520 aimed to implement it.
But after imprement, change the command by Crosshatch change the commands and arguments hisself.

I suggest a new command that matches the current OpenBVE.
thank you.

Reproduction

Route

https://kanakyusubway.web.fc2.com/bve/route/chiba/

Train

Logs

Related information

[ginga81]

In my opinion, regarding the arguments, for example, if you specify 0,2, the first argument is the distance from the starting point to measure the distance, and 2 is for Rail2 where the TFO runs.

Filter for TFO traveling on Rail2 from distance 0

[leezer3]

I think this probably needs a couple of things changing:

1. Change NearestTrain to consider TFOs.
2. Add a new animated instruction to return the current rail. For static objects, return the rail index used in the .FreeObj command, and for trains, TFOs etc. return the current running rail.

[ginga81]

I agree with your opinion.
Ultimately, the goal is to be able to do the same thing with the data that Crosshatch is currently releasing, so I'll leave it up to you.

[leezer3]

Build from today will now take into account TFOs when looking for the nearest train.

I've also internally re-named TrackFollowingObject to ScriptedTrain
The XML has not changed at the minute (and obviously backwards compatability would be maintained if it did), but I think using this form is somewhat more desciptive of what it actually does.

Getting the track index is actually a little more complex than I'd hoped, and I think is going to require some more major work.
Essentially, we pass somewhat too many parameters here, which are then stored in the object:
https://github.com/leezer3/OpenBVE/blob/master/source/OpenBveApi/Objects/ObjectTypes/UnifiedObject.cs#L52C15-L52C16
To add the track index I think really wants that set of functions re-writing to take a helper struct.

In the pipeline, but not just yet :)

[ginga81]

Thank you.
Crosshatch seems to animate the arrival guide as the distance of Rail0 is the distance of own vehicle, for example, the distance of TFO coming from the opposite direction in Rail2.
So I will announce to Crosshatch to wait until it is implemented.

[ginga81]

According to Crosshatch, Animated started to behave unexpectedly in version 1.10.0.1.
Below is his report.

'This is probably because OpenBVE have become more aware of the TFO involved in this issue.
Even NearestTrainFilter not written .animated file reacts to the TFO of the oncoming train, the platform door, stop position indicator, and approach indicator's animated no longer work in conjunction with the driving vehicle.'

Route data where the abnormality started to occur
https://kanakyusubway.web.fc2.com/bve/route/chiba/

[ginga81]

https://x.com/cross_hatch/status/1779498158592307488
In the second half of the video, the platform door opens and closes automatically in conjunction with the TFO, and the D and green circles in the center of the screen move on their own, but these are ordinary animated files that do nothing.
And at the normally, these are supposed to be linked to the distance of train while driving by player.

[leezer3]

This is 'intended' behaviour (or at least not directly a bug), as the TFO is currently closest.

They would have been activated in the same way by a RunInterval / Pretrain.
Need to sort out the track index, and possibly a PlayerTrainDistance function, which I hope to look at properly this week.

[ginga81]

At 1.10.0.1, I think a similar function is implement in playerTrackDistance, but I think it is the distance of an object with respect to an arbitrary track number, but is there no specification of the rail number?

playerTrackDistance[railno]

[leezer3]

That's correct at the minute.
It's on the list of things to sort out, but my initial implementation has some pretty far-reaching design changes which I'm not totally happy with.

Still thinking....