I'm sorry but this is completely irrelevant, network code (since you are talking about bandwidth) doesn't work like that at all. There are client stuff, server stuff and replicated stuff....actually a really good netcode would also divide the replicated into "zone of interest" thus a client that is outside a range of interest should not care receive that stuff until he get into the range. Only a moron would replicate avionic and such stuff but soon he would realize that not only it is resource consuming but also USELESS. The increase of aircraft complexity does not increase the required bandwidth since almost all those complexity falls on the client stuff side.

Now nothing related to you itself, but this behavior i've seen so many times. Fanboys that do anything they can to defend their beloved product up to the point where they swim into unknown waters which most of time ends with them imagining that the devs are doing such a "never seen before" job thus transforming a really stupid thing into some sort of epic god job. This just to justify bugs, delays and so on so for....In my house we don't call it fanboy, we call it directly worship!

Speaking of ED, the only things that i give credit to them is that they made a really good flight model (which is not an easy task) but left the FM outside they have done nothing that goes beyond of the ordinary. To be honest in many aspect i find their product just a bad implementation of what is already in the market (considering the whole gaming market and all genres....talking about engines) by at least one decade and has added nothing new in the market.


UPDATE:
Do you really believe that the server calculate the flight model for each client and send everything back to the client ????? Or that the server care about whether you are using the pod or the aim camera to aim???? That would be one of the most naive and inefficient implementation.

There are game out there that really are the result of incredible and innovative works.....DCS is way way way far away.

If i understand Striker correctly: the AI planes are hosted on the server
and every change (flaps, gear, position etc) must be transfered to the clients.
The more airplanes, the more bandwith needed. The more complex the environment,
the more data must be transfered, because the server usually hosts most objects.

The amount of data can be optimised by transfering only "what is needed"
(think about BMS bubble implementation), but i think LOMAC and FC transfered
"everything" all the time. There was some uproar in the beginning about the
needed upload bandwith for a server. I don't know if this has been changed
or if there is a link between the clients (mesh-model (BMS) vs client-server (DCS?))
in DCS nowadays.

In BMS we calculate 1Mbit per client on the server and 40Kbit per client on the
clients. Flying the Balkans campaign let some clients lag due to the number of
objects deaggregated in a short time.

I was just trying to be humorous and break the "Ice", get it, "Break The Ice".
Anyhow, I think you're dissecting my statement and looking for more meaning than I meant.
We have a bunch of guys in our group that fly different aircraft.
For example, I'm sitting on the Tarmac in an A-10C and another guy's next to me in an Mi-8.
I simply meant that I see all the input from the other person as they're moving the controls.
So all of those complex movement and changes are visually represented to me.
Also, because all of the environmental conditions, wind direction and speed, are modeled I see that too.
So in effect it's a way more complex set of rules than a sim from years ago with simpler avionics and flight models.
That's all I meant.
I know it's not possible for me to see the other person clicking controls in the cockpit.
That would be useless information anyhow.
When I'm in F2 view and look into someone else cockpit I see a simplified view.
I've always been aware of that.
I meant that all of the above combined along with more client aircraft added up to much more demanding bandwidth and processing.
Anyhow,this is way off topic from the original post so I'm just going to leave it at that.
I won't comment any further on this thread.

No, I'm just asking you why you say number of aircraft is a factor. So far, I'm not seeing anything to back up that statement.



So what? You'll only see control inputs when you're X distance away, and if properly implemented, you'll see control inputs regardless if the aircraft is high-fidelity or not. As for the environmental conditions, that's all calculated on your end and any decent sim will model that. The difference of "rules" between sims of old and sims of today are limited partly because of hardware, partly because of "the bar" set at that time, and partly because of budget.

Your initial statement:
People also forget that DCS World 1 had a lot of problems when it first came out. It ran great after they fixed the problems and has been mostly flawless up till the release of 1.5. You also need to remember that this is a completely different animal now. You're talking about running many different aircraft modules in the same environment, unlike another sim that is basically using the same cockpit avionics with different skins. This is a huge leap for any company and there are certain to be problems.

