• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

P3D v4 64 bit terrain following

The -3.28 readout is the elevation at 0 lat, 0 lon.
It certainly looks like the gauge is not loading if you're getting zeros in TF_pSurface and TF_PDK.
Sorry I'm out of town right now so don't have access to my dev computer for a few days.
The main gauge element is RGB000, but if you're not seeing the display element then the gauge is probably not loading.
Maybe a run time library issue, but I'll have to check when I get home whether it is the 2012 or 2015 libraries.
 
Just for sake of testing , place the gauge in both your panel folder and gauges folder and see...Now I remmber to have done both. -3.28 I see indeed only with coordinates at 0.
1545966504658.png


1545966268354.png
 
rpmc said:
Changing L:Var units to number doesn't solve my issue. Note that TF_SimConnect, FSSimIsPaused, TF_pSurface and TF_PDK always return zero regardless of Pause state.
Bob
Click to expand...
Do you have the updated version of the gauge? just asking...Anycase it is the same link but Doug updated it with a few more Lvars and the FSSimIsPaused corrected and a few turned into booleans instead.
 
I have the second version of the dll... size is 124KB. The initial posting contained a dll size 123KB.

Copying tf_link-x64.dll into the Gauges folder gets it to load!! I don't understand why a normal path nomenclature in panel.cfg did not do the trick.

However, the elevations don't make sense to me. Try 19.500183 lat, -155.736684 lon. It's on the flank of the Mauna Loa volcano. According to Google maps, elevation is 7000', but TFPointElevation_0 returns 2648.2. That's not even a meters/feet conversion issue. Still playing with this so that I understand it ...

Bob

By the way, including TFPointAlt_X, or not, seems to make no difference
 
Got the same, good catch:scratchch...
But the gauge is a very early attempt so lets see what he comes with after debugging.
 
The PDK function actually wants lat and lon in radians. I've been multiplying the input values by PI/180 to get the values to pass to the function.
I did notice small variations from what might be expected. For instance the value of -3 at lat 0 lon 0. That p;oint is actually in the Atlantic Ocean, off the African coast. It should be returning zero.
Given that, the values I got at CYOW, CYEG, and KDEN were quite reasonable.
Just curious - how close was your aircraft to Mauna Loa? When I was trying the locations I did, the aircraft was fairly close to them - you can see the routine I used above.
 
ddawson said:
The PDK function actually wants lat and lon in radians. I've been multiplying the input values by PI/180 to get the values to pass to the function.
Click to expand...
So Doug, just for me to understand we should be passing radians instead of degrees to the PDK functions? i.e:
Code: 
    (A:PLANE LATITUDE, radians) (>L:TFPointLat_1, number)
    (A:PLANE LONGITUDE, radians) (>L:TFPointLon_1, number)

In your example I haven't spot the conversion:
Code: 
<Update>

(A:plane Latitude, degrees) (>L:TFPointLat_0)
(A:plane Latitude, degrees) 1 + (>L:TFPointLat_1, number)
(A:plane Latitude, degrees) 2 + (>L:TFPointLat_2, number)
(A:plane Latitude, degrees) 3 + (>L:TFPointLat_3, number)
(A:plane Latitude, degrees) 4 + (>L:TFPointLat_4, number)
(A:plane Longitude, degrees) (>L:TFPointLon_0)

(A:plane Longitude, degrees) 1 + (>L:TFPointLon_1, number)
(A:plane Longitude, degrees) 2 + (>L:TFPointLon_2, number)
(A:plane Longitude, degrees) 3 + (>L:TFPointLon_3, number)
(A:plane Longitude, degrees) 4 + (>L:TFPointLon_4, number)

(A:plane Altitude, feet) (>L:TFPointAlt_0, number)
(A:plane Altitude, feet) (>L:TFPointAlt_1, number)
(A:plane Altitude, feet) (>L:TFPointAlt_2, number)
(A:plane Altitude, feet) (>L:TFPointAlt_3, number)
(A:plane Altitude, feet) (>L:TFPointAlt_4, number)

</Update>

Just curious - how close was your aircraft to Mauna Loa? When I was trying the locations I did, the aircraft was fairly close to them - you can see the routine I used above.
Click to expand...
I did the test from 17,000 feet, but Bob mentioned another interesting observation:

By the way, including TFPointAlt_X, or not, seems to make no difference
Click to expand...
So surely there are still stuff to sort out:scratchch, when I'm back home I will do a couple of more test on lower altitudes..
 
The TF_Link gauge does the conversion from degrees to radians. You should be using values in degrees.
I'm wondering if the settings in the Sim's UI regarding preferences for lat and lon matter here If so, I can make the gauge read the settings from the Prepar3d.cfg file.
 
rpmc said:
I have the second version of the dll... size is 124KB. The initial posting contained a dll size 123KB.
Copying tf_link-x64.dll into the Gauges folder gets it to load!! I don't understand why a normal path nomenclature in panel.cfg did not do the trick.
However, the elevations don't make sense to me. Try 19.500183 lat, -155.736684 lon. It's on the flank of the Mauna Loa volcano. According to Google maps, elevation is 7000', but TFPointElevation_0 returns 2648.2. That's not even a meters/feet conversion issue. Still playing with this so that I understand it ...
Bob
By the way, including TFPointAlt_X, or not, seems to make no difference
Click to expand...
This does seem to be a reality bubble issue.
When I was sitting on the ground at CYMO, I got the same number you did for Mauna Loa. When I moved to PHNL, the answer was suddenly 6994.6 - much closer to what you were expecting.
Maybe I should update the thing to report a ridiculous negative number if the requested location is outside the reality bubble.
 
Right. You asked the key question, "How close to Mauna Loa were you?" When very far away (like 1000's of NM), I also get nonsensical results. When close such as at PHNL, it's good. Further, if I move the airplane around using the Nav map and set A: PLANE LATITUDE/LONGITUDE to TFPointLat/Lon, I get pretty much an exact match with A:GROUND ALTITUDE.
The elevation returned certainly is in feet. Interestingly, though it is an L:Var, TFPointAlt does not respond to changes in units. It returns the same number regardless of units chosen, including no units chosen.
One last item. I tried generating an array of TFPointLat/Lons in an XML loop and writing the resulting elevations to a Logger file - using only one TFPoint - TFPointAlt_0. I hoped to be able to 'instantly' generate an elevation profile of a flight plan. As I suspected, that didn't work.

Bob
 
By the way, would it be helpful to have the option of providing lat and lon values in radians?
I ask because that is what the PDK function wants anyway. I'm converting the degree values to radians, but it strikes me that if you're doing trig functions in xml to get the values you need, that radians might be more convenient.
 
ddawson said:
By the way, would it be helpful to have the option of providing lat and lon values in radians?
I ask because that is what the PDK function wants anyway. I'm converting the degree values to radians, but it strikes me that if you're doing trig functions in xml to get the values you need, that radians might be more convenient.
Click to expand...
I think degrees would be sufficient. If you allow either, I presume one would specify degrees or radians units as normal and let the sim convert to radians. But, I was finding that units conversions weren't working, at least for L:TFPointAlt_X.
Bob
 
Bob,
I got the gauge respecting L:Var units, so you will need to use degrees or radians for the inputs, but you can now get feet or meters for the elevation values.
New version uploaded to same address.

Doug
 
Doug,

Version 1.2 works great. Thanks for the units fix. Many uses for this gauge!

Regards,

Bob
 
You must log in or register to reply here.
Back
Top