[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.

[R H Steele]

roeter, on 31 January 2014 - 10:45 AM, said:

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

Changing the starting time of F9? I did not notice F9 starting 5 min earlier than the activity had any affect. Agreed, Certainly no path change is needed, or could be accomplished and still run the activity as it is. Was the F9 change from 14:55 to 15:01 just best practice - not having traffic start too close to the time of the activity/player train?

Train 9F (CP110) will not meet F7, they are not on the same track, 9F ends in Mactier (at the end of the modeled portion), does not go south to McMillian.

The normal default path for F7, even with a changed starting time could still conflict with the player train and the activity scheduled meet with 107 at CN Brecehin or CN Smail. Although to be fair, with it starting near the same time as the player train and at a point so far south it could provide another interesting meet??

I still believe that the original intent of starting F7 prior to the start of the activity (few hours) and so far south was to have it meet up near the crossovers. There must have been a reason for doing it in this manner, although I'll be darned if I can figure it.

[roeter]

Starting train 9 at 15:01 rather than at 14:55 avoids the problem that the player train starts on a path allready cleared for another train (that other train happens to be 9 which starts behind the player train). So the player train now starts with it's own proper path, no more 'End Authority' and no more max.speed of 0. Train 9 will now pass the player train at South Parry 6 mins. later, but is still well on time to get there before the player can complete the shunt move.
The path of train 7 is just simply the reverse of the player train path - it starts at the far end at Halton and it just needs this long to get all the way down. Where you actually pass it also depends on how quick or slow you complete the shunting at South Parry. The switch to Manual to perform the shunt removes the 'deadlock' settings, when switching back to Auto after the shunt is completed the 'deadlock' is checked again, and where the trains will meet depends on where train 7 is at that moment.

Regards,
Rob Roeterdink

[R H Steele]

roeter, on 31 January 2014 - 03:38 PM, said:

Starting train 9 at 15:01 rather than at 14:55 avoids the problem that the player train starts on a path allready cleared for another train (that other train happens to be 9 which starts behind the player train). So the player train now starts with it's own proper path, no more 'End Authority' and no more max.speed of 0. Train 9 will now pass the player train at South Parry 6 mins. later, but is still well on time to get there before the player can complete the shunt move.
Rob Roeterdink

Of Course, how dense could I be. (a lot, obviously) what an elegant simple solution. I was looking for path changes, etc. etc to make to the player train. Nice education I'm receiving. Thanks, already made the changes.

[R H Steele]

roeter, on 31 January 2014 - 10:45 AM, said:

And here is my report :

• removed the "opp_sig_lr" test from sigscr.dat.

Regards,
Rob Roeterdink

Concerning: removed the "opp_sig_lr" test from sigscr.dat.

I found this entry:

// If required, show the appropriate 'stop' indication.
if ( !enabled || // Not enabled/cleared to show natural state?
opp_sig_lr (SIGFN_DISTANCE) !=# SIGASP_STOP || // Entry from next interlocking blocked?
block_state() !=# BLOCK_CLEAR || // Block ahead not clear?
!route_set() ) // Switch not set as per link?
state = SIGASP_STOP;

beginning on the following lines: 151,191,226,266,303,340,383,416,458,500,542,584,863,899,935,974,1013,1050

and on line 369 was found:

// 3 color Bottom Head Absolute Junction.

extern float block_state ();
extern float route_set ();
extern float next_sig_lr ();
extern float sig_feature ();
extern float def_draw_state ();
extern float opp_sig_lr (); (my bolds)
extern float state;
extern float draw_state;
extern float enabled;

float next_state;

Do all the sections beginning at the above line numbers need to be removed - including entry at section beginning line 369?
extern float opp_sig_lr ();

or all entries EXCEPT one found in section beginning line 369?

Whoops - succeeded in turning all signals yellow. How do you disable the "opp_sig_lr"?

[roeter]

To make the signals work correctly, remove all lines which read :

opp_sig_lr (SIGFN_DISTANCE) !=# SIGASP_STOP || // Entry from next interlocking blocked?

This is indeed on all the lines you indicate.

The line must be removed to maintain the rest of the "if" statement, which now should look like :

// If required, show the appropriate 'stop' indication.
	if ( !enabled ||							// Not enabled/cleared to show natural state?
		block_state() !=# BLOCK_CLEAR ||			// Block ahead not clear?
			!route_set() )					// Switch not set as per link?
		state = SIGASP_STOP;

The line starting with 'extern' is just a declaration and has no further functions.

Regards,
Rob Roeterdink