Multi-crew for one huey implemented or not?

[shagrat]

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

I have no insight into the code, for that matter, but I have some knowledge about data synchronization over WAN / Internet connections. From an IT perspective it is irrelevant where the data is coming from.

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

Edited April 3, 2018 by shagrat

[PeaceSells]

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

[PeaceSells]

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.

[shagrat]

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.

Edited April 4, 2018 by shagrat

[PeaceSells]

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.

[harf4ng]

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

[Chic]

No

[scorpion80]

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

[Esac_mirmidon]

To finish It.

[Rub-_-]

-_-

[Scrape]

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

 

The Gazelle has had SRS compatible multi-crew since release. It's only gotten better.

[j0nx]

There's no incentive for them to add any features to these old modules. They aren't going to make any money for it so why devote the resources or make it a high priority if you do? It's simple business logic.

[Sneak69]

There's no incentive for them to add any features to these old modules. They aren't going to make any money for it so why devote the resources or make it a high priority if you do? It's simple business logic.

Because it was promised in by them and people bought it becasue of said features.

[PeaceSells]

There's no incentive for them to add any features to these old modules. They aren't going to make any money for it so why devote the resources or make it a high priority if you do? It's simple business logic.

 

No, business logic isn't that at all...

[Roman_455vAEW]

I just got the L-39 recently and flew multicrew with a friend and it was phenomenal. One of the best experiences I have had in DCS...

 

Anyways this is a bump to see when this feature coming to the UH-1 and MI-8...

Talk to us Belsimtec/ED

 

Sent from my XT1710-02 using Tapatalk

[Rub-_-]

I wait for the Tomcat. in a jet it would be really fun. i mean in they huey as well, imagine you play with 4 Players at once, 2 doorgunner and 1 Pilot + 1 Copilot. that would be great Battlefield like. but as i said. it wont come. Maybe they make a huey V2 with that Features but you have to buy it. also a Vietnam map would be great then. then all the planes of the era makes sense. Tornado IDS would be cool too.

[chief]

There's no incentive for them to add any features to these old modules. They aren't going to make any money for it so why devote the resources or make it a high priority if you do? It's simple business logic.

 

It's not adding features. It's finishing a product. And the incentive is keeping your client base. I have spent thousands on addons. Mostly in fsx/p3d and there are a few companies that have lost my business due to either not finishing a product or a declining quality of their product. I'm sure I'm not the only one who has done this. So that should be their incentive. To keep us as loyal customers.

[BlacleyCole]

Unwell belsemic is no longer they became part of ed last month iirc

[Haukka81]

Im quite sure that Huey will never get multicrew. They got out money and rest is history.

 

I hope to be wrong but so far nothing shows else.

 

 

Sent from my iPhone using Tapatalk

[shagrat]

Im quite sure that Huey will never get multicrew. They got out money and rest is history.

 

I hope to be wrong but so far nothing shows else.

 

 

Sent from my iPhone using Tapatalk

Apart from BST told us a couple month ago, they started on that. Plan to implement it in the Huey before the Mi-8, etc.

 

Multi-crew is likely coming big time with the F-14, the F-15E in the pipeline, C-101 getting there.

Edited July 5, 2018 by shagrat

[BlacleyCole]

We can hope ed will pick up the slack now they own belsemic mods

[SnowTiger]

It would also be nice to see the GPS implemented in the Huey as well (not just for the Mi-8).

[iKyrThraad993i]

Guys, I would think multicrew on the aircraft is not easy due to net coding to make sure everything shows up equal and also how the cockpit works. When it comes to aircraft that have different more advanced system it will be alittle harder and take more time to work.

 

This is not a easy task I would believe.

 

Give them time even if its a while I see them doing it soon

[SnowTiger]

I agree that netcode could easily be an issue, however, I was flying Multi-crew during the early 1990's in Janes Lonbow. So it can't be "that" difficult.

 

Changes to the way the internet works and things like netcode etc, probably do make it more difficult to make it work well. But without knowing anything about software design, I'd say it can't be that difficult to achieve considering how long ago it was when it was working just fine (in other software).

 

But I'd rather have it working well (i.e. flawlessly) than have some half-A$$'d attempt released. So ya, it could take a while yet.

[sniperwolfpk5]

Guys, I would think multicrew on the aircraft is not easy due to net coding to make sure everything shows up equal and also how the cockpit works. When it comes to aircraft that have different more advanced system it will be alittle harder and take more time to work.

 

This is not a easy task I would believe.

 

Give them time even if its a while I see them doing it soon

 

I agree that netcode could easily be an issue, however, I was flying Multi-crew during the early 1990's in Janes Lonbow. So it can't be "that" difficult.

 

Changes to the way the internet works and things like netcode etc, probably do make it more difficult to make it work well. But without knowing anything about software design, I'd say it can't be that difficult to achieve considering how long ago it was when it was working just fine (in other software).

 

But I'd rather have it working well (i.e. flawlessly) than have some half-A$$'d attempt released. So ya, it could take a while yet.

 

The question is not whether multi-crew is difficult or easy to implement, others already implemented it so please stop discussing this net-coding difficult thing and stop defending a company. Multi-crew is in their feature list and people bought this module due to certain features set.

 

Huey was the first module of BST. How much time passed since then. The actual problem is that it is not in their priority list. I don't think so they are working on it. They are already busy on other more prioritized projects.

 

BST has the top notch quality products, there is not a single word doubt but when it comes to communication with community they are the poorest among all the 3rd party. They don't bother to communicate, that is the said truth