Custom events again....

[JB3DG]

@N4GIX adding DWORD user_param is what crashes the sim every time which is what i have stated several times.

@Tom
So if i understand correctly, the K: part == KEY_ in the gauges.h and EVENT_ANY == the remaining characters of KEY_EVENT_ANY?

 

[n4gix]

Okay, let's step back a minute and examine some history from 2010...

In this thread, Post #13, Virtuali "suggests" that what we're attempting, i.e., using the (>K:0x11000) method, should work:
http://www.fsdeveloper.com/forum/showthread.php?t=20738&postcount=13

Sadly though, even after someone commented that "it doesn't work" Virtuali never replied to that observation...

Note also that what J.P. Langer did does work:

1) In gauges.h I have declared the new events:

// Third parties can use custom events in this range to communicate between 3D VC's and 2D C++ gauges.
#define THIRD_PARTY_EVENT_ID_MIN 0x00011000
#define THIRD_PARTY_EVENT_ID_MAX 0x0001FFFF

// Third party events
const int KEY_PHI_MODE_INC = 0x11000; 
const int KEY_PHI_MODE_DEC = 0x11001;

// GAUGE_KEY_EVENT_HANDLER
static void FSAPI EventHandler(ID32 event, UINT32 evdata, PVOID userdata)
{
	switch(event)
	{
		case KEY_NULL : 
		break;

		case KEY_PHI_MODE_INC:
			HomingState++;
			if(HomingState>4)
			HomingState=0;
		break;

		case KEY_PHI_MODE_DEC:
			HomingState--;
			if(HomingState<0)
			HomingState=4;
		break;

		default:
		break;
	}
}

Of course what he did simply allows him to use a convenient NAME rather than a hex number, and it's unclear if he ever got it to work from an XML command...

 

[JB3DG]

Its because I have read those threads that i asked 2-3 posts back if anyone has ever tested the method we are trying to achieve here.

 

[taguilo]

@Tom
So if i understand correctly, the K: part == KEY_ in the gauges.h and EVENT_ANY == the remaining characters of KEY_EVENT_ANY?

No, "K:" is an conventional identifier used by the scripting parser function to identify what kind of operation needs to make as follows, for example:

If this is "A:", then go to the aircraft varget class
If this is "K:", then go to events class
If this is "C:", then go to the "CUSTOM_NAME" class
If this is "L:", then go to the Variables handler class

etc, etc

Technically KEY_EVENT_ANY and EVENT_ANY are two different things, but guys at MS noticed that using the same name would help developers identify the same process, an event in this case.

Tom

 

[taguilo]

In this thread, Post #13, Virtuali "suggests" that what we're attempting, i.e., using the (>K:0x11000) method, should work:
http://www.fsdeveloper.com/forum/showthread.php?t=20738&postcount=13

Sadly though, even after someone commented that "it doesn't work" Virtuali never replied to that observation...

Yes, at first sight seems pretty logical that it should work, unless you know how it is internally managed.

Tom

 

[JB3DG]

Ok so where can i find this events class that so i can use left/right click to trigger my event?

 

[WarpD]

Yes, at first sight seems pretty logical that it should work, unless you know how it is internally managed.

Tom

Just to be crystal... it's supposed to work. It's documented in the SDK as supported in that manner. So... snarky replies aside... it's not unreasonable to expect it to function as documented. Logic has nothing to do with it.

 

[JB3DG]

The only problem is....Im trying to USE it and it is NOT WORKING

 

[taguilo]

Ok so where can i find this events class that so i can use left/right click to trigger my event?

Sadly you can't, it's not exposed to external user calls. However, it must be possible to build a custom module that "imitates" the operation of an event handler; I doubt it is worth the effort though...

Just to be crystal... it's supposed to work. It's documented in the SDK as supported in that manner. So... snarky replies aside... it's not unreasonable to expect it to function as documented. Logic has nothing to do with it.

Well, the only reference in the SDK is with <EventID> token, not more than that. Certainly the SDK isn't much helpful on many areas, indeed leaving a lot of issues to our own interpretation.

Tom

 

[JB3DG]

Ok this thread is getting a little off here....so please lets debug this problem in a orderly and systematic manner

Ed and Bill, have you actually tested this system?

And second, I need to make sure that the reason it isnt working for me is not in the seat. So with that in mind....Please answer my question about the 4th parameter of your event handlers.

If i add DWORD user_param as the 4th parameter it crashes the sim with a pointer error. So how do i get around this and second, does it actually have a useful function? I cant see how it would tie in with event_id or evdata as it isnt referenced in the switch statements or the if statements.

 

[WarpD]

Per the SDK the custom event handler is defined as follows:

typedef void (*GAUGE_KEY_EVENT_HANDLER) (ID32 event, UINT32 evdata, PVOID userdata);

