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

Custom events again....

taguilo

Resource contributor
Messages
1,585
Country
argentina
Multiply that by around 100 switches, lights and knobs... and it's a really, really bad idea when it comes to multiplayer/shared cockpit.

Ed,
10,100...1000...up to trigger_key_event(iEvent,iValue) is the same code, no extra lines needed. The only part that could become "heavy" is this one:

Code:
const int AC_SWITCH  = 70000;

void FSAPI EventHandler(ID32 event, UINT32 evdata, PVOID userdata)
{
     switch(event)
    {
         case AC_SWITCH:
etc

but that would be the same when using this method and by <EventID> as well.
In any case, the bad idea would be so many switches,lights and knobs and not the code to handle them;)

Tom
 
Messages
1,861
Country
us-ohio
Correct me if I'm wrong... but don't Lvars get 'broadcast' during multiplayer mode?
 
Messages
26
Country
france
Correct me if I'm wrong... but don't Lvars get 'broadcast' during multiplayer mode?

Hi,
For what I had tested during my Etendard project, L:vars are not shared between multiplayers but L:vars are shared between shared cockpit players...

Times ago, there was a thread speaking about gauge flooding, and many interesting things were said about that... I didn't find out the link...

I found also this thread that says that Custom Event can be fired with an (>K:XXXXX) call:
[FSXA] Custom EventIDs - Questions!

I didn't have time to try it but I will soon...
Regards,

Sylvain
 

taguilo

Resource contributor
Messages
1,585
Country
argentina
Correct me if I'm wrong... but don't Lvars get 'broadcast' during multiplayer mode?

Yes, that's what the SDK says (and I know of your devotion to the SDK :) )
However, in a C++ gaugeset scenario, only those LVars used within the model would be broadcasted and hypotetically received by nobody, so I can't see a big tradeoff here.


I found also this thread that says that Custom Event can be fired with an (>K:XXXXX) call:
[FSXA] Custom EventIDs - Questions!

I didn't have time to try it but I will soon...
Regards,

Sylvain

Unfortunately the evaluations and conclutions in that thread were wrong. See post #15 here where I explain the reasons why it can't work.

Tom
 

JB3DG

Resource contributor
Messages
1,323
Country
southafrica
And with 100+ switches....Thats why we need a alternative to using L vars for Right/Left clicks.
 

JB3DG

Resource contributor
Messages
1,323
Country
southafrica
There is one other option....use unused FSX key events like the G1000 or the GPS key events to trigger custom events.
 
Messages
26
Country
france
And with 100+ switches....Thats why we need a alternative to using L vars for Right/Left clicks.

Hi,
I agree with you it's very frustrating to not being able to use (>K:xxxxx) call with custom event.
But I don't understand why you want left/right click for switch? Most of switch are 2 positions switch for which a single click is needed : a toggle behaviour...so custom event can be easily used.

Last I never noticed any issue with the use of Lvars in a vc whatever the mode used (single, mp, or sc): most of the Etendard vc animations are based on Lvars without any significant loss of fps... To my own point of view, Lvars are shared only in shared cockpit..
R.
Sylvain
 

JB3DG

Resource contributor
Messages
1,323
Country
southafrica
We are talking about knobs and multi position switches here. Thats where the left/right click comes in. And having too many L vars will clog up a shared pit. Thats what we are attempting to prevent here....

Update:

I just thought of a another option. If you are using L vars for the animation of the knob/switch maybe one can send a value outside of the animation range and have it get reset by the key event in the gauge. Unless it makes the knob jump around that is....
 
Last edited:

n4gix

Resource contributor
Messages
11,661
Country
unitedstates
Ed,
10,100...1000...up to trigger_key_event(iEvent,iValue) is the same code, no extra lines needed. The only part that could become "heavy" is this one:

Neither event_handler or the L:vars need be monitored all the time. The only time they would need to be evaluated is when a mouse event of some kind was triggered.

IOW, every mouse action would set a triggered flag, the evaluation would run, custom key_event sent, L:var updated and finally the triggered flag reset.

-OR-

Alternatively, how about multiplexing a couple of unused SET type tokens and their associated variables?
 
Last edited:

n4gix

Resource contributor
Messages
11,661
Country
unitedstates
This is a very, very old thread, but somehow the method that actually works was never posted.

What Jon and I found is that by setting up one custom L:var we can easily use any form of mouse clicking and wheel rotations to send custom EventId hex numbers:

0x10001 (>L:Event,enum)

The event handler in the C gauge will monitor (L:Event,enum), then retrieve the value before resetting via 0 (>L:Event,enum).
 
Top