[roeter]

A very 'basic' activity evaluation function has been included in release X1955.
It consists of two (independent) data logging options.
One will log various train parameters (e.g. speed, allowed max. speed, throttle, brake, dyn. brake, track elevation - all against (play) time).
The other creates a list of station stops, with booked and actual timings, delay and if the stop was properly completed.

Both sets of information are logged as *.csv files, and can be loaded into spreadsheet tooling to show lists or create grahps.
Attached is a print-out of a graph of train speed vs. maximum allowed speed, and a print-out of the station stop list.

The logging can be activated in the 'options' menu, in the added tab "Evaluation".
It is also possible to select the frequency of the train data logging (interval between 1 and 60 seconds), and the data included in this logging.

Additional notes :

• The files are created in the "Routes" directory of the MSTS directory structure.
  
• The filenames are derived from route name and activity name.
  In case you select train data logging while in "explorer" mode, the activity name is set to "explorer".
  
• If a logging file with the name as derived allready exists at the start of an activity, the index _1 will be added to the name. If that exists, index is _2 etc. - upto 99 (if all files exists upto 99 logging is not started).
  
• All logging details are saved and restored when a session is saved and restored, so an activity evaluation will continue after restarting.
  Changes to the settings are ignored on resume.
  
• Because evaluation recording settings are saved, logging will continue to the same file.
  This is what is required if you save on exit and then resume.
  However, if you exit and revert to a previous save, or if you resume from the same saved session more than once, the recorded data will contain "double" entries - either multiple entries with the same timestamp, or multiple station stop information.
  This can not be avoided.
  It is not too difficult, though, to remove this double data once the file has been loaded into a spreadsheet.

Examples :
 Marschbahn78_78_C_4282.pdf (24.79K)
Number of downloads: 620
 Marschbahn78_78_C_4282B.pdf (21.57K)
Number of downloads: 564

Regards,
Rob Roeterdink

[James Ross]

roeter, on 24 January 2014 - 09:28 AM, said:

• The files are created in the "Routes" directory of the MSTS directory structure.

This point is unacceptable; there are many reasons why, but the most fundamental is that people will not have write access to that directory in a default set-up (and nor should we ever expect them to have write access) so it'll just fail.

[roeter]

If you don't have write access to the Routes directory (or it's subdirectories), you will never be able to create any activities etc. as these are held in the the Activity directory which is a subdirectory of the Routes directory. Many users use mini-routes and that will require write access to the Routes directory as well (otherwise you can never switch routes).
If you save an MSTS activity evaluation, it is stored in the activities directory - which is a subdirectory of the route which is in the Routes directory.
So most if not all users will have write access to the Routes directory enabled.

Regards,
Rob Roeterdink

[cjakeman]

James Ross, on 24 January 2014 - 12:11 PM, said:

This point is unacceptable;

The load cache files go into

C:\Users\Chris\AppData\Roaming\Open Rails\Load Cache

and the Save pack files go into

C:\Users\Chris\AppData\Roaming\Open Rails\Save Packs

so I suggest the Activity Evaluation files might go into

C:\Users\Chris\AppData\Roaming\Open Rails\Activity Evaluations

Of course the stem of this path will depend on your system - see UserSettings.cs lines 60-64 or GameStateRunActivity.cs lines 613-614

Hope that helps,

[copperpen]

An MSTS evaluation save actually goes into the save folder of whichever installation the route belongs to. A save game state in OR is retrieved via the menu and can be deleted from there without ever going to the AppData folder. Maybe the evaluation report can be dealt with in the same way. Does the evaluation also include a total time taken, if not can that be included please?.

[James Ross]

roeter, on 24 January 2014 - 12:34 PM, said:

If you don't have write access to the Routes directory (or it's subdirectories), you will never be able to create any activities etc. as these are held in the the Activity directory which is a subdirectory of the Routes directory. Many users use mini-routes and that will require write access to the Routes directory as well (otherwise you can never switch routes).
If you save an MSTS activity evaluation, it is stored in the activities directory - which is a subdirectory of the route which is in the Routes directory.
So most if not all users will have write access to the Routes directory enabled.

Actually untrue; Windows Vista and later will redirect the failed writes to these directories to the VirtualStore directory in a default configuration, which keeps MSTS working just fine (because their existence is merged back in when MSTS looks for files).

[roeter]

James Ross, on 24 January 2014 - 01:00 PM, said:

Actually untrue; Windows Vista and later will redirect the failed writes to these directories to the VirtualStore directory in a default configuration, which keeps MSTS working just fine (because their existence is merged back in when MSTS looks for files).

Only if you have MSTS installed in it's default path - which is actively discouraged (see this link).

Regards,
Rob Roeterdink

[James Ross]

