Multi-crew for one huey implemented or not?

[BlacleyCole]

I’m assuming for multiplayer positions you’ll have to be in the multiplayer mode on a multiplayer server correct? And when will it be announced?

[Sneak69]

... And when will it be announced?

 

4+ years ago.

[shagrat]

4+ years ago.

They "announced" that we will have multiple seats (pilot, co-pilot, gunners) we can switch. That was a first in DCS.

In addition, they wanted to "look into the possibility" of making this work in multiplayer, as there was a plan (!) from ED to support dual-cockpit... Or something along those lines.

 

As far as I am aware, the technical implementation for dual-cockpit was introduced with the L-39C and thus after(!) the Huey was coded. From what I've seen in multiple posts here Multiplayer support requires a specific way to code the systems, which is a bit challenging it seems.

 

If they manage to get it to work, they will tell us, for sure.

[QuiGon]

They "announced" that we will have multiple seats (pilot, co-pilot, gunners) we can switch. That was a first in DCS.

In addition, they wanted to "look into the possibility" of making this work in multiplayer, as there was a plan (!) from ED to support dual-cockpit... Or something along those lines.

 

As far as I am aware, the technical implementation for dual-cockpit was introduced with the L-39C and thus after(!) the Huey was coded. From what I've seen in multiple posts here Multiplayer support requires a specific way to code the systems, which is a bit challenging it seems.

 

If they manage to get it to work, they will tell us, for sure.

 

From the very beginning of the Hueys release as a DCS module, the official product description listed the following feature among others:

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

That's pretty clear and distinct.

 

Yes, it is a very challenging task, because, as you said, the Huey has been developed before ED implemented the multicrew tech, which means the Huey needs a huge rebuild to make use of the multicrew tech. That needs time:

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..

Edited March 28, 2018 by QuiGon

[BlacleyCole]

Good at least with multi crew the instructor could sit in the left seat and the student in the right seat this would then take on the rl training environment. Better than now watch a video a flail about until you get it right.

[shagrat]

From the very beginning of the Hueys release as a DCS module, the official product description listed the following feature among others:

That's pretty clear and distinct.

 

Yes, and "later update" does mean they are still on schedule... ;)

 

As far as I remember, they posted some insights during and shortly after the early access, about that plan and that they need a generic support of multicrew in DCS World to work.

 

The most challenging part, from my point of view, is the switching of helicopter controls (cyclic, collective and rudder axis) in real-time.

The only solution that I can think of, is to let the "autopilot" hold parameters/fly straight until the pilot-in-command is synched and then switch control back from autopilot to human.

When I look at the Gazelle the issue with the switches is far more difficult. I don't like for example, that you can't operate the NADIR from the left side.

In the Huey the left-seater should be capable of operating the radios and weapons panel, yet the pilot (right seat) may need to operate the weapons panel as well, or even the radio. If you think if physical switches, I can only think of a configurable separation for each panel, or even better, every switch. That would allow individual configuration.

