Eagerly awaited aircraft for DCS World

It's not about “deserving” anything, and crew contact is not a factor. It's about making the tech work between two clients, preferably with a minimal bandwidth footprint. It would be a weak excuse for a broken implementation, but that's not what anyone wants in a simulation, now is it? If a crew gets into a slapfight over a switch position, they may end up with a broken-off switch, but even then, it will be in a single position that affects the functionality of the aircraft in a singular way — one part of the aircraft will not detach and fly off in a different direction like it does when things desync in DCS. We can already see this even without the multicrew if the server and the client disagrees on things: the player explodes out of nowhere for no good reason; the server says it has a good reason because it never received the switch flip that set the bombs to high-drag…

 

 

That's not an assumption you can build a shared cockpit around, especially not when the real buttons are connected and would be the same thing. You can't really use examples of a completely different setup to explain away the complexities of an cockpit that does not have that separation. The throttle switches would be the same because both crew members use the exact same throttle handles.

 

 

…and that is exactly the mindblowing complexity of the issue: that coordination must exist in the code, or things will break. It's not a matter of communication, but of determining who is in control when there is no hard separation between the two. One guy's joystick is in a steady left bank; the other guy's joystick is carefully adjusting pitch — which of the two does the plane listen to? Which one is genuine input and which is just jitter outside of the null zone and which one is just having a bad spring so his stick is naturally tilting a bit to the lower left? It has nothing to do with the players coordinating — it has to do with the question how does the game know? How does it handle conflicting inputs? How does it genuinely transition control from one to the other without interpreting it as going from a 20° left to a full right stick and immediately ripping wings, rotors, flaperons, whathaveyou right off the airframe? This is not a player problem; it's a code and logic problem that comes inherent with two necessarily different inputs having to share one in-game control.

 

 

It is a game-breaking thing. It means the module cannot be said to actually provide its main selling point. Arguably, it can't even be sold because of how broken it is.

Even airline pilots have a standard procedure of calling out who has control of the aircraft. Before they take over the controls they say "My aircraft".

Even airline pilots have a standard procedure of calling out who has control of the aircraft. Before they take over the controls they say "My aircraft".

…which has nothing to do with the problem at hand or its solution.

Again, this is not a pilot problem or a communication problem. It's a coding and game logic problem.

On 11/29/2020 at 5:21 PM, Tippis said:

 

…which has nothing to do with the problem at hand or its solution.

 

Again, this is not a pilot problem or a communication problem. It's a coding and game logic problem.

But its not a very difficult problem. Whoever says "My plane" via the radio menu, controls stick, throttle rudder etc. In the ctrl+enter window you can have position of both sticks so 2nd seat can adjust his controls before taking control to avoid sudden jerk caused by different stick positions.

So what's the takeaway here? That the mystery plane that will be announced can't be a multicrew module because it's something that DCS doesn't do that well?

1 hour ago, Lurker said:

So what's the takeaway here? That the mystery plane that will be announced can't be a multicrew module because it's something that DCS doesn't do that well?

It can be any multicrew plane because apparently the multicrew alone makes it brain melting. If thats the case, I will be very disapointed. 

On 11/29/2020 at 6:21 PM, Tippis said:

 

…which has nothing to do with the problem at hand or its solution.

 

Again, this is not a pilot problem or a communication problem. It's a coding and game logic problem.

It is exactly the solution for the problem. You can not get over the game logic problem without implementing system where either pilot can request control and other needs to release controls with acceptance. It just needs to be technical limitation where other player can not send constant input as example any axis.

There is no technical problems whatsoever when there is a button or a switch position that both can control. It is normal sync situation. Switch 123 is ON or OFF. If either one operate that switch, it status will be synced from player A to player B and vice versa.

The DCS anyways needs a new functionality where a button/switch can not be constantly triggered. There needs to be time delay between action. This can be seen example in VR here you take your VR GLOVE on the switch/button and it will be triggered constantly as long the glove is in the zone. It should be limited to only one action per touch. So if you flip it from ON to OFF, then you need to bring hand away from the switch and back close to touch it again to get it from OFF to ON.

