Zero Degree Node Removal for OR?

[R. Steele]

i

My experience has been that OR is aware of the position of each train on a node-by-node basis. The presence of zero-degree loops foreshortens the distance between useable nodes and can confuse the dispatcher as to if it is appropriate to clear a track for movement. This is true even if all of the paths follow the same exact route through the zero-degree loops, and even if "location-linked passing path processing" is activated. OR sees turnouts, therefore it sees the possibility of diverging tracks, therefore it diligently tries to route the traffic accordingly. The dispatcher has an important job to do -- Don't blame the dispatcher!

Your experience in on point, however, I don't understand the reference to "blaming the dispatcher"?? ( perhaps I missed the humor? ) IMO ( and others opinion, so I've read ) there is a problem being introduced into OR AI traffic movement caused by the zero point node hacks.

There has been some brilliant coding in OR to overcome other deficiencies caused by legacy considerations, why not try to fix this? I am suggesting that someone with working knowledge of the OR code and the zero point node data point in the msts files may be able to code a solution.

Of course, in the end, we may have to live with this problem caused by legacy files and hacks.

[slipperman]

Hi Fellas,
Thanks for your valiant attempts to explain these zero nodes to me!

@Gerry : Thanks for the reference to Yuri's tutorial
I now understand how they are created. Is the problem of removing them because nodes are numbered sequentially and any missing ones will cause problems with signalling, etc.?
As I understand MSTS, it is not permitted to join two points toe to toe but to add a short straight track piece between them. As these nodes seem to be created toe to toe, isn't that a way to uniquely identify them ?

Cheers,
Ged

[dcarleton]

I don't understand the reference to "blaming the dispatcher"??

In the real-life world, train and engine crews are notorious for blaming the dispatcher!

[dcarleton]

As these nodes seem to be created toe to toe, isn't that a way to uniquely identify them?

They're not always created that way. Some routes have the two nodes separated by short straight track pieces, an actual theoretically functioning but useless passing siding (crossing loop) perhaps three to five meters long.

[R. Steele]

In the real-life world, train and engine crews are notorious for blaming the dispatcher!

Ahhh....enlightenment...thanks for that ... my ignorance can be explained by this: "Forever, ridin' drag in railroad knowledge" always playing catchup...but learning everyday.

[R. Steele]

They're not always created that way. Some routes have the two nodes separated by short straight track pieces, an actual theoretically functioning but useless passing siding (crossing loop) perhaps three to five meters long.

So there may be more than one data identifier associated with the zero node points. It would appear that a crucial bit of knowledge would be the data difference ( hopefully there is a difference, Eric has expressed that there is nothing unique about zero point nodes ... I have high regard for his expertise on such matters ) between a normally used switch and the zero point node switches.

[ebnertra000]

A couple things here:

The old 0° node switches are not placed 'toe-to-toe', in that the red-pole ends do not face eachother (red poles facing eachother is not allowed). The 0° switch, which I used for this many years ago, is actually designed such that both blue-pole ends will connect with the blue-pole ends on the opposing switch, much like puzzle pieces.

That said, 0° switches are not solely used for this purpose. I have had to use them for yard switches in tight quarters. I even use them as mock derails, so simply ignoring 0° switches is a rather crude solution to this issue, and will introduce issues in those cases where 0° switches are used in places other than the now-infamous 0° node.

There is no easy solution to this, and the only solution guaranteed to work is to remove them. Welcome to the self-inflicted hell that is route construction. We hope you'll enjoy your stay...

[eric]

Essentially the "fix" would be consolidating two long nodes into one, and removing all the interactives on the two long nodes being consolidated.

How difficult it is depends entirely on how many interactives exist. No signals, crossings, etc? It's a two minute job. 20 miles of platforms, stations, level crossings, etc? It could be hours...

Believe me, if I thought it could easily be done programmatic, I'd be advocating for a TSRE fix or writing a routine for WFH.

And yes, the 0* switches are quite useful. I have several in the IRM route streetcar line as there are no 60r turnouts in Scalerail.

[slipperman]

Hi Chaps,
Thanks, again for the enlightenment
I thought it worth asking questions, but now I'll retreat back into my little hut and keep quiet, on this subject, at least!

Cheers,
Ged

[niknak]

Hi Chaps,
Thanks, again for the enlightenment
I thought it worth asking questions, but now I'll retreat back into my little hut and keep quiet, on this subject, at least!

Cheers,
Ged

Watch out for zero nodes on the way Ged.....

[R. Steele]

Essentially the "fix" would be consolidating two long nodes into one, and removing all the interactives on the two long nodes being consolidated.

How difficult it is depends entirely on how many interactives exist. No signals, crossings, etc? It's a two minute job. 20 miles of platforms, stations, level crossings, etc? It could be hours...

