Multi-crew for one huey implemented or not?

[Sandman1330]

Would you as a customer feel ok, with your car coming with a notice, that "in order to have the brakes work as advertised, you simply need to keep the steering wheel centered and the indicators must be off", or would you like the manufacturer to fix that or find a better solution?

 

My guess is, they want to make it right... And very speculative guess: with the Hind and Cobra in the works and the F-14 on the horizon, maybe they are working on AI Co-Pilot(s) similar to Jester AI?

 

Again, I would be very happy with a simple navigator / ride along seat for the time being.

 

Perhaps I’m misunderstanding you, but I don’t follow the connection... All I’m saying is that one can use the control indicator to ensure his control axis are lined up with the other players before handing over control. Without truly connected controls, I don’t see any other way around it. If this isn’t an acceptable solution for you, I guess we will just need to agree to disagree.

[Sharkku]

I suggest the logic for stick and cyclic input should work like this:

A value for the amount of movement should be determined for all axis combined, stick and collective. Pilot and co-pilot each have their own value. If the value is above a low threshold, then that person is considered active. If both are active, then the inputs should be averaged. If one person is moving his controls less, the average should shift weight towards the one moving more. If one stops movement below the threshold, the control should go to the other, smoothed over 1-2 seconds or less.

 

When i talk about amount of movement, I don't mean amount of static deflection, but actual movement, the derivative.

 

With this logic, both pilots can fight each other, the result being no input, or each can take over when the other stops moving the stick. Pilots will have to communicate who has the control, and transitions should be smooth. The threshold serves to eliminate axis jitter causing an inactive stick to be determined active. Thoughts?

[shagrat]

I suggest the logic for stick and cyclic input should work like this:

A value for the amount of movement should be determined for all axis combined, stick and collective. Pilot and co-pilot each have their own value. If the value is above a low threshold, then that person is considered active. If both are active, then the inputs should be averaged. If one person is moving his controls less, the average should shift weight towards the one moving more. If one stops movement below the threshold, the control should go to the other, smoothed over 1-2 seconds or less.

 

When i talk about amount of movement, I don't mean amount of static deflection, but actual movement, the derivative.

 

With this logic, both pilots can fight each other, the result being no input, or each can take over when the other stops moving the stick. Pilots will have to communicate who has the control, and transitions should be smooth. The threshold serves to eliminate axis jitter causing an inactive stick to be determined active. Thoughts?

My proposal in the SA-342 Gazelle thread a while ago was, to activate the AI (Auto-Pilot) on the active Pilot's "you have control"-click , while Autopilot controls the axis, transfer the complete flight model and system modeling to the second client, then on the " I have control "-click, "deactivate" AI Autopilot and transfer axis back to the new pilot.

That still won't solve the issue with the buttons not synced, but it could solve the network lag and transition issues.

 

Problem is, it is just an idea and we don't know if it is "easy" to implement, or working at all, with no details that only the developers know.

 

We need to be patient and see what ED is coming up with.

[LithiumR]

Again, I would be very happy with a simple navigator / ride along seat for the time being.

 

If I could just load my friends up (or just a friend) as gunners only I would be happy. It would be so badass to go cruising through the valleys with my friends as gunners. I would buy them all the module lol.

[_schepper_]

If I could just load my friends up (or just a friend) as gunners only I would be happy. It would be so badass to go cruising through the valleys with my friends as gunners. I would buy them all the module lol.

Me too :D

 

Verstuurd vanaf mijn SM-J510FN met Tapatalk

[Robert31178]

You'd all die in fiery crashes lol...the only way I survive in a Huey is because of the mini-gun snipers I roll with......

[_schepper_]

You'd all die in fiery crashes lol...the only way I survive in a Huey is because of the mini-gun snipers I roll with......

We will not die... iff the only targets are cows ;)

 

Verstuurd vanaf mijn SM-J510FN met Tapatalk

[crow0827]

when is it coming?

[Rub-_-]

looooooooooooooooooooooool

[Berniyh]

You can't send confirmations back and forth over a UDP connection. On a TCP connection the latency increases and performance will be reduced tremendously. On a typical asynchronous connection (more download bandwidth than upload bandwidth) with higher numbers of players you may clog the connection with ACK and re-send packages need to be acknowledged again, thus some info can be delayed for more than a "couple" dozen milliseconds.

Quite honestly, this can't be that big of a deal.

 

 

We're racing close to each other in racing sims with only centimeters between the cars online and it is working out.

Flipping switches in a flight sim just can't be that big of a deal.

 

 

The only (and main) issue is what happens if you have opposing inputs on the same function, but that can be circumvented e.g. by defining master controls and slave controls (possibly differently for different parts in the cockpit) + corresponding notification if a mismatch occurs.

[shagrat]

Quite honestly, this can't be that big of a deal.

 

 

