Thoughts/Discussion of Mixed XML & C

[Waugh]

Background
One can now create a "C", "XML", or "Mixed" gauge. Further, one can create a mixed gauge in at least two ways, either using the C++ Cabin comfort method (newer), or the more basic XML <-> C stuff used in the past.

The newer method allows a more OO approach, but requires a dll.xml entry, rather than just dumping the dll into the gauges directory.

Survey
What do you see as the primary benefit of "mixed mode" (C & XML) gauges? (and/or straight C/XML if desired)

What advantages/disadvantages do you see to the different approaches?

Do you have a different favored approach? Why?

Post your thoughts.

Patrick

 

[n4gix]

For my purposes, I only communicate mouse input from the model to the C gauge via a custom L:var,unit type variable.

For this reason, I much prefer the very simple approach...

Using the custom key input method developed for the F18 is overkill IMHO...

Also, IMHO the use of a custom coded .dll is likewise overly comlex and convoluted.

 

[Waugh]

Bill,

Thanks for your thoughts, although I'm not sure if I get what you are saying.

I know that for any "custom" button that does not yet exist in FS, in the past, I have had to get creative to allow mouse, and custom keyboard/joystick input to control it that is user assignable. Perhaps this is what you mean.

I basically used DirectInput to get any assigned key/button, and then the dll's mouse handler to both pass a "state" to the button object which then used all inputs to "decide" if it was pushed or not.

While, once it is designed and coded it is not that difficult, it certainly invovles a lot. I'm not sure that having the "click" stuff in an XML portion of a working gauge would solve any of the above, so I presume you are talking about something else entirely that I have not considered.

Are you just saying the mouse stuff is easier to handle in the XML vs. the C part? Just curious what you think.

Only benefit I see so far is that it would make it a lot easier for an end-user to change/customize artwork. Anyway, hope this thread sparks some discussion. =)

The new tools are fun to play with as well.

 

[n4gix]

Okay, I'll try to make it more clear...

The task is to create a 3d switch cover for the virtual cockpit and animate/link it to the corresponding 2d version of the switch in a C gauge.

There is a "new method" that ACES created that allows us to create custom event IDs in a model, so that the IDs can be referenced in the panel system or in a SimConnect client. The specific method of implementation is -in my view- unnecessarily complicated and convoluted. YMMV of course.

In addition, since my company is commited to producing concurrent FS9 and FSX versions of the same aircraft, I need a method that will work in both platforms...

What I see as the KISS solution is this:

1) create a new <Animation> and <PartInfo> section in the modeldef.xml file, such as the following, then keyframe animate the part and use the Animation/Attachpoint Tools as usual*:

* N.B. "Translating" the script below to "FS9" format is trivial, and will allow the same solution to work cross-platform with no other modifications to the C gauges.

<Animation name="switch_cover" guid="FD7F7013-28B4-4317-8947-12B3A5ABD8D0" length="50" type="Sim" typeParam2="switch_cover" typeParam="AutoPlay" />


    <PartInfo>
        <Name>switch_cover</Name>
	  <AnimLength>50</AnimLength>
        <Animation>
            <Parameter>
                <Code>
                    (L:SwitchCover,number) 50 *
                </Code>
		    <Lag>200</Lag>
            </Parameter>
        </Animation>
        <MouseRect>
            <Cursor>Hand</Cursor>
		<TooltipText>Open/Close Cover</TooltipText>
		<CallbackCode>(L:SwitchCover,number) ! (&gt;L:SwitchCover,number)</CallbackCode>
        </MouseRect>
    </PartInfo>

Note that the script above will animate the switch cover and also provides the mouse rectangle to enable operation in the virtual cockpit.

2) Add the necessary support to the C gauge to enable bi-directional communications.

a. First we need to "read" the L:variable to detect when/if the status has changed in the VC. This is rediculously simple:

FLOAT64 SwitchCover = 0 ;

	case PANEL_SERVICE_PRE_DRAW:
			execute_calculator_code("(L:SwitchCover,enum)",&SwitchCover,NULL,NULL) ;
	break;

b. Code the mouse callback to set the L:var as needed:

ID SwitchCover_id ;

// Switch Cover
BOOL FSAPI SwitchCover_cb( PPIXPOINT relative_point, FLAGS32 mouse_flags)
{
	SwitchCover_id = check_named_variable ( "SwitchCover" ) ;
	if (SwitchCover == 0) 
	{ set_named_variable_value ( SwitchCover_id, (FLOAT64)1.0 ) ; }
	else { set_named_variable_value ( SwitchCover_id, (FLOAT64)0.0 ) ; }
}

c. Use the same L:var to control the 2d bitmap appearance

// Switch Cover
FLOAT64 FSAPI SwitchCover_cb( PELEMENT_ICON pelement)
{
	FLOAT64 val=pelement->source_var.var_value.n;
	if ( SwitchCover == 1 ) 
		{ val = 0 ; } 
	else { val = -1 ; }
	return val;
}

 

[Waugh]

I understand what you are refering to now. Yes, I have just now been exploring this custom event thing, and my early opinion is that it appears that the method will be more valuable when one is coding in an OO way, vs. using more c-like code.

I'm just now putting together a new more "de-coupled" way of doing things that lends itself more to code/object re-use.

I'll post more when I have something concrete.

Patrick

 

[n4gix]

Regardless of the method used, the XML scripting for the model remains fairly consistent. For example:

  <PartInfo>
    <Name>switch_guard_fire_l</Name>
    <AnimLength>100</AnimLength>
    <Animation>
      <Parameter>
        <Code>
          (L:switch_guard_fire_l,number) 100 *
        </Code>
        <Lag>400</Lag>
      </Parameter>
    </Animation>
    <MouseRect>
      <Cursor>Hand</Cursor>
      <MouseFlags>LeftSingle</MouseFlags>
      <EventID>0x00011003</EventID>
    </MouseRect>
  </PartInfo>

Even though the mouse_event specifies a unique <EventID>, the C code must still read this EventID, then send the (L:switch_guard_fire_1,number) data back to the model.

The only real difference is that using this new method moves ALL "logic" to the C gauge, which admittedly has the advantage of making the entire system easier to maintain...

...particularly so if the 3d modeler and the programmer aren't the same person...

So, instead of monitoring a whole bunch of unique L:vars, one need only monitor for any EventID, then use a case callback to determine what action to take based on the specific EventID.

It's instructive to note that while the F18 uses this new method, the EH101 uses the method I've described in my post above. Clearly then there are cases where one method may be more advantageous than the other...