[roeter]

The problem isn't where the player train is, but way back where 7F is stuck.
The player train is approaching a meet with 7F which the deadlock processing has set up. But for some reason, 7F is stuck further back for a signal which for whatever reason refuses to clear.
My intention is to get this route myself and then I can have a close look as to what is keeping 7F from proceding. I am waiting for the bank transfer to PayPal to come through, then I can order the route (download). Should be in a couple of days or so.

Regards,
Rob Roeterdink

[Metro4001]

GTADon, on 30 January 2014 - 06:04 AM, said:

Regarding "Use manual mode and the dispatcher window to throw switches and override signals." this works only partially with this route (Bala 2.0). I used that and so did Claude350, but at the siding in "Sparrow Lake" the dispatcher will not give a proceed after the switch is aligned even though the signals stay red in all directions, but the switch position changes and is green in the small indicator.

The dispatch window is activated by pressing Control + 9. You then have to minimize your main OR window and you should see a new OR window in your tray(?), this is the dispatch window. Click on it and it looks somewhat like the AE display except in real time. Have a look around and find where an AI is stuck and zoom in. Click on the signal in front of the train and it'll give you a few options; System Controlled, Stop, Approach, and Proceed. If you click proceed the stuck train will get a green signal and continue on it's way.

[GTADon]

It was indicated earlier to press through "Shift-F5" to eventually get to the dispatch window, now this is all new.

This is good because I am learning some new things about OR as I go along. I will try this and see what happens and let you know.

Thank you all.
:sign_thanks: :sign_thanks:

[R H Steele]

GTADon, on 30 January 2014 - 06:04 AM, said:

I am not deterred and will stick with OR, MSTS is just not the same after using this fine program. There has to be something within the matrix of the Bala 2 Activities that OR just does not like. :sign_thanks:

Yes Sir, my vote for Open Rails (OpR for Marcus). Appears my copy Bala2 was shipped, so I'll be patient. And I included the ":sign_thanks:" just because I like it. Bob Pickering's acts do run very smoothly, agreed.

[R H Steele]

roeter, on 30 January 2014 - 02:23 PM, said:

The problem isn't where the player train is, but way back where 7F is stuck.
The player train is approaching a meet with 7F which the deadlock processing has set up. But for some reason, 7F is stuck further back for a signal which for whatever reason refuses to clear.
My intention is to get this route myself and then I can have a close look as to what is keeping 7F from proceding. I am waiting for the bank transfer to PayPal to come through, then I can order the route (download). Should be in a couple of days or so.

Regards,
Rob Roeterdink

So Mr. Roeterdink, after reading many of your posts regarding switching, signaling, route problems, and the like -- may I ask an impertinent question? Is there some CTC Elvas Tower somewhere with a comfortable chair, worldwide connection via fiberoptic hyperlink --- with you sitting in the chair. :sign_thanks: Please excuse. Just being my usual wacko, flippant, self. Seriously, I always read your (and also the other development team members) posts -- you guys seem to unfailingly zero in on the problem in question. Thanks for all your fine work. (now, if your hat size didn't inflate after that - you're a better person than me >>>> :sign_thanks: biggest hat I could fine in the emoticons, ignore the freezing. Can we get a bigger hat)

[R H Steele]

Okay, just finished CN M31451. First checked it out in AE, watched the trains, read all the messages, checked the paths, etc. etc. Yep Rob is right (and not the first time either) F7 - which is CN_X30131_AI is stuck way south. Looking over the activity I believe the intention was to have a meet of AI trains F9 and F7 at or near the crossovers just south of the yard. F9 passes through the yard during the centerbeam pickup (or thereabouts). Thing is F7 starts at 12:00 (that not quite right) but's it's 3 hours earlier than the start of the activity. There probably is a reason for this in MSTS - I am not experienced enough to know what it could be.
F7 certainly is not supposed to meet the player train way south - a message states that there is only one southbound meet at Brechin with 107 (and 107 is another AI running north). So I reworked F7's path to make it run through the yard, meeting the player train hopefully in the neighborhood of original intent. (if that doesn't make sense - it's late).