We're racing close to each other in racing sims with only centimeters between the cars online and it is working out.

Flipping switches in a flight sim just can't be that big of a deal.

 

 

The only (and main) issue is what happens if you have opposing inputs on the same function, but that can be circumvented e.g. by defining master controls and slave controls (possibly differently for different parts in the cockpit) + corresponding notification if a mismatch occurs.

For starters, add a world simulation of a 350*350 NM area outside the racetrack, with two regiments of armor fighting each other, add ballistic calculations and collision query for all objects including bullets flying around and see how that works out...

[Berniyh]

For starters, add a world simulation of a 350*350 NM area outside the racetrack, with two regiments of armor fighting each other, add ballistic calculations and collision query for all objects including bullets flying around and see how that works out...

All of which has absolutely nothing to do with the problem at hands.

[shagrat]

All of which has absolutely nothing to do with the problem at hands.

The server needs to handle and sync that in parallel between the clients, so that is clogging the network bandwidth.

A dozen cars on a racetrack with basically two to three axis and a handful switches to sync isn't really a good comparison...

[chief]

The server needs to handle and sync that in parallel between the clients, so that is clogging the network bandwidth.

A dozen cars on a racetrack with basically two to three axis and a handful switches to sync isn't really a good comparison...

 

It's called making the connection between the two pilots sharing the cockpit peer to peer. They do it in P3d using vatsim and that dwarfs the 350 by 350 NM map we are in. Also try having 50+ other aircraft within 5 NM of your aircraft not to mention the other 1000+ on the network. So... It can easily be done

[Robert31178]

Chief and Bern......I mean, you could always write the code for ED/BST yourself?

[shagrat]

So... It can easily be done

 

Yep, definitely. I am positive ED is not implementing it on purpose. It is just a 3 hours task, but they simply love this discussions too much, to just do it...

 

Maybe you can quickly show it in a Mod, just in case ED does not know how "easily" it can be done...

 

EDIT: ...and peer to peer does not reduce the traffic from the server to the client, with the rest of the world syncing to each client what to show around him. I have also elaborated already, why latency ( in a peer to peer connection, that is how it actually is done already) still causes problems, with lag and inconsistency.

Edited November 2, 2018 by shagrat

[QuiGon]

An update on the development status of multicrewing for the Huey would be really appreciated though, as the last one is now almost a year old and there they said it should only take a couple of months untill the feature goes live:

Hi guys! Multicrew was one of the topics we wanted to roll out as news article, but since you are active here recently, we will address it here.

 

First of all we want to say that we don't want to run from what we said. Multicrew will be done and its progressing. Yes it taking its time and we can only be grateful for your patience!

 

Things with helicopter multicrew are not exactly same as in, for instance, L-39. It is because L-39 have two separate cockpits, therefore two clients have each their own accessible controls to fiddle with. But its changing when you have two guys at the same cockpit and both of them have access to whole cockpit, things are getting tricky that way and we tried to dance around those issues we faced. And as solution so far we see separation of available commands for pilot and co-pilot with which we are working right now.

 

As of now we have implementation for multicrew and we are testing it and resolving surfaced issues. Testing process taking its toll, it should go through different testers ours and ED..

 

At this point we think its a matter of months until multicrew patch for Huey will go live, if no critical showstopper issues will appear.

 

Besides that, there is more changes for UH-1H, that are coming even sooner... You will hear about them soon..

So, what's going on?

[Berniyh]

The server needs to handle and sync that in parallel between the clients, so that is clogging the network bandwidth.

A dozen cars on a racetrack with basically two to three axis and a handful switches to sync isn't really a good comparison...

This sort of thing takes next to no bandwidth at all, since you only need to send something over the network if something on either side changes, which quite frankly is not very often (in comparison to everything you noted).

The only thing that could be bandwidth-heavy are the actual axis controls (since those change their state permanently), but that was not what was discussed in the post that I quoted.

 

 

And actually sync between the axis controls only makes sence for axis with force feedback, otherwise you have to separate them anyway (and switch on command).

FFB is a valid use case, but I think most people would be ok with the first version not implementing control sync via FFB.

 

Chief and Bern......I mean, you could always write the code for ED/BST yourself?

What are you trying to accomplish? Just silence the discussion?

Of course I can't write it myself, because I don't have the current code at my hands.

 

 

