[R H Steele]

When I posted the "pokey problem" I was being lazy and looking for a short cut to troubleshooting an activity, did not really expect one. Indeed, the problem was with the traffic scheme in the activity. Once that was cleared up everything ran, no screen freezes in full screen mode.

Question: why does a faulty activity still produce a frozen screen? I thought this was a feature of MSTS that was not to be carried over to OR. (definitely not ranting here - just wondering)
1. Activity tests ok using OR test mode (V09)
2. Activity when run causes OR to freeze in full screen, in windowed ALT-F4 works. (what is one supposed to do when full screen freezes and ALT-F4 is inop?)(V09)
3. MSTS AE toolset shows problem when activity is run in "playback" mode
4. Is there anyway to circumvent a full screen freeze - possibly stopping the sim and displaying a message "Activity Traffic Error, run AE and fix", then defaults back to menu screen perhaps?

Cheers, rhs (aka gerry :) we really do need a bigger clown)

[engmod]

Have you tried with the latest experimental code?
http://openrails.org/experimental.html

[Lindsayts]

Now I do not use to many activities though I do drive a couple and I have found a true freeze is almost noexistent even in a route like the SOB. One can get stuck at signals on occasion as OR treats the AI rolling stock completely diffently.

OR is also a rapidly moving target particularly in more recent times and somethings simply do not work out the way one thinks they should. Because of this rapid development its very likely some circumstances will crop up that OR cannot handle. All one can do in such cases is gather as ____MUCH CLEAR____ evidence as one can and submit a bug.
Note, if something odd crops up that no one has mentioned I usually submit a post asking if anyone else has the problem, if not it could easily be some strange local only issue and so needs much more work on my part.

Another aspect to keep in mind is different railways around the world __DO__ use differing signalling and safe working rules so it more likely does not do what one wishes (Note 1). This is as yet not configurable, and its very likely will be a big job to make it so.

Note 1, An example of this certainly here is Victoria (Aus) is that the older 2 position mechanical signalling only indicates a path is avaible (that the path is occupied is indcated by the crew carrying the sections staff or ticket) so one can safely over shoot a signal at the end of a platform (as long as one has the staff), this being required in a lot of country stations with shorter platforms. This is as yet not availible in OR.

Lindsay

[roeter]

There are two kinds of program freezes which can occur.

The first - and most common - is a crash : the program causes an error trap to close (e.g. accessing an non-existing object, trying to get a non-existing element from an array or list etc.), which stops one of the threads. Usually this crash is recorded in the log-file and that makes is relatively easy to find - allthough the underlying cause can sometimes be in a completely different part of the program making it very complicated to sort out and resolve the error.

The second reason a freeze can occur is a program loop - and that is much harder to solve. One of the threads, usually train control, gets into an endless loop - but keeps running, there is no crash. Other threads also keep running, so display and sound continue. These loops are very hard to tackle. There is no usefull information in the logfile. So the person who wants to solve the problem needs to 'reconstruct' the situation in exactly the same way as when the problem occured. Obviously that requires the same route and activity, but it may depend on used rolling stock (different rolling stock can lead to trains running slightly different - but that difference can be enough so the problem does not occur), it may even depend on the PC used by the player (timing aspects). But even if the developer can reproduce the situation, it still requires a lot of work to find the loop. Debug is no use - as other threads keep running, the debugger does not automatically stop within the loop. So, the loop must be found either by trying to reasoning through the working of the code, or by setting breakpoints in all code where loops can occur - and it will not be surprising there are hundreds of possible loops in the code.

The Pokey problem is a loop problem. The likely cause is that the player train starts on a path allready cleared for an AI train - probably in front of that AI train allthough I cannot be sure of that. I do not know where the loop occurs, but I have an idea which may - and it is a bit MAY - prevent this.
But - at the moment I am reworking the whole of signalling and traincontrol process for Multiplayer, which presently has some very serious flaws and needs restructering. That work will take weeks if not months. This problem will just have to wait.

Regards,

Rob Roeterdink

[R H Steele]

 roeter, on 12 October 2013 - 12:15 AM, said:

There are two kinds of program freezes which can occur.

