.
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 33

Thread: TANE World Origin Lat and Long reset when exit surveyor

  1. #16
    Join Date
    Nov 2006
    Location
    Australia, NSW, Sydney
    Posts
    6,908
    Blog Entries
    3
     

    Default

    Now, after performing the same tests with world origin and date settings in both TANE (build 94916) and TRS19 (build 98592), I can report the following conclusions:-

    Tests (in both TANE and TRS19):

    1. Created a route and set the world origin. I did not alter the date. Saved the route.
    2. Created two different sessions based on that route. Each session had a different date (month and day). This data was saved in the session as evidenced by the fact that after changing the date I selected Save from the main menu and only the option to overwrite the existing session or to create a new session appeared.
    3. Completely exited TANE/TRS19 to the Windows desktop


    TRS19:

    1. Loading just the route showed today's date. The world origin coordinates were as I had set them.
    2. Loading each session showed the correct date set for that session. The world origin coordinates were as I had set them.


    TANE:

    1. Loading just the route showed today's date. All the world origin coordinates had been changed to 0. Interestingly, the East/West and North/South settings were still correct.
    2. Loading each session showed the correct date set for that session. All the world origin coordinates had been changed to 0. Again, the East/West and North/South settings were still correct.
    Last edited by pware; January 22nd, 2019 at 03:23 AM.
    TRS19 Platinum 105100 - TRS19 SP1 (standard) 105096 - TANE SP4 105766

  2. #17
    Join Date
    Nov 2006
    Location
    Australia, NSW, Sydney
    Posts
    6,908
    Blog Entries
    3
     

    Default

    Quote Originally Posted by Christopher824 View Post
    The question is how do I remove a time,date, xyz coordinate once its set, to a user device aware 'GPS' coordinate? Like, hey here I am let's start 'here'. Thank you
    The answer, as far as I can work out, is that you cannot have the xyz coordinates automatically "picked up" from some GPS device attached to the computer. The Trainz Native Interface does not, as far as I know, handle GPS devices. As for the date I have found that once a date has been set it will always be set (but can be changed to another date). In my test above I did not set a date in the route so it, from past experience, will always default to the current (i.e. todays date). If you set a date in the route then that will become permanent in the route although session dates will overrule it.

    Opening and reading the config.txt files for the sessions and route I created for the test did not reveal any date or world origin data.
    Last edited by pware; January 22nd, 2019 at 03:36 AM. Reason: clarification
    TRS19 Platinum 105100 - TRS19 SP1 (standard) 105096 - TANE SP4 105766

  3. #18
    Join Date
    Nov 2006
    Location
    United States of America, California, Port Hueneme
    Posts
    1,936
     

    Default

    In my case, (TANE) I don't have to save the session to get the "0's". Click on the W.O. asset, and a menu opens with some coordinates that according to Wiki are from Berlin (?). So, I change these to my coordinates manually. They are taken from Google Earth. Then I click the tick at the bottom to accept and the menu goes away. When you open it again everything is back to "0". Click on reset and the Berlin coordinates are restored. If this "feature" has no effect on time of sunrise/sunset, then why bother? Leave it to whatever it decides to be. Of course it would be more interesting if changing the latitude, and given the month of the year, sunrise and s.set would change to more realistic times. But the 6 AM and 6PM are unchangeable, for good or bad.

  4. #19
    Join Date
    Dec 2011
    Location
    USA, Florida and Illinois
    Posts
    811
    Blog Entries
    1
     

    Default

    Quote Originally Posted by pware View Post
    The answer, as far as I can work out, is that you cannot have the xyz coordinates automatically "picked up" from some GPS device attached to the computer. The Trainz Native Interface does not, as far as I know, handle GPS devices.
    I figured as much, could be a cool asset script to build in the future for location aware systems, if there is a way to set that from a script... someday.

    Quote Originally Posted by pware View Post
    As for the date I have found that once a date has been set it will always be set (but can be changed to another date). In my test above I did not set a date in the route so it, from past experience, will always default to the current (i.e. todays date). If you set a date in the route then that will become permanent in the route although session dates will overrule it.
    This is the one that drives me crazy. If you can set it, it must set it somewhere. I have a route that when I choose to QuickDrive it fro Surveyor, it asks me to save the Route and Session, then opens in Driver with the environment set to today's date. That is what I like. One Route that I made, I made the mistake of changing the date, always opens up in QuickDrive with at old date (not today) unless I change it before I load the QuickDrive. So all the seasonal stuff is locked into that date. Drives Me Crazy !

    Another thing I see is that the time is always 10:00am in QucikDrive when I launch it on my Routes
    If it's not broke, don't fix it.


  5. #20
    Join Date
    Nov 2006
    Location
    Australia, NSW, Sydney
    Posts
    6,908
    Blog Entries
    3
     

    Default

    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.
    TRS19 Platinum 105100 - TRS19 SP1 (standard) 105096 - TANE SP4 105766

  6. #21
    Join Date
    Nov 2006
    Location
    Australia, NSW, Sydney
    Posts
    6,908
    Blog Entries
    3
     

    Default

    Quote Originally Posted by Christopher824 View Post
    Another thing I see is that the time is always 10:00am in QucikDrive when I launch it on my Routes
    The Time and Rate Rule and the Startup Options Rule are used to set the time in a session. I rarely use QuickDrive except when testing.
    TRS19 Platinum 105100 - TRS19 SP1 (standard) 105096 - TANE SP4 105766

  7. #22
    Join Date
    Nov 2007
    Location
    Seattle, WA, United States of America
    Posts
    635
    Blog Entries
    60
     

    Default

    Quote Originally Posted by pware View Post
    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~[

  8. #23
    Join Date
    Nov 2006
    Location
    Australia, NSW, Sydney
    Posts
    6,908
    Blog Entries
    3
     

    Default

    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?
    TRS19 Platinum 105100 - TRS19 SP1 (standard) 105096 - TANE SP4 105766

  9. #24
    Join Date
    Dec 2011
    Location
    USA, Florida and Illinois
    Posts
    811
    Blog Entries
    1
     

    Default

    Quote Originally Posted by RHKluckhohn View Post
    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.



    If it's not broke, don't fix it.


  10. #25
    Join Date
    Jun 2016
    Location
    New Zealand
    Posts
    3,259
     

    Default

    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.
    Narcolepsy is not napping.



  11. #26
    Join Date
    Nov 2006
    Location
    United States of America, Massachusetts, Haverhill
    Posts
    27,665
     

    Default

    Quote Originally Posted by KotangaGirl View Post
    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.
    John
    Trainz User Since: 12-2003
    Trainz User ID: 124863
    T:ANE Build: 94829
    TRS2019/Trainz-PLUS: 106618

  12. #27
    Join Date
    Jun 2016
    Location
    New Zealand
    Posts
    3,259
     

    Default

    Yes a region also contains an altitude setting John.
    Narcolepsy is not napping.



  13. #28
    Join Date
    Nov 2006
    Location
    Australia, NSW, Sydney
    Posts
    6,908
    Blog Entries
    3
     

    Default

    The Trainz Wiki has a page on region assets at http://online.ts2009.com/mediaWiki/i...a_Region_Asset but it is important to remember that the altitude is relative to the original height of the starting baseboard. The Wiki explains.
    TRS19 Platinum 105100 - TRS19 SP1 (standard) 105096 - TANE SP4 105766

  14. #29
    Join Date
    Nov 2007
    Location
    Seattle, WA, United States of America
    Posts
    635
    Blog Entries
    60
     

    Default

    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~[

  15. #30
    Join Date
    Dec 2011
    Location
    USA, Florida and Illinois
    Posts
    811
    Blog Entries
    1
     

    Default

    Quote Originally Posted by RHKluckhohn View Post
    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.

    Quote Originally Posted by RHKluckhohn View Post
    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;

    Quote Originally Posted by RHKluckhohn View Post
    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!
    If it's not broke, don't fix it.


Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •