Multi-crew for one huey implemented or not?

[PeaceSells]

it wont come.

 

I do believe it will come.

[Esac_mirmidon]

Rub,you dont know what you are taking about.

[Weta43]

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

[shagrat]

(...)

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.

Edited March 31, 2018 by shagrat

[BlacleyCole]

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

[shagrat]

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

Depends on the switch. Triggers for example are pressed and then released. Until the release the weapon fires.

 

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.

[shagrat]

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

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

[BlacleyCole]

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.

[shagrat]

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.

That can cover the switch position, but not the underlying systems and is exactly what the Gazelle dual-cockpit multiplayer does, currently.

 

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.

[PeaceSells]

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.

[hannibal]

hey peace.

 

i would like to have multiseat as much as you do.

i have been beating up on belsimtek on some of the posts.. especially the doorgunner capabilty.

 

all i can do is wish. but i am grateful that we even have the huey at all.

but i know belsimtek has been at work with the FA18C, as well as Mi24 and F4... and dcs 2.5 is still being refined.

 

as silver dragon mentioned, mutliseat parts are beling developed.

 

all i can be is patient and grateful, an as bart simpson would say, good things comes to those who wait.. :p

 

 

I LOOK FORWARD TO UPCOMING COOP CAPABLE DCS MODULES FROM ALL 3RD PARTIES AND FROM DCS, ESPECIALLY FOR VR!

[sniperwolfpk5]

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.

 

 

 

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

 

 

 

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.

 

 

 

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

 

 

 

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.

 

 

 

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

 

 

 

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.

+1 Well all these make sense

[shagrat]

+1 Well all these make sense

No, they don't... Because they compare apples to pineapples.

 

And the Gazelle uses DCS World to simulate the environment and their objects as much as the L-39C and other multicrew modules.

You have a lot of guessing in your post. I am talking from experience and what the devs posted or said about the issues.

 

In the usual game you do not simulate electrical current running through systems, or the hydraulics moving a sight through pressure.

As I said do we really think the developers of these complex state-of-the-art modules just need some pointers from somebody who played some shooters, because they don't realize how easy it is to just throw the whole Simulation and realistic part away and replace it through a simple vector and button sync and multi-crew works... Albeit we have a more simplified flight and systems modeling like in every other game?!

 

I'll leave it at that. And you may want to consider why you are not flying the brilliantly simulated air assets in these perfect battle simulators, where synching is no problem at all.

[sniperwolfpk5]

There are games, those have simulation aspects and they are doing things just right. One thing which I do agree is the proper multi crew implementation, which ED will implement in core of DCS. I can't say any thing on Gazelle as I don't have, but what I thing, they have their own multi-crew implementation which has issues.

[shagrat]

There are games, those have simulation aspects and they are doing things just right.

What I said above. To realize that you need to nerf down the Simulation aspect to the same standards which would defy the whole purpose of a study sim.

 

Apples and oranges...

One thing which I do agree is the proper multi crew implementation, which ED will implement in core of DCS. I can't say any thing on Gazelle as I don't have, but what I thing, they have their own multi-crew implementation which has issues.

 

As the network stack and synchronization is based in DCS there is no "own implementation". They were just the first 3rd party to try and utilize the functionality that came with the L-39C multicrew development for a helicopter. Which is(!) EDs implementation of multicrew in DCS, albeit this is still WIP and was already improved...

Edited April 2, 2018 by shagrat
Typo fixed

[shagrat]

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.

The Gazelle was developed with the multicrew implementation provided with the development of Multicrew for the L-39C (by ED).

The whole network, synchronization and world modeling (keep track of objects/collision models etc.) Is part of the DCS World core, modules need to interface with that.

 

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

As I said before there is only one multicrew core and that is part of DCS World. And the fidelity of the simulated systems inside the shell of the 3D-object is exactly what makes the difference between a more simplistic infantry combat game and a high fidelity study sim.

In the former a simple vector from a 3D-point origin is most the data you need to sync, along with some vectors of model parts of the 3D-object, turret or head for example.

 

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.

See below. DCS models detailed internal systems with their dependencies. Switching the wrong button or getting a hit at the wrong component usually initiates a cascade of secondary or tertiary effects in dependend systems.

Games use a highly simplified "if hit in section A gunner A is dead" or "Motor hit wait 20sec and explode motor" action system.

UDP by design accepts, that information is lost during network transport. Thus you need to implement your own concept of verification, to ensure everyone has a synched state of world, objects, switches, system details as far as necessary to ensure a consistent modeling. From the gauges showing the same values, the rotor blades actually moving in both PCs (another issue from the Gazelle Beta implementation of multicrew) and keeping track of system states, button positions and press and release of temporary switches/buttons.

To do this you need to send information in both directions and that means you add more latency... As you said yourself 300 milliseconds lag is unplayable. So a transport verification for switch inputs at least need double the time to send back the acknowledgement. Thus the acceptable latency is "ping" x 2 needs to be less than maximum latency.

In the end every "ping" over 150 milliseconds means a round trip of a minimum of 300 milliseconds plus the internal CPU cycles.

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.

Still if a trigger press is reaching the simulated gun 2 seconds late you will miss or even worse hit the wrong target.

 

If the button pressed/switched is connected to a system modeling even half a second can cause issues (remember when the L-39C had a dead engine for the back seat or outright exploded when starting mid air, as the two cockpits/seats were out of sync on entering the plane).

 

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

Correct, so as you said even 300 milliseconds delay is unplayable, does that mean 999 milliseconds is still less than a second yet three times more, than what you deem unplayable?

 

I'm sorry, you sound 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.

No, as I explained the challenge is to ensure that when the trigger is pulled or any other button switch etc. both PCs have the same world simulated around them and show the same information.

In case of the Viviane sight the shot is accurately calculated, but unfortunately your targeting sight in your screen was showing it a bit out of sync so the shot misses...

 

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

Not to the switches, but the minigun can only shoot when electricity is available to the gun-motor. This is part of the electrical system model and needs to run through the client calculating the internal systems and synced over the network to the guy in the gunner position.

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?

.

In a real cockpit both guys operate the same switch. You can feel the position if the switch. If the co-pilot switches to off, the switch is(!) In the off position. In a sim with bad sync it may remain on for the pilot and worse it is stilk in the wrong position when the pilot triggers a depending system, with another switch...

 

Even in a dual cockpit jet most double implemented switches use magnetic switches and physically sync between front and back seat, or the instructor pilots switches have precedence over the students.

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.

In the L-39C that exact out of sync issues caused exploding planes on entering the cockpit simultaneously, made for avionics not showing any or wrong input, and in the Gazelle you had exploding Helicopters on entering the cockpit on the ground, pilot have rotor spinning, while the co-pilot had no blades rotating, which is a bit strange in mid flight. Your targeting sight showing a couple feet to the left or right when firing made you miss the targets... So no definitely no problem with a little out-of-sync. ;)

 

I agree we have different opinions and this takes way more time than I expected.

 

How about we accept Belsimtek is still working on the implementation and we just wait, what they come up with?

 

We can't speed up progress anyway. :dunno:

Edited April 2, 2018 by shagrat

[PeaceSells]

@Shagrat: I wasn't trying to give pointers to the devs, I doubt they need it.

[PeaceSells]

Not to the switches, but the minigun can only shoot when electricity is available to the gun-motor. This is part of the electrical system model and needs to run through the client calculating the internal systems and synced over the network to the guy in the gunner position.

 

I think this is probably the main topic around which we have different understandings. As far as I know, you don't transmit the systems modeling over the net, that would probably clog the connection. I guess the simulation is run independently on each client machine, and only key events like the flipping of a switch, a system failure, etc. are transmitted. Gunner will be able to shoot as long as his machine doesn't receive the info that electric system has failed. Exactly how much information is transmitted and how much is simulated independently is a matter of tuning by the developers, as with any game.

 

I don't think all the crew members run the flight model on their machine, probably only the pilot that has control runs it, and the position of the aircraft in the world is updated through the net to the other members, with latency. On the gunner's screen, the aircraft is always in a position which is some milliseconds behind the pilot's screen, but when the gunner pushes the trigger, he is the one that is running the shooting simulation, the location of the spawn of the projectiles, their direction and speed, etc., and the pilot is the one that's receiving that kind of information with latency. So gunners should hit what they are aiming at, and pilots watch it with some latency. Who is running what and who is being updated with the due latency is a matter of decision by the developers as with any game.

[Holton181]

...but when the gunner pushes the trigger, he is the one that is running the shooting simulation, the location of the spawn of the projectiles, their direction and speed, etc., and the pilot is the one that's receiving that kind of information with latency. So gunners should hit what they are aiming at, and pilots watch it with some latency.