So much more complicated than IRL... :(

[PeaceSells]

With all the respect, I can't believe it's that complicated to allow a second player to act on the aircraft commands. It doesn't really matter if it's on the hands of ED or Belsimtek to implement the support for multicrew. All this talk about the technical difficulties doesn't really make sense: DCS engine and the Huey were developed by ED/Belsimtek, not some other developer who holds the technology. All the "technical difficulties" is their own code.

[Esac_mirmidon]

You know how to code it?

 

Yes? Then maybe you can share with us how easy or not it is.

 

No? Then how do you know if is difficult or not?

 

PD: Is not only make other players take control, is mainly about MP Coop sync of both players actions at the same time with a stable net code without input lags and desync. Not an easy one to code.

Edited March 28, 2018 by Esac_mirmidon

[PeaceSells]

You know how to code it?

 

If I was part of the staff who did the progam, then yes, I would probably know how to code it.

 

No? Then how do you know if is difficult or not?

 

How do you not know it can't possibly be so difficult that it takes 4 years (or more to come?)

[Esac_mirmidon]

You have the answers in this thread.

 

The MP Coop code wasnt available at Huey´s release. This code was and is beeing developed AFTER. And is still WIP because it needs refinining and tuning.

 

And again if you dont know how to code it you cant say if is difficult or not. The long development time complain is fair and i could agree is taking to much. But is unfair to say is not so complicated when you dont know how to do it.

[shagrat]

If I was part of the staff who did the progam, then yes, I would probably know how to code it.

 

 

 

How do you not know it can't possibly be so difficult that it takes 4 years (or more to come?)

Without any knowledge of the code, just a simple scenario.

Player 1 has configured his input on the Warthog Throttle to use the physical APU switch to switch the fuel pump switch in the Huey. Switch forward = fuel pump on, switch aft = fuel pump off.

Player 2 has a similar configuration.

 

Now Player 1 starts the Huey, flicks the switch up to enable power to the fuel pump.

Now during the flight Player 2 wants to switch weapons and accidentally grabs the fuel pump switch and moves his, to the OFF position. The switch in the Simulation on Player 2's PC follows this input...but due to slight network lag, the Simulated Huey on Player 1's PC never gets the memo. In addition, even if it has no network latency and is in sync the switch on Player 1's Throttle stays in the ON position...

 

Now, how can you ensure that while both Players flick switches and press buttons, maybe even at the exact time and with different inputs, plus the chance of network latency inducing lag and some switch actions never reach the other player's PC you still have a working and consistent cockpit simulation?

 

That is why they likely try to figure out, how to either manage this reliable, or worst case, how to split the controls in a way that functionality is still OK, but you don't interfere with ASM modeling of the electrical and/or hydraulic system simulation!

If Player 1 flicks a generator switch, the Simulation models a flow of electric currents through multiple systems and indicators that are connected to other system models and a bunch of other switches...

 

So just solve this problem and let Belsimtek know. I guess they would be very happy ;)

[shagrat]

And just one effect of a bad sync over network was very noticeable during the early access if the L-39C, was that your plane either had a stalled engine or exploded immediately when spawning, depending on network performance (and that was developed around multi-crew and had the benefit of two separate cockpits).

 

ED optimized the netcode since then, but the root cause (slow or intermittent internet connection) is still an issue and needs consideration.

[hannibal]

still hope, hoping for gunner multiseat!!!!!! :praying hands: emoji

[PeaceSells]

Without any knowledge of the code, just a simple scenario.

Player 1 has configured his input on the Warthog Throttle to use the physical APU switch to switch the fuel pump switch in the Huey. Switch forward = fuel pump on, switch aft = fuel pump off.

Player 2 has a similar configuration.

 

Now Player 1 starts the Huey, flicks the switch up to enable power to the fuel pump.

Now during the flight Player 2 wants to switch weapons and accidentally grabs the fuel pump switch and moves his, to the OFF position. The switch in the Simulation on Player 2's PC follows this input...but due to slight network lag, the Simulated Huey on Player 1's PC never gets the memo. In addition, even if it has no network latency and is in sync the switch on Player 1's Throttle stays in the ON position...

 

Now, how can you ensure that while both Players flick switches and press buttons, maybe even at the exact time and with different inputs, plus the chance of network latency inducing lag and some switch actions never reach the other player's PC you still have a working and consistent cockpit simulation?

 

That is why they likely try to figure out, how to either manage this reliable, or worst case, how to split the controls in a way that functionality is still OK, but you don't interfere with ASM modeling of the electrical and/or hydraulic system simulation!

If Player 1 flicks a generator switch, the Simulation models a flow of electric currents through multiple systems and indicators that are connected to other system models and a bunch of other switches...

 

So just solve this problem and let Belsimtek know. I guess they would be very happy ;)

 

 

Shagrat, imagine you are flying in formation with your wingman, then your wingman crashes into terrain and you never get the "memo", as you desdcribed. You would see your wingman forever flying alongside in with you. But you don't... because ED solved this a long time ago (like all other multiplayer games since more than 20 years ago)... The server is in charge of managing things like that in multiplayer, sending and receiving memos and making sure the ones concerned receive them sooner or later.

