• 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.

FSX Connecting Gauges to Simconnect.. Can I?

Messages
9
Country
indonesia
Dear All,

I have a project to make a custom gauge like a radar and some "on/off" button and send the data to my simconnect application. Can I do it??

Because I have read on msdn and i can find none variable to read a data from the gauge.



Best Regard,

bluejoystick..
 
Yes, you can. The easiest way I can think of is to open a SimConnect client in your C gauge and set-up a shared data area to write your gauge's local C variables into. You can then read that same area from your external SimConnect application. Or if your external app is a regular Windows app not using SimConnect you could open a TCP/IP channel and pipe the data to it from the gauge. It would take a more wider knowledge of C and the Windows SDK, but it is very possible.

Si
 
I haven't seen any source example of a combined C++ simconnect plus gauge DLL, but I've done it and know the two sets of code can co-exist in the same DLL. The simconnect CallDispatch code in a DLL is fundamentally different than in an EXE in that you call it ONCE (there is a simconnect DLL example) and you might have to play around to get the DLL init code working the way you want as you combine the entrypoints of both API's (DLLstart, DLLstop, moduleinit from memory...) and have to choose where to put your simconnect registration code.

I find the automatic C++ gauge DLL registration process (dynamic load when the aircraft is loaded) much more convenient than the dll.xml approach suggested for the simconnect DLL, but I don't know if the included gauge code in the combined DLL means you no longer need the dll.xml entry... I've used the dll.xml for my code and that definitely works for both the simconnect and the gauge apis.

B21
 
Yes, you can. The easiest way I can think of is to open a SimConnect client in your C gauge and set-up a shared data area to write your gauge's local C variables into. You can then read that same area from your external SimConnect application. Or if your external app is a regular Windows app not using SimConnect you could open a TCP/IP channel and pipe the data to it from the gauge. It would take a more wider knowledge of C and the Windows SDK, but it is very possible.

Si

Simon, can you also "write" to those variables from SimConnect client, using SimConnect_SetDataOnSimObject ?

Misho
 
You can't do it that way because your custom gauge wont have any properties that SimConenct recognises for use with SetDataonSimObject.

What you could do is create a Client Data Area as detailed within the SDK and use that to share miscellaneous variables between your gauge and SimConnect application.

You'll need to write a SimConnect client within your C gauge, (which doesn't require the dll.xml stuff mentioned earlier), and use that to populate the Client Data Area with your variables. Then you can write an external exe application that also connects to FSX as a SimConnect client app, to access the same data area.

But in reality you need not use SimConnect at all for this if you didn't want to. You could simply open a TCP/IP channel between you C gauge and external exe and pipe data between them if you wanted. SimConnect is really useful for sending events to FSX and getting native FSX variables automatically when they change and notification of native events. But if all you want to do is share custom data, it may be easier to use standard Windows SDK functionality.

Si
 
Thanks - the thing is - I'd like to send data and values of custom variables to AI objects and SimVars. SetDataonSimObject has an ObjectID parameter that lets you do that, but only to "known" FSX vars. Is it possible to define an L: var from within the model animation (in the "modeldef.xml") and have an access to these directly through SimConnect? Something like:

struct myData
{
...
bool AccessHatchOpen,
....
};

hr = SimConnect_AddToDataDefinition(hSimConnect, DEFINITION_1, "L:AccessHatchOpen", "Bool");

and then:

SimConnect_SetDataOnSimObject(hSimConnect, DEFINITION_1, ObjectID, 0, sizeof(myData), &myData);

Where the AI model has been compiled with one of its parts animated using the "L:AccessHatchOpen" as a trigger.

I haven't seen anything from withing Gauges that lets you control vars of non-user objects.

A fallback to this would be to use one of the stock FSX variables that are easily accessible through this, and which you know you're not going to use (for example one of the exit Enums)... but I'd rather do this properly.

Misho
 
Misho forget about sim_connect for a couple of days and look at the SDK for creating C gauges (specifically the Cabin Comfort example which mixes C with XML)... step 1 will be to create a plain-vanilla C gauge dll that can, for example, read a variable from an XML gauge, increment it, and write it to another variable that can be read by the gauge. None of this involves sim_connect. When you get this working you'll have learned the C dll and the XML gauge communicate via shared variables that have the name format "C:<registered_c_module_name>:<variable name>". E.g. you create a C dll that calls the registration API as "mymodule", and maybe tracks a couple of variables called var1 and var2. At that point an XML gauge can execute code such as "77 (&gt;C:mymodule:var1)" and the value 77 can be read inside the C dll.

When you get that DLL working, you can cut-and-paste your sim_connect routines into it and *then* you'll need to work out simply how to get your sim_connect program connecting to FSX and bingo, in the same code you have both sim_connect and a gauge interface working.

Rumor has it the now defunct FS11 development was going to replace the XML scripting of gauges and C++ programming to separate API for gauges and sim_connect with one joined up programming system using the language Lua. But it ain't gonna happen now...

B21
B21
 
