FSXA Gauges in multiplayer shared cockpit

[Roy Holmes]

I'm working on a F-105F, the two seat Thud, for multiplayer use with the two cockpits occupied. I have never developed anything for shared cockpit use, nor flown in a shared cockpit so far and I'm curious about how it will work.

In general, the rear cockpit is similar to the front and flying by myself, I can control things almost equally well in either cockpit. I have a mix of 2D and 3D gauges and I have found that the 2D ones work in both, but the mouse areas for the 3D ones only work in the front, possibly because the rear 3D gauges are exact copies of the front ones.

The F-105F had lights that showed who had control of various systems somewhat similar to the F-4 where the radios had lights that showed who was in control. I can code those lights according to which cockpit made the last selection.

My question is will what I see and can control when flying solo in the rear cockpit be the same as another pilot flying in multiplayer can see and control?

I'd like to have some insight on this before I decide what should or should not be in the rear cockpit

I have attached pics of the exterior, front and back cockpits as they are currently

Roy

 

[n4gix]

When you clone/copy objects, the Mouse and Animation content is not copied. Only the Attachpoint entries are copied.

This means that you need to use the Attachpoint Mouse and Animation assignments again.

Multiplayer is easy, but the Shared Cockpit is not. This is because XML mouse events aren't transmitted across the network to the other cockpit. I know the "theory" of how it's done, but have not -as yet- done it myself.

If you examine the scripts used by the two Acceleration models (F-18 and EH101) you'll notice that the mouse events are all Custom EventIDs. This means that you need a C "helper gauge" that will interpret the CEIDs, then issule the appropriate XML actions for use by both the local and the networked aircraft's panel/gauge system.

In short, only C type key_events are sent across the network...

 

[Roy Holmes]

Bill,
Thanks, it will be interesting for sure. I expect to have the opportunity to try it out within a couple of weeks and I'll post my findings.

Actually, the copied 3D gauges do animate, though the mouse rectangle is absent. Could be an FSDS thing. There was only one 3D gauge (HSI) that had a mouse input and I made a 2D version for the rear seat for that reason and because I wanted it display different things than the front one does.

I do not see any problems with not passing mouse key events between cockpits, I'm hoping, but unsure that L: vars may be passed.

Thanks again,
Roy

 

[Au-MaV]

Hi Roy
Yeah its a fsds thing you need to make a copy of the code and rename it (on the texan I prefaced all the parts front_partname rear_partname) It appears that any dupes of the same part drop the mouse code at compile time
Wozza

 

[n4gix]

Bill,
I do not see any problems with not passing mouse key events between cockpits, I'm hoping, but unsure that L: vars may be passed.

(L:var,unit) are passed, it is the custom events such as (>LoSomething) that aren't passed. Hence the need for a C helper gauge to translate for us.

          <EventIDInc>0x11000</EventIDInc>
          <EventIDDec>0x11001</EventIDDec>

 

[Roy Holmes]

Hi Wozza,
You make a very good point. If you have a dupe, it is best to identify the difference at the beginning of the name, not the end. If you have two modeldef entries like wozza_roy_HSI_front and wozza_roy_HSI_back, FSDS grabs the first one it sees. Change them to front_wozza_roy_HSI and back_wozza_roy_HSI and they are two different animals as far as FSDS is concerned. The names are just as meaningful. Good example of how FSDS can screw up multiple part names is lever_throttle.

If the order in modeldef, top to bottom is
lever_throttle
lever_throttle0
lever_throttle1
lever_throttle2
lever_throttle3
FSDS will only associate a mouse rectangle with lever_throttle and if you actually have lever_throtle0 through lever_throttle3, only lever_throttle0 will have the mouse rectangle. The effect is the same as if you had called the engine 1 throttle, lever_throttle.

However, if you change the order in modeldef to:
lever_throttle0
lever_throttle1
lever_throttle2
lever_throttle3
lever_throttle
So the generic lever_throttle is at the end,
FSDS will associate a mouse rectangle with all four.
Alternately you can just delete lever_throttle.

Same applies to all other multiple parts, shift the generic to after the specific or delete the generic and FSDS handles it OK. A good check is in the compile log, if you only had one entry for lever_throttle, then you will only have one mouse rectangle. On the other hand, if the compile log has separate entries for each throttle they will all have mouse rectangles.

But I do like your idea of putting the specific identifier at the front when you create new modeldef entries for duplicate or multiple parts.

Thanks for nudging my aged brain into remembering things!

Roy

 

[chrisdub]

My tests showed the following results

L: variables in multiplayer shared cockpit are transferred , unfortunately at a very slow speed, sometime more than 10 mn for one variable. The more L: var then the more slow it will be.

Using the FS10 Gauge header and the serialized callback function is working but it wont work if you have many L: var transmitted at the same time because this will just jam the connection between the 2 users.

Your only solution is to connect the 2 planes via an external program on top of the default multiplayer shared cockpit.

 

[Roy Holmes]

Having started this thread, I'm duty bound to sum up what I have found.

Since the other pilot was unfamiliar with the details of each cockpit, I was able to talk him through the switches and displays. I pressed a switch and he saw the result immediately. It made no difference whether the switch was controlled by A: or L variable state.

The pilot not in command had control of everything except flight controls and throttle. Or at least I saw no evidence to the contrary.

The only conflict or issue I saw was that when a frequency change was made in one cockpit, the other one saw the frequency flickering between settings. However this was due to the way I coded the frequency setting and I need to code an "in command" state that would only allow one cockpit to change frequency at any one time.

Basically I was surprised at how well it all turned out

Roy