Multi-crew for one huey implemented or not?

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?)

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 ;)

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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

it wont come.

I do believe it will come.

Rub,you dont know what you are taking about.

Rub-_- even a quick search on the forums would show that features are appearing in the M.E. which make it obvious that multi-crew is being developed in the background...

(...)

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

No, I don't. It is how you do transfer controls currently.

Have you flown the Gazelle in Multiplayer?

Try switching controls to the left seat.

Apart from the sync issues with the Viviane sight controls, where sometimes the sight is out-of-sync, as well.

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.

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.

What you can do (and DCS is likely doing already) is, to receive a UDP package with a "button press" and the client ( which can be the server in a two player session, but is likely an internet hosted server) that currently calculates the Helicopter (Systems modeling, Flight model, etc.) sends a UDP broadcast to all clients "flying" in the same Helicopter, together with the flight model information about vector, etc. The result is still a doubling of latency trough both network, too and fro plus the calculation latency of two PCs.

As it is impossible to model the electrical or hydraulical systems on two different PCs with the same result at the same time, when the input into the equation is done with even a delay of a few milliseconds, as other parameters change in real-time, they likely need to figure a way to "circumvent" the system modeling, but still keep the behaviour and buttons behave somehow realistically.

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.

I mean what delay would you as a pilot find acceptable? A spike of latency to 150 msec with "client send action" - "server received action" - "server send action to participants" - "participants acknowledge", even with a perfect connection and no package loss means at least 3 * 150 milliseconds. Basically half a second delay.

A typical limit for multiplayer games is a ping of 300 milliseconds. That is where server admins already draw the line and kick you, to spare other players the problems caused through your warping and erratically flying aircraft... Or 1st person shooter avatar jumping magically out of gun bullets paths.

It's always a matter of milliseconds, regardless.

Just because you count time in milliseconds it doesn't reduce the effect on the modeled system.

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.

And I am trying to tell you a bit of the real life challenges that come with modeling accurate to real life systems in a study sim and not a simple ego shooter.

Again, I suggest looking at the attempts to implement multiplayer in the Gazelle. Don't get me wrong, I like what Pat has done there, but it also shows some of the underlying issues that need to be solved.

Unfortunately just put an additional server into the communication isn't a feasible solution, unless we do LAN parties, again.

I was under the impression that the switch inputs are momentarily even for toggles ie the code is sent when the switch is moved so a toggle can be on on player one and player two moves his version of the switch to off the sim will update that switch to off if players one switch was off and player two was on and 2 moved it to off the sim would check status see it’s already set to off and ignore the input. I think I discovered this during the programming of my puma since one switch is a three position mode switch and reading somewhere you need to set the press and release of each push button otherwise it creates problems

I was under the impression that the switch inputs are momentarily even for toggles ie the code is sent when the switch is moved so a toggle can be on on player one and player two moves his version of the switch to off the sim will update that switch to off if players one switch was off and player two was on and 2 moved it to off the sim would check status see it’s already set to off and ignore the input. I think I discovered this during the programming of my puma since one switch is a three position mode switch and reading somewhere you need to set the press and release of each push button otherwise it creates problems

The difficulty is, that a network connection isn't reliable. So you may press the trigger send the "depressed" info, but the "release" is lost. If this have not changed recentlt you can try this by switching to a gunner seat, press the trigger and hold it and then press F3 to switch into an external view and release the mouse button. It should continue firing. (No time to check with latest update).

You need to implement a feedback.

Unfortunately that means info travels two times between the two clients (or 4 in a full staffed Huey). Next problem what if a switch needs to be accessible by both pilots? What if the pilot switches to "off", while an "on" command is reaching his PC 30msec later? It would feel like "the switch didn't work?" and now think of a simpit with physical switches that get out of sync to the sim, etc.

...and just to confirm:

A post from PilotMI8 on the russian forum on 27th March, confirming they will do Multicrew for the Mi-8, but FIRST they will implement it for the Huey!

Original post (use Google translate).

https://forums.eagle.ru/showpost.php?p=3436207&postcount=3904

B00mer:

Подскажите пожалуйста, работы над реализацией мультиэкипажа ведутся или хотябы планируются? Обнадеживает появившийся пункт в полном редакторе о выборе приоритета управления.

PilotMI8:

ведутся. Но сначала на Хью

In that case run a check of all switches in all cockpits and display warning of inconsistencies when they occur run it before startup thenevery so often after that orhave a configuration tab for multi player where each player designatestheirrole pilot, copilot and each gunner that gives their inputs priority based on switch location and pilot chooses weather the overhead. And center panel belong to him or the co pilot to designate who has priorities there.

Plus that’s one of the reasonsons I’m going virtual for all inputs besides the controls.

In that case run a check of all switches in all cockpits and display warning of inconsistencies when they occur run it before startup thenevery so often after that orhave a configuration tab for multi player where each player designatestheirrole pilot, copilot and each gunner that gives their inputs priority based on switch location and pilot chooses weather the overhead. And center panel belong to him or the co pilot to designate who has priorities there.

 

Plus that’s one of the reasonsons I’m going virtual for all inputs besides the controls.

Yet, only one client can model the electrical/hydraulical and avionics simulation (the other is slaved to the "pilots" simulation), that is why you have deviation between the Viviane sight in the Gazelle... Only the left seat can operate the sight, yet if not all movement input is accurately synced to the pilots PC over the network, the pilot sees the crosshairs a couple feet beside the target, while for the left-seat it looks spot on. Unfortunately the pilot PC calculates the systems, and the shot and thus the missile misses.

Currently the "workaround" is, to ask the pilot if the crosshairs are "on target", then the left-seater corrects if necessary (blind just by the pilot commanding left/right, up/down) while glancing on the sight and trying to keep a stable hover/flight path...

Honestly, I am pretty sure the guys who develop close to real life, state-of-the-art simulations may have thought of a lot of possible ways to do this and that is what they try and enhance at the moment... But it definitely isn't "simply do xyz and that's it! Problem solved!" ...the underlying issues are a bit more challenging due to the nature of the systems modeling and the realities of internet connections.

If anybody had come up with a way to do 100% loss resilient data transfer in real time over an internet connection, he would be a billionaire and every bank, company and service-provider would have implemented it by now!

As all these major players still pay incredible large sums to get a dedicated fiberglass line and reserve huge amounts of bandwidth over well defined and reliable MPLS-networks just to get at least a "better" latency, I guess neither ED or Belsimtek can simply fix the root cause. So they have to mitigate and fix the resulting problems and that is definitely not an easy task.

Just my two cents.

Anyway they just confirmed a couple days ago, they still work on it, and we will see multicrew for the Huey, before they implement it into the Mi-8.

Have you flown the Gazelle in Multiplayer?

I've nerver flown the Gazelle, but I've heard there are problems with their implementation of multicrew. I suppose this is because ED didn't update the engine to include multicrew support, thus Polychop had to "improvise" it in.

...that is why you have deviation between the Viviane sight in the Gazelle... Only the left seat can operate the sight, yet if not all movement input is accurately synced to the pilots PC over the network, the pilot sees the crosshairs a couple feet beside the target, while for the left-seat it looks spot on. Unfortunately the pilot PC calculates the systems, and the shot and thus the missile misses.

I'm no network expert, but in every other game I've played the shot seems calculated by the shooter, and not the by pilot. Meaning it's the shooter position (position of aircraft in the shooter machine) that defines where the projectile spawns and where it goes. You can shoot from the second/third/fourth position etc. of any vehicle in Arma 3 or Battlefield 4 for example and it goes where you're aiming. As I understand, that has nothing to do with being high fidelity or not. If the Gazelle is not doing that, I would believe it's due the current lack of multicrew implementation in the DCS engine (which I guess is temporary).

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.

