L: & G: Variables in Multiplayer

[Geoff_D]

AS Quoted in SDK:

When running in the shared cockpit scenario of multi-player mode, local ( L: ) and gauge ( G: ) parameters are synchronized between aircraft. Note also that local and gauge parameters are available to all other gauges in an aircraft panel, so information can be shared among gauges, though care should be taken to name each variable uniquely and clearly.

Although, not docuented as such in the SDK, I believe that also, at least ( L: ) varaiable are sent out in MP, even if the aircraft is not in Shared Cockpit.

This means that if one uses any ( L: ) or ( G: ), these are spewed out in Multiplayer, (if their value changes ?), eating up MP bandwidth, sending this data to every Aircraft in the session.

While this might be nice if you want to do this sharing of data, it does also happen if you just want a local vaiable within your Gauge system.

Developers might consider this and bear it in mind, if feel they have any responsibility not to flood "Multiplayer Sessions" with unnecessary data.

Geoff

 

[n4gix]

I don't believe that they are, Geoff. For that matter, I've found the even L:vars don't work worth a darn in MP, which is one reason why the F-18 in Acceleration uses custom IDs rather than L:vars for the key events.

G:vars are, to my mind, pretty useless since they are only "seen" within the scope of the single "gauge" in which they are used, so that bit from the SDK is just flat wrong. There'd be no point in "sharing" a variable which could not be used!

That's one of my main complaints about the GPS system. It's not even possible to keep the virtual cockpit, 2d panel and popup instance of the GPS in synch!

 

[Geoff_D]

I don't believe that they are, Geoff. For that matter, I've found the even L:vars don't work worth a darn in MP, which is one reason why the F-18 in Acceleration uses custom IDs rather than L:vars for the key events.

G:vars are, to my mind, pretty useless since they are only "seen" within the scope of the single "gauge" in which they are used, so that bit from the SDK is just flat wrong. There'd be no point in "sharing" a variable which could be used!

That's one of my main complaints about the GPS system. It's not even possible to keep the virtual cockpit, 2d panel and popup instance of the GPS in synch!

Bill, Thanks for the every interesting Feedback, and the bit about the SDK being wrong.

Make some sense now though. G:Vars are local to a single Gauge, L:vars are shared between Gauges, and across MP.

But you woud have thought that LOCAL variables would have been CALLED L:var, and SHARED Variables would have been called S:vars !!!
Perhaps that would have cut down on the confusion ? -- Nahhh ---


Not the first time SDK has been incorrect: SDK says that TRANSPONDER variables are not sent out in MP, but obviously they are, or the RADAR could not see each plane's Squawk Code !!!

As far as L:ars are concerned, I have "seem" them flooding MP sessions, when Developers have use them in custom gauges. I doubt if most realize that by using them, they can be causing this flooding.

Geoff

 

[virtuali]

I don't believe that they are, Geoff. For that matter, I've found the even L:vars don't work worth a darn in MP, which is one reason why the F-18 in Acceleration uses custom IDs rather than L:vars for the key events.

Well, being compatible with multiplayer wasn't the main reason why we did it that way, although it was a nice side effect.

Main reason was, the Custom ID area is there just for that reason: to allow developers define their own custom events, to be handled in the same way as the default ones.

With custom events, instead of having to use *two* different pieces of code, one to handle the standard events, and one that polls L: variables to simulate custom events, the code is just the same: ONE keyboard handler, that will receive both default AND custom events, that will be called only when an event (default or custom) actually happened, not constantly at every cycle.

Code is cleaner and simpler to understand (a single big "switch" statement over a single event id), and performances is better too, since there's no polling and it's all event driven, which how is supposed to be.

This, from the point of view of a C++ program. But custom events are useful in XML as well, since one can use the same K: syntax use to custom events as if they were default ones, the only difference would be the custom events use hex codes instead of names.

In fact, I'm very surprised almost nobody uses custom events this way, at least those developing for FSX only should.

 

[n4gix]

This, from the point of view of a C++ program. But custom events are useful in XML as well, since one can use the same K: syntax use to custom events as if they were default ones, the only difference would be the custom events use hex codes instead of names.

In fact, I'm very surprised almost nobody uses custom events this way, at least those developing for FSX only should.

Umberto, I was hoping that you might have chimed in on another thread where I asked if there was any other way than using the <CallbackJumpDragging> prototype.

I really, REALLY hate "dragging" and would much prefer to use Left/Right/Middle click, and WheelUp/WheelDown functions.

From what you've written above, then I should be able to send a Custom Event ID like this?

  <PartInfo>
    <Name>GLEX_Display_Knob_R</Name>
    <AnimLength>100</AnimLength>
    <Animation>
      <Parameter>
        <Code>(L:Display_Knob_R, enum)</Code>
        <Lag>300</Lag>
      </Parameter>
    </Animation>
    <MouseRect>
      <Cursor>Hand</Cursor>
      <MouseFlags>LeftSingle+RightSingle</MouseFlags>
      <CallbackCode>
        (M:Event) 'LeftSingle'  scmi 0 == if{ (>K:0x11000) }
        (M:Event) 'RightSingle' scmi 0 == if{ (>K:0x11001) }
      </CallbackCode>
    </MouseRect>
  </PartInfo>

In this case, the <Animation> L:var would be set by the C++ gauge after processing the CustomEventIDs.

 

[virtuali]

From what you've written above, then I should be able to send a Custom Event ID like this?

I've never used it with an M: event, but I don't see why it shouldn't work, unless there's some bug in the xtomdl compiler that doesn't accept custom events using the M: event syntax.

But it's difficult to say without checking your C++ code: have you setup an event handler properly ? Does it gets called when you fire a custom event ?

To see if the problem is your XML code or your C++ code, try to tag your knob as knob_bingo_bug, I know for sure that one works and, if the custom event is triggered in your C++ code (just put a breakpoint inside your handler routine), you'll know for sure the problem is the XML.

I guess you can also use the knob_bingo_bug as a starting poing for knobs with custom events, perhaps changing it a little bit to suit your preferences for buttons to use.

  <PartInfo>
    <Name>knob_bingo_bug</Name>
    <AnimLength>360</AnimLength>
    <Animation>
      <Parameter>
        <Code>
          (L:knob_bingo_bug,number)
        </Code>
      </Parameter>
    </Animation>
    <MouseRect>
      <Cursor>Hand</Cursor>
      <MouseFlags>LeftSingle+LeftDrag+Wheel</MouseFlags>
      <CallbackJumpDragging>
        <XMovement>
          <Delta>2</Delta>
          <EventIdInc>0x11001</EventIdInc>
          <EventIdDec>0x11002</EventIdDec>
        </XMovement>
      </CallbackJumpDragging>
    </MouseRect>
  </PartInfo>

The knob here rotates 360 degrees in 360 frames, I've setup 4 keyframes at frames 0, 90, 180 and 270. As in your example, XML only fires the event, the L: var that actually rotates the knob is set from C++

 

[n4gix]

I've never used it with an M: event, but I don't see why it shouldn't work, unless there's some bug in the xtomdl compiler that doesn't accept custom events using the M: event syntax.

But it's difficult to say without checking your C++ code: have you setup an event handler properly ? Does it gets called when you fire a custom event ?

Ed Wilson is coding the C++ part of this project, I'm only responsible for the Max model, texturing, and of course the embedded XML scripts. Thus far I haven't gotten anything from Ed with which to check.

I may cobble up a test C++ gauge with an event handler just for debugging purposes, to validate the XML at the very least!

 

[sparouty]

Hi!
Regarding L variable in MP, it seemes that L variables of the VC models are not shared in between players (not tested with shared cockpit), but it is different between exterior models...

I would not say that L variables are "shared" because there are not send from one player to other, but different exterior models drawn by a same player's computer use the same value of L variable.

If you have two similar planes in a MP session : player A and player B.
Player A see his plane, with his own L variable, and he see also the player B's plane manage as a AI plane by player A's FSX session. If player A fires a L variable ( for the drag chute for instance), he will see both plane's dragchute opening but player B doesn't see anything...

After many online tests, I recommand to use only MP FS variables to manage animation of the exterior model...
I hope my two cents helps...
Sylvain