I've never claimed to be good with the maths and I think I've proved it again <sigh>... I've been trying to use the __inline functions from the SDK.FlightMap.cpp to return my current lat, lon and alt. However, a print to string command returns just the 'f', showing that the data is incorrect.if (gpsinfo && gpsinfo->dwSize >= sizeof (GPS_INFO))wsprintf(pelement->string, "%10.0f", SIF48_TO_FLOAT64(gpsinfo->vPosition.lat));if (gpsinfo && gpsinfo->dwSize >= sizeof (GPS_INFO))wsprintf(pelement->string, "%10.0f", ANGL48_TO_FLOAT64(gpsinfo->vPosition.lon));Would someone please be kind enough to put me out of my misery and tell me what I should be doing?-Dai

Aside from the fact it's not a typical lat/lon value... why are you trying to do this?The current lat/lon is already available in far greater accuracy from FS itself. The GPS data doesn't update as accurately nor quickly.

if (gpsinfo){  if (gpsinfo->dwSize==sizeof (GPS_INFO))  {	wsprintf(pelement->string, "%10.0f", SIF48_TO_FLOAT64(gpsinfo->vPosition.lat));  }}

Don't lump your logic checks into one line. Relying on a boolean 'short-circuit' to avoid any type of crashes is a really bad idea. The way you had it written... if gpsinfo was null, you could potentially get a access violation by testing the dwSize field of a null pointer. (experience talking here...)C/C++ lets you do a lot of things, code-wise... however, just because you can doesn't mean you should. :(Is pelement->string a widechar string? I don't think it is... which means you should be using the sprintf() function.

I only posted the line that was the source of the trouble; there is an 'else' trap following it in case the block size is NULL or the struct is not initialised but yes, I agree with your general comment on putting all your eggs in one basket.Whay am I trying to do this? I'm trying to build an early INS system and they weren't as accurate or as quick in updating the aircraft position as they could be. As it happens, the gps_info.h file contains (as a subset) all of the information that this particular INS system is able to use/display. I'll try sprintf and see if that makes a difference.-Dai

The value in LATLONALT is already available from the GPS without the use of gps_info.h.I will caution you that use of the gps_info interface can cause problems. FS does not always return the pointer to it, under certain conditions. If the aircraft is reloaded... if you fly the aircraft, select "End Flight" and then create a new flight... it will return a NULL pointer.So... there is a strong risk with using that data.

Damn.... thanks for the information on the gps_info.h. Time to revert to plan ..err... plan ...err. Oh well. You've probably saved me a great deal of aggro, for which I am very grateful.-Dai

No problem.

Dai,Why not simply fetch the current lat/lon from the GPS directly?execute_calculator_code("(A:GPS POSITION LAT, Radians)",&gps_lat,NULL,NULL);execute_calculator_code("(A:GPS POSITION LON, Radians)",&gps_lon,NULL,NULL);

Now how did I know that was coming? :( :( -DaiAlthough in all seriousness I am starting to build a library of XML calls because they are a lot easier to work with than some of the C-gauge tokens.