I'm experimenting with building a short route using miles, chains and yards instead of the default metres and 25m blocks with the following settings:

Code: Select all

.UnitOfLength 1609.344; 20.1168; 0.9144,
.BlockLength 0:1:0,


When viewing the route with Route Viewer, the position of the camera is still shown in metres. Would it possible to have the distance shown in the same units as those specified in Options.UnitofLength, e.g. Position: 3:50:18?

Additionally, when Options.UnitOfLength is changed from the default, which measurements are affected? Is it solely .Track options or does it affect any dimensions within .csv/.b3d .FreeObjects aswell?

All parameters in the route file which are sensitive to Options.UnitOfLength are highlighted as such in the documentation. Options.UnitOfLength only affects the route file itself, not any of the objects used.

I will include the readouts reflecting the choice of units in the next version of RouteViewer.

Further experimentation appears to show that once an alternative Options.UnitOfLength has been specified with multiple arguments, e.g. miles:chains:yards, those units and the default unit of metres are directly interchangeable.

For example, assuming Options.UnitOfLength has been set up for miles:chains:yards thus:

Code: Select all

.UnitOfLength 1609.344; 20.1168; 0.9144

then it appears that

Code: Select all

Track.RailStart 1;3.5;0;1

places a rail 3.5 metres to the right of rail(0) whereas using

Code: Select all

Track.RailStart 1;0:0:3.5;0;1

places a rail 3.5 yards to the right of rail(0).

It appears that when Options.UnitOfLength has been set for x:y:z then distances with no colons (:) are interpreted as metres and those with them as x:y:z.

EDIT: Additional thought: if it is possible (as it appears to be) to simultaneously use x:y:z and metres in the same route file, Route Viewer should allow you the option of displaying all values in default metres or the .UnitOfLength option x:y:z (or whatever).

You are right, unfortunately. This is a long standing bug that was not detected before, likely because Options.UnitOfLength is not used extensively.

Issue:
When using non-colon track positions, the specified unit of length is not applied at all, but reverts to meters.

Undefined behavior:
I just realize by the way that the behavior for using less arguments in a track position than are defined by Options.UnitOfLength is currently unspecified. Therefore, we should define it.

Should 2 = 0:2 = 0:0:2 (skips initial parameters), or
should 2 = 2:0 = 2:0:0 (skips trailing parameters) ?

The former is more useful when working with offsets (e.g. free objects), while the latter is more useful for track positions.

Interestingly, I've been finding that the way it treats non-colon units in metres is actually rather useful! It does allow you some versatility in placement. The option to place larger distances by x:y:z and small object placements by m can be rather helpful. Is there any reason why the dual-unit system shouldn't be allowed to persist?

Yes, if you only specifiy one unit, you would want that to work, too.

I just think that there may be some use in allowing the use of the default metres alongside a customised .UnitOfLength. I have certainly found much use for x:y:z and just m side by side in the same route.

Does anyone else have any thoughts on this, viz. the ability to use miles:chains:yards and metres in the same route file by specifying distances as x:y:z or, if without colons, interpreted as metres?

EDIT: to be clearer, as all object files have their dimensions explicitly in metres, the ability to place them with metres in the route file is helpful, over-and-above the usefulness of the mi:ch:yd system for overall distances. Thoughts, people?

I have come to the conclusion that there are only three meaningful possibilities when using fewer parameters in a:b:c as specified via Options.UnitOfLength:

a) Make them left-associative (a:b),
b) make them right-associative (b:c),
c) forbid the case entirely.

As the behavior is currently unspecified, I have decided for now on case b). Assuming that multiple units are given and ordered from most-significant (e.g. miles) to least significant unit (e.g. yards), then dropping the most-significant unit seems more practical because you could just enter the least-significant unit without any of the others when working on small scale, e.g. in Track.FreeObj.

If you want meters still, you could, via solution b), define miles:chains:yards:meters and thus work with four units. For specifying track positions, you would need to give the additional fourth parameter, and when you solely want to use meters, you don't need to give anything else but meters.

An excellent all-round solution, Michelle: thank you.