Thanks B21! I studied the Cabin Comfort example and understand it, more or less. I've been communicating with animation XML variables using a gauge, that is no problem, and as you described, it is possible to comm between C++ and XML gauges (for which I haven't had a need yet, but I think I could handle it if need arises)

The intent, however, is to completely forego C++ gauges... I don't want to have anything to do with any gauge, or for that matter, any panel.cfg at all. Basically, I'd like to enable user to define a custom variable/animation in their model (using modeldef.xml) and then trigger these through a small, user-configurable SimConnect app.

I want to be able to let people control SimObjects with as few components as possible (Let Arno open and close hangar doors, for example :o ) and for that, I don't want to have a gauge and a panel associated with it. The objects in the "SimObjects/Misc" folder are example of that - FoodPallet and CargoPod. They are not "dumb" bgl static props, but are capable of a bit of "life" in them, by a virtue of having the ability to be controlled. I truly believe this is a bit of a "holy grail" for the living world everyone has been asking for (I keep seeing posts on whether such and such object can be triggered, controlled, turned into wind, conditionally displayed etc.). Well, they can, if they are SimObjects.

I've actually made good headway in this: I've created a simple hangar model with animated doors. It is residing in a brand new directory "Hangars" in the SimObjects folder. I copied all the rest of the SimObject container from the default Aircreation Trike. Then, I hooked its door anim to an existing FSX variable - in this case, master_battery_switch. Now, I can use SimConnect to place this hangar anywhere, AND trigger its door animation through any condition I like (while sitting in my airplane), all through SimConnect. (I defined a custom key to open/close, but the trigger can be practically anything) This is obviously kludgy solution (if I can call it "solution"): The object has to be "aircraft" category, and I have to use an existing FSX variable which will, obviously, in the case of the hangar building, be unused. However, this works, and if someone really wants to have user-triggered hangar doors, this is one way of doing it.

The next step is to figure out how to use custom vars (defined in the model animation itself, "L:HangarDoorOpen" for example) instead of FSX ones. Once I figure that out, the system may let me set the category to "SimpleObject" instead of "aircraft" (or even let me define my own) and that would basically be what I am looking for. You can see why I want to completely forego the gauges altogether - they just wouldn't be an elegant solution for controlling a simple object. Any insight on this would be appreciated and welcome :o

Misho
 
The reason all you are getting is less than optimal solutions is because you can't do what you want to do directly. While the XML scripting system hooks into the SimVar system as a consumer, it doesn't hook in as a provider of variables, so there's no way to directly access the L: or G: variables used in gauges and animations from SimConnect.

Using a SimObject like you have been is the closest thing to a solution available - you might want to consider using the ground vehicle category instead of aircraft though, much lower overhead (although also fewer variables predefined).
 
Thanks Tim, for this extremely helpful insight! I now have a much clearer view of the way to procede.

I was wondering if you can also shed some light on another topic (which I also started a thread on, here): Custom Events. To quote SDK,

The ability to export custom event IDs in a model, so that the IDs can be referenced in the panel system or in a SimConnect client, has been added.

While there is a clear example in SDK of this used with gauge/panel interface, the SimConnect interface is a bit more foggy. As I mentioned in my thread, I have tried to send/receive the custom events from SimConnet to the model, as the SDK blurb suggests, but I haven't been able to get anything out.

Would you mind quickly explaining in what context are custom events and SimConnect related?

Misho
 
thanks for the detailed explanation misho - I see what you're trying to achieve. But you still need to bridge from simconnect -> L:variable.

Wouldn't 'execute_calculator_code()' in a sim_connect/gauge DLL that is launched from dll.xml give you what you need? (linky). The clever bit of this trick would be there is *no* actual user gauge on the panel but (a) the sim_connect/gauge DLL doesn't need an actual gauge in the panel to get it launched as that is already done in dll.xml - this bit is already tried and tested as per cabin comfort, and (b) doing execute_calculator_code("77 (>L:myVar)",NULL,NULL,NULL) in the DLL doesn't depend on a user XML gauge being there to see the value either...

B21
 
Hey All,

I don't know much about XML Gauge....but i think you may need to develop a DLL, and let the dll.xml to load it...by then...you can request a pointer to the PANELS export (linkage) structure containing the function pointer to the "execute_calculator" function)..then execute (call)..it when you need to.....without making a gauge that needs to be loaded by the panel.cfg of an aircraft. Also asume that the DLL also connects to SIMCONNECT. I didn't tested this...but i think it'ssomething you may want to try it out...


Hope that helps,


Manuel Ambulo
 
Last edited:
thanks for the detailed explanation misho - I see what you're trying to achieve. But you still need to bridge from simconnect -> L:variable.

Yes - I was trying SimConnect -> L:Var and Tim explained that is not possible.

So, the way forward is SimConnect -> dll gauge -> L:Var, and from what you are indicating, the dll gauge can be made "silent", with the SimConnect code merged in, so that would be exactly what I need. Awesome.

Wouldn't 'execute_calculator_code()' in a sim_connect/gauge DLL that is launched from dll.xml give you what you need? (linky). The clever bit of this trick would be there is *no* actual user gauge on the panel but (a) the sim_connect/gauge DLL doesn't need an actual gauge in the panel to get it launched as that is already done in dll.xml - this bit is already tried and tested as per cabin comfort, and (b) doing execute_calculator_code("77 (>L:myVar)",NULL,NULL,NULL) in the DLL doesn't depend on a user XML gauge being there to see the value either...