It is like the input system is reading constantly every single status of the bindings there is without any kind limiter to how many times in milliseconds/second can a button/switch be triggered. 

7 hours ago, sparrow88 said:

 

But its not a very difficult problem. Whoever says "My plane" via the radio menu, controls stick, throttle rudder etc. In the ctrl+enter window you can have position of both sticks so 2nd seat can adjust his controls before taking control to avoid sudden jerk caused by different stick positions.

Exactly. You simply have two methods easily available:

1. Radio root menu item that is "I have the control" where you are given the control in 1-2 second delay timer regardless which pilot you are, or if you are the "instructor" and other is "trainee".
2. Radio root menu item that is "I have the control" that is applied only after other player selects "You have the control". 

And that of course can as well be a shortcut binding for a button, so it can be even voice activated (nice if using DCS own VoIP system!). 

Automatically would pop-up that your suggested input-box for a few seconds to allow position the controls to transfer it smoothly. It could even be mandatory to move the control axis in +/- 5% from the proper position and hold there for a second to match them and then automatically controls are transferred.

Meanwhile the other player does not have any axis controls over the other player who has active control. It would be safe to move throttle or joystick or pedals and nothing happens.

This would allow "instructor" at the backseat in L-39 to have override control when so required. Simply by taking control away from trainee!

The F-14 RIO wouldn't even have the axis bindings for any flight controls, so rear seater can't by any means fly it as the rear seat is a "different vehicle" from the front seater.

On 11/29/2020 at 7:25 AM, Tippis said:

The brain-melting part is synchronisation, especially of more complex controls than simple switches, and there are quite a few of those. All the really important bits that need to be shared aren't switches but far more complicated controls, often directly tied to player input devices.

But wouldn't such a feature be about DCS World itself, and not about specific module (using that feature)?

If ED would implement a proper synchronization between pilots, it should be available for all modules from the start.

18 hours ago, sparrow88 said:

But its not a very difficult problem. Whoever says "My plane" via the radio menu

...will have their controls out of sync with the guy who was in control, and need to go through a lot of steps to do something that needs to be instant and, worse: which needs to be controllable by both parties at times. The problem here is that it can't just be one person at all times, at least not if it's done right.

11 hours ago, Fri13 said:

It is exactly the solution for the problem. You can not get over the game logic problem without implementing system where either pilot can request control and other needs to release controls with acceptance.

You must be able to take control without the other party releasing it. Otherwise, one of the main points of having secondary controls is lost: the ability to take over when the other guy is no longer able to do anything. Creating such a system is not a requirement to make the whole thing work - it's not actually needed at all. Communication between the pilots is not relevant to the game logic simply because the game logic does not understand what players say to each other.

Quote

Automatically would pop-up that your suggested input-box for a few seconds to allow position the controls to transfer it smoothly. It could even be mandatory to move the control axis in +/- 5% from the proper position and hold there for a second to match them and then automatically controls are transferred.

 

Meanwhile the other player does not have any axis controls over the other player who has active control. It would be safe to move throttle or joystick or pedals and nothing happens.

That could work as a very ugly, slow, and unrealistic hack, sure - if it's one thing DCS could use at the moment, it's far fewer ugly pop-ups that appear out of nowhere. But again, this is something that needs to be able to happen pretty much instantly, and unilaterally.

Quote

This would allow "instructor" at the backseat in L-39 to have override control when so required. Simply by taking control away from trainee!

The F-14 RIO wouldn't even have the axis bindings for any flight controls

That's just it: the L-39 already basically has that. It doesn't really work and causes desync. And the F-14 is not relevant to the problem at hand so people can stop bringing it up. Again, there's a reason why this is mind-melting: because it has been tried, and those attempts have either failed or ended up not being implemented. The F-14 does not change that fact because it is such a simple aircraft to manage relative to the ones with actual shared controls, and it was still a huge deal that Heatblur managed to make it work.