[PeaceSells]

You have the answers in this thread.

 

The MP Coop code wasnt available at Huey´s release. This code was and is beeing developed AFTER. And is still WIP because it needs refinining and tuning.

 

And again if you dont know how to code it you cant say if is difficult or not. The long development time complain is fair and i could agree is taking to much. But is unfair to say is not so complicated when you dont know how to do it.

 

I'm not saying it's not complicated, coding regarding games is complicated by nature... I'm saying it's not difficult since they are the ones who created and have the technology of their own engine. If it's that difficult for them, then it's a bad bad sign. This is what I just can't refrain from saying after reading all those posts about all these technical difficulties, as if they're supposed to generate some form of solidarization because they can't solve the technical issues that they created themselves, in order to deliver a feature that they announced themselves.

Edited March 29, 2018 by PeaceSells

[shagrat]

Shagrat, imagine you are flying in formation with your wingman, then your wingman crashes into terrain and you never get the "memo", as you desdcribed. You would see your wingman forever flying alongside in with you. But you don't... because ED solved this a long time ago (like all other multiplayer games since more than 20 years ago)... The server is in charge of managing things like that in multiplayer, sending and receiving memos and making sure the ones concerned receive them sooner or later.

 

Yes, your wingman disappears, because his data, as in Vector data, was not coming over the connection since a while ago, so your client guesses(!) his position and course for a bit, before the timeout makes the other player's aircraft "disappear".

 

In fact you already don't get any input for a couple seconds, but he is a ghost and your PC waits, if he can reconnect. While this happens no button presses, axis changes etc. can be synced as there is no connection.

You may have noticed lag warping, when the connection is intermittent and DCS tries to put the staggered vector info into a position, sometimes placing the other aircraft into your aircraft...

 

And before this comes up, simply caching button presses and send them later is not a solution as we have the detailed internal system modeling I pointed out before. If the electrical system queries switch positions and it has to guess, you won't enjoy your flight.

Left seater presses the trigger, network connection loss for 2 seconds cause a 3 second delay, while the pilot initiates a turn. In the middle of the turn the gun gets the cached trigger press and shoots down your wingman now in front of you... It's just a made up example.

 

As for the other games. There is not one other Simulation that has this depth of system modeling and fully interactive cockpit and multi-crew over Internet, that does not suffer from de-sync, lag or connection timeout. At least I know of none.

 

Anyway they are still working on it, it seems, and they are right on track for any "later update" in the future.

Nobody said "it is easy" or "we will deliver this feature in 4 years".

 

As with a lot complex DCS topics, we will simply need to be patient and wait what the Devs come up with.

[scorpion80]

Didn't wanted to open a flamewar... but i like it.. seems i'm not the only one waiting for.

 

The important thing is that it's still under dev.

 

Thanks to all.

[PeaceSells]

And before this comes up, simply caching button presses and send them later is not a solution as we have the detailed internal system modeling I pointed out before. If the electrical system queries switch positions and it has to guess, you won't enjoy your flight.

Left seater presses the trigger, network connection loss for 2 seconds cause a 3 second delay, while the pilot initiates a turn. In the middle of the turn the gun gets the cached trigger press and shoots down your wingman now in front of you... It's just a made up example.

 

This isn't me coming up with solutions, this is how things already work: bullets are spawned in your client at the time you pull the trigger, and server receives info and keeps track of timings. Otherwise, you would often shoot in directions you didn't aim at when manouveriung, even without multicrew, and this doesn't happen because it's part of netcode that DCS and all multiplayer games have. This is no different if you have many switches or few switches in cockpit, if you have electrical/hydraulic systems modeled or not, principle is the same. You don't "guess" if the other guy has pressed a button or not, you wait till you received the info that he has. Until then he hasn't. Server is responsible to decide the state of such things and inform all parts concerned. Pressing a fuel pump switch isn't more critical than pressing the trigger.

[shagrat]

This isn't me coming up with solutions, this is how things already work: bullets are spawned in your client at the time you pull the trigger, and server receives info and keeps track of timings. Otherwise, you would often shoot in directions you didn't aim at when manouveriung, even without multicrew, and this doesn't happen because it's part of netcode that DCS and all multiplayer games have. This is no different if you have many switches or few switches in cockpit, if you have electrical/hydraulic systems modeled or not, principle is the same. You don't "guess" if the other guy has pressed a button or not, you wait till you received the info that he has. Until then he hasn't. Server is responsible to decide the state of such things and inform all parts concerned. Pressing a fuel pump switch isn't more critical than pressing the trigger.

That is all correct, with the exception, that you refer to the "guy" pressing "a" button.

The challenge is to synchronize "two guys" pressing the same or different "buttons".

 

One guy disables a system with a button, press, but it is lost during sync and the system still works for the other guy... Is the gun or the rocket pod enabled? Depends on the seat you fly in.

[PeaceSells]

One guy disables a system with a button, press, but it is lost during sync and the system still works for the other guy... Is the gun or the rocket pod enabled? Depends on the seat you fly in.

 

Co-pilot presses the button to disable the rocket, but it doesn't get disabled until info is sent to the server. Server then decides that now it's disabled and sends this info back to him and his pilot. Then rocket system gets disabled on both clients. This means some miliseconds delay between you pressing the button and the system getting effectively disabled, but this is normal in multiplayer. If the pilot presses the trigger before receiving the info from server that it's been disabled, then he will fire rockets normally, until he gets the info. But this just for some miliseconds, no actual harm done. It's not like comms (voice or text) between both players is instant anyway.

 

Trust me, ED/Belsimtek knows all this better than me. This can't be the reason for the delay. They just have to put in the man-hours to actually do it, it's what it all comes down to in the end. Not saying it's simple and instant, but you have to put your man-hours into it.

[Sneak69]

Just wish they would update us on it. Keep us in the loop, even if its not going to happen for a long time.

[Silver_Dragon]

Trust me, ED/Belsimtek knows all this better than me. This can't be the reason for the delay. They just have to put in the man-hours to actually do it, it's what it all comes down to in the end. Not saying it's simple and instant, but you have to put your man-hours into it.

 

Remember ED has a good quantity of parallel project on course (DCS World engine / Bug and fixing / EDGE / New features / F/A-18C and others fly modules / Maps / Campaigns and of course, the Professional Military and Civil Projects), the same as BSK and your entertainment and professional modules. Thinks about has only "put more mans on the work" has only a little off the scope actually. Surely ED and BSK has moving your resources of the better way.

Edited March 29, 2018 by Silver_Dragon

[shagrat]

Co-pilot presses the button to disable the rocket, but it doesn't get disabled until info is sent to the server. Server then decides that now it's disabled and sends this info back to him and his pilot.

Do you know the difference between UDP and TCP protocol? There is a reason why most, if not all online games use UDP for data transport, as the C in TCP causes inacceptable delays.

That was what I meant by "caching" inputs on the server...

If you need to wait for an answer from the server before any action (switch, axis input, etc) is executed this accumulates quickly to a couple dozens, then hundreds of cached actions/inputs. Try switching flight controls in the Gazelle to see how this works even if you sync the control inputs directly between the clients without a master server!

Then rocket system gets disabled on both clients. This means some miliseconds delay between you pressing the button and the system getting effectively disabled, but this is normal in multiplayer. If the pilot presses the trigger before receiving the info from server that it's been disabled, then he will fire rockets normally, until he gets the info. But this just for some miliseconds, no actual harm done.

The switch switches between rockets and guns. If you fire a Salvo of rockets instead of a quick burst with the minigun that is a huge difference. Especially as you will miss, because the reticle needs different settings. And we do not even talk about switching control inputs here.

 

