Correcting the Orphan Blue Pole / Matrix3x3 Errors

compiled by Yuri Sos and Allan Lownsborough
with valuable contributions by Charlie Leveritt

Overview

Blue Poles

You see them in Route Editor - these pesky "blue poles" that seem to be out in the landscape on their own. You can't select them, you can't delete them - these are the so-called "orphan blue poles". The cause is unknown as they appear randomly even when carefully saving practices are employed in Route Editor.

You may not even see the "blue poles", but have arrived at this tutorial after finding lots of "matrix3x3" errors in your Ts_Utils Integrity Check Report. No matter, the repair principles are similar.

The easiest way to get rid of these is to revert to an earlier backup, but so often these blue poles have gone un-noticed through many back-ups and changes.

Nevertheless, if you aren't backing up your route on a regular basis, here's the link to the Route_Riter tutorial on back-ups: click here for a tutorial on using Route_Riter to back up your files.

Matrix3x3 errors (?) - are these really errors?

Carl-Heinz Rive, author of TsUtils says "I don't know for sure if 'matrix3x3' is really an error. Therefore this message (reporting the presence of a matrix3x3 parameter in TsUtils ichk report) is marked with a 'question mark'.

Normally, 'matrix3x3' should be NO error, but forum-discussion shows that there may be various problems if 'matrix3x3' is used within a world-object-definition instead of 'qdirection' . Therefore this message is logged.

'matrix3x3' and 'qdirection' (which must be used 'either..or') define the position of an object within space relative to north heading.

'qdirection' is (mathematically) a 'quaternion' which defines a rotation from a default heading to the current heading of the object (but also 'bank' and 'slope': 3 dimensions). More information about this can be read in the documentation that accompanies Michael Vone's 'Object-Rotator'.

'matrix3x3' is another way to define the position of an object within space. The exact meaning of the values within the definition is not known to me. However, as far as I know you can define an object unambigous within space using 3 coordinates (each 3 dimensions) and together with the 'position'-value of an object-definition, there are 4 coordinates available."

As Carl-Heinz says, there's some debate as to whether these matrix3x3 parameters are even errors as they appear in the .W files in both Static objects as well as TrackObj (both road and rail) statements within .W files (see a snippet of ichk report above).

Tutorial Authors' opinion: The presence of the orphan blue pole indicates that it is part of the track database: the track piece that's specified within the TrackObj that contains a matrix3x3 parameter is never visible, nor is it even on the normal track alignment. Thus we believe they should be corrected or deleted as soon as they are found.

However, Matrix3x3 statements that ARE NOT part of a TrackObj representing an orphan blue pole (ie the road or track piece appears to be placed correctly) should be left alone (an example of this follows shortly).

 

Repair Technique

You generally see these blue poles in the Route Editor (example as in top image), but sometimes, the only time you see them is when you are in the Activity Editor and there is a track node way off the normal tracks: see below. Note that if you highlight the node (arrow #1), you can record the latitude and longitude (arrow #2).

Now open the Route Editor, enter the Latitude and Longitude into the "Camera" window (arrow #1 below) and press "Jump". You will arrive at the blue pole. (arrow #2 below). If you can't see it, check that you are at the correct Lat/Long - sometimes the "Jump" goes astray; move the camera around; you may need to press "W" to go into Wireframe mode as the blue pole may be underground.

The purpose of finding the pole is so that you can establish in which .W file the error is located. The "w" filename is made up of tile X + tile Z so in the example above. you would look for "w+000864+010356.w".

Open the appropriate w+000864+010356.w file (arrow #1 below) in ConTEXT or your favourite Unicode-aware Text Editor and search for "Matrix" (arrow #2 below):

Let's look at what we've found: the blue pole IS a track piece (in this case, a zero degree point/switch found in Xtracks); the Position and Matrix3x3 parameters contain odd numbering conventions (using e-nnn). This is the result when a number larger that the space allocated for it is displayed.

What we're going to do now is turn this into "proper" track section. You'll notice that the TrackObj immediately below the one containing the Matrix parameter has a normal looking Position and QDirection: we're going to copy the Position and QDirection line from this TrackObj and paste them into the faulty one above, overwriting the faulty Position and Matrix3x3 lines:

Then change the elevation parameter in the Position line and increment it by a few metres (the elevation or "y" co-ordinate is the second number in the Position line) so that the line looks like this:

Record Tile x/Tile y/ x-coordinate (-591) y-coordinate (-590). Save the .w file.

Open Route Editor.

In the Camera Window, enter the x-coordinate, y-coordinate, tile-x and Tile-y parameters and press "Jump".

Here we are: the errant track piece is now suspended 4 metres above the rest of the track.

You can highlight the track piece......

....select it and delete it.

Now point your camera at the sky and click to make sure you're not selecting anything and Save the Route changes. In this way, the track database will be updated without the need for a track database rebuild (which is usually undesirable once the route has interactives such as signals installed).

 

Leaving Well Enough Alone

As we said in the introduction, you shouldn't assume that all matrix3x3 statements are errors.

Here's an example of a matrix3x3 statement in a TrackObj that is perfectly placed and the road database is perfectly functional.

The road piece in question is a 50m 2-lane road placed across the bridge in the centre of this screenshot. The RDB lines above the road are in perfect position and the absence of extra/orphan blue poles should alert you that there is no problem here.The .W file shows that the TrackObj specification contains a matrix3x3 statement.

You can select and even delete this piece of road (see below):

Now let's change the matrix3x3 statement to a Qdirection statement. Apart from the incorrect position (which has never been a problem before as demonstrated above), you cannot select nor delete this piece.........

....... nor the pieces on either side of where this road piece was originally located (even though those adjacent pieces have QDirection statements, not Matrix3x3 statements.

In other words the matrix3x3 statement seems to have some other link to the item in the RDB.

 

End-End-Vector Errors

Another error you're likely to run into is the "end-end vector" error, click here for information on solving this problem.