Believe me, if I thought it could easily be done programmatic, I'd be advocating for a TSRE fix or writing a routine for WFH.

And yes, the 0* switches are quite useful. I have several in the IRM route streetcar line as there are no 60r turnouts in Scalerail.

Understand, thanks for the input...I think I'll do some more research in the early threads and try to round out my thinking on this...

Remaining thoughts & questions: This is what is bothering me, and perhaps it's because my knowledge and experience with the subject is so lacking...The zero point nodes as used in long stretches of track to counter the coding flaw in MSTS that allowed coupler forces to multiple until breaks occurred ( another one of those ingenious hacks used in MSTS - kudos to who first proposed it )...these nodes do not visually appear as actual switches...now when this same type of hack is used in a yard or the other useful places as described by Eric and Travis:
1. Do they appear as switches?
2. There has to be a different mathematical signature in the data file in each instance of "zero node" use. Because in one instance OR displays a switch where there is none, and in the useful zero node cases, OR ignores them and no invisible switch appears. Why? There should be a mathematical solution in there somewhere. Yes? No?

Ged's right, time to reflect...although - instead of a hut - I believe I may try a warm -- almost overflowing bath - ease myself in until the water gently laps over the side -- and then -- jump up and hollar EUREKA! Although, I'd probably just crack my empty head and lie there -- happily gurglin'.

Thanks all for the information and discussion.

[PerryPlatypus]

I'm going to agree with most of the party here and say that I don't think there is any easy and reliable way to code OR to be smart enough to know when to remove the zero degree nodes, because there are inevitably going to be users who have used the EXACT same zero degree track shape that is conventionally used for breaking up a long node for some other function. So inevitably that runs the risk of breaking something for someone else.

I think the solution is not get OR to ignore these nodes, but to fix whatever path processing issue OR is having when it sees them. The way it SHOULD work is that OR sees the first node, thinks "oh there is a potential siding here", then sees the second node a few meters later and says "okay, it's not long enough to pass trains" and then continues along the path until it finds a siding that is long enough.

One thing I wonder - does OR look purely at length between nodes to determine passing length, or does it look at an approximated "clear length" of a siding? The clear point is the location beyond a turnout where a train or railcar, etc. is sufficiently "in the clear" so that a train can pass on the adjacent track without clipping the side of the other train. Because even if this "siding" between two zero degree nodes has a physical length of 5-10 meters, its clear length should be ZERO meters. That alone should be enough to tell OR's dispatcher to not even consider it as a potential meeting point, even for an extremely short ENG.

[R. Steele]

Eureka Sean, interesting, very interesting point...maybe there is way...thanks for looking at this with a new viewpoint!

[ebnertra000]

0° nodes are switches, and that's how OR will see them. They're an unusual set of paired switches, but they are switches, nonetheless, whether they're used as 0° nodes or as yard switches or as mock derails. Their signature in the .tdb will be effective the same as any other normal style of switch, and that's why there's no magic bullet for getting OR to ignore them.

The only thing that could work if OR's trying to set up meets on 0° nodes is what Sean described, where OR checks the length of the 'siding' it thinks it's found and realizes "Hmm...2m? That's just a touch too short" and looks elsewhere for a meeting point. That doesn't remove the node, it just makes OR smart enough to know it can't set up a meet there

Please don't run down my street naked shouting in Greek...

[geepster775]

I wonder if the issue here is because this particular Starter route has 2 zero degree node pairs spaced roughly 4.5 miles apart on a 13 mile single track stretch. Is it the double set of zeros that is giving OR grief? Contrast that to the Conrail Indy route where (on the Marion end) there is a 14 mile single track stretch between CP 106 and CP 120 with no other (industry) switches, and there is only one zero degree set at about mile 113.5, which is roughly 7 miles on either side to the switch nodes at the Control Points. How much of the trouble here is route builder consistency and/or discipline issues? Some guy just unilaterally deciding 4 miles is too long of a distance?

Unless someone actually removes zero degree nodes (which breaks paths and requires patching of just about every activity for Scenic in existence), the easiest solution is to decrease the volume of AI traffic in troublesome activities to make standoffs less probable. Even moreso because this particular standoff is caused by a train running ahead of and in the same direction of the player that the player never catches up to. So in my mind it is completely expendable and suitable for removal from the activity. It is unfortunate that where Open Rails shines, increasing the volume of AI's on a single track, is a feature that cannot be exercised to its fullest on these historical routes with embedded MSTS accommodations.

I dislike the idea of using programmer time to yet again make obsolete route assets work, when the goal should be replacing these obsolete assets. I am grateful that payware OR-only routes are being built today without these zero nodes and other MSTS workarounds. So while the professional side is doing things right, I wish some of our freeware builders would take that cue and stop playing with themselves over this belief that routes still can be built today to successfully accommodate both platforms. Odds are diminishing daily as MSTS/OR divergence increases.