Attached is a zip file with a new activity file, and a new path for CN_X30131_AI (the FABLED F7). There is a readme included. Please read it, explains when to use manual or auto, when to tab through signal (yep that still happens) and what to watch for.

Backup all files, please. Swap out the activity and path files new for original and keep the originals or overwrite after copying originals. LEGALESE - I dunno nuttin about nuttin - it's all your fault. I'm going to bed. Have Fun :sign_thanks: :sign_thanks: Edit: cn_m314.zip removed by rhs - this would only serve to confuse. Make the sigscr.dat edit and change starting time of F9 (CN_110_AI) as mentioned elsewhere in this thread.

[markus_GE]

GTADon, on 30 January 2014 - 04:35 PM, said:

It was indicated earlier to press through "Shift-F5" to eventually get to the dispatch window, now this is all new.

This is good because I am learning some new things about OR as I go along. I will try this and see what happens and let you know.

Thank you all.
:sign_thanks: :sign_thanks:

Don,

Shift F5 will display the ingame dispatcher hud, that gives some basic info on what the AI dispatcher is foing.

Ctrl 9 openas a totaaly new dispatcher window, showing a similar interface to MSTS AE´s user interface, in which YOU - the player - can take over the role of the dispatcher. This window doesn´t just give you some info on what´s going on, you can actually change what´s going on. That´s the difference between the dispatcher HUD and dispatcher window. (Note you must switch OpR to windowed mode (don´t recall the keaboard shortcut to do that right now... so, please look it up yourself in OpR´s options->keyboard tab) in order to access the dispatcher window after activating it.)


@ Gerry: I first read this abbreviation in an introductory post of a "new Hire" some time ago, and immediately "fell in love" with it. "OpR" is far less likely to be confused with the logical connector "or" than is the abbreviation "OR" for Open Rails. And it´s shorter to write than "ORTS" ;)

Long story short, credit does not go to me ;)

Cheers, Markus

[roeter]

Well, I'm afraid to say that Bala2 is indeed incompatible with OR - at least the signalling is incompatible.
The reason for this is that a construction is used in sigcfg.dat which I haven't seen before in any route and, admittedly, did not know was possible and allowed.

Various signals are defined as two signal types :

SignalFnType ( NORMAL DISTANCE )

That construction is certainly not supported by OR, and changes to implement that would be very extensive.

This does cause all kinds of problems.
The main problem - and that's the problem which keeps so many signals at danger - is as follows.
In the signal script for normal signals, there is a test if opposite signals are cleared - if so, the actual signal will not clear.
But this test is done for signals of type DISTANCE. As OR cannot allocate two different signal types to a signal, it does not find the intended signal, but instead finds a switch-stand much further down the route (which, strange enough, is also type DISTANCE). A switch-stand never has state STOP, and thus the main signal will never clear.

I suppose they have their reasons for this rather strange and very exceptional construction, but, apart from writing new sigcfg.dat and sigscr.dat files, I see no easy way to get this to work.

Some further observations.

The number for SignalNumClearAhead is rather high for the type of signals used - it is set to 6, whereas 3 or 4 would suffice. The result is that trains clear their path much further ahead than strictly necessary, leading to longer waits at meets.

At the start of this activity, the player train is placed on a path which is allready reserved for the train coming up from behind (partly as result of the extended clearing as mentioned above). This too is causing some problems.

Regards,
Rob Roeterdink

[cjakeman]

markus_GE, on 31 January 2014 - 06:00 AM, said:

"OpR" is far less likely to be confused with the logical connector "or" than is the abbreviation "OR" for Open Rails. And it´s shorter to write than "ORTS"
Long story short, credit does not go to me

All true, but the brand is "OR" and the logo shows "OR" and we've no plans to change.

[markus_GE]

cjakeman, on 31 January 2014 - 08:26 AM, said:

All true, but the brand is "OR" and the logo shows "OR" and we've no plans to change.

So are you suggesting I should revert to "OR" again? Or maybe "ORTS" to avoid confusion?

Cheers, Markus