But that's not the point. I was quoting a post by shagrat that didn't talk about code specifics (most likely because he hasn't seen it either) and just was commenting on that in general that it should not be an issue.

shagrat talks about this as if DCS were the first game that allows people to play things on the internet, which … well we all know that it's not.

 

 

Don't get me wrong. Multiplayer over the internet is a huge task and there are significant challenges, some of which are unique to flight sims.

But syncing buttons is not a huge task.

Even for 500 buttons, we're talking about a few kB/s at maximum if you do it in the very unefficient way to send everything all the time. If you do it efficiently (event based, so only an event for a specific button if the state changed) it's less and non-continuous.

 

 

 

If there are setbacks on this topic (which seems to be the case), I seriously doubt they are related to this, but rather that there are other signiificant issues.

[EagleEye]

An update on the development status of multicrewing for the Huey would be really appreciated though, as the last one is now almost a year old and there they said it should only take a couple of months untill the feature goes live:

So, what's going on?

Yeah, thats the thing I dont like about (former) Belsimtek. After that post from belsimtek I thought communication about their modules would go uphill, it doesnt.:cry:

[rogonaut]

bumped ! :)

[shagrat]

This sort of thing takes next to no bandwidth at all, since you only need to send something over the network if something on either side changes, which quite frankly is not very often (in comparison to everything you noted).

The only thing that could be bandwidth-heavy are the actual axis controls (since those change their state permanently), but that was not what was discussed in the post that I quoted.

 

 

And actually sync between the axis controls only makes sence for axis with force feedback, otherwise you have to separate them anyway (and switch on command).

FFB is a valid use case, but I think most people would be ok with the first version not implementing control sync via FFB.

 

 

What are you trying to accomplish? Just silence the discussion?

Of course I can't write it myself, because I don't have the current code at my hands.

 

 

But that's not the point. I was quoting a post by shagrat that didn't talk about code specifics (most likely because he hasn't seen it either) and just was commenting on that in general that it should not be an issue.

shagrat talks about this as if DCS were the first game that allows people to play things on the internet, which … well we all know that it's not.

 

 

Don't get me wrong. Multiplayer over the internet is a huge task and there are significant challenges, some of which are unique to flight sims.

But syncing buttons is not a huge task.

Even for 500 buttons, we're talking about a few kB/s at maximum if you do it in the very unefficient way to send everything all the time. If you do it efficiently (event based, so only an event for a specific button if the state changed) it's less and non-continuous.

 

 

 

If there are setbacks on this topic (which seems to be the case), I seriously doubt they are related to this, but rather that there are other signiificant issues.

I explained in this thread, why it isn't just "syncing", as in a helicopter button states and for example concurring switch positions plus latency need to be tied into the systems modeling on the PC that calculates the internal systems, adding a tournaround latency of double the ping, axis have issues... etc., etc. etc.

 

Not going to discuss this again. They need to do much more than just syncing buttons, for anything with an advanced system modeling.

 

For the Huey and Mi-8 the code and API for Multiplayer dual-cockpit wasn't available (introduced with the L-39C and that has individual switches for each pilot), so basically they need to redo the ASM and create a solution for two people touching the same virtual switch in the sim, at the same time, while actually they operate two different physical switches on their HOTAS on two different PCs, while you can't control the network latency to ensure instantaneous sync and thus consistency... for starters.

Edited November 2, 2018 by shagrat

[Johnny_Rico]

Really hope this comes, been waiting years for it, the huey if Iam not mistaken had this "feature" listed in the sale page did it not ?

[hazzer]

Really hope this comes, been waiting years for it, the huey if Iam not mistaken had this "feature" listed in the sale page did it not ?

 

It did indeed, also for the mi8.

[shagrat]

Really hope this comes, been waiting years for it, the huey if Iam not mistaken had this "feature" listed in the sale page did it not ?

Actually, it had not. It had "multiseat" advertised and it was the first module, that allowed us to switch seats in an aircraft and take different positions as pilot, co-pilot/commander or door gunner. It was implemented in a way that you could use it in multiplayer (AI "co-pilot").

As at that point in time multicrew, as in "flying together in one aircraft", was not implemented in DCS World this was what they could do and what they did.

 

The confusion comes from the statements that where published on the forums, that ED was looking into a multicrew feature and are actively developing this. Belsimtek said they would look into this feature when available and see if they can implement it to the Huey and later the Mi-8. They were pretty confident in their words, but they made clear it is something depending on ED to implement, first.

It turned out, with the L-39C that the way it was implemented caused issues with the old system modeling... and the rest of the story we know.

 

I am desperate to get this feature myself. I even cannot understand, why we didn't at least get a passive navigator/instructor seat, that can monitor the gauges and help navigating, without the need to touch one single button...

[schroedi]

Actually, it had not. It had "multiseat" advertised and it was the first module, that allowed us to switch seats in an aircraft and take different positions as pilot, co-pilot/commander or door gunner. It was implemented in a way that you could use it in multiplayer (AI "co-pilot").

 

That's not correct, Belsimtek changed it after some time.

The original text was:

"Multiplayer coop mode for crew members of the same helicopter under development for a later update."

 

Look under Key features:

https://web.archive.org/web/20160117033859/http://www.digitalcombatsimulator.com:80/en/products/helicopters/huey/