Multiplayer features: Shared carrier and dual control

[AndersG]

Hi,

Some of you might know about these experiments already, but a bit of a publicity never hurts..

The add-ons need FlightGear version 1.0.0 or newer (i.e. developers version FlightGear/CVS).

MP Nimitz [edit]Now available in FlightGear/CVS[/edit]

Have you ever wanted to steer Nimitz or perhaps wished that the carrier was in the same position for all multiplayer pilots?

Then my MPCarrier might be the answer:
It adds a Nimitz vehicle to your aircraft list, but also adds support for
synchronizing the standard AI Nimitz carrier (in the AI scenario nimitz_demo) with a pilot steering Nimitz on the multiplayer network.
This way everyone synchronizing with the same Nimitz player will see the carrier in the same location.

Usage: Add to your FlightGear command line:

Code: Select all

--prop:/sim/mp-carriers/nimitz-callsign=<mp-nimitz player's callsign>

Install in data/Aircraft like any other aircraft.

Get the archive here:
http://www.gidenstam.org/FlightGear/mis ... r_over_MP/

c172p dual control [edit]Dual control is available for some aircraft in FlightGear 1.9.x and FlightGear/CVS. Among them Zeppelin NT (1.9.1), Buccaneer (1.9.1) and F-14b (CVS)[/edit]

Ever wanted to share your aircraft with somebody else on the multiplayer network?

It can be done as this experimental aircraft demonstrates. The copilot can control all primary flight controls, throttle, mixture, brakes, cockpit switches and many functions of the radios and the navigational equipment.
(Lag can be a bit of a problem, though. Some of it is due to imperfections in the MP system so there is hope for improvements)

Pilot usage: Add to command line:

Code: Select all

--aircraft=c172p-pilot --prop:/sim/remote/pilot-callsign=<the copilot>

Copilot usage: Add to command line:

Code: Select all

--aircraft=c172p-copilot --prop:/sim/remote/pilot-callsign=<the pilot>

Install in data/Aircraft like any other aircraft. The archive is here:
http://www.gidenstam.org/FlightGear/Dua ... CVS.tar.gz

Check for new versions and news here:
http://www.gidenstam.org/FlightGear/DualControl/

Cheers,

Anders


[edit]
Changed dual control URLs since I moved it to a new place.
Removed obsolete information.
[/edit]

[technobill]

How does this go for Macs?

[AndersG]

How does this go for Macs?

As far as I can see there should be no trouble - neither of these use anything outside "standard" FlightGear capabilities.

/Anders

[AndersG]

Oups.. my in last version of MPCarrier the speed control was broken. A new working version is up now. There is also a very experimental integration with the ATC aircraft but it has some problems still.

http://www.gidenstam.org/FlightGear/mis ... r_over_MP/

/Anders

[MD-Terp]

So, I was online this afternoon (what was it -- about 3p-4p Eastern, so about 8p-9p GMT?) and noticed that some people were messing with the Multi-Player Carrier. At the time I was on, there were two people piloting carriers; one under the name "Nimitz" and one "morteno".

I use the Windows 1.0.0 release. I downloaded the MP Carrier and (after struggling a bit with Vista and its propensity to make "phantom directories") got it unpacked into the right subfolder location.

I started off setting my command line for "Nimitz" but wound up on an AI carrier. I tried again using "morteno" and it worked fine. I then tried to go back to "Nimitz" but I noticed an error message in the launch window -- something along the lines of "MP Carrier -- user invalid, using incorrect vehicle".

As I switched the command line back and forth from "Nimitz" to "morteno", I noticed that about 50% of the time I tried "morteno" it would work (the other half I would get the above message), but never was it successful in connecting with the one calling himself "Nimitz".

Is there something I need to adjust on my end? There was another pilot who mentioned something I needed to add to one of the xml configuration files but now, hours later, I can't recall what he said. Plus I am at work now and not able to look around for it. I'm hoping that by the time I get off of work, a nice answer will be posted here, so I can play again tomorrow! Smile

Anyway, the times that it did manage to work, it was a lot of fun -- made my first successful approach just after morteno had sailed under the Golden Gate, which made life a little harder trying to fly a carrier approach with a big orange bridge right in my path... lol...

[AndersG]

I started off setting my command line for "Nimitz" but wound up on an AI carrier. I tried again using "morteno" and it worked fine. I then tried to go back to "Nimitz" but I noticed an error message in the launch window -- something along the lines of "MP Carrier -- user invalid, using incorrect vehicle".

