Simconnect SDK upgrade?

Pete Dowson · 2 Feb 2009

paolo said:
Hello Pete, good news about the EFI737. Do you think that will be possible to manage the EFIS functions only for B737 or also the EFIS functions for the A320 of FSX defualt?

Is there the same problem in the Airbus too? I don't think I've ever looked at it. And I really haven't been poring through all the other XML gauges to see what other "L" variables I can link to. There may be plenty but I've got so much else to do. And if they have the same name they should operate in the same way.

I did send you a "high priority" email explaining the new facilities and also asking you about other things, sent on Friday evening, but you've not replied yet! Perhaps you could answer me there instead please? I see emails immediately. I scan here once or twice a day.

Pete

paolo · 2 Feb 2009

No Peter, I have not received your mail. Please send me again at plstg@live.it or support@cpflight.com

Regards,
paolo

n4gix · 2 Feb 2009

Pete Dowson said:
Is there the same problem in the Airbus too? I don't think I've ever looked at it. And I really haven't been poring through all the other XML gauges to see what other "L" variables I can link to. There may be plenty but I've got so much else to do. And if they have the same name they should operate in the same way.

If you haven't used it, I highly recommend Doug S. Dawson's "xml_id.gau" for quickly identifying all L:vars currently loaded in the sim.

It's available at AVSIM of course. I also have the source code for Doug's gauge...

Pete Dowson · 2 Feb 2009

n4gix said:
If you haven't used it, I highly recommend Doug S. Dawson's "xml_id.gau" for quickly identifying all L:vars currently loaded in the sim.

It's available at AVSIM of course. I also have the source code for Doug's gauge...

Oh, is that possible? Is the source shareable at all? It might be useful to only ask for those which are loaded (saves wasted processor cycles), and maybe I could look at ways of making the FSUIPC access to L: variables more flexible, like with the named macro system.

Thanks,

Pete

n4gix · 2 Feb 2009

Pete Dowson said:
Oh, is that possible? Is the source shareable at all? It might be useful to only ask for those which are loaded (saves wasted processor cycles), and maybe I could look at ways of making the FSUIPC access to L: variables more flexible, like with the named macro system.

Thanks,

Pete

Sure thing. Doug made the source available several years ago. It works well in both FS9 and FSX. The routine is fairly simple though. It's mainly a matter of setting up and populating an indexed array:

Code:

int i, j, checked = 0;
XML_VAR *xml = new XML_VAR[65536];

void FSAPI gaugecall(PGAUGEHDR pgauge, int service_id, UINT32 extra_data)
{
switch(service_id)
{

case PANEL_SERVICE_PRE_UPDATE:
    if ( checked <= 0 )
		{
		j = 0;
		ZeroMemory ( &xml[0], 65536 * sizeof(xml[0]) );
		checked = 180;
		while ( j < 65536 )
			{
			xml[j].name = NULL;
			xml[j].name = get_name_of_named_variable(j);
			if ( xml[j].name != NULL ) xml[j].id = j;  else xml[j].id = -1;
			j++;
			}
		}
	else checked--;
break;

case PANEL_SERVICE_DISCONNECT:
	delete[] xml;
break;
}
}

et cetera...

Pete Dowson · 3 Feb 2009

n4gix said:
Sure thing. Doug made the source available several years ago. It works well in both FS9 and FSX. The routine is fairly simple though. It's mainly a matter of setting up and populating an indexed array

Ah. The crux of it is this:

PCSTRINGZ (FSAPI *get_name_of_named_variable) (ID id);

I'd never realised that the ID here was a simple index. Quite often IDs tend to be actual pointers (like Handles), so there's no way of ennumerating them.

Thanks!

Pete

n4gix · 3 Feb 2009

I hope it's useful info.

One thing I should point out though is that -for me at least- occasionally in FS9 this list of L:vars will include some in a/c that are not loaded, and have not been loaded during the session. No one, including Susan was ever able to explain how or why this happened...

