Sorry for the delay in responding to your questions but I was out of reach of the internet for most of last week, and had a fair few things to catch up when I got home again.
Anyway, here's my thoughts on this.
rickloader, on 19 March 2019 - 02:33 AM, said:
Would the "tt output full evaluation" give any useful information?
Not really, that's more intended for when there are conflicts between trains, causing delays and lock-ups.
Quote
Could "multiple pickup for same location" relate to the TSRE5 platform length bug you highlighted on trainsim.com?. If so I could delete and replace platforms as Goku claims to have fixed this in the latest TSRE.
No, that's not the cause. At worst, the incorrect platform definition is TSRE could cause the trains to stop at an incorrect position, but it would still be treated as that station stop.
As for the problem with these "multiple pickup" reports, I'll get back to that later.
Quote
Might changes in Path handling explain the results in different OR versions? If so I could try different OR versions to pinpoint where the tt problem starts.
As far as I know there are no changes to path handling which affect timetables.
Quote
A strange part of the problem is that the timetable plays differently when observed, to when the trains are run internally.
Examples.By this I mean that when a certain detaching train is player train or seen from an observer train, the $detach works ok. However, when the detach is run unseen by computer it does not occur.
Conversley I spent ages trying to get a $transfer to work and the active train would not see the passive train as a train to couple to. Imagine my surprise when the passive train later passed complete with the transferred carriages. The transfer does complete off screen.
Perhaps these are just examples of my timetable inconsistency. I did wonder if the timetable collumns not being arranged in strict time sequence might confuse OR. However a timetable reconstructed with collums in time sequence still failed.
There are some known problems when the player train is involved in attach or transfer actions. Corrections for these problems are 'in the pipeline' (it just takes a bit longer to get these through to the end of that pipe than I had anticipated).
Otherwise, it's rather strange that there would be differences in what happens when the trains are observed or not, as obviously it's all the same code.
Quote
Just in case I have done something silly in the time table, here it is attached. Pls view in open office or similar.
I can`t easily share my wip route as it is rather big.
I looked through the timetable but I did not see anything out of the ordinary.
That brings me to the problem of the "multiple pickup" errors.
It looks like you stumbled on a program error here - the pickups are not at the same location and should have been handled normally.
I will have to look into that, but that will take time. This could cause some of the problems you experience as the train might get stuck where it is supposed to the one of the pickups.
I would suggest that for now, you split the affected workings into two separate trains. Best thing to do is to terminate the train at the location of the first pickup, and define the pickup for that location in the #dispose field. The second pickup can remain as it is.
You can use the present full path for the second train but you will need to define a new path for the first portion as that path has to terminate at the first pickup location.
Could you please try that and let me know if it helped?
Regards,
Rob Roeterdink
PS. I seem to have picked up a rogue attachment. Whatever it is, it is not mine so please ignore it.