This should tell you something.

10 hours ago, Fri13 said:

But wouldn't such a feature be about DCS World itself, and not about specific module (using that feature)?

If ED would implement a proper synchronization between pilots, it should be available for all modules from the start.

Sure, but that's how these things usually go, right? One module gets a new thing as its marquee feature, and then others benefit as it gets retrofitted to them as well. Ground radar is the classical example, where it was long-requested and then finally rolled out to much fanfare in relation to the Hornet, but other modules got it too once it was in (granted, the ground radar is perhaps a bad example since the Jeff was the first one to actually use the code).

Also, holy crap this new post editor is crap

5 hours ago, Tippis said:

That could work as a very ugly, slow, and unrealistic hack, sure - if it's one thing DCS could use at the moment, it's far fewer ugly pop-ups that appear out of nowhere. But again, this is something that needs to be able to happen pretty much instantly, and unilaterally.

There can always be 2 options, one initiated by the current pilot- slow one that allows controls to be synced manually, and fast one, where co pilot just takes controls in whatever state they are in during emergency.  Still nothing brain melting.

So, less than a month to know!

Bye

Phant

On 12/2/2020 at 10:58 AM, Tippis said:

You must be able to take control without the other party releasing it. Otherwise, one of the main points of having secondary controls is lost: the ability to take over when the other guy is no longer able to do anything. Creating such a system is not a requirement to make the whole thing work - it's not actually needed at all. Communication between the pilots is not relevant to the game logic simply because the game logic does not understand what players say to each other.

As I said, there are few options. But automatically you can not never take controls away from other player. Meaning, if you move your joystick, it can not never overrule the other player joystick movements. Meaning, your input must be 100% ignored.

1) Player A has control, Player B doesn't have control without requesting from A and A accepting it.

2) Player A/B has control, Player B/A doesn't have control but can request control and is given without other accepting it.

3) Player A/B has control, Player B/A doesn't have control but control is given who syncs the controller with another who is in control.

The communication is important that player A request control and B needs to give the control. That is the authoritative control scheme like with a trainers where instructor controls override everything that the trainee does. It is a safety and training feature where experienced and in command pilot can take controls when needed.

But in helicopters you can not do that as is strictly about communication and trust that other will keep their hands off from the controls when other flies.

Technically that can not be done as two separate digital controllers.

If the other player is no longer able to do anything, be it incapacitated or disconnected, then automatically controls are given to another player alive or connected. It is imminent transfer of controls. 

On 12/2/2020 at 10:58 AM, Tippis said:

That could work as a very ugly, slow, and unrealistic hack, sure - if it's one thing DCS could use at the moment, it's far fewer ugly pop-ups that appear out of nowhere. But again, this is something that needs to be able to happen pretty much instantly, and unilaterally.

It is not unrealistic. In real life the controls moves in synced. When the trainee moves the throttle/collective, the instructor throttle moves as well. When the trainee moves stick/cyclic it is as well synced all the time. 

There is impossibility to have two separate gaming devices to be synced same way unless they are Force Feedback ones, where they would be moving as in real thing.

So, only way to make it realistic is that other player needs to move his controllers to same position as the other player has and then it gets automatically released for there at good given time. This of course cause problems with centering joysticks or scenarios where accidentally the controllers become same, but if you have throttle and joystick (and pedals) and all needs to be matching position before controls are released automatically, it would minimize the accidental one. But anyways the syncing is required so that one player doesn't have aircraft trimmed to extreme position and other has it centered and on controls release the extreme control input is given. 

That is why it can not happen instantly as if player A has throttle at max, pedals and joystick centered, then when other player would move controllers to same position it would instantly transfer controls suddenly to other player. So there needs to be delays where player in controls can freely move controller past the other player controllers positions etc. 

On 12/2/2020 at 10:58 AM, Tippis said:

