[Sid P.]

The activity "Marseille-Nimes Special (Duplex) for the LGVMed 3.0 route ran OK in X2353, but dies with a "System.ArgumentOutOfRangeException:" error in X2365 at startup.
OpenrailsLog.txt attached.

Another activity for the same route - "Marseille-Nimes direct (Duplex) runs OK in X2365 - the starting location is different, and it is snowing in the activity that failed.

Cheers,
Sid

Attached File(s)

•  OpenRailsLog.txt (9.13K)
  Number of downloads: 170

[Csantucci]

Fixed in X.2369. The .act file refers to a platform entry (51) that does not exist in the .tdb file (maybe it was built with a preceding version of the route), and OR was not protected against such mismatch.

[gpz]

Carlo, are you sure OR should really be protected against such a mismatch? Wouldn't such a fix just hide a real error, that would be better just to be kept to exit from the game?

Maybe a correct fix for this would just hide the detailed trace log, and display a human readable description about the problem, and exit.

[James Ross]

gpz, on 29 July 2014 - 12:25 AM, said:

Carlo, are you sure OR should really be protected against such a mismatch? Wouldn't such a fix just hide a real error, that would be better just to be kept to exit from the game?

Maybe a correct fix for this would just hide the detailed trace log, and display a human readable description about the problem, and exit.

I can't seem to get to the Subversion server to check if the fix provided is logging anything, but I would generally be happy with bad data causing either:

• A logged warning that it is being ignored/skipped
  
• A specific but fatal error

There's no need to make things fatal if we can cope reasonably well, e.g. by ignoring the station stop, but it must log the data problem as a warning in that case. :buffalobill:

[jbnx42]

James Ross, on 29 July 2014 - 12:47 AM, said:

I can't seem to get to the Subversion server to check if the fix provided is logging anything, but I would generally be happy with bad data causing either:

• A logged warning that it is being ignored/skipped
  
• A specific but fatal error

There's no need to make things fatal if we can cope reasonably well, e.g. by ignoring the station stop, but it must log the data problem as a warning in that case. :buffalobill:

As a software developer, I will chime in here.

Think of the end user, a non technical person who just wants to drive trains. Such a user should never see a dot net framework error. As James says, such a user should see a friendly fatal error, such as "The selected activity could not be loaded due to a defective activity definition. Please contact the author." This type of user need not know about warnings; they should be logged and swallowed.

Now there may be a more technical user such as an author, developer or other advanced user. For such a user, they may wish to see more detail. Perhaps a command line switch to alert them about initial problems that could appear on an opening dialog as soon as the activity finished loading, such as "15 warnings issued, 4 of them severe. See the log."

If not done already, such standards should be hashed out and published as firm guidelines for the project.

Thanks, John

[Csantucci]

Passing from theory to the practical case, in this case the fix I introduced simply skips the activity-specific override for the number of passengers waiting at a platform that does not exist (the related activity line is simply garbage), but this does not affect activity execution. So, I don't agree with Peter's proposal forcing exit of the game. Let's not deprive the player of the pleasure of playing the activity.
I agree with James' proposal about inserting a warning entry in the logfile, that anyhow lets the game proceed. I will do that in occasion of my next commit.

[Sid P.]

Csantucci, on 28 July 2014 - 11:46 PM, said:

Fixed in X.2369. The .act file refers to a platform entry (51) that does not exist in the .tdb file (maybe it was built with a preceding version of the route), and OR was not protected against such mismatch.

Thanks for the quick reply and fix, Carlo.

Looking at it as a user, I like the idea that there is some kind of friendly report, even if it is only in the logfile. I notice OR warning of many items in some routes, but managing to run just fine ( e.g the Monon route has lots of warnings for the sigscr file). It is preferable to MSTS, which sometimes just quits at startup without saying anything. On the other hand, I agree that ORTS can't be expected to handle all activity errors gracefully.

Cheers,
Sid

[Csantucci]

Trace warning introduced in X.2370.

[Sid P.]

Csantucci, on 29 July 2014 - 11:51 PM, said:

Trace warning introduced in X.2370.

Noted - thanks. This warning could be useful when setting up "Timetable" activities.

Cheers,
Sid.