After preparing the build report for attachment to my reply, I re-read the section relating to the car and found why the system was deleting the final destination - the car length is longer than the spur length, and thus the car could never be delivered to the destination. A copy of the build report is attached. I increased the length of the spur, reset the train and built the train again. The car now moves correctly.
This will teach me to read the build report more carefully when I have a problem. I now need to review all my spurs, and the cars that should be sent to the spurs to ensure that I do not have any similar issues. Problem is that most of my experience is with my own layout where the maximum length of cars is 50'. For the club layout, I need to deal with more modern, and longer cars.
As a suggestion for a future build of Ops Pro, it may assist others if a warning is issued when the system deletes the final destination because it is not an obvious situation and the car was being moved.
On Mon, Sep 2, 2024 at 1:21?AM Dan Boudreau via <daboudreau=[email protected]> wrote:
On Sun, Sep 1, 2024 at 09:53 AM, Eric Coughlan wrote:
To me, I feel that there is a logic error in the system where the testing of the schedule matching is being applied without first checking that a final destination has been set. It seems to ignore a manually set final destination.
What you've described doesn't seem right.? Could you please attach a build report for the train that isn't moving the car correctly so we can see how you've configured things.
?
The program changes a car's load and final destination when the car gets delivered, not when a train gets built.
?
If a spur is full, the program will first look for an alternate track for that spur to spot the car, and if not available, find the nearest yard to temporally store the car until the spur track becomes available.? The program should not remove the car's final destination AND track until the car is spotted at the spur.?