That's just it: the L-39 already basically has that. It doesn't really work and causes desync.

It doesn't work when players controllers are sending ghost inputs and you have axis input transmitted constantly on each movement. Everytime the axis moves it overrides the other controller binded for that same axis. If you have two perfect controllers that doesn't send any ghost inputs, then you can switch between them as perfectly as long you use either one at the time. If you start to move both same time, it is the controller that was last one to start sending new input.

Again, it doesn't work if there is no communication where instructor would be required to use a communication menu "I have the controls" that activates the instructor controls and disables the trainee input. There just is no way to have two digital inputs same time for the same output. 

On 12/2/2020 at 10:58 AM, Tippis said:

And the F-14 is not relevant to the problem at hand so people can stop bringing it up.

It is relevant, as in real aircraft there is no means to fly aircraft as RIO. So there is no problem with it. 

The problems has been that mouse clicks has been possible be given to other cockpit as invisible arm. 

The coding problem is that the cockpits has been modeled and one 3D model is used, and one input system is used. Why mouse clicks went through to other cockpit. 

And when the seat is programmed separately that one must have different bindings for RIO and different bindings for pilot, and those bindings are active only for corresponding seat, there is no way that RIO can fly the aircraft from the backseat as RIO bindings doesn't have those bindings and RIO can not activate pilot bindings.

What comes to cockpit, it should be two separate models. One for RIO and one for Pilot. Where one seat can not by any means activate the other seat switches or buttons. Simple fix is to add a transparent barrier between that blocks mouse clicks etc. 

When it comes to helicopters like Gazelle or Huey, it can not be done such manner as lots of buttons and switches are shared. Both can example operate the weapons control panel or either one can start-up the helicopter. Why a different methods are required than what the F-14 has, by specifically sharing lots of buttons and switches between players and not like F-14 where they are blocked.   

On 12/2/2020 at 10:58 AM, Tippis said:

Again, there's a reason why this is mind-melting: because it has been tried, and those attempts have either failed or ended up not being implemented. The F-14 does not change that fact because it is such a simple aircraft to manage relative to the ones with actual shared controls, and it was still a huge deal that Heatblur managed to make it work.

It is not "mind-melting" if someone implements the sold feature. It is like saying that it is "mind-melting" that Hornet is getting A-G radar in Early Access.

On 12/2/2020 at 10:58 AM, Tippis said:

Sure, but that's how these things usually go, right? One module gets a new thing as its marquee feature, and then others benefit as it gets retrofitted to them as well. Ground radar is the classical example, where it was long-requested and then finally rolled out to much fanfare in relation to the Hornet, but other modules got it too once it was in (granted, the ground radar is perhaps a bad example since the Jeff was the first one to actually use the code).

Only when it is from the ED. The third-parties do not share functions unless they make own deals and agreements. So if ED doesn't make a A-G radar, it was Heatblur that made own to Viggen. JF-17 had as well own implementation before switching to ED provided one. 

This is why ED needs to do lots of functions so others can use it.

So if ED can not come up with synced multiplayer controls, others need to try to invent new means to do it and if you have all third parties doing own it is a mess, and if ED can not do it to DCS itself fast enough for engine reasons, it is that everyone is waiting who doesn't want to make own (that likely gets broken after ED own). 

6 hours ago, Fri13 said:

As I said, there are few options. But automatically you can not never take controls away from other player.

And that is the crux of the matter (I'm assuming the repeated double negation here is in error because otherwise you're contradicting your conclusion and the whole problem goes away). The thing that makes it mind melting is that, to make the thing work properly, exactly that needs to happen: you need to be able to take control away from the other player without their say-so. Either for realism reasons (they got shot) or for simulation reasons (they disconnected) or for practical reasons (cat on keyboard)… and even for QoL reasons (the other guy is flying like a spaz and need to be… corrected). Some of those can conceivably be detected and the transfer be automated but some can not and a robust system need to be able to handle both. And this needs to be done with minimal delays, without desync, and preferably without any ugly UI intrusions, although some compromises always have to be made.

Quote

 

The communication is important that player A request control and B needs to give the control. That is the authoritative control scheme like with a trainers where instructor controls override everything that the trainee does. It is a safety and training feature where experienced and in command pilot can take controls when needed.

But in helicopters you can not do that as is strictly about communication and trust that other will keep their hands off from the controls when other flies.

Technically that can not be done as two separate digital controllers.

 

…which was kind of the whole point all along: communication is not actually part of the problem because it's all about how you deal with those synced or inherently authoritative controls when in this case aren't synced because that's now how game controllers generally work. What the pilots do and how they communicate has very little to do with what the game has to interpret, handle, and arbitrate between.

Using the comms menu as a short-hand for a real-life standard procedure and tying the transfer to that is a cute shorthand, but it also doesn't really match how the system works, and it even becomes a bit silly under certain circumstances. It's not exactly to figure out a scenario — real or in the simulation — where you'd just take control without any such communication going on, or where a request-response setup would stretch the willing suspension of disbelief because the responder would not actually be able to respond in that situation.

Quote

It is not unrealistic.

It's inherently unrealistic, the same way the input pop-up and SC IFLOS and any of the myriad of other crud crowning your field of view are unrealistic.

Quote

That is why it can not happen instantly as if player A has throttle at max, pedals and joystick centered, then when other player would move controllers to same position it would instantly transfer controls suddenly to other player. So there needs to be delays where player in controls can freely move controller past the other player controllers positions etc. 

It can happen instantly just fine without that — it just creates a slightly different problem, similar to how you've completely over-trimmed your aircraft. In fact, that would be one way of solving it: rather than have the sequence Request -> Align -> Transfer, you could have [optional Request ->] Transfer -> Align, where the last step would effectively just be a trim reset like what is already available in a number of airframes.

Quote

It is relevant, as in real aircraft there is no means to fly aircraft as RIO. So there is no problem with it. 

…and that's exactly why it's not relevant to the problem at hand: because the problem simply doesn't exist there .

You might as well bring up the F-15C at that point. It also has no problem with it.

Quote

It is not "mind-melting" if someone implements the sold feature.

Eh, yes it is. That's the whole point: you've overcome a significant coding or engineering challenge. Mind-melting doesn't mean that it can never happen or be implemented — if it did, this supposed mind-melting aircraft will never be implemented, but it is. That's why we're having this discussion and trying to figure out what could qualify as a mind-melting aircraft.

Quote

 

Only when it is from the ED. The third-parties do not share functions unless they make own deals and agreements. So if ED doesn't make a A-G radar, it was Heatblur that made own to Viggen. JF-17 had as well own implementation before switching to ED provided one. 

This is why ED needs to do lots of functions so others can use it.

 

