Position light routes

[geepster775]

Has ANYONE? come up with modified signal scripts so all the N&W routes we have (Pokey, East River, Clinch Valley) that use Hank's position light signals display proper signal indications when run in Open Rails? These signals are affected by the same "processing changes" between MSTS and OR that also afflicted the SLI switch stands, where the switch stands were displaying reversed when the actual switch was normal. The switch stand fix was easy and only affected one item, whereas the PL issues need a broader fix. Has anybody already fixed those scripts or is nobody running these N&W routes anymore in Open Rails?

[CSRX]

Has ANYONE? come up with modified signal scripts so all the N&W routes we have (Pokey, East River, Clinch Valley) that use Hank's position light signals display proper signal indications when run in Open Rails? These signals are affected by the same "processing changes" between MSTS and OR that also afflicted the SLI switch stands, where the switch stands were displaying reversed when the actual switch was normal. The switch stand fix was easy and only affected one item, whereas the PL issues need a broader fix. Has anybody already fixed those scripts or is nobody running these N&W routes anymore in Open Rails?

Personally I think those three routes you mentioned need a overhaul to begin with anyways. As for the light scripture, That seems to be a strange one indeed. I personally run on dark territory routes, so I haven't ran into this issue yet. Though I do hope it gets fixed, especially if a decent Activity Editor becomes provided.

[ebnertra000]

Did he make a set that showed NW signal aspects? I thought it was just PRR aspects...unless it was a special for those routes. I could see about it, if I can get a hold of him to get it cleared first

[geepster775]

This was first spotted 2 YEARS ago, and as of today, I still have not seen a fix.

https://www.trainsim.com/vbts/showthread.php?323217-NW-permissive-CPL-issue

It also "spread" to other non-CPL routes (in this case, the Orin Line) which all have early (primitive) Jovet scripts.

https://www.trainsim.com/vbts/showthread.php?324126-More-signal-scripts-quot-broken

The "fix" is similar to what needs to happen with the switch stands to make them display properly.

https://www.trainsim.com/vbts/showthread.php?325302-Adding-switchstands-not-present-in-completed-route&p=1899647#post1899647

The switch stands were an easy fix in that there is only one entry that needs to be modded. The signals are a different story. Lots of entries for lots of types of signals need mods. I didn't build these signal systems originally, and it's above my pay grade.

Clearly, 99% of the user base here can be diagnosed as a clinical hoarder or packrat. Obviously, most people here all about collecting shit, and never running it. Because If people gave 10% of the effort at running the material found in the library here instead of just hoarding it, there would have been plenty of calls over the past 2 YEARS to get this broken stuff fixed once and for all. Lots of people standing around on these 2 year old threads scratching their ass, but nothing is ever coming out of it to fix it.

I don't have a grievance that Open Rails does calculations differently that breaks MSTS material. But when they do, Open Rails FIXES TO THE NOW-BROKEN MATERIAL NEED TO BE ISSUED. And in 99% of the cases, that should be the domain of the original route author or the signal supplier.

[ftldave]

And in 99% of the cases, that should be the domain of the original route author or the signal supplier.

A most eloquent rephrasing of the shorter, more direct, and stock "This isn't an Open Rails problem" reply.

[geepster775]

On the contrary, it IS an Open Rails problem. But if Open Rails does signal processing better than MSTS, then we need to accept it and get a fix.

Or as Shawn says, maybe its "update time" to re-signal the route with newer signals that have proper Open Rails-only scripts. But I can assure you any updates won't be distributed through this site, what with its stench of death. I get a whiff of that stench of death every day when someone says "I can't get MSTS to install on my Win 10".

Now back to our regular hoarding programming.....

[klsc85]

Are we talking about dark signals? If so, I found the fix long ago. The OR log file shows this problem:

Warning: Skipped extra SignalAspect in C:\1MSTS\ROUTES\Norfolk Southern - Clinch Valley\sigcfg.dat:line 548


Warning: Skipped extra SignalAspect in C:\1MSTS\ROUTES\Norfolk Southern - Clinch Valley\sigcfg.dat:line 625

Using notepad to find the offending lines, I found the error:

SignalAspects ( 3
SignalAspect ( STOP_AND_PROCEED "Red" SpeedMPH ( 15 ) )
SignalAspect ( APPROACH_1 "Yellow" SpeedMPH ( 30 ) )
SignalAspect ( APPROACH_2 "Yellow" SpeedMPH ( 45 ) )
SignalAspect ( CLEAR_2 "Green" )

SignalAspects ( 3 needs to be changed to ( 4 on both lines. It works on all three routes. Maybe this is the fix you're looking for.

Uncle E

[geepster775]

Here is an explanation that I was given on how MSTS and Open Rails treat signals differently.

------------ ---------- --

"Frame 0 (zero) is the correct way to address the first animation frame (pose) in a shape node. But MSTS will assume "1" is the first frame if you do not ever address a frame #0. And that's the problem with a lot of semaphores and switchstands: they're coded for "frame 1" being the first frame, which MSTS silently forgives, but which Open Rails does not. Since most switchstands only use two frames of animation, the switchstand appearance becomes reversed in Open Rails, since what MSTS assumed was the first frame (#1) is assumed to be the second frame by Open Rails. Frames virtually repeat in both directions, so for Open Rails, when it sees frame #2 (which is actually a third frame, but which the shape may not have) it wraps back around and assumes frame #0—the true first frame. When I started doing signal animation, it took me a while to figure out this inconsistency because it didn't make sense seeing both codings working the same way. But I finally figured out what MSTS was thinking."

------------ ---------- --

So, its not just the dark signals, but lots of other signal indications appear to be "one off" in Open Rails compared to the maximum indications possible under MSTS.

The Orin Line seems to be the very first route I ever recall downloading that came with Jovet signals. I don't recall any before that. So I can pretty much understand if things were scripted a bit differently at the time. In today's Jovet scripts, these Open Rails differences are factored in. No clue as to how Hank does things.





On the East River route, heading from Walton to Bluefield. Signals at Walton. In MSTS, I get a red over 'green'. (diverging clear)





In ORTS, the best I get is red over flashing yellow (diverging approach)






Dark signal at Cowan, just emerging from the tunnel, I am lined for the straight route







At Belspring, at the other end of the Cowan siding, you must diverge over to the other track. In MSTS, I get a green





In Open Rails, the best indication is flashing yellow




All of my ORTS indications seem to be one step degraded down from MSTS max when using the original sigscripts.