Bottom line: number of aircraft have nothing to do with "a lot of problems" and does not make the sim "a completely differnt animal." It is not "a huge leap" and is not an excuse for delays and bugs, provided the developer knows what they are doing.



As been shown above, no.

Where is the complexity here? A simple float that says where its control position are? This is no more complex than a simple word in a html page...again people praising programmers for really stupid things!

Just to be a little more clear, the client reads the user input, do all the calculus that has to be done, then just replicate the final control position as a simple float.....wow the complexity behind a float replication is amazing....luckily ED has archived this incredible goal.

Yeah, I read that as if "it's never been done before, they're breaking new grounds, so of course there'll be bugs." Uh.... no.

Even if it were, things like control surface actuation being visible in MP, well good for you if you manage to get that working in your sim. However, these OTHER guys have managed to HACK an old sim in order to do the exact same thing. Who's got the better skillset now? IMHO, I'm more impressed by the guys that make a sim do what it's never been dreamed of doing or designed to do rather than those who have total control of their code and do the same thing.

Robustness.

You are not transmitting one float. You are transmitting a stream of floats, each of which represents the position at a point in time. Transmission in games needs to be fast, therefore it needs to be a tradeoff between raw speed and reliability. This in terms means you are going to drop packets. Dropping packets means you don't get the float for each point in time, at which point you need to start interpolating.

If the connection experiences a hickup, you need to predict the behaviour of that object/control surface based on what it was doing last time you got information from the server. You also need to make sure that your predictions are sane, because certain circumstances may cause your predictor to become unstable and return physically impossible results.

If you think this is easy, you must have mastered at least Kalman Filter theory, let alone a few other advanced signal processing/digital communication topics.

What???! Are you even serious? Control surfaces go up/down or left/right. The control surface was going up, packets were dropped. Guess what? The control surface goes up. Is it that hard to interpolate that? It's not going to go 360-degrees and slay that nearby BMP just because you dropped packets! Was the control surface near max-deflection when the packets were dropped? Then put it on max deflection. Done.

Even if you apply this problem to the entire aircraft and not just a control surface, well, that's what the FM is there for! If the aircraft was pulling 4Gs at 350knots and packets were dropped, it is that hard for the sim to tell that the aircraft won't be pulling 9Gs at 600knots all of a sudden?

Then going back to control surfaces, you only really worry about this when the viewer is a certain distance from the aircraft; it's pointless rendering flap/aileron/rudder movement when aircraft are 10nm apart!

So at the most, this will only really be in play so that aircraft don't "jump around" in the air for close formation flying, A-A refuelling, or dogfights. Hmmmm.... I wonder how difficult this task is.... are other sims/games/developers not doing this already in MYRIAD other games? Do you really think DCS is the only one doing this?

He wanted to know why it is not that easy, i explained the basic concept.

I am not going to roll out every intricacy of the problems involved, especially since you aren't really interested in the topic instead of just picking away at every word out of my mouth. If i'm wrong, do some research yourself.

If you want an introduction to the set of problems and how they can be tackled, watch some academic youtube videos.



That flight surface is part of the FM, it's not just eye candy. The more error you make in predicting its exact position during the next frame of the FM simulation, the further the plane will be away from its actual position once the network packets start arriving again, causing a noticeable warp.

You aren't even scratching the surface with your simplistic examples.

I maintain your concept is flawed. Read on to know why.


I am interested in support for Striker's original statement/argument. Since you've decided to pick up the torch, then I have no choice but to "pick away" at your argument. If you don't like that, then don't join the discussion.


Sure, there is a problem, and there are many ways to solve it. Not all are the correct way of doing it, although there may be many "correct ways" at arriving at the desired outcome.



Sorry, but no dice.

Are you seriously telling me that if you and I were flying, MY computer determines the FM of YOUR aircraft based on the state of deflection of YOUR control surfaces, and if packets are dropped, then your aircraft will "jump/warp" in the air?? First of all, why is MY computer determining YOUR FM and location in the air? Would it not make more sense for FM to be calculated off of flight surfaces of YOUR aircraft on YOUR computer, and just transmit your "in the air" data over network? Second, this model just makes no sense in terms of streamlining what needs to be transmitted... if your example were true, then data for control surfaces need to be transmitted across the network whether the aircraft are 0.2nm apart or 20nm apart! How many control surfaces x how many aircraft x how many different FMs.... It's not "complicated," it wrong.

Calculate FM on client-side regardless of flight surface deflection --- yes, make flight surface deflection EYE CANDY instead of an actual thing you base calculations out of --- and transmit "location in the air" over the network. Put a threshold, maybe 1-2nm, then transmit flight surface deflection over the network so the other guy can see it, but it'll still be eye candy. Point is: prioritize the math, then tie the eye candy into it, not the other way around.


The simpler it is, the less likely things are to go wrong. Now explain to me why your complicated example is correct.

It does not work like that at all, it is all about velocity vectorS with dead reckoning interpolation, since forever regardless consumer or professional simulator. I'm sorry to disappoint you control surfaces are only eye candy.

ED sheep in a nutshell

Ouch!

Now let's see where he goes after this....

DCS: World 21 - 28 November Week update.
https://youtu.be/WYqZxu22smk

How can you be so sure?

Looking at the velocity vector only means you are throwing away a lot of precision that you could get cheap by predicting the evolution of the acceleration vector as well, which has to be derived from a noisy measure of the respective user input. This is a classic Kalman Filter problem.

Kalman Filtering offers superior precision over simple dead reckoning in this scenario. You don't have to take my word on it, just read around the internets.

http://alumni.media.mit.edu/~aggelos/papers/tuffc_nov04.pdf
https://pdfs.semanticscholar.org/7ef5/223703d7192fd5daafd9a8071b369abc8edd.pdf
http://stackoverflow.com/questions/13812627/tcp-realtime-multiplayer

There are a myriad of papers published by IEEE, but i can't make those available for free.

Well, it is difficult to get any data about DCS network code,
but the OTHER sim has data about client/client and server/client
bandwith requirements: BMS Manual, page 280.

15Kbit per plane, 7.5Kbit per moving ground unit and
15Kbit per weapon entity (even chaff/flares).

I'll guess the concept is not that different in DCS.

Regardless, where do you think the computations take place for your aircraft? My computer or yours?

It would make infinitely more sense to send position and velocity along with deltas and let the local client interpolate control surface movement from that.

While ED has made some mistakes I can't believe they would make so egregious a mistake as to send the state of every bit on every plane in the mission to every client. It's completely unnecessary.

Besides, haven't we all seen AI planes flying around with damage that would seem to preclude their ability to fly? Almost as if, I don't know, the AI planes control surfaces are NOT actually responsible?

When I'm fighting against an enemy fighter, I need to know where it is and how it's moving, I don't need to know if the left aileron is deflecting properly for the current rate of roll. So there's no reason to send that. For ED to have bothered to implement THAT when they're still having issues with missile FMs is absurd. That would be a rabbit hole they could ill afford to fall down.



The Jedi Master

from reddit

https://www.reddit.com/r/hoggit/comments/5fbo6w/dcs_155_advertisement/

leaf, that clearly can't be flying correctly. The ailerons are in the "down" position, yet the aircraft is banking to the left when it should clearly be drifting to the right. This is a clear example of packet loss that Sobek is talking about.

As for the link, I love the responses:
Release date: December.....Feburary....Apr...July....Q4 2018
Ergel drynarmics
yet here it is workeang purfeaerctlyerss

So much for SimHQ being such a "negative" site, huh?

Hoggit has loads of positive stuff. Furthermore, they flat out know to call their #%&*$# #%&*$#.

So yes, SimHQ still is such a negative site.