External DLL interface no longer works properly

Hi all,

I rely on the external DLL SDK to drive a motion system. Unfortunately, with the recent update it no longer functions properly.

Note: I don't know if the latest release caused the problem: I didn't run FS2 for a while. The release in question is 2.4.5.31 (by the main exe file info). I have a fairly old backup of 2.0.11.3, and if I run it, everything works fine.

The problem is this:

• The main update function, Aerofly_FS_2_External_DLL_Update(), seems to be called at only 10 Hz instead of every frame (or ~60 Hz). (As an alternative explanation, the first argument, delta_time, may be incorrect: I haven't checked it, but this is less likely).
• Acceleration-related data, namely Aircraft.Acceleration and Aircraft.Gravity, are non-sensical: they contain strange peaks about every second and zero most of the time. At the same time, Aircraft.AngularVelocity is correct.

The latest SDK update is from 2018-08-23, more than half a year old. I had my plug-in compiled with an even older SDK (2017), and now I tried with this new one, and the result is the same. (Anyway, the changes between them are not significant for this task and are (supposedly) non-breaking, and all have TM_DLL_INTERFACE_VERSION = 1).

Are there any unannounced changes, or it's just a bug? Could the developers fix it? One cannot drive motion with broken data like this...

Quote from Jet-Pack

Which Aerofly FS 2 version are you using? Steam or DVD?

Steam. But I'm interested in both. If the DVD version behaves any differently, I could use it instead.

Quote from Spit40

Its been "broken" for about 6 months. I think when the R22 came in and around the same day I'd finished building my g-seat which requires those acceleration DOFs. IPACS say they'll build a new one but at present they're just supporting preferred partners.

I feared that. But if so, I find it strange they don't immediately fix it. It must be a small mistake/regression somewhere: the flight dynamics engine must have this data readily available, and it must be correct, otherwise nothing would fly. Such things are usually one-line problems...

Meanwhile, without this data, FS2 cannot be used in a professional environment.

Have you already reported the problem to IPACS when you found it?

Quote from MartinM

Lets be realistic - Motion Platform resources are currently being invested where the big money sits. Thats not an offense but a reality.

A good move? Not for the non-commercial community.

Unless some smart community user comes up with a solution, like FSUIPC, I guess IPACS will not push it - dead end. Blame me, if I am wrong with my observation - lets c in a year from now

I'm sorry, but I don't buy this. Motion, at least in its basic form, doesn't require anything but an interface to the already existing data (accelerations, angular velocities, attitude) in real time. (It's far from trivial how to use this data to create good motion, but this is our problem, not IPACS's). Such an interface was already developed and worked for a couple of years. Breaking half of it (while still having an official SDK to use it) can only be a bug.

Now, a company can decide not to fix it, of course, esp. if they were going to redo the whole thing anyway. However,

• This shows poor attitude. Even if it was free, it's still an official and current product. I bought it specifically because it had an external interface (incl. for motion). For many PC Sim users, from home to professional simulators (many of them are based on off-the-shelf sims like FS2), a flight sim is totally useless without an external interface. A company that lets this to happen has no trust, esp. when compared to others that do take it seriously (e.g. X-Plane). This is exacerbated by the idiotic policy of 'required' updates on Steam.
• Being an engineer, I'm almost sure the actual problem is simple and require little effort to fix. If the new interface was a week away, then fine, but with 'no timeline', the 'old' product should be supported.

As for FSUIPC, it was needed only because MSFS lacked any interface then and was the only available sim of that kind. Neither is the case now. FS2 does have an interface (which half works), and has decent alternatives.

Quote from admin

Please no speculations here. We will bring back motion support, we have stated this in other threads before. But before doing this, we want to finish the new interface first together with a few partners. Sorry we have no timeline for this right now, we will keep you updated.

The DLL solution people previously used was never ment for being used for this purpose, therefor we are working on a dedicated interface here. Also some of the available solutions broke our actual VR implementation by not being 100% sync to what Aerofly FS was rendering, so there is clearly the need to work on a dedicated interface and not through 3rd party DLL solutions.

Thanks for the reply. I should have done more research, but in my mind such situation couldn't last long - it would cause a revolt. So I checked only a couple of recent pages...

I fully agree that a better interface would be desirable. However, with 'no timeline' for it, in the meantime why don't you fix what almost works, and worked before? As I tried to argue above, a modern PC flight sim is practically useless without such an interface: it's an enthusiasts' game, and they tend to build rigs around it, if not now, then potentially. Also, professional sim manufacturers evaluate software based on its flexibility and support...

May I ask what the 'old' interface was 'meant' for? If we consider only output for a moment, the requirements are basically the same for any practical task, whether it's motion or driving the gauges or recording, etc.: real-time access to most of the simulation data. I hope in the new interface you won't restrict the output only to a small subset of 'motion' data such as accelerations. Even motion often makes use of additional data to create various effects.