Just wondering, if the pilot need to perform a sharp maneuver, like an evasive action to avoid incoming fire, and puts the rotor disc in the trajectory of the bullets fired by his own gunner (co-pilot or door) due to latency?

The gunner would see his bullets go unhindered towards his target, possibly killing some of them, but all of a sudden, for no apparent reason, his still functioning helicopter start tumbling to ground, because his bullets, in a "parallel universe", is making shish kebab out of the rotor blades and also due to that totally missed the targets killed in his own "universe".

[shagrat]

I think this is probably the main topic around which we have different understandings. As far as I know, you don't transmit the systems modeling over the net, that would probably clog the connection. I guess the simulation is run independently on each client machine, and only key events like the flipping of a switch, a system failure, etc. are transmitted. Gunner will be able to shoot as long as his machine doesn't receive the info that electric system has failed. Exactly how much information is transmitted and how much is simulated independently is a matter of tuning by the developers, as with any game.

 

I don't think all the crew members run the flight model on their machine, probably only the pilot that has control runs it, and the position of the aircraft in the world is updated through the net to the other members, with latency. On the gunner's screen, the aircraft is always in a position which is some milliseconds behind the pilot's screen, but when the gunner pushes the trigger, he is the one that is running the shooting simulation, the location of the spawn of the projectiles, their direction and speed, etc., and the pilot is the one that's receiving that kind of information with latency. So gunners should hit what they are aiming at, and pilots watch it with some latency. Who is running what and who is being updated with the due latency is a matter of decision by the developers as with any game.

No, unfortunately you can't run two different system models on two different machines, as they are A) modeled with dependencies to have an accurate damage modeling of internal systems, B) you get different results on different clients calculating the same things as soon as any dynamic input from the DCS environment is used (e.g. weather system, etc.).

As you can't sync everything (definitely would clog the connection, plus may not get stable results in real-time, anyway), you need to have one PC the Pilot's, usually run the whole system modeling and sync all absolutely necessary info (avionics and gauges displayed, switch states, direction and angle of gun/sight pointing etc. to the co-pilot's PC and keep that synced as much as possible so the co-pilot at least sees what the Pilot sees.

Now on top of that you need to sync back any manipulation of switches, axis and other input to the pilot's PC and feed it into the flight and system model.

 

That is what is currently done.

 

Now, the challenge is to balance these inputs/synchronization over a normal internet connection and still have the pilot's PC run the simulation in real time and guess/estimate the inputs lost or too late so the simulation, never has to wait for a delayed package with a vital input.

 

So in fact when you press the trigger as co-pilot it sends the "press trigger" info over the Internet, feeds it into the systems modeling, that checks all circuit breakers are in, electrical lines undamaged, generator provides enough power, etc. and fires the gun (actions the underlying system) as if the pilot had pushed the button on his PC.

Now the info is sent back to the co-pilot's PC to show the gun firing animation, along with the vector info of the bullets fired (basically what you get when watching a TACview). Now if the co-pilot releases the trigger you can either send a "trigger released" info and hope it doesn't get lost. You can constantly send a "trigger still pressed" and if that doesn't reach the pilot PC assume the button is no longer pressed. Or you can send a "got the info, you have released the trigger" back to the co-pilot's PC and if he doesn't get this info, he resends the "trigger released"... Each come with their own issues and things to consider.

Now this is "just" one trigger button. In DCS you can have quite a large amount of controls that you want/need to keep in sync. Some simple on/off switches, others multiposition rotaries and for sights/TGP/cameras even one or more constant analogue axis.

 

This is a tad bit different than simpler games with some simulation aspects do it.

I am also sure, that ED and the 3rd parties are working on methods to balance this and/or optimizing system modeling APIs to cater for a better synchronization, but it is far from simple... ;)

Edited April 2, 2018 by shagrat

[Mr_sukebe]

I did think that the Albatross is already multi-player. If so, isn't that a good indication of where the capability is?

[shagrat]

I did think that the Albatross is already multi-player. If so, isn't that a good indication of where the capability is?

For jets yes, for two people in the same cockpit, sharing stuff like weapons controls and plus two side-gunners maybe. I would more look into the Gazelle for comparison, but as PilotMi-8 said, they are working on it, so likely improving it...

[PeaceSells]

No, unfortunately you can't run two different system models on two different machines, as they are A) modeled with dependencies to have an accurate damage modeling of internal systems, B) you get different results on different clients calculating the same things as soon as any dynamic input from the DCS environment is used (e.g. weather system, etc.).

As you can't sync everything (definitely would clog the connection, plus may not get stable results in real-time, anyway), you need to have one PC the Pilot's, usually run the whole system modeling and sync all absolutely necessary info (avionics and gauges displayed, switch states, direction and angle of gun/sight pointing etc. to the co-pilot's PC and keep that synced as much as possible so the co-pilot at least sees what the Pilot sees.

Now on top of that you need to sync back any manipulation of switches, axis and other input to the pilot's PC and feed it into the flight and system model.

 

That is what is currently done.

 

That makes sense and I agree with that. What I don't agree is that it imposes harder challenges than the other multiplayer real-time games.

 

So in fact when you press the trigger as co-pilot it sends the "press trigger" info over the Internet, feeds it into the systems modeling, that checks all circuit breakers are in, electrical lines undamaged, generator provides enough power, etc. and fires the gun (actions the underlying system) as if the pilot had pushed the button on his PC.

Now the info is sent back to the co-pilot's PC to show the gun firing animation, along with the vector info of the bullets fired (basically what you get when watching a TACview). Now if the co-pilot releases the trigger you can either send a "trigger released" info and hope it doesn't get lost. You can constantly send a "trigger still pressed" and if that doesn't reach the pilot PC assume the button is no longer pressed. Or you can send a "got the info, you have released the trigger" back to the co-pilot's PC and if he doesn't get this info, he resends the "trigger released"... Each come with their own issues and things to consider.

 

That doesn't make sense to me. In my understanding, gunner should fire instantly when he presses the trigger if his machine hasn't received any prior info that gun isn't working. If he's going to perform this check, sending info to the pilot's client and back, between the trigger press and the gun actually firing, I don't believe any coding will be able to make this a good multiplayer experience, specially if the position and direction of the shot will be calculated by the pilot's machine, and not the gunner's.

Edited April 3, 2018 by PeaceSells

[shagrat]

That makes sense and I agree with that. What I don't agree is that it imposes harder challenges than the other multiplayer real-time games.

Other MP games simply model an empty 3-D shell with a vector (that is why you can control them, by pointing a mouse at a certain point in space and the model follows suite).

 

In DCS there are multiple dynamic factors, from air pressure, temperature, humidity, wind direction and speed that dynamically affects the flight model and the engine model, and the engine model is tied into the electrical system model and hydraulics etc.

 

The challenge is to (re)code the whole stuff in a way, it works with two clients flying the same machine and switching stuff in real-time.

 

Other games don't have that challenge, as the "engine model" consists of "OK/damaged 50% max speed/dead, can't move/explode" so a simple two digit binary state (00, 01, 10, 11) is all you need to sync.

 

That doesn't make sense to me. In my understanding, gunner should fire instantly when he presses the trigger if his machine hasn't received any prior info that gun isn't working. If he's going to perform this check, sending info to the pilot's client and back, between the trigger press and the gun actually firing, I don't believe any coding will be able to make this a good multiplayer experience, specially if the position and direction of the shot will be calculated by the pilot's machine, and not the gunner's.

That doesn't work this way, in any game. The typical "Server & multiple Clients" setup of most multiplayer game, requires that the client sends the information about trigger press and direction (vector) to the server which typically holds the positional information and collision model of all objects, the server calculates the point of origin and vector to the target from the client info and checks for collisions (hits, crashes). The client may see a perfect hit visually, but the server doesn't and he causes no damage.

The server ensures all participating clients have the same info.

In DCS the Server can be a client as well (if you host a mission), so this PC needs to calculate the flight model of the aircraft the guy is flying, the aircrafts internal systems (ASM) and on top the world simulation with all objects and bullets needing to be tracked and checked for collisions... And sync that info between all clients.

 

The button and switches sync of the multicrewed object should usually be done between the clients directly (I am estimating here from experience, not 100% sure as MMPO games changed a lot to server based stuff)...

[scorpion80]

all of this remain words as long as someone of BSK or ED write something.

 

Don't know if shagrat is a Tester/programmer/whatelse in the ED BTU (under nick there is just "ED Translator").

 

As users we can't know if part of the synchronization between the two or more clients as been already written.

 

Hope someone of the BelSimTek will answer.

 

Cheers