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