roeter, on 24 January 2014 - 01:45 PM, said:

Only if you have MSTS installed in it's default path - which is actively discouraged (see this link).

I did say "in a default set-up", which you seem to have finally admitted to now, but there are other reasons if you don't agree on that one point; mixing up game-generated data files and content seems pretty silly (even if MSTS did it, though it never had any permissions concerns either), the Windows 7 Client Software Logo Program, for example, says (on page 9) that user-specific application data "must be stored in Users\<username>\AppData", and it's even not recommended by other people in various guises.

Even when we have an OR content management system, which will store downloaded content in ProgramData by default (most likely), the user-specific data must be stored in AppData. (Saved games can be a bit of an exception, in that they're be allowed in to My Documents.)

There is simply no excuse for this kind of abhorrent program behaviour IMHO and it is one of a small number of things I'll get really angry and upset over.

[roeter]

copperpen, on 24 January 2014 - 12:53 PM, said:

An MSTS evaluation save actually goes into the save folder of whichever installation the route belongs to.

Sorry - you're right. I haven't played MSTS for a long time, but I knew it was somewhere where I never looked for it.

Quote

Does the evaluation also include a total time taken, if not can that be included please?.

The train data has the actual 'play time' as timestamp, so the total time taken is simply the difference between the timestamp of the first and last entry.
The station stop data has the actual arrival and departure times, so the total time can be taken from the departure of the first stop and the arrival of the last.

It is not possible to generate anything special for end of activity.
First of all, OR does not have an explicit "end of activity" function : a player can quit a game, but whether that is because he has saved and intents to return later, or whether it is really the end of that activity, only the player knows.
Also, the data is logged from the train control function, which is only called through the "update" function - there is no 'trigger' to this function when the game is stopped. The logging simply stops because no more updates are called.

Regards,
Rob Roeterdink

[cjakeman]

cjakeman, on 24 January 2014 - 12:42 PM, said:

and the Save Pack files go into

C:\Users\Chris\AppData\Roaming\Open Rails\Save Packs

Meanwhile the Save files all pile up in

C:\Users\Chris\AppData\Roaming\Open Rails

where, being multiple files for each save, they are untidy and I intend to move them into

C:\Users\Chris\AppData\Roaming\Open Rails\Saves

Just rather busy with paid work at the moment . . .

[dforrest]

Would it be possible to have a simple evaluation to be generated at the completion of an Activity as is done in MSTS?

------------
David

[roeter]

Not really, for a whole set of reasons.
First of all there is no such distinct 'end of activity' which terminates the simulation as in MSTS. On a 'possible' end of activity, the 'close' window pops up - but the player can continue if he wishes to do so. But even if he selects 'quit' at that moment he may have just saved before that and return later to resume - so there is no knowing if stopping the sim means the end of the activity.
Furthermore, part of the data is taken from the train control logic but that part of the program is not 'involved' in stopping the simulation - when the simulation is stopped, there simply are no more updates to the train control.
A further point is that it would need evaluation data from the full activity which might have been saved and resumed, so all the evaluation data would have to be kept in the program data and included in save / resume data as well.
That's all quite a bit of additional work, and it's not on my list of things to do at the moment.

Regards,
Rob Roeterdink

[Sid P.]

Hi All-
After reading these posts, I'm not sure where and "if" the evaluation files are found.
What's the status with X1975?
Do you have to finish the activity to get a file ?

Thanks,
Sid

[dforrest]

roeter, on 01 February 2014 - 04:50 AM, said:

Not really, for a whole set of reasons.
First of all there is no such distinct 'end of activity' which terminates the simulation as in MSTS. On a 'possible' end of activity, the 'close' window pops up - but the player can continue if he wishes to do so. But even if he selects 'quit' at that moment he may have just saved before that and return later to resume - so there is no knowing if stopping the sim means the end of the activity.
Furthermore, part of the data is taken from the train control logic but that part of the program is not 'involved' in stopping the simulation - when the simulation is stopped, there simply are no more updates to the train control.
A further point is that it would need evaluation data from the full activity which might have been saved and resumed, so all the evaluation data would have to be kept in the program data and included in save / resume data as well.
That's all quite a bit of additional work, and it's not on my list of things to do at the moment.

Regards,
Rob Roeterdink

In my opinion the lack of a distinct “end of activity” in OR is a bug which should be addressed. The “end of activity” is clearly defined on the activity (.act) file. From my experience, most MSTS users expect to see an on-screen notification when they have completed an activity and a report which is saved for future reference. I am sure that this would be expected by these users in OR.

---------------
David

[dforrest]

Is there any more progress on this?

I feel very strongly that, for Open Rails by be a viable alternative for the "general user", activity evaluations with general information on the completion of the activity. is an absolute necessity.

-------------
David