PeaceSells

Some servers use Discord, others use Teamspeak and others use SimpleRadio (SRS). They usually state what program for communication they use in their mission description.

The fact that you die doesn't bug anyone, you don't have to worry about that. What will make your teammates more happy about your presence is when you use comms to pass and receive good info, whether you die or not. Get into multiplayer, fighting human players is so much more immersive than fighting bots.

Flying high, where missiles have long range, ECM prevents R-27ER/AIM-120 from being fired at max range, because the max range of the missile becomes greater than the burn-through distance. To be honest, I only know this is true when flying the F-15 or Su-27. I have no experience in the Mirage, but I suppose it should work.

Yes, I wasn't referring to drag, I should have said "low speed lift" instead of "low speed performance". As far as I know, delta wings should allow low drag at high speeds while retaining good lift at low speeds (as a general rule), but at the cost of higher drag caused by angle of attack, meaning more speed loss at turns...

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

I might be wrong, but wasn't the delta wing design created to allow high speed low drag, while still retaining low speed performance?

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.

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

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.

I do believe it will come.

I have the FC3. From the remaining 3 aircraft that you mentioned, I would get the Su-25A. It's a very cool module IMO.

You don't wait for inputs like axis, gun triggers etc., these are instant on your seat and delayed on the co-pilot seat. When you decide to pass control to the co-pilot, he will receive it after the delay and, from then on, he will be the one with the instant commands on his machine. This is nothing new, this is already done by others and I'm sure ED knows how to do that very well. Being high fidelity or not has nothing to do with this, we are talking about control authority and it's the same whether you have 10 or 100 commands. Now if you are talking about having both pilots having control at the same time, I have no idea how to do that, since on the internet ping is never 0 ms. I don't think this is what ED/Belsimtek is aiming for, unless they find a way for all players to have 0 ms ping. 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. 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. It's always a matter of milliseconds, regardless. 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.

Co-pilot presses the button to disable the rocket, but it doesn't get disabled until info is sent to the server. Server then decides that now it's disabled and sends this info back to him and his pilot. Then rocket system gets disabled on both clients. This means some miliseconds delay between you pressing the button and the system getting effectively disabled, but this is normal in multiplayer. If the pilot presses the trigger before receiving the info from server that it's been disabled, then he will fire rockets normally, until he gets the info. But this just for some miliseconds, no actual harm done. It's not like comms (voice or text) between both players is instant anyway. Trust me, ED/Belsimtek knows all this better than me. This can't be the reason for the delay. They just have to put in the man-hours to actually do it, it's what it all comes down to in the end. Not saying it's simple and instant, but you have to put your man-hours into it.

This isn't me coming up with solutions, this is how things already work: bullets are spawned in your client at the time you pull the trigger, and server receives info and keeps track of timings. Otherwise, you would often shoot in directions you didn't aim at when manouveriung, even without multicrew, and this doesn't happen because it's part of netcode that DCS and all multiplayer games have. This is no different if you have many switches or few switches in cockpit, if you have electrical/hydraulic systems modeled or not, principle is the same. You don't "guess" if the other guy has pressed a button or not, you wait till you received the info that he has. Until then he hasn't. Server is responsible to decide the state of such things and inform all parts concerned. Pressing a fuel pump switch isn't more critical than pressing the trigger.

An F-15 or an Su-27 flying high enough will have line of sight on you, if they aren't too far away, no matter how low you are in the valleys. And their radar will see you. I suppose a Mirage or MiG-29 also will, but I have no experience flying these.

I'm not saying it's not complicated, coding regarding games is complicated by nature... I'm saying it's not difficult since they are the ones who created and have the technology of their own engine. If it's that difficult for them, then it's a bad bad sign. This is what I just can't refrain from saying after reading all those posts about all these technical difficulties, as if they're supposed to generate some form of solidarization because they can't solve the technical issues that they created themselves, in order to deliver a feature that they announced themselves.

Shagrat, imagine you are flying in formation with your wingman, then your wingman crashes into terrain and you never get the "memo", as you desdcribed. You would see your wingman forever flying alongside in with you. But you don't... because ED solved this a long time ago (like all other multiplayer games since more than 20 years ago)... The server is in charge of managing things like that in multiplayer, sending and receiving memos and making sure the ones concerned receive them sooner or later.

If I was part of the staff who did the progam, then yes, I would probably know how to code it. How do you not know it can't possibly be so difficult that it takes 4 years (or more to come?)

With all the respect, I can't believe it's that complicated to allow a second player to act on the aircraft commands. It doesn't really matter if it's on the hands of ED or Belsimtek to implement the support for multicrew. All this talk about the technical difficulties doesn't really make sense: DCS engine and the Huey were developed by ED/Belsimtek, not some other developer who holds the technology. All the "technical difficulties" is their own code.

You have to consider that there isn't a lot of options around when it comes to high fidelity sims of modern high performance aircraft... On another note, it's good to know the campaign is being worked on, the other day I tried the Bear Trap and was also stuck due to F-16's failing their missions...

The AIM-120, which is an active type missile, can be guided in TWS mode, but as far as I know it's not through reflected emission. IIRC, the launcher aircraft sends some type of datalink signal to the missile, informing it about the target's position. The 530D is a semi-active type and, as far as I know, all semi-active missiles need continuous hard lock on the target.

That was brilliant, thanks for clarifying beyond any doubt!

Did they fix the CBU-97 falling short of the aimimg point already?

There is pop with vis range set to extreme and trees vis set to 100%. Just zoom in and out and you will see.

How about script to explode aircraft on touchdown or take-off if they're not on required frequencies? (kidding, but would be fun) Let us all put pressure on ED to create proper ATC AI behavior... more than ppl already put in the past...