Sure, but the point was that a new fancy feature is usually attached to new fancy module that shows it off. Just because other modules could, should, and eventually would benefit from the same feature doesn't mean it's being rolled out as a “DCS feature”, but rather as something a new aircraft offers as a first (which conveniently also makes that aircraft a testbed before it's rolled out to other modules).

Can we please get back to the discussion of what you think the mystery plane will be? I for one am laying even odds that it won't even be announced this year. This is after all Eagle Dynamics. Where everything is subject to change. 

21 hours ago, Tippis said:

Eh, yes it is. That's the whole point: you've overcome a significant coding or engineering challenge. Mind-melting doesn't mean that it can never happen or be implemented — if it did, this supposed mind-melting aircraft will never be implemented, but it is. That's why we're having this discussion and trying to figure out what could qualify as a mind-melting aircraft.

For me brain melting means something that is widely thought to be impossible to implement - like Rafale due to Dassault stance on IP, or F117 due to lack of info regarding its RCS. 

4 hours ago, Lurker said:

Can we please get back to the discussion of what you think the mystery plane will be? I for one am laying even odds that it won't even be announced this year. This is after all Eagle Dynamics. Where everything is subject to change. 

Wouldnt be surprised either if the announcement gets delayed. Also I'm getting the feeling that "brainmelting" will be a highly subjective emotion and lots of people

will be underwhelmed by the actual aircraft either way..

Not sure whether giving that adjective was the smartest move, unless ED pulls something out of the hat  that really surprises us.

Given all the criteria that have been added over time , that this modules supposedly meets or doesn't meet, I can' t think of any aircraft that meets all of those and still

can be considered "brainmelting" in a somewhat universal way . Ok Mig-25 maybe. But unlikely.

It would be nice to pleasantly surprised, but I'm preparing to be underwhelmed when the cover comes off.Happy to be wrong though on that

Regards,

Snappy

For me there are 2 brainmelting aircrafts coming to DCS, one is the eurofighter, the other the F15e. Other than that i only would be superenthusiastic of something like a full fidelidy su30mki or similar... A superhornet would also be awesome, a gripen, a rafale, a tornado, phantom... Ok i'm easily sold

Enviado desde mi ELE-L29 mediante Tapatalk

1 hour ago, Snappy said:

I can' t think of any aircraft that meets all of those and still

can be considered "brainmelting" in a somewhat universal way

Basically this, and has been from the start. Anyone who is getting super-stuck on "brainmelting" lingo is setting themselves up for disappointment in my opinion. It is probably something cool for many, and not for others. You don't tease something by saying "it is something maybe cool for some and maybe not for others" though. Anyway, the year is almost (thankfully if I may say so) up, so IF they will still reveal it this year, not long to go now.

I think it may prove to be MV-22 Osprey to troll us all, and honestly that one would be brainmelting whether everybody likes or not :)) Or maybe Apache, but not entirely sure of that, they did tease it after all, but then said it's hoped for later if I recall correctly.

High tech Russian aircraft, or indeed surprise module being any Russian aircraft was denied multiple times before as far as I recall.

I personally hope it's not another later tech aircraft, many other things can be brainmelting just fine, but that's just me. And seeing as they sell better, it'll probably be something that'll please crowds, but we'll see.

I agree people are reading too much into a fluke that some one said...

We are in December now, I don´t believe they are going to announce anything at all, 2021 is mosquito and mi 24 and marianas... maybe 2022 apache an or F-4 (if we are really, really lucky), THATS it. No more "brain melting" announcements here...

I would love to be proven wrong of course, but I don't keep my hopes up...

3 hours ago, Baco said:

...We are in December now, I don´t believe they are going to announce anything at all...

Later this year, we are looking forward to announcing an eagerly awaited aircraft for DCS World

Later this year, we are looking forward to announcing an eagerly awaited aircraft for DCS World

Later this year, we are looking forward to announcing an eagerly awaited aircraft for DCS World

Bye

Phant

F-35 hahahaha

On 12/4/2020 at 8:29 PM, WinterH said:

I personally hope it's not another later tech aircraft, many other things can be brainmelting just fine, but that's just me. And seeing as they sell better, it'll probably be something that'll please crowds, but we'll see.

Hmm didnt they say in one of the interviews that some work regarding full fidelity Mig29 is already being planned?

As far as I recall it was more along the lines of MiG-29A perhaps being under consideration for future. But the surprise module itself is said not to be a red-side aircraft a few times.

On 11/27/2020 at 3:08 AM, Dragon1-1 said:

Remember that this might well be the reason ED did not. I don't know how common a practice this is in this industry, but in many other areas, when you arrange a licensing deal, you try to put an exclusivity clause in, just so that other developers can't just go and buy the same license if they want to compete with you. If VRS have pushed such a clause through, then Boeing couldn't sell the Superbug license to ED even if they wanted to, because they would then be in breach of contract with VRS.

 

In fact, given how long those guys have been making Superbug packs for the previous MSFS versions, I wouldn't be surprised if they were sitting on the license all this time. If so, short of actually getting them to make it for DCS, too, we've got no chance of getting it.

As much as you might be spot on with this, I'd very much hate companies for being companies if that was the case. DCS is never competition to a 3rd party addon to a civsim. Not even remotely. And TBH, if such a license would be blocked by a 3rd party that only works for a civsim, this would be such an utter waste to be fair.

On 11/29/2020 at 8:04 AM, Notso said:

I sort of get what you're saying, but the picture you paint are two people who have agreed to "fly" together as a crew in MP or SP - and then just start playing with each other's "stuff" randomly at the same times. The big challenge IRL in a crewed aircraft is the crew coordination that boils down to who does what and when. If y'all are hammering on each others switches, controls, stick and throttle at the same time - then you deserve to desync. The crew contract could be as simple as "don't touch my sh*t and I won't touch yours unless we agree on it ahead of time.

This certainly is a point, but exactly there come the problems and managing on how to deal with those is the nut to crack.

On 12/3/2020 at 3:52 PM, Fri13 said:

It doesn't work when players controllers are sending ghost inputs and you have axis input transmitted constantly on each movement. Everytime the axis moves it overrides the other controller binded for that same axis. If you have two perfect controllers that doesn't send any ghost inputs, then you can switch between them as perfectly as long you use either one at the time. If you start to move both same time, it is the controller that was last one to start sending new input.

 

Again, it doesn't work if there is no communication where instructor would be required to use a communication menu "I have the controls" that activates the instructor controls and disables the trainee input. There just is no way to have two digital inputs same time for the same output. 

Well, I'd personally suggest having the control inputs merged, just as if you'd put two controlers in UJR with "Merge" (maybe it's another function, don't quote me on that exactly, but it's in there) that result in one axis. Each of them control the thing just fine, but everytime the other controller does some input as well, it kinda gets added. So basically if the student flies a 60° AoB 2G turn, but the teacher wanted him to do less, he could always correct the attutide with his stick - of course while telling him at the same time so he doesn't try to correct the corrections. Now the real deal here is latency. Something we simply can't just overcome, especially over the internet. As long as mankind has yet to overcome the speed of 1c with literally anything (waves, signals, etc), we won't be having that without noticable delay ever. Basically there should at least be an option to do the "You have control" - "I have control" - "You have control" thing by clicking some keybinds, comm options or whatever, but it should absolutely not be mandatory right off the bat. Also a tricky thing to solve is anything that's sliders or rotaries. You can't just merge those which is fine for sticks and rudders (without FFB though, that would need a different treatment), since you're literally adding another amount of force to what's applied already by the other guy.

On 12/3/2020 at 2:52 AM, phant said:

So, less than a month to know!

Well, considering that ED didn't bring updates or newsletters over the holidays in the past and usually come back in January, they literally do have two more newsletters (11th and 18th) to tell us which the brain melter is going to be, unless they really delay the announcement altogether because of reasons.

Oh and well, the more I've read this thread, the more I tend to believe it's going to be:

I mean, there's literally everything else ruled out, well, almost

But in the end, I'll just wait another two weeks^soon™ and see

23 minutes ago, Eldur said:

As much as you might be spot on with this, I'd very much hate companies for being companies if that was the case. DCS is never competition to a 3rd party addon to a civsim. Not even remotely. And TBH, if such a license would be blocked by a 3rd party that only works for a civsim, this would be such an utter waste to be fair.

That's just how it is. In entertainment industry, exclusivity deals are common. You don't want your competition to see your fancy new product doing well, promptly bid for the same license and cut into your profits with a knock-off. Also, DCS would definitely definitely be a competition for any other Superbug addon. Remember that it's a small and very tight market, some hardcore Superbug fans would be willing to buy both, but if someone had to choose only one, DCS would likely win out in most cases, due to supporting actual combat operations. Right now, anyone who wants to fly the Superbug only has one choice, and this suits its creators just fine. If that's the case, the only option would be to convince VRS to expand their offer to cover DCS.