The second reason a freeze can occur is a program loop - and that is much harder to solve. One of the threads, usually train control, gets into an endless loop - but keeps running, there is no crash. Other threads also keep running, so display and sound continue. These loops are very hard to tackle. There is no usefull information in the logfile. So the person who wants to solve the problem needs to 'reconstruct' the situation in exactly the same way as when the problem occured. Obviously that requires the same route and activity, but it may depend on used rolling stock (different rolling stock can lead to trains running slightly different - but that difference can be enough so the problem does not occur), it may even depend on the PC used by the player (timing aspects). But even if the developer can reproduce the situation, it still requires a lot of work to find the loop. Debug is no use - as other threads keep running, the debugger does not automatically stop within the loop. So, the loop must be found either by trying to reasoning through the working of the code, or by setting breakpoints in all code where loops can occur - and it will not be surprising there are hundreds of possible loops in the code.

The Pokey problem is a loop problem. The likely cause is that the player train starts on a path allready cleared for an AI train - probably in front of that AI train allthough I cannot be sure of that. I do not know where the loop occurs, but I have an idea which may - and it is a bit MAY - prevent this.
But - at the moment I am reworking the whole of signalling and traincontrol process for Multiplayer, which presently has some very serious flaws and needs restructering. That work will take weeks if not months. This problem will just have to wait.

Regards,

Rob Roeterdink

Rob, thanks much for the precise explanation to my unclear questions, YES, it was a program loop, that described the situation EXACTLY, at least I know what the correct term is. PLEASE do not think of this as a bug, Don't devote anytime to it. The activity has two trains merging on the same path (as far as I can see). I constructed a new AI path, eliminated a "dummy" AI engine that moved ahead of the player train (what that is for I do not know), and slight adjust of the timing. Used Ctrl-M to let Traffic move first, when I was ready, Ctrl-M to go back to Auto Dispatch. Waited for my green signal, the activity ran with no freeze. Signals work, all trains running correctly. How about this ... if your idea does prevent this situation -- please have it implemented by 2027. No later than, please.

***What I really wanted to know .... it there some way to get out this loop besides restarting the computer. Game ALT-F4 is inop, Ctrl-Alt-Del inop, could not access task manager; is there some other key stroke combo that will get out of the loop without resorting to a restart? If anyone knows...let me in on it. Cheers, rhs (aka gerry) :) {we need a bigger clown)

[roeter]

Hmm, that last point is very odd. Never had problems accessing the taskmanager, whatever program got itself into a loop (OR is not the only program to which that happens ...). Have you tried 'windows'+R command ('windows' is the windows button, 'windows'+R should bring up the 'run' command window from which you can start the taskmanager).

Regards,

Rob Roeterdink

[markus_GE]

Indeed, "Win R" sometimes is the only Option to get out of OR and finally somehow cancel it. Never had similar things with other programs, not even my self-written ones, that actually can be quite nasty at times.

Anyway, when pressing "Win R", a window Comes up asking for the Name of a .exe to start a Task from. Enter "taskmgr.exe" there an click OK. That should bring up tasnmanager. :)

Cheers, Markus

[cjakeman]

 roeter, on 12 October 2013 - 12:15 AM, said:

The second reason a freeze can occur is a program loop - and that is much harder to solve. One of the threads, usually train control, gets into an endless loop - but keeps running, there is no crash. Other threads also keep running, so display and sound continue. These loops are very hard to tackle. There is no usefull information in the logfile. So the person who wants to solve the problem needs to 'reconstruct' the situation in exactly the same way as when the problem occured.

When stuck in a loop, press F2. If it saves, then "Replay" becomes your friend to repeat as often as needed, perhaps with a version having extra diagnostics.

[R H Steele]

Have you tried 'windows'+R command ('windows' is the windows button, 'windows'+R should bring up the 'run' command window from which you can start the taskmanager).

When stuck in a loop, press F2. If it saves, then "Replay" becomes your friend to repeat as often as needed, perhaps with a version having extra diagnostics.

Wonderful, thanks to both of you -- I must have been sleeping the day that information was handed out; my computer skills are mostly self-taught from the business I was a partner in. "Self-taught" - a euphemism for "I know how to yell for help when I get in trouble!" Cheers, rhs (aka gerry) :) {we need a bigger clown)

[R H Steele]

Well looks like I've got something going on unique to my system -- When OR gets into a loop in full screen or goes into the "white screen of death" mode - either way - Win+R does not make the cmd box appear. When the restart is hit - OR cancels, and just before restart the command box can be seen on the desktop - so it did load unseen to me because of the frozen screen and it does not seem to accept a command. Next time I'll just enter the taskmgr.exe even though I cannot see the command box and see what happens. I am going to poke around, do some investigating. Cheers, rhs (aka gerry) :blink: {we need a bigger clown)