[James Ross]

 roeter, on 31 January 2014 - 08:25 AM, said:

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.

Is it possible that interpreting the signal as just the last type would work (assuming we use the first type currently), or is this clearly in need of the signal being both 'types' at once?

[Csantucci]

 roeter, on 31 January 2014 - 08:25 AM, said:

SignalFnType ( NORMAL DISTANCE )

What MSTS digests wonders me everyday more...

[roeter]

 James Ross, on 31 January 2014 - 08:36 AM, said:

Is it possible that interpreting the signal as just the last type would work (assuming we use the first type currently), or is this clearly in need of the signal being both 'types' at once?

Yes, the signals need both types.
The type NORMAL is required to make it an actual working signal (all other types are merely for info only and do not affect the trains).
The type DISTANCE is required as that type is used in the opp_sig_lr function, to test if the opposite signal is clear.

It seems to me the 'double' type is defined for signals along the 'main' lines, not for signals in yards. It could be they use this check to try and prevent 'deadlocks', which were ofcourse quite common in MSTS.
Such an additional test would not be required in OR as that allready has separate logic to prevent deadlocks. So one thing that could be tried is simply to remove all the opp_sig_lr tests from sigscr.dat.
I will try that later and see what the result is.

Regards,
Rob Roeterdink

[R H Steele]

 roeter, on 31 January 2014 - 08:25 AM, said:

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

Is this the reason the player train starts in Node: End Auth? When it passes the first signal I believe it switches to Node: Switch and then back to Node: End Auth. Finally it ends at Node: Auto Signal. Also there is no speed limit set in the track monitor. That finally changes.

[roeter]

 R H Steele, on 31 January 2014 - 09:05 AM, said:

Is this the reason the player train starts in Node: End Auth? When it passes the first signal I believe it switches to Node: Switch and then back to Node: End Auth. Finally it ends at Node: Auto Signal. Also there is no speed limit set in the track monitor. That finally changes.

Yes, that is exactly what happens. The player train has no valid path because that is allready reserved for train 9.
If the situation was the other way round (if the initial position of an AI train was on a location allready reserved for the player train), the AI train would not be placed. But not placing the player train is not really an option.

Regards,
Rob Roeterdink

[R H Steele]

Progress Report on running Cn M31451 with the new path and act files made for F7

1. All signals to Trent Canal Swing Bridge were green or yellow that cleared to green

2. Stopped by Red at Approach to Washago --- Switched to manual >> tab thru >> back to auto

3. At CN Smail got caution, then red, diverted to siding > then passed by Northbound 8F (cn_q107). The 107 meet, not at East Brechin.

4. Got green when 8F (107) cleared switch. No other AI Traffic at this point.

Taking a break and will resume later. I have hopes it works all the way to end of activity.

Edit: perhaps by reworking the starting point of player train the Node: End Auth can be avoided. That's much more of a chore than changing the F7 AIpath.

[roeter]

And here is my report :

• removed the "opp_sig_lr" test from sigscr.dat.
  
• changed starting time of train 9 (cp_110) to 15:01:00, so just after the player train starts (no need to change the path).
  
• made no changes to other trains or any path.

Result : all went smooth. Train 9 passed as I picked up the centre beams. Heading for a meet with train 7, but not reached it yet.
Train 7 is on it's way though, it is no longer stuck far back.
Did not need to change any signals by tab or anything, all cleared as required so far.
Time for a little break, will continue later.

Regards,
Rob Roeterdink

[roeter]

 Csantucci, on 31 January 2014 - 08:49 AM, said:

What MSTS digests wonders me everyday more...

It's not really that surprising, when you come to think of it. MSTS uses bitmaps for many of these type and state definitions, and in a bitmap you can, ofcourse, have multiple valid values - just set and check the bit you want, the rest is don't care.
OR, on the other hand, uses enumerations for these type and states and the whole principle of an enumeration is ofcourse that it can only have one value.
Now, anyone out there willing to rewrite OR and replace all these enumerations by bitmaps? :wheelchair:

Regards,
Rob Roeterdink

[James Ross]

 roeter, on 31 January 2014 - 12:29 PM, said:

OR, on the other hand, uses enumerations for these type and states and the whole principle of an enumeration is ofcourse that it can only have one value.
Now, anyone out there willing to rewrite OR and replace all these enumerations by bitmaps? :wheelchair:

Well, you can turn it from a normal enumeration to a bitmask just by adding the attribute [Flags] to the declaration... I guess the fun is all the code that checks it. :clapping:

[R H Steele]

Another Progress Report:

1. Flashing caution at approach to Hot Box Detector 75.0, passing this next signal is green, then yellow, then red.

2. Red signal at CN Brechin East. Stop > Manual Mode > tab thru > stop to change back to Auto. Mode will appear as Node: Max Dist, will change to Auto when EOT passes signal.

3. All clear into McMillian Yards - no more tabbing. I don't mind "tab thru" you gotta stop for the red anyway. In some instances I have completed an activity in manual, throwing my own switches to get to the correct end of the activity. (make sure you know if there is any traffic, start times, and positions)

There is one more AI CN_M30521_AI (10F) which passes between yards at the south terminus. It starts at 18:57 -- player does not arrive until around after 7 or 8 PM so will probably not spot this train. I would change this for another interesting meet in the yards.


Read Rob Roeterdinks changes, humbly - like mine better. You will have more meets - for eg. player train meets F7, F9, and F8. Also by changing timing of last AI 10F another meet could be arranged at the end of the activity.
Not disputing the fact that the signal configurations are not in the mainstream, and changing them is an approach out of my league. Redesigning the activity to work around those obstacles is what makes it fun for me. Practically speaking, there has to be a limit to what can be accomplished by changing OR to solve each activity boondoggle or quirk that MSTS has to offer. IMHO easier to rework activity to make it interesting and playable in OR, which I have found (in my admittedly limited experience) to be possible.

I would not say that CN Bala2 is incompatible with Open Rails, it does present some obstacles to work with. But isn't that one of the reasons we like this avocation?

In the future when OR finally has an Activity Editor, I'm sure these sort of situations will be minimized for activities written specifically for Open Rails.

In case anyone missed it the first time here is the zip with the changes (attached) Edit: 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.