As I switched the command line back and forth from "Nimitz" to "morteno", I noticed that about 50% of the time I tried "morteno" it would work (the other half I would get the above message), but never was it successful in connecting with the one calling himself "Nimitz".

The client side MP-Nimitz Nasal module had a clever function that tried to prevent you from accidentally latching your AI carrier to a player flying an aircraft. Unfortunately it didn't work when there were several mp-nimitz vehicles on the network. The test is removed in the latest version.

/Anders

[MD-Terp]

The client side MP-Nimitz Nasal module had a clever function that tried to prevent you from accidentally latching your AI carrier to a player flying an aircraft. Unfortunately it didn't work when there were several mp-nimitz vehicles on the network. The test is removed in the latest version.

First of all -- so, I should just delete the MPCarrier folder under /data/Aircraft and download it again? The corrected version is online?

Second -- does that mean that we now *can* attach it to a player flying a plane? I bet that would increase the difficulty level of a successful approach, exponentially... hahahahaha... "Can you fly straight and level, please? I'm trying to land on you!"

Thanks for the prompt reply!

[AndersG]

First of all -- so, I should just delete the MPCarrier folder under /data/Aircraft and download it again? The corrected version is online?

Yes, that is probably the safest way to update. This time there are no changes in the number of files and file names, though so just unpacking on top of the old one ought to work too.

Second -- does that mean that we now *can* attach it to a player flying a plane? I bet that would increase the difficulty level of a successful approach, exponentially... hahahahaha... "Can you fly straight and level, please? I'm trying to land on you!"

That probably only works when more than 200m away, that is, while the AI carrier is teleported to the carrier player's position. Once you get closer the teleporting is stopped and the AI carriers own physics model controls the carrier's behaviour. It might plummet at that point...

/Anders

[MD-Terp]

Well I did so and am now playing around with commanding the carrier. I seem to be intermittently disappearing from MP server 04. Any idea why?

It reminds me of that movie from the early 80's called "The Final Countdown" -- how the carrier would disappear and reappear from the scopes just before being transported back in time to 1941. I believe, in fact, that the carrier involved in the storyline was in fact the Nimitz...

If you've never seen it, it's a hoot of a movie, if a little silly...

[AndersG]

Well I did so and am now playing around with commanding the carrier. I seem to be intermittently disappearing from MP server 04. Any idea why?

Nope, I have no idea why that happens. When testing I thought it was due to me lowering the update packet rate for my Nimitz player (I have a fairly low B/W connection) but other people most likely don't do that. It could be some how caused by the constant teleporting of the player's "aircraft", but I don't see that happening for the c172p-copilot which use the same mechanism.

/Anders

[MD-Terp]

Anders --

Today, myself and two other users played around with the MP Carrier some more. We had some frustrating problems that hopefully you can look into and work out. This is not to be taken as a complaint but more of a bug report for your examination.

The carrier was piloted by the user Jester (who logged on as "Nimitz"... LOL; I always thought his name was CHESTER Nimitz but whatever! ) Myself and someone called "franck" were in Seahawks alternating approaches.

Jester Nimitz was set up just off of KSFO bearing about 050-060 about 3-4 nm from the terminal at a constant heading of the same, steaming at about 4 knots, or so he said. However, Franck and I both reported that the carrier would turn sharply while we were each on our short finals. A couple times we were able to catch the wire anyway, but most of the time we had to bolter and set up again only to have the same thing happen.

Jester swore he was at a constant speed and heading, and I have no reason to believe he was messing with us.

We speculated that the program was trying to reconcile discrepancies in the carrier position for our three respective programs. This seemed to be corroborated on one occasion as I was on a left downwind, abeam, panned over watching the deck as Franck landed. He seemed to hover about 100 yards ahead of and slightly to the right of the deck. Of course from his vantage I'm sure he was aboard the Nimitz.

Can you shed any light on this? While the three of us had fun shooting the repeated approaches, it would have been a bit more rewarding to hit some more of them given a (relatively) stable and predictable target!

Thanks for any insight and, hopefully eventually, corrections you can provide.

[AndersG]

Anders --
Jester Nimitz was set up just off of KSFO bearing about 050-060 about 3-4 nm from the terminal at a constant heading of the same, steaming at about 4 knots, or so he said. However, Franck and I both reported that the carrier would turn sharply while we were each on our short finals. A couple times we were able to catch the wire anyway, but most of the time we had to bolter and set up again only to have the same thing happen.

