Question User input callback question

[Mogeley]

For a MFD I'm writing a callback function that takes the user input and get's an available landing pad or runway to land at. I need the landing pad coordinates, but for some reason my variables are never updated. I'm trying to get the longitude and latitude and save it in the variables "tgtlng" and "tgtlat". The line of code where the variables are set is bold.

double tgtlng, tgtlat, tgtrad;

// Callback function for target input dialog
bool clbkTargetDialog(void *id, char *str, void *usrdata)
{
	AutoPilotMFD* cMFD = (AutoPilotMFD*)usrdata;
	//OBJHANDLE objTarget;
	ELEMENTS e;
	ORBITPARAM op;
	
	OBJHANDLE hVessel = oapiGetVesselByName(str);
	OBJHANDLE hObj = NULL, hRef = NULL, hBase = NULL, hPlanet = NULL;
	hObj = oapiGetGbodyByName(str);
	hRef = cMFD->mV->GetSurfaceRef();
	hBase = oapiGetBaseByName(hRef, str);
	DWORD navtype;
	char* desc;
	bool result;

	// Determine if the string is a ship, planet, base, or orbit parameters
	if (hVessel != NULL)
	{
		cMFD->tgtV = oapiGetVesselInterface(hVessel);
		//cMFD->tgtname = cMFD->tgtV->GetName();
		strncpy(cMFD->tgtname,cMFD->tgtV->GetClassName(),31);
	} else if (hBase != NULL) {
		hTGT = hBase;
	} else if (hObj != NULL) {
		hBase = oapiGetBaseByName(hObj, str);
		hTGT = hBase;
	}

	if (hBase != NULL) {
		DWORD padcount = oapiGetBasePadCount(hBase); // 0 to < padcount
		NAVHANDLE hNav = NULL;
		for (int i = 0; i < padcount; i++) {
			// Finds first available landing pad. If ILS runways are found these override landing pads. This assumes that if a base has a runway it should be used.
			hNav = oapiGetBasePadNav(hBase, i);
			if (hNav != NULL) {
				navtype = oapiGetNavType(hNav);
				if (navtype == TRANSMITTER_ILS) {
					[B]result = oapiGetBasePadEquPos(hBase, i, &tgtlng, &tgtlat, &tgtrad);[/B]
				} else if (navtype == TRANSMITTER_VTOL) {
					
				}
				
			}
		}
	}

	return(true);
}

Here's the function from the API documentation:
OAPIFUNC bool oapiGetBasePadEquPos (OBJHANDLE hBase, DWORD pad, double *lng, double *lat, double *rad=0)

Thanks!

 

[dbeachy1]

I assume tgtlng and tgtlat are used elsewhere in code that is not listed, correct? (I was just wondering how you knew for sure they were never updated -- what if they were updated but there is a bug in the code that uses them?) Assuming they really are not updated, are you sure that hBase is valid (i.e., not NULL?) Also, I see that you assign the return code of oapiGetBasePadEquPos to 'result', but that value is never checked. Are you sure that 'result == true'?

In any case, I recommend simply running Orbiter.exe under the debugger and setting a breakpoint at the beginning of your 'clbkTargetDialog' method: then you can just step through it line-by-line and easily see exactly why the values aren't being updated. Much easier than making guesses at it. For instructions on how to debug a DLL under Microsoft Visual Studio, take a look here. Remember that the .exe file you want to launch under the debugger is Orbiter.exe.

 

[Mogeley]

Yeah, the values are not being updated. I found this problem shortly after posting. Kind of ironic... It seems that Cape Canaveral has no landing pads with the nav type of ILS, only VTOL. I'm wanting to find the ends of the runways if this is possible.

Any ideas how to get the positions of the ILS transmitters or the ends of the runways?

Thanks for the link too that is also helpful...

 

[Notebook]

Mogeley, this might have some useful info, though it is old.

http://www.orbiter-forum.com/showthread.php?t=4668&highlight=ils

N.

 

[Hielor]

Yeah, the values are not being updated. I found this problem shortly after posting. Kind of ironic... It seems that Cape Canaveral has no landing pads with the nav type of ILS, only VTOL. I'm wanting to find the ends of the runways if this is possible.

Any ideas how to get the positions of the ILS transmitters or the ends of the runways?

Thanks for the link too that is also helpful...

The runways aren't landing pads. If you're tuned to the ILS frequency, you can use the radio frequency functions to find the "location" of the ILS transmitter (the end of the runway), but you can't find the localizer course, as pointed out in the thread Notebook linked.

 

[Mogeley]

Mogeley, this might have some useful info, though it is old.

http://www.orbiter-forum.com/showthread.php?t=4668&highlight=ils

N.

Thanks, yeah that is very useful. The project I'm working on is for the Orbiter 2009, which will probably be released way before my MFD is considered finished. I'm not sure if the new function is implemented yet as the documentation is unfinished for that part.

