TANE World Origin Lat and Long reset when exit surveyor

The good news is that the lat/long problem has been resolved in TANE SP3 HF1 (beta) - build 98700.

I have just completed patching TANE SP3 from build 94916 to build 98700 and I repeated the test as described above. On reloading the route the world origin values I had set were retained.

TANE SP4 105766 broke it again. Manually entered coordinates and altitude are not accepted. Clicking reset produces:
world-origin

{
latitude 48,51,1
longitude 90,30,-1
altitude 1008
}

Save, Exit, re-enter surveyor and click reset again and we get:

world-origin
{
latitude 48,51,1
longitude 114,30,1
altitude 1008
}

>:B~[
 
It is working fine for me in TANE SP4. If I change the lat/long/alt and click the tick icon (not reset) then those new values are saved. After I exit and reload the new lat/long/alt values appear exactly as I entered them.

Reset always restores the original or previous settings (not sure which).

EDIT: I am editing, saving and reloading the session. Maybe that is the issue?
 
TANE SP4 105766 broke it again. Manually entered coordinates and altitude are not accepted. Clicking reset produces:
world-origin

{
latitude 48,51,1
longitude 90,30,-1
altitude 1008
}

Save, Exit, re-enter surveyor and click reset again and we get:

world-origin
{
latitude 48,51,1
longitude 114,30,1
altitude 1008
}

>:B~[

The Trainz coordinate values must be put in with correct value type
Degrees and decimal minutes (DMM)

When you Submit Edits on your config file, it performs some math on those numbers. Your second number needs to have a decimal place and a number after it so it will compile correctly. I have tried this on both TANE and TRS19, and it does work correctly, as well as retaining any altitude, aka elevation. Here is a before and after on one of my TANE Routes. Notice how it extended the precision of the decimal number, example is for Denver Colorado.

Elevation TANE 01.PNG


Elevation TANE 03.PNG
 
Please excuse me if I am wrong, but would not creating a region dependency for a layout be much simpler than struggling with trying to enter world origin details into either the route or session. I've done this with my personal Norfolk (Uk) layouts and it works without any problems.
 
Please excuse me if I am wrong, but would not creating a region dependency for a layout be much simpler than struggling with trying to enter world origin details into either the route or session. I've done this with my personal Norfolk (Uk) layouts and it works without any problems.

Does that fix the height? I just tried this way, by editing the config.txt file, and I was able to adjust the height down on a route I wanted to merge into another. Yay! Now I have to prep the route for merging by changing textures and other things to match, but that's the easy stuff.
 
The config data I posted above was cut-and-pasted from my test route config.txt file. That is what Trainz generated.

Today after rechecking my data with Google Earth I opened the route Fond du Lac Branch with my alternate installation of 105766, opened the config.txt file in CM and found:

world-origin
{ latitude 43,46.710999,1
longitude 88,27.382,-1
altitude 228.179993
}

which is all correct.

After reverting to original, opened the route in surveyor, located the WO and opened it for edit.

TANE SP4 105766 displays a truncated lat and lon with only two decimal places in the minutes. As displayed they are approximately correct. (2009 and 12 both display 3 decimal places. This route is ported over from 09 to 12 to T:ANE.)

The actual elevation at Fond du Lac Junction is ~231.65 meters. The displayed altitude is "0", that is, null, nothing, nada. It should be around 228.2, because the WO is buried 2 meters out of sight. and in fact if we go to the adjacent junction and take the vertex height we find it reads "228.18".

Attempting to edit the altitude produces garbage. The decimal point is not accepted; any numbers entered are changed to "1000" on tabbing or clicking out of the box.
Because this happens with both my beta and my original updated installations of 105766, I claim it is broken in this regard. I've put in a trouble ticket on it.

:B~[
 
The config data I posted above was cut-and-pasted from my test route config.txt file. That is what Trainz generated.[

It generated an error, and defaulted to some set of coordinates, because the inputted data was not in a valid format 51 and 51.000001, I believe Trainz looks at 51 and sees an integer, and sees 51.000001 as a double, when it tries to do double math to the integer, it errors.

Today after rechecking my data with Google Earth I opened the route Fond du Lac Branch with my alternate installation of 105766, opened the config.txt file in CM and found:

world-origin
{ latitude 43,46.710999,1
longitude 88,27.382,-1
altitude 228.179993
}

which is all correct. [

You should only enter these 3 settings by editing the config.txt file if you are including Altitude, because as you say;

Attempting to edit the altitude produces garbage... , I claim it is broken in this regard. I've put in a trouble ticket on it.

:B~[

Thanks for putting in a trouble ticket!
 
It is working fine for me in TANE SP4. If I change the lat/long/alt and click the tick icon (not reset) then those new values are saved. After I exit and reload the new lat/long/alt values appear exactly as I entered them.

Reset always restores the original or previous settings (not sure which).

EDIT: I am editing, saving and reloading the session. Maybe that is the issue?

Peter, what build are you working in? In 105766 I find it makes no difference whether I change the settings in the session (i.e. use the '?' button) or the Menu>Environment>WO. In either case it requires re-saving the route. I am doing my work in the default session but when I look at it in one of the other sessions it all looks and works the same.

And the WO panel still doesn't work right. Can't tab from box to box and the altitude box produces basura.

I don't have any other versions of T:ANE available but I get the same results in the beta install which was updated incrementally and the "original" install, which was updated with the public release.

:B~\
 
My TANE build is 105776.

How very curious!

Got a reply back from the trouble desk. Don't bother with the links, they both come back to this thread(!)(my emphasis):


Hi rhkluckhohn - Thanks for reporting this to QA. We find the post here to be correct and working in both TANE & TRS19.
The issue we see is in TANE where altitude is not being saved.
To work-around this we could manually edit the route config.txt, input the correct altitude, save changes and submit.
The dialog will continue to report "0", but the value persists in the config.txt and the Snow Altitude (enviroment > environment tab) will respond accordingly
A region asset may also be used to define altitude.


A task has been submitted although there are no planned updates to TANE at this time.
 
Back
Top