What you can do (and DCS is likely doing already) is, to receive a UDP package with a "button press" and the client ( which can be the server in a two player session, but is likely an internet hosted server) that currently calculates the Helicopter (Systems modeling, Flight model, etc.) sends a UDP broadcast to all clients "flying" in the same Helicopter, together with the flight model information about vector, etc. The result is still a doubling of latency trough both network, too and fro plus the calculation latency of two PCs.

 

As it is impossible to model the electrical or hydraulical systems on two different PCs with the same result at the same time, when the input into the equation is done with even a delay of a few milliseconds, as other parameters change in real-time, they likely need to figure a way to "circumvent" the system modeling, but still keep the behaviour and buttons behave somehow realistically.

You keep mentioning UDP protocol, but as far as I know all real-time games use the UDP protocol and it's no obstacle. You also keep mentioning the advanced system modeling and yes, it does mean DCS has to handle a lot more information about the cockpit, but on the other side DCS doesn't have to handle a lot of detailed information in the small scale world and combat that other games have. Action in DCS is much more slower-paced, while in other games it's common to have 64 players all shooting in full-auto at the same time, genereting zillions of projectiles, each one with it's own ballistic calculations, etc. Let's not imply that DCS is the only game that has challenges in network usage.

I mean what delay would you as a pilot find acceptable? A spike of latency to 150 msec with "client send action" - "server received action" - "server send action to participants" - "participants acknowledge", even with a perfect connection and no package loss means at least 3 * 150 milliseconds. Basically half a second delay.

 

A typical limit for multiplayer games is a ping of 300 milliseconds. That is where server admins already draw the line and kick you, to spare other players the problems caused through your warping and erratically flying aircraft... Or 1st person shooter avatar jumping magically out of gun bullets paths.

If I ask my co-pilot to flip a switch, I wouldn't even expect him to touch it before 2 seconds. And in DCS, where you have to first grab your mouse and then "mouse click" with a floating cursor on a tiny swaying button due to TrackIR amplifying your natural head sway, I would put a lot more seconds in that expectancy. I doubt that you would notice a difference if a bad connection added even 1 second more to this process.

Just because you count time in milliseconds it doesn't reduce the effect on the modeled system.

I'm only counting in milliseconds to indicate that it's smaller than a second.

And I am trying to tell you a bit of the real life challenges that come with modeling accurate to real life systems in a study sim and not a simple ego shooter.

I'm sorry, you soud like other titles have less challenges regarding amount of data, network usage etc. Yet the stuff that you mention as obstacle for DCS are stuff like figuring out what direction the shot will go.

Unfortunately that means info travels two times between the two clients (or 4 in a full staffed Huey).

Why on earth would you give the door gunners access to the cockpit switches?

Next problem what if a switch needs to be accessible by both pilots? What if the pilot switches to "off", while an "on" command is reaching his PC 30msec later? It would feel like "the switch didn't work?" and now think of a simpit with physical switches that get out of sync to the sim, etc.

What if you had a cockpit IRL that was accessible by both pilots? What if the pilot switches to off and the co-pilot swithes to on, right after? Would it feel like the switch doesn't work?

Even if the cockpit gets out of sync for some time. Yes, everything gets out of sync for some time. Enemies get out of sync in critical situations, not only in DCS, and I don't think this was ever a reason to not do anything. Desync does happen, has always happened and will always happen. AND games aren't really supposed to be playable at 300ms ping, bad connections, etc.

I'm sorry, I don't mind you saying that ED has challenges in redoing a lot of code that they probably hardcoded in the past to be only singlecrew, because that was all that was needed at the time, or that you say that ED is a small company and has other projects in parallel, or that it takes time and requires highly specialized personel that are hard to find. What really bugs me is that you keep mentioning stuff that we know aren't really obstacles, overcomplicating things for those who don't have any notion of game-making, to make ED be applauded, instead of frowned upon, for this delay.

These posts are starting to take me more time to write than I would like and I'm starting to feel we are not going anywhere. I now feel you won't simply agree with me, and I guess I already said what I had to say. Who wants to read these long posts can read and have their own conclusions.