The notion of "some milliseconds" is interesting. You double the normal latency, as you need the server to answer, so a 110 msec lag becomes a 220 msec lag.

What do you think is an acceptable lag, before the co pilot should be kicked mid-game?

It's not like comms (voice or text) between both players is instant anyway.

Awww, come on, you don't compare "chat messages" to flight controls and avionics, do you? (DCS does not have voice comms, that is 3rd party stuff like Teamspeak or SRS that has its seperate network stack)

Trust me, ED/Belsimtek knows all this better than me. This can't be the reason for the delay. They just have to put in the man-hours to actually do it, it's what it all comes down to in the end. Not saying it's simple and instant, but you have to put your man-hours into it.

Sorry, but it is hard to trust you with that, as you compare apples to oranges.

I am really wondering if you participated in the L-39C and Gazelle beta phases and have seen the progress from then to now, but also the underlying issues that are hard to come by.

And man-hours can't solve problems, brains and skill solves problems. Sometimes it takes seconds to find a solution, sometimes you realize it takes a complete rework and need to balance gain and effort.

 

Anyway the whole discussion is more or less useless. We can't speed up work by barking up a tree.

 

I simply wanted to give some background from what I know is one of the problems in implementing Dual/Multiseat in MP.

 

They either find a way to solve it or not.

Edited March 29, 2018 by shagrat

[PeaceSells]

If you need to wait for an answer from the server before any action (switch, axis input, etc) is executed this accumulates quickly to a couple dozens, then hundreds of cached actions/inputs.

 

You don't wait for inputs like axis, gun triggers etc., these are instant on your seat and delayed on the co-pilot seat. When you decide to pass control to the co-pilot, he will receive it after the delay and, from then on, he will be the one with the instant commands on his machine. This is nothing new, this is already done by others and I'm sure ED knows how to do that very well. Being high fidelity or not has nothing to do with this, we are talking about control authority and it's the same whether you have 10 or 100 commands.

 

Now if you are talking about having both pilots having control at the same time, I have no idea how to do that, since on the internet ping is never 0 ms. I don't think this is what ED/Belsimtek is aiming for, unless they find a way for all players to have 0 ms ping.

 

The switch switches between rockets and guns. If you fire a Salvo of rockets instead of a quick burst with the minigun that is a huge difference. Especially as you will miss, because the reticle needs different settings. And we do not even talk about switching control inputs here.

 

If it's your co-pilot doing the selector switch, how do you know which is selected before firing? You either have to look down to the switch or rely on his call confirming he has switched. Even he will only be sure that the selector has been switched after his own machine received the confirmation by the server and the switch got effectively flipped on his screen.

 

The notion of "some milliseconds" is interesting. You double the normal latency, as you need the server to answer, so a 110 msec lag becomes a 220 msec lag.

What do you think is an acceptable lag, before the co pilot should be kicked mid-game?

 

Not sure I understand, what do you mean by being kicked? You mean co-pilot being punished because his response to the pilot's requests take milliseconds? A person's normal response is a matter of seconds not milliseconds, I don't see anything wrong there.

 

Awww, come on, you don't compare "chat messages" to flight controls and avionics, do you? (DCS does not have voice comms, that is 3rd party stuff like Teamspeak or SRS that has its seperate network stack)

 

It's always a matter of milliseconds, regardless.

 

Anyway the whole discussion is more or less useless. We can't speed up work by barking up a tree.

 

I don't want to speed up work... I guess what I'm trying to say is that we understand it takes time, and it should take time indeed, but we don't agree with posts that make it sound like Belsimtek/ED are heroes fighting against the monstruous limitations of today's technologies, doing unprecedented work and we should be thankful that they are taking all the time to make sure everything works ok.

[Rub-_-]

it wont come.

 

iIf you want it raise some charts and prepurchases and tell them how much money and customers they would gain, if the put power in this single feature.

 

otherwise they wont care, cause the profit doenst meet the effort.

 

regards from the many years years experiences it professional developer & quality manager with the glass ball.

 

in acdc words: money talks