So you would declare a function like this:

void FSAPI MyEventHandler(ID32 eventID, UINT32 evdata, PVOID userdata)
{
  switch (eventID)
  {
  case 0x11000:
    // do something with evdata
    switch (evdata)
    {
    case 0:
      // do something
      break;
    }
    break;
  }
}

If what is being stated is true, that FSX only pays attention to strict strings passed... then it will never work in a fashion to send values in 'evdata'. The base behavior of sending a custom event... does work... as long as it's set within:

    <EventID>0x11000</EventID>

 

[JB3DG]

just a little trivia....changing the ID32 param from event to event_id only helps for debugging purposes. event is actually a C++ keyword like switch and if and void etc and should not be used as a variable name although it does work. However you will not see the actual values being passed to it when its breakpoints are hit during debugging.

 

[WarpD]

The typedef I posted is part of the gauges.h file. It isn't how YOU should be naming your handler at all.

 

[JB3DG]

Lol!

Anyways....You guys are considerably more experienced than i am....Now that this method has been screwed do you have any other ideas for handling this? Maybe something like a mdl parser or something like that.....

 

[taguilo]

Lol!

Anyways....You guys are considerably more experienced than i am....Now that this method has been screwed do you have any other ideas for handling this? Maybe something like a mdl parser or something like that.....

Well, I just built a module (.dll) that trigger events using trigger_key_event().
It works perfect when called from inside a gauge, but won't work when doing the same within a <CallbackCode> in a .MDL file. Seems that it's not possible to instantiate a "gaugeCallback" class within a .mdl, something that sounds reasonable...

OTOH, I was thinking...what happens if you save the value of the custom event you defined, ie 0x11001 (>L:MyLVar,number); then inspect this variable in a C++ gauge, and in the same gauge call trigger_key_event passing the value as an argument? You should be able to capture the event in the same gauge or in any other using register_key_event (?)

Tom

 

[n4gix]

I see what you are suggesting, Tom.

The C gauge can monitor for change in a custom L:var, such as:

(L:18152,enum)

then generate a C event such as

send_key_event(0x18152,enum)

where enum is the value to be passed after evaluating (L:18152,enum)

It is this latter that would be passed along the m-p connection to the remote a/c's C gauge, and acted on locally.

 

[JB3DG]

Well i switched to using L vars to trigger the events in C++ and i have to say despite it being more roundabout I am actually able to move faster compared to straight XML. Would be nice though to avoid XML vars at all cost....Which brings me to something i would like to point out.

L vars actually are transmitted during shared pit but unlike the event system which only transmits when something happens they are updated continously. And if you have too many of them you can jam the transmission of both the L vars and events. so....use with caution.

 

[taguilo]

I see what you are suggesting, Tom.

The C gauge can monitor for change in a custom L:var, such as:

(L:18152,enum)

then generate a C event such as

send_key_event(0x18152,enum)

where enum is the value to be passed after evaluating (L:18152,enum)

It is this latter that would be passed along the m-p connection to the remote a/c's C gauge, and acted on locally.

Yes, that's pretty close to what I thought. Now, a bit of trouble arises here in case you need to pass the event code AND a value different from bool check (0-1).
For example, if you have a 4-position switch, you'll need to pass the event ID (0x110nn) and the value (0-4). Obviously this could be handled using two LVars: 0x11001 (>L:MyEventID,number) and 3 (>L:MyEventValue,number) . Instead, I see a more efficient way using decimal numbers directly and only one variable; for example:

-custom event base number is 70000
Sw_pos1 if{ 70001 (>L:MyEvent,number) }
Sw_pos2 if{ 70002 (>L:MyEvent,number) }

In the C++ gauge, "MyEvent" is a registered variable, a one-less call than compared to using execute_calculator_code. "MyEvent" value is % 10 to extract the last digit, for example (pseudocode)

int iValue = MyEvent % 10
int iEvent = MyEvent - iValue

then trigger_key_event(iEvent,iValue)

and to capture:

const int AC_SWITCH  = 70000;

[I]void FSAPI EventHandler(ID32 event, UINT32 evdata, PVOID userdata)
{
     switch(event)
    {
         case AC_SWITCH:
		switch (evdata)
		{
		case 0:
			break;
		case 1:
			break;
		case 2:
			break;          
           etc etc
[/I]

The only "cost" is a one-cycle retard. I believe it should work fine.

Tom

 

[WarpD]

Multiply that by around 100 switches, lights and knobs... and it's a really, really bad idea when it comes to multiplayer/shared cockpit.

 

[n4gix]

I need to set aside some time soon so I can actually test out these various theories within a controlled environment...

I actually have two i7 systems sitting pretty much side-by-side between which I can set up a direct MP/SC session, and test things quickly and throughly...