Therefore I have taken the decision to delay release of the P-40F and future VEAO modules until a stable DCS 2.5 has been released. I feel that this is the only way forward and it is not a decision I have thought about lightly.

To quote Pete on our FB page:
"Yes in short, we rely on more outputs from dcs then other developers do, so when something changes for a dcs update it can throw things out of whack, it's something we are battling but it's a fundamental change to approach, it's getting better but not quite there yet.
Pman"

When we coded the Hawk we were one of the first 3rd party developers to be in contract with TFC and the SDK was in its infancy.
Hawk was coded back then for what existed within DCS at that time.
DCS has evolved massively form 1.2.16 to 1.5 to 2.0 and now upcoming 2.1
A lot of code was re-written when we released the EFM.

However; we have to rely on DCS passing the module certain information; mostly atmospheric but there are a few other core systems that DCS communicates back and forward with the module.

I cannot comment on how other 3rd party developers make their aircraft talk to DCS and vice versa and to what level of detail.

Now with our modules so far we have relied on DCS heavily to pass that information across to the module and back again.

Let's say DCS uses parameter X and we are looking for a value of X but suddenly that value is no longer X but Y then some co-dependencies of our systems will fall over and could cause cascading faults, which we have to try and bug hunt.

An example of this is the HSI spinning on start-up in Hawk. One version it was absolutely fine and the next patch it started spinning wildly for no reason on power-up.
It took us a while to figure out that there had actually been a power trip caused by the sim and this is why the HSI spins when the DC bus goes live.
Why does it power trip? Well because Hawk has been coded to schematic level and that's what the real HSI does when a power trip happens.
Why is the sim telling it there is a power trip? We have no idea, still today.
So the easiest answer to that is to remove the power trip function.

Well we shouldn't have to, that's how the real aircraft works but let's suppose that we want to remove it.
There are a ton of dependencies within the AHRS system; navigation, course, heading bug, ILS, VORTAC, Etc. and the code is complicated enough that if we remove the power-trip functionality it could mess up something else entirely so it's a lengthy process to disect.

We're not saying the code is incompatible, we are saying we are experiencing problems that we don't fully understand as to why DCS causes them.
No it shouldn't be like that but the fact of the matter is that it is.

Another example is with P-40 happening right now. We had a fully flyable aircraft as you've seen from Pete and my videos. I could even live stream it right now with the version I have.
The guys did an SDK update last week and now they have no thrust at all.
The throttle moves in animation and the control indicator shows the throttle input moving, but again no thrust.
We've not changed anything. So now the guys are going through each parameter DCS is passing to us to see what's changed and what is causing no thrust.

We can't allow that to happen when it gets in your hands. So we have to code less dependencies on DCS passing the parameters to us.
And therein lies the problem; we code around this for 1.5.6 but what does 2.0 and 2.1 do. Oh look it's fine in one of those versions, but why....

The decision to continue to develop but not release until 2.5 means we are not trying to bug hunt for 4 different versions of DCS but 1 or 2 (release and development) which means these sorts of problems shouldn't crop up and cause similar issues to that Hawk has been having over the years.

So, how long until ED closes the thread?

Where's the NDA?

So much for DCS being "modular" if one dev integrates their module one way and another dev integrates their module another way..... the comedy just writes itself, really.

It's not my place to comment on the internal structure of VEAO's Coding team.

That being said, any discussion of coding in detail is likely a NDA Violation as well.

The Core Sim Likely Changes faster than the Coders can keep up with, and trying to develop across what's 4 Branches now (REL, OB, OA, Normany Closed ALpha), can cause a head ache as to why a function works in one branch and not another.,

So it's best to pick a single Branch (ie 2.5), and develop for that one, as when 2.5 is released it will eventually take over all branches, and the code base will be the same across REL, OB, OA branches.

The Core Sim Likely Changes faster than the Coders can keep up with

they're blinded by ignorance and military contracts that bankroll the losses and waste of resources in their desktop development and products.

Again, I ask --- what recent product(s) do they have that have come from military contracts?

Are you saying 2.5 is the "engine"? If this were true, then ED would've released 2.5 ages ago as it clearly would've been top priority.

Is it just me, or is this statement the epitome of stupidity?

Again, I ask --- what recent product(s) do they have that have come from military contracts?