I've considered parsing the config files. This would not be difficult once the parser was written, and it would need to map local coordinates to Longitude, latitudes. It's just weird doing something that Orbiter already does.

The ironic part is I moved from coding from Lua script to the Orbiter API to get able to get runway locations. To find out the API doesn't do this either (yet). I find this funny... :rofl:

---------- Post added at 11:56 AM ---------- Previous post was at 11:51 AM ----------

The runways aren't landing pads. If you're tuned to the ILS frequency, you can use the radio frequency functions to find the "location" of the ILS transmitter (the end of the runway), but you can't find the localizer course, as pointed out in the thread Notebook linked.

2 transmitters defines a course. That's if there's 2 transmitters and they are near each end of the runway. Parsing the base config file may be the way to go...

 

[Hielor]

Thanks, yeah that is very useful. The project I'm working on is for the Orbiter 2009, which will probably be released way before my MFD is considered finished. I'm not sure if the new function is implemented yet as the documentation is unfinished for that part.

I've considered parsing the config files. This would not be difficult once the parser was written, and it would need to map local coordinates to Longitude, latitudes. It's just weird doing something that Orbiter already does.

The ironic part is I moved from coding from Lua script to the Orbiter API to get able to get runway locations. To find out the API doesn't do this either (yet). I find this funny... :rofl:

If you're writing your addon for Orbiter 2009, why can't you just use the new function that Martin described in that thread, rather than parsing the config file?

2 transmitters defines a course. That's if there's 2 transmitters and they are near each end of the runway. Parsing the base config file may be the way to go...

Not all runways have ILS transmitters on both ends.

 

[Mogeley]

If you're writing your addon for Orbiter 2009, why can't you just use the new function that Martin described in that thread, rather than parsing the config file?

The only thing I can find for the function is the constructor. There's no documentation yet, I can try to figure it out but we'll see if I can.

 

[orb]

I've considered parsing the config files. This would not be difficult once the parser was written, and it would need to map local coordinates to Longitude, latitudes. It's just weird doing something that Orbiter already does.

(... snip ...)

Parsing the base config file may be the way to go...

I've written a config file parser (here's more about it), and it translates object coordinates in bases to longitude and latitude. All known objects are read, so also RUNWAYs. ILS frequencies aren't read though, but tell me if you need them to be read from a RUNWAY entry, and I'll add it.

(BTW. Position of END1/END2 objects is stored in my BaseObject class as center point coordinates, length and rotation/bearing.)

 

[Hielor]

The only thing I can find for the function is the constructor. There's no documentation yet, I can try to figure it out but we'll see if I can.

So the oapiGetNavData doesn't work for you when compiling against the O2009 SDK?

 

[Mogeley]

So the oapiGetNavData doesn't work for you when compiling against the O2009 SDK?

I have to wait to get home before I can try to compile it. I'm still not quite sure what the function returns. This is the only thing I found on the NAVDATA type definition.

typedef union {
	struct {
		double appdir;
	} ils;
} NAVDATA;

OAPIFUNC DWORD oapiGetNavData (NAVHANDLE hNav, NAVDATA *data);

 

[Hielor]

I have to wait to get home before I can try to compile it. I'm still not quite sure what the function returns. This is the only thing I found on the NAVDATA type definition.

typedef union {
    struct {
        double appdir;
    } ils;
} NAVDATA;
 
OAPIFUNC DWORD oapiGetNavData (NAVHANDLE hNav, NAVDATA *data);

"appdir" is, I imagine, "approach direction." You send that function a NAVHANDLE and a pointer to a NAVDATA, and it fills the appdir element with the approach direction for that ILS transmitter. Not sure what the return value would be, but it's irrelevant.

 

[Mogeley]

"appdir" is, I imagine, "approach direction." You send that function a NAVHANDLE and a pointer to a NAVDATA, and it fills the appdir element with the approach direction for that ILS transmitter. Not sure what the return value would be, but it's irrelevant.

That sounds about right.

The DWORD returned value may be the Nav channel (Channel numbers range from 0 to 639) or the Nav type.

I would still need the Nav location to determine the end of the runway and glideslope. I can try to use oapiGetNavPos (NAVHANDLE hNav, VECTOR3 *gpos) to get the nav position. I'm not sure how to get the nav handles for the ILS transmitters.

 

[Hielor]

That sounds about right.

The DWORD returned value may be the Nav channel (Channel numbers range from 0 to 639) or the Nav type.

I would still need the Nav location to determine the end of the runway and glideslope. I can try to use oapiGetNavPos (NAVHANDLE hNav, VECTOR3 *gpos) to get the nav position. I'm not sure how to get the nav handles for the ILS transmitters.

Return value might also be an error code ("That's not an ILS, noob"). You can get a NAVHANDLE for the ILS transmitter the same way as any other navaid--there's a function which retrieves the NAVHANDLE for the transmitter that one of the vessel's radios is currently tuned to.