Jester swore he was at a constant speed and heading, and I have no reason to believe he was messing with us.

I have gotten other reports about this kind of turns too. But it is a mystery how it can happen. Could you keep an eye on the carrier's rudder position with the property browser? It is in /ai/models/carrier/surface-positions/rudder-pos-deg .

We speculated that the program was trying to reconcile discrepancies in the carrier position for our three respective programs. This seemed to be corroborated on one occasion as I was on a left downwind, abeam, panned over watching the deck as Franck landed. He seemed to hover about 100 yards ahead of and slightly to the right of the deck. Of course from his vantage I'm sure he was aboard the Nimitz.

The mp-carrier operates in two modes - when you is further than 200 meters from (the center of) it the carrier is latched to the position and orientation of the Nimitz player. When closer than 200m the carrier acts according to its FDM but with base-speed and rudder-position set by the Nimitz player. You could try increasing this distance in mp-nimitz.xml then the carrier would stop teleporting earlier.

At least for me FlightGear with MP runs unevenly with lots of model loading stutters around KSFO. Each such stutter adds to the divergence between the local AI carrier position and the position of the Nimitz player when on deck. This also holds to some extent when in the air since the buffering of MP data gets confused - I often see MP aircraft movement being replayed.
But this still doesn't explain the turns.

Testing far away from the MP hotspot might shed some more light.

Cheers,

Anders

[AndersG]

Some further thoughts:

As far as I can see the only plausible explanation for the turns is that Nimitz reverts to it's AI behaviour, i.e. it'll set course back to it's designated area of operations west of the Golden Gate bridge. This could happen if the mp-nimitz Nasal code stops setting the rudder command every frame. Some possible causes are:
1. The local fgfs instance decided the Nimitz player went off-line. Given the (unexplained) intermittent behaviour of mp-nimitz on the multiplayer network this doesn't look unlikely.
2. Some other player using mp-nimitz left MP and that caused all mp-nimitz update loops to die. This is also plausible. When/How/Why the load/unload is called in the presence of multiple instances of a model is a bit of a mystery to me so my handling of that in mp-nimitz could easily have errors.

Cheers,

Anders

[glazmax]

Great work on the mp-nimitz!

Jester Nimitz reminds me somehow of Tyler Durden (Fight Club) .

One thought I had about the lag spike discrepancies: Is it possible to latch the aircraft to the nimitz when parking brake applied? So the position on deck of the "own" nimitz would be sent to the mp-nimitz and synchronized. If parking brake is released, nimitz reacts with its own FDM again.

And another thought: As discussed on multiplayer yesterday, the callsign adjustment is sometimes troublesome, because the mp-carrier does not show up in mpmap. A possible solution would be to include a fixed startup callsign=Nimitz within the preferences.xml. So first come, first serve principle, meaning the first player that selects the mp callsign Nimitz represents the mp-nimitz.

sail on,
glazmax

[MD-Terp]

Is it possible to latch the aircraft to the nimitz when parking brake applied? So the position on deck of the "own" nimitz would be sent to the mp-nimitz and synchronized. If parking brake is released, nimitz reacts with its own FDM again.

Two thoughts -- (1) when approaching a carrier I often set the parking brake in advance, to assist the wire in getting the plane stopped. I know this is not strict real-world procedure, but I know that others do it as well. So the parking brake might be set even if the plane is not on the deck just yet. (2) what about more than one plane on the deck?

And another thought: As discussed on multiplayer yesterday, the callsign adjustment is sometimes troublesome, because the mp-carrier does not show up in mpmap. A possible solution would be to include a fixed startup callsign=Nimitz within the preferences.xml. So first come, first serve principle, meaning the first player that selects the mp callsign Nimitz represents the mp-nimitz.

The MP Carrier does indeed show up, but intermittently. In my launcher (I use the Windows release) I just added that whole paramater to the startup command and thus far I have left it saying "Nimitz". But before I launch Flightgear I have been checking the MP map to see if anyone else is logged in and selected the mp-carrier as their vehicle type, and if so, upon opening the lancher I just hit "Prev" and change the end to the appropriate callsign.

You Linux-environment users may get more benefit from a "standard" Nimitz callsign but for those of us running from the launcher it doesn't seem to me to be a big deal...