Multi-crew for one huey implemented or not?

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!

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

+1 Well all these make sense

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.

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.

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

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:

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

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.

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

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.

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

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

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

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.

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

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

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

You need to solve problems about data processing in real-time, transfer without loss of vital information over a potentially unreliable connection and solve bandwidth requirements, latency issues and keeping data in sync around global data centers.

From working with DCS I know a bit about the challenges, yet there are no secrets. If you participated in the early access L-39C and Gazelle phase, there was a lot of discussion about the issues encountered.

...I don't want to sound like an ass, that knows it all.

I am trying to showcase some of the issues ED and BST need to overcome (or hopefully have already solved in internal builds), as we have the reoccurring point of view, that it is a non issue to build this, as "other games" have non of these issues.

But that is normal, as DCS World is pretty unique even in the study sim corner of gaming. :)

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

That's an abysmal simplification. There's much more info than just a vector. Some also have different degrees of physics simulation. But AFAIK, you typically don't transmit every variable about you over the net. For example, if you have a physics simulation, you probably don't transmit the forces, etc. acting on you, you only transmit the result (your position in space, for example, which is just a vector) which is what's relevant to others.

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.

Are you saying that in DCS you keep transmitting to others the dynamic factors and forces acting on you, instead of the end result that's actually relevant to others, like position, damage, etc? I wouldn't think so...

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.

No, no... that's inverted. All the stuff you described do happen, but not on that order. Your shot goes off instantly when you press the trigger, no checking with the server at this moment, so no delay and no misalignment. You shoot in the direction you aim on your own machiche. Now if you're going to hit someone or not is another story. Because that someone might be there on your machine, but on the server he could be already somewhere else. That's when the delay happens, because you don't use the location of the enemy from your machine, you wait for the server to tell you if you hit him or not. This might seem not very different from what you described, but this difference is crucial for real-time combat games. What you described might be fine for MMORPG (I have no experience with MMORPG), but not for real-time combat simulations/action games.

You can test this by yourself, join a DCS server (or another real-time combat game) and fire your gun. See if there's any delay between squeezing the trigger and your bullets flying off (miniguns aren't ideal for this test because of the spin-up time).

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

It doesn't really matter, lots of crucial stuff about multiplayer can be concluded by a player just by playing the game. The delays, when exactly they occur, do your shots come off from your gun or do they appear to come off from the empty space where you were some milliseconds ago? Do they fly in the direction you aimed or to the side? Do enemies die instantly when you hit them or is there a delay? Among other observations...

No offense intended, but simply as a player you should already know the answers to many of the things discussed here just by observing these "details". You guys need to wake up.

That's an abysmal simplification. There's much more info than just a vector. Some also have different degrees of physics simulation. But AFAIK, you typically don't transmit every variable about you over the net. For example, if you have a physics simulation, you probably don't transmit the forces, etc. acting on you, you only transmit the result (your position in space, for example, which is just a vector) which is what's relevant to others.

Exactly, the physics simulation is done in each client, as you pass the same initial vector. What I refered to is for example, the motor block which is usually not modeled with fuel pressure from the pump, starter requiring electrical current available from the generator or battery, and how fuel and electricity is used/depleted in the whole system. So a "bullet hit" can trigger a preprogrammed "motor damage" and reduce engine power or stop the vehicle and explode it in x sec.

In DCS if you hit the model at a part where the generator is hit, you have all/most systems still working, but on battery with limited time. Maybe the time is even further reduced when a weapon pulls additional power from the battery...

So you can replace this detailed Advanced System Modeling (ASM) with a nerfed shooter style alive/50%/dead mechanic, but I guess a lot of study sim fans won't be happy.

Are you saying that in DCS you keep transmitting to others the dynamic factors and forces acting on you, instead of the end result that's actually relevant to others, like position, damage, etc? I wouldn't think so...

No, I said it needs to route your "button pressed" through the electrical model to know if the system can be engaged or not.

No, no... that's inverted. All the stuff you described do happen, but not on that order. Your shot goes off instantly when you press the trigger, no checking with the server at this moment, so no delay and no misalignment. You shoot in the direction you aim on your own machiche. Now if you're going to hit someone or not is another story. Because that someone might be there on your machine, but on the server he could be already somewhere else. That's when the delay happens, because you don't use the location of the enemy from your machine, you wait for the server to tell you if you hit him or not. This might seem not very different from what you described, but this difference is crucial for real-time combat games. What you described might be fine for MMORPG (I have no experience with MMORPG), but not for real-time combat simulations/action games.

See above... Check if you can fire, or the other option, continuously transmit "weapons ready".

You can test this by yourself, join a DCS server (or another real-time combat game) and fire your gun. See if there's any delay between squeezing the trigger and your bullets flying off (miniguns aren't ideal for this test because of the spin-up time).

Why do you guess, TacView is transmitting the events (like gunfire, hits, ejects etc.) from the server to the clients and not the other way round?

And we do not talk about normal multiplayer, of course the gun fires immediately as you run the systems modeling in your client.

The hit determination and sync with other clients is coordinated by the server.

But that was not the point. We were talking about synchronizing stuff between two clients actuating buttons and systems in ONE aircraft. Where only ONE client can do the systems modeling, or at least that was, how it worked with the L-39C and Gazelle.

See above... Check if you can fire, or the other option, continuously transmit "weapons ready".

Doesn't it transmit "weapons ready" once (or once in a while) and it's ready until transmit "weapons not ready". Wouldn't be this how it's done?

No, I said it needs to route your "button pressed" through the electrical model to know if the system can be engaged or not.

Does it need to route through the electrical model or just through the "weapons ready" or weapons not ready"? Because I always see the weapons in DCS either shoot or not shoot, never seen they work in a "degraded" state. Same with laser, radar, etc. Even if it would work in a degraded state, say 50%, I don't think it would run through the electrical simulation everytime you shoot...

So you can replace this detailed Advanced System Modeling (ASM) with a nerfed shooter style alive/50%/dead mechanic, but I guess a lot of study sim fans won't be happy.

I don't mean that at all...

Why do you guess, TacView is transmitting the events (like gunfire, hits, ejects etc.) from the server to the clients and not the other way round?

My point is if you press the trigger and don't see delay (delay due to pinging to server and back is very noticeable), then it can't possibly be checking with server. It's physically impossible.

And we do not talk about normal multiplayer, of course the gun fires immediately as you run the systems modeling in your client.

I'm talking about multiplayer the whole time...

But that was not the point. We were talking about synchronizing stuff between two clients actuating buttons and systems in ONE aircraft. Where only ONE client can do the systems modeling, or at least that was, how it worked with the L-39C and Gazelle.

I guess that's the same, but in the case of cockpit switches it's not critical that the switch is flipped without any delay (unlike the trigger), as I understand it.

So, now that we are in 2018, can we multiplayer in the same huey, to be the gunner for instance?

Sorry, I was lazy to read all the 22 pages ^^

No

The Gazelle has the multicrew now. What is Belsimtek waiting for?

To finish It.

-_-