[mauried]

Does OR understand the node point in the middle of a diamond crossing?
Ive had a couple of crashes on diamond crossings as OR happily signals 2 trains across the crossing at the same time.
Looking at a diamond crossing in the Dispatcher window doesnt show any node point
at the middle of the crossing ,which means that OR doesnt know that the tracks actually cross each other.
Looking at the same crossing in the MSTS AE, you can clearly see the node point.
Thanks.

[roeter]

Diamond crossings are processed as they should if the details are correct.
Crossings in MSTS are not set up as nodes, but through 'crossing items' in the .tdb. These crossing items come in pairs, with the two items defining the track sections between the nodes which make up the crossing.
Sadly, though, many of these crossing items are not defined correctly. Sometimes one of the items of the pair is missing, but the most frequent error is that the two items in the pair do not match, and are linked to incorrect nodes. Check you logfile for reports on incorrect crossing items : there are only few routes which do not have such reports.

Regards,
Rob Roeterdink

[mauried]

Thanks.
Ive had problems previously with the MSTS RE with items called crossing markers which sometimes appear when a diamond crossing
is deleted and replaced with another type.
Ill try some differant types of diamond crossings and see what happens.

[Buttercup]

Is this related?

http://msts.steam4me.../diamond_X.html

http://msts.steam4me...make_xover.html

[disc]

What's happen if the same crossing signals work in activity mode, but not in timetable mode (green signal when a train train crossing the path ahead)?

[roeter]

 disc, on 24 November 2014 - 04:06 PM, said:

What's happen if the same crossing signals work in activity mode, but not in timetable mode (green signal when a train train crossing the path ahead)?

Something strange. The signalling logic does not depend on the running mode - it's just the train organization which differs.
Perhaps there is a difference in the train paths which causes the different reaction. The route I use most often has plenty of crossings, in particular crossings which are part of single or double slips, and I have not seen such anomalies except on locations where the crossing items were not set correctly.

Quote

Is this related?

http://msts.steam4me.../diamond_X.html

http://msts.steam4me...make_xover.html

Not really. That explains how you can create a crossing on a location where tracks just overlay one another.
But MSTS itself does have actual crossings, and various track systems have added a lot more, including crossings points in single and double slips. The problem occurs with these 'real' crossings.
An example of such an error is where one crossing item does not link the two nodes accross a single slip, but follows the turnout of the slip. The other item may be correct, but in such a situation only three points are referenced in the crossing items, making it impossible to properly locate it.

Regards,
Rob Roeterdink

[Genma Saotome]

It might help knowing the name of the shape file in question.

[mauried]

The crossing that was causing the problem is a A1tXover6db.
Its used with A1tPnt3db switches.
Ive since re arranged the track to avoid the use of the crossing, and all works, so does look like the crossing track piece
has some kind of problem.

[vince]

These X-Tracks add-on sections do indeed have the proper node built into them. But a problem arises if a Route Editor Track Database rebuild is executed because the rebuild routing neatly removes the crossover TrackNode!

The only way to recover the 'lost' TrackNode is in the Route Editor to visit and Select, De-select and immediately save the track section. This will re-write the TrackNode information into the Track Database and the Track Item Table (*.tit) file.

I have many crossovers in my LIRR build that are missing the crossover TrackNode due to the times that I had to rebuild the databases.

Not a problem as following the final TDB rebuild I will run before I begin installing interactives I will visit every crossover location and do the select/de-select/save routine to restore the TrackNodes.

This is one of the (many) reasons that it is not a good idea to routinely run the Track Database rebuild routine. It WILL trash the crossover nodes!

Speculating now; I believe it's something to do with the minimum distances the MSTS rebuild routine can calculate between nodes and endpoints of the crossover sections. Less that this minimum distance (I have no idea what this distance might be) and the rebuilder misses the TrackNode.

Regards,

vince