B21

Yes it would - actually, there are a few different methods besides "execute_calculator_code" for this, and I think Bill once mentioned check_named_variable/set_named_variable_value approach is a bit more elegant than execute_calculator_code. However, you mentioned the format for setting L:var, and I am not sure if that works for check/set.

All that being said - the fundamental problem is being able to set those vars on an AI object, NOT user object. I don't see any mechannism for doing this within panel gauge. SimConnect DOES have facility for this with SimConnect_SetDataOnSimObject(...ObjectID... )... but will the gauge code in the "universal" dll know to what object I am setting L: vars? Or, in other words, what is the scope of the L:var when in a SimConnect/gauge dll? In a "normal" dll (attached to the aircraft in the panel.cfg), the scope, obviously, is user aircraft.

Misho
 
Yes, this method will work in the main_callback of a .dll:

Code:
double my_variable = 1 ; // this is the C variable
ID my_variable_id; // this is the pointer address to the XML variable

register_named_variable ( "MyVariable" ); // this is the (L:MyVariable,enum)


// the following is equivalent to an XML command
//  my_variable (>L:MyVariable,enum)

    my_variable_id = check_named_variable ( "MyVariable" ) ;
    set_named_variable_value ( my_variable_id, (FLOAT64)pitot_cover ) ;

// if you need to "read" the value of (L:MyVariable,enum) then use the following

my_variable_id = check_named_variable("MyVariable");
my_variable = get_named_variable_value (my_variable_id);
 
Thanks Bill! Yup, I've been using this code without problems. The question is: is it possible to set "MyVariable" of an AI aircraft (or any general SimObject)?

Misho
 
Well, in my experience I've been able to control the L:vars on one of my own models when it was used as an AI, so I'd say yes...

...it is possible and does work... ;)
 
Do L: vars actually relate to any particular aircraft/object in FSX ? I hadn't thought about this but had assumed they're effectively global to the sim environment (not multi-player).

misho did you try the simple test of setting L:HangarDoorOpen in a trivial XML gauge on the user panel (just for a test, temporarily add the "1 (&gt;L:HangarDoorOpen, number)" to any existing gauge) and confirm the hanger doors do open. Maybe this is what n4gix confirmed...

B21
 
That was exactly my thought - I am guessing that any model defined with L:HangarDoorOpen animation would have its hangar door open - Very interesting!

This is exciting - thanks guys! I will verify this over the weekend, and on a parallel track, I'll work on your suggestions as well, merging SimConnect into a gauge dll... While I am not a crackerjack programmer, I've hired someone who is, and I'll get him working on this. I'll report on what we come up with - hopefully a very elegant solution for a truly living world!

Misho
 
Guys,

the L: variables are Global (which is sort of strange, considering they are named L:, as if in "Local" ?? ) to the whole simulation so, if you want to use L: variables, you need to set multiple copies with different names, like my_variable_1, for AI object 1, my_variable_2 for AI 2, etc.

The Simvars ( the "gauge" variables ) are object based but, their availability depends on the SimObject type. An "Aircraft" type will have more usable variables than a "GroundVehicle" and "SimpleObject" will have even less Simvars active. Of course, it's overkill to create an Aircraft, just to trigger a single animation... These are of course very easy to read/write via Simconnect but, the issue is: there are VERY few that are really usable as read/write, without having the sim interfering with it, and write its own values instead. Using some hackery (es. multiplexing values or using single bit values for on/off triggers), it's possible to squeeze some data in those few usable Simvars, and set values to AI objects, but this is far from an ideal and flexible solution.

What we should really use, instead, are the V: variables...

The V: variables are really a mistery, and are the real and correct way to trigger custom animation on AI objects. There's just ONE V: variable used in the sim, which is:

V:SimContain.BaggageLoaderArmAngle

As the name says, it's used by the default Baggage loader vehicle, to trigger the arm animation. The V: variables are supposed to be like L: vars so, they are customizable, and not global, but local to each object.

Unfortunately, there's no documentation whatsoever about the V: variables and how to use them, I tried asking to some people at ACES but, unfortunately, it was just a few weeks before ACES was closed...

Perhaps Tim has some ideas ?
 
Last edited:
You've brought up an interesting point, Umberto. How I noticed this truly "global nature" of custom L:vars was by simple observation...

You see, I've set up some AI traffic based on some of my models, and one day noticed that all the "ground stuff" I've included was being triggered on all of the AI aircraft, based on what I commanded in my user aircraft's Preflight controls...

If I triggered the chocks for example, all of my custom AI aircraft suddenly had their chocks displayed, even if they were airborne.

One day I was doing a "formation flight" with five SR22T AI, and when I fired off the CAPS *all* of the AI SR22T's chutes fired also! What a sight that was... :rotfl:

I've never even considered V:vars at all, but even so wouldn't they behave the same way as L:vars?
 
Back
Top