FSX never exhibits this behavior though, so perhaps it's something that's unique to my particular FS9 configuration...

ADDENDUM: after looking back at my archived discussion with Doug and Susan, FSX Demo did exhibit this odd behavior as well. Although Susan never wrote back to confirm/deny this, I note that with FSX RTM the odd behavior stopped. Was that a coincidence? Perhaps, but I think not...

Pete Dowson · 3 Feb 2009

n4gix said:
I hope it's useful info.

Well, it's encouraged me to delve further. I have found that instead of using "execute_calculator_code", it is far more efficient to use these:

check_named_variable -- to get the ID, also checks if variable exists.

then using the ID:

get_named_variable_value to read the setting, and
set_named_variable_value to write it.

One thing I should point out though is that -for me at least- occasionally in FS9 this list of L:vars will include some in a/c that are not loaded, and have not been loaded during the session. No one, including Susan was ever able to explain how or why this happened...

At present I'm not considering backtracking to FS9. All my new code is for FSX / ESP. I have merged ESPIPC and FSUIPC4 into one module, FSUIPC4, which works in both FSX and ESP, and which is installed into either or both by the same installer.

Here's a typical list, from the Cessna 172, using a new facility I've added to log panel local variables. I've no idea what most of them are !

:

616812 Aircraft="Cessna Skyhawk 172SP Paint1"
616812 Panel includes these local variables:
616812 L:map_ZoomStep = 0.000000
616812 L:map_ZoomFactor = 0.000000
616812 L:MapInit = 0.000000
616828 L:LayerAirports = 0.000000
616828 L:LayerAirspaces = 0.000000
616828 L:LayerTerrain = 0.000000
616828 L:LayerVORs = 0.000000
616828 L:LayerILSs = 0.000000
616828 L:LayerNDBs = 0.000000
616828 L:LayerLowAirways = 0.000000
616828 L:LayerTags = 0.000000
616828 L:LayerCompass = 0.000000
616828 L:LayerIntersections = 0.000000
616828 L:LayerRangeRings = 0.000000
616828 L:VehicleObjectDetail = 0.000000
616828 L:Filter = 0.000000
616828 L:LastLandingLightPosition = 0.000000
616828 L:EmergencyThrottleInUse = 0.000000
616828 L:Engine1ThrottlePosition = 50.000000

I'm considering expanding the FSUIPC4 macro facilities with the ability to write to named L: variables, thus providing a way of assigning to buttons and keypresses. Doesn't look too hard to incorporate into the current facilities.

Thanks & Regards

Pete

n4gix · 3 Feb 2009

Pete Dowson said:
Well, it's encouraged me to delve further. I have found that instead of using "execute_calculator_code", it is far more efficient to use these:

check_named_variable -- to get the ID, also checks if variable exists.

then using the ID:

get_named_variable_value to read the setting, and
set_named_variable_value to write it.

Yes, those are the first examples I cited in my Wiki article. For use with an dynamic indexed array, they are without doubt more efficient...

Here's a typical list, from the Cessna 172, using a new facility I've added to log panel local variables. I've no idea what most of them are !:

616812 L:map_ZoomStep = 0.000000 //controls zoom level
616812 L:map_ZoomFactor = 0.000000 //sets the zoom scalar
616812 L:MapInit = 0.000000 //used as an init "do once flag"
616828 L:LayerAirports = 0.000000 //hide/display apt
616828 L:LayerAirspaces = 0.000000 //hide/display airspaces
616828 L:LayerTerrain = 0.000000 //hide/display color map
616828 L:LayerVORs = 0.000000 //hide/display VORs
616828 L:LayerILSs = 0.000000 //ditto for ILSs
616828 L:LayerNDBs = 0.000000 //ditto for NDBs
616828 L:LayerLowAirways = 0.000000 //ditto for Victor Routes
616828 L:LayerTags = 0.000000 //ditto text labels
616828 L:LayerCompass = 0.000000 //ditto Rose
616828 L:LayerIntersections = 0.000000 //ditto for Intersections
616828 L:LayerRangeRings = 0.000000 //ditto for RangeRings**
616828 L:VehicleObjectDetail = 0.000000 //see below*

I know what all of them are for, but curiously none of them are used in the default G500 or G1000! :yikes:

I see such L:vars only in third-party gauge scripts, such as mine and Nick Pike's... :coffee:

They are used to control such things as listed above.

*ObjectDetailLayerVehicles Int
-1 = Default
0 = Draw nothing
0x1 = Track line
0x2 = Ground vehicles
0x4 = Airborne vehicles
0x8 = Racing vehicles

** Now this one is truly odd, since RangeRings are only defined in the Radar.cab file, which obviously isn't loaded with the default C172!

Most of the above are boolean. The complete list of GPS Map variables is in the FSX Panels and Gauges SDK: XML Gauge Maps.

616828 L:Filter = 0.000000 //unknown to me!

I suspect it's used to "filter out" map item details when zooming out...

Quite frankly, I am quite confused by the list above!

n4gix · 3 Feb 2009

Oh, keep in mind that gauges aren't the only things that can create L:vars...

For example, L:EmergencyThrottleInUse, bool is actually "created" by the cessna172sp.mdl itself...

...as is L:Engine1ThrottlePosition, percent

...and L:LastLandingLightPosition,percent

You can "Open" any .mdl file in Notepad.exe or WordPad.exe and search for L: to locate which ones are defined by a model.

BTW, regarding the L:vars in the other reply, I see that Doug's gauge shows the exact same list, yet aside from the three I've identified as belonging to the model itself, I've yet to identify the source of the others... :banghead:

Pete Dowson · 4 Feb 2009

n4gix said:
Oh, keep in mind that gauges aren't the only things that can create L:vars...

Okay, thanks. I didn't know that.

BTW, regarding the L:vars in the other reply, I see that Doug's gauge shows the exact same list, yet aside from the three I've identified as belonging to the model itself, I've yet to identify the source of the others...

Hmmm. I've mapped out plans and a method for allowing users to create macro files which add controls to FSUIPC for key or button assignment to set, increment, decrement or "toggle" any L:vars they wish. Maybe that's not so wise? If i do that I shall have to emphasise that their use is up to them and I cannot support whatever they screw up!

Still, it could be quite powerful. If I can also offer reading capabilities -- probably via Lua plug-ins only -- then I can see possibilities for a lot more interaction between user gadgets and FSX panelling.

All this is a bit odd for me, really, considering I don't use any panels in my own sims -- only Project Magenta instrumentation on my 737NG, and Aerosoft GA28R analogue instruments on my Arrow III.

Still, the programming is the interest in this, not practical uses for myself. ;-)

Best Regards

Pete

n4gix · 4 Feb 2009

Pete Dowson said:
Okay, thanks. I didn't know that.

Yes, in fact all animations in FSX models are the result of embedded XML scripts. Custom animations are of course generated/controlled via L:vars.

Hmmm. I've mapped out plans and a method for allowing users to create macro files which add controls to FSUIPC for key or button assignment to set, increment, decrement or "toggle" any L:vars they wish. Maybe that's not so wise? If i do that I shall have to emphasise that their use is up to them and I cannot support whatever they screw up!

That would be a wise disclaimer! At first I thought that perhaps some of the GPS tags used in the <CustomDraw> section of the G500's XML script were being recast somehow to bogus L:vars by FSX's engine, but...

...further digging leads me to discount that as a possibility, since no where in any of the default C172's model or gauge XML scripts is anything resembling L:LayerRangeRings, L:LayerCompass, or L:MapInit be located...

Still, it could be quite powerful. If I can also offer reading capabilities -- probably via Lua plug-ins only -- then I can see possibilities for a lot more interaction between user gadgets and FSX panelling.

Oh, absolutely. As long as the end user is advised that some of what might be listed may -in fact- have no real use at all, that which is useful could be of great potential benefit.

Bill