[atsf37l]

Csantucci, on 20 December 2014 - 12:10 AM, said:

Herb,
I've looked at your logfile. It has nothing to do with the automatic updating of OR versions, but with the internal OR Updater process, that lasts long time during the save operation, letting the Watchdog process believe that the Updater process is hung, which is not true, and therefore interrupting everything. This should be quite easily fixable by someone knowing better than me how the Save code and/or the watchdog code operate.
In the meantime you can use the RunactivityLAA.exe and Runactivity.exe included in the attached zip (overwrite the standard versions after having backed up them), that should bypass the problem.
Runactivities.zip

Thanks Carlo. I'll give it a try. :bigboss:

[R H Steele]

So the above posts still leave a question? Why is it that Herb is having this problem while I, using the same coded versions of OR, have never once experienced it? Unless, Herb is using a tester version not being released to general users. Not being a coder - What am I missing here?

I know this is asking a lot, maybe it cannot be provided in a simple version or something a non-coder could easily grasp.

If you have time to answer, fine, if not, also okay. Just curiosity on my part.

[Csantucci]

The problem arises when there are very many commands to be saved (for eventual future replays). This happens if you make a save after a long activity run. In the case of Herb there were more than 3.000 commands to be saved! Saving many commands requires time to the updater process. When this time rises beyond a certain threshold, the watchdog process believes that the save operation is hanging and stops everything returning to the main menu.
Therefore, Gerry, if you like to experience too what Herb has experienced, either run an activity for long time and then try saving (you should get the problem), or start the activity, play for some time monkey testing (press and press keyboard keys), and then try saving.
In my temporary runactivities I've muzzled the watchdog :) , waiting for someone solving the problem.

[atsf37l]

Carlo, in your summation I see a basic problem in ORTS over MSTS. With MSTS the save function takes a snapshot of where you are and what is currently where and quickly saves the activity. With ORTS the save function is trying to save everything that happened since the activity began?

Why? Why does it need to know, for example, how many times I changed the viewing angle over the course of the last two hours of running? What possible value would such data have for resuming from a save? This is just one element of redundant information that the save function is trying to capture.

IMHO, the whole save function should be rewritten with an eye to "snapshot" the activity and forget about chronicling every piddlin keystroke. :)

Ps: See how easily a casual user solves these major problems? As the programmers pull out more hair! LOL!

[Csantucci]

Herb,
OR saves the whole story of what you've done for the Replay function: the Replay function automatically replays everything you've done in the saved session, so it needs to know what you've done. If you don't use the Replay function, but only the Resume function, saving the whole story of what you've done is in effect useless.

[atsf37l]

OK, explain this to me, please. How does "replay" using the resume/replay screen differ from merely starting the activity over again on the main screen? I do not understand the necessity of "replay." :)

[roeter]

The replay function repeats all actions exactly at the same time as during the original run. This can help in debugging a certain situation which arose from a series of specific actions. Such problems can otherwise be hard to capture as no person can actually repeat his actions at exactly the same moment as during the first run.
That, therefor, is the difference between replay and simply resume the activity.
However, it is ofcourse not so that everyone always replays his activities.
There is therefor a strong case for the replay function - or at least the inclusion of the replay commands in the save - to be captured by a user option. As the program groes more reliable and more stable, and with a large amount of special log and dump functions available, the need for exact replay is diminishing, and it is causing problems with saves.
It's a case of the cure getting worse than the original disease.

Regards,
Rob Roeterdink

[R H Steele]

Csantucci, on 20 December 2014 - 09:09 AM, said:

The problem arises when there are very many commands to be saved (for eventual future replays). This happens if you make a save after a long activity run. In the case of Herb there were more than 3.000 commands to be saved! Saving many commands requires time to the updater process. When this time rises beyond a certain threshold, the watchdog process believes that the save operation is hanging and stops everything returning to the main menu.
Therefore, Gerry, if you like to experience too what Herb has experienced, either run an activity for long time and then try saving (you should get the problem), or start the activity, play for some time monkey testing (press and press keyboard keys), and then try saving.
In my temporary runactivities I've muzzled the watchdog :) , waiting for someone solving the problem.

Now I understand. I had forgotten replay....I used it once to see how it worked, but never since. The longest activity I have run is on the PRR East, 81/2 hours, probably far short of the time Herb spends. That did not present a problem. Probably because I had not reached a data saturation point regarding amount of data to be saved.

Reading Rob's response, is there possibly a time when replay may be made an optional part of save? So, there would be a ReplaySave....detail oriented, and the Default Save ... which would operate more like the snapshot Herb mentions.

Thank you to all for taking the time to explain. Much Appreciated.

[cjakeman]

R H Steele, on 20 December 2014 - 03:42 PM, said:

Reading Rob's response, is there possibly a time when replay may be made an optional part of save?

I don't think that's a permanent solution. It leaves us with an option that will usually work but may fail. That would damage Open Rails' reputation.

It would be much better to find a solution and then the Replay wouldn't need to be optional.

Of course, we might make it optional while we were working on a fix, just to help out.

[atsf37l]

If it were removed from the software it would probably speed up the saving process, particularly on day 3 of a three day activity on the north end of the RGS! Hit save and go make a sandwich! :bigboss: