Fix: multiple issues with TFO

[s520]

This PR fixes multiple issues with TFO.

• Change: the TFO operation plan to be calculated only when reading the route
  • Previously, if the player jumped between stations, it would be calculated again.
• Fix: the method of calculating the acceleration of TFO
  • Calculation formula of acceleration was incorrect. (Fix: [Minor]TFO: motor sound problem #608)

I'm currently working on fixing #598.

UPDATE: 2021/04/21

• Fix: TrackFollower did not consider the Invalid TrackElement when moving backwards
  • Changed to take this into consideration when moving backward as well as when moving forward. (Fix: [TrackFollowingObject]The object goes off the rail #598)

[s520]

#598 was a problem due to the position of RailEnd on Route CSV and <Point> on TFO.
Block with RailEnd is Invalid TrackElement.
If TFO switches the rail index of TrackFollower to the rail where RailEnd is written, the behavior of TrackFollower is broken because TrackFollower moving backward doesn't consider Invalid TrackElement.

We need to find out that this change does not destroy anything else.

[leezer3]

I don't think it should.

The original code only uses TrackFollowers on Rail0.
We've added multiple rails to the equation, and this / the TrackFollowerFunction are the only places that use it.

Possibly need to think about junctions though.
#329

That is an incomplete branch, but perhaps we need to think about a RailIndexChange event, as opposed to switching then in the TFO itself?

[s520]

Hmm... I'll have a look at that branch and think about it.

[leezer3]

It's not so much for this bug fix, as opposed to a later improvement.
(and the branch is seriously out of date with master)

The switch logic would need to be coded into the routefile, and then I suppose you would need time based switch events (?) in the TFO plan to set them as appropriate, and then reset afterwards.
The advantage would be getting the sim closer to operating as per a 'real' railway, bit on the flip side it'd require a rework of the TFO concept & likely not be backwards compatible.

[s520]

I feel bad. I can not grasp the intent of your remarks.
Are you negative to fd34644 itself, or are you negative because it may affect more than just TFO?

[leezer3]

None if those, nothing wrong with your code I can see.

I was referring to the potential effects of the linked incomplete branch.

[s520]

Thank you. I seem to have misunderstood.

I have fixed the additional issue pointed out here.

[leezer3]

No problem, thanks :)

[s520]

I forgot to uncomment the test.
This PR is now ready for review.
Please review it.

[leezer3]

I've added a couple of small improvements:
ebad2e4
fbf1d43

These are intended to address the following situation:
A train contains a train.dat file, but which has an unrecognised BVE format string in. (I'm not aware of any, but I've only found about 2 of the BVE1210000 format files, and I don't want to rule out others, especially as my collection is more Western focused)
With the changes from this PR, we completely failed to load the train & subsequently crashed attempting to assign AI.

The first disables the start panel if the train format is unsupported.
The second adds another format- UnknownBVE & converts the new function into an enum return as opposed to a void (neater I think).

It might want a check for non-zero cars / handles here, or a check that the loading of the train succedded:
https://github.com/leezer3/OpenBVE/blob/master/source/OpenBVE/System/Loading.cs#L299

[s520]

I see. Thank you for fixing it.