How to build a FSUIPC-based module instead of standalone app

[PhilippM]

Hi developers,

at the moment my application is a separate .exe file that uses the FSUIPC.lib and has to be started once FS is running and to be stopped when FS is shut down.

Now I want to integrate the application as a module (dll) into the FS process itself rather than requiring the user to start it.

I found the MoudleUser.lib to be the preferred way of accessing FSUIPC data in that case, but I have a much more basic question: With exactly what callbacks do I have to replace my "main()" function? What callbacks must my FS-module expose to runtime linkage so it is called in FS startup ?

Philipp

[Pete Dowson]

at the moment my application is a separate .exe file that uses the FSUIPC.lib and has to be started once FS is running and to be stopped when FS is shut down.

Now I want to integrate the application as a module (dll) into the FS process itself rather than requiring the user to start it.

That's not really a good reason for implementing it as a DLL. You can do what you want to do by having it started and ended automatically by a parameter in the FSUIPC INI file in any case -- see the chapter on "Programs: facilities to load and run additional programs" in the FSUIPC Advanced Users guide.

Writing a program to run in the same process as FS means taking great care to avoid affecting its performance. You don't have the benefit of windows operating its timesharing capabilities, nor will your code necessarily run on a different core. You also have to take great care not to crash FS through any mishandling or using non-reentrant library or FS facilities. It's a lot more work.

I found the MoudleUser.lib to be the preferred way of accessing FSUIPC data in that case, but I have a much more basic question: With exactly what callbacks do I have to replace my "main()" function? What callbacks must my FS-module expose to runtime linkage so it is called in FS startup ?

It depends on whether you are talking about FS9 and before or FSX. For FS9 and before, loadable DLLs are like Gauges but with filetype DLL instead of GAU. Try writing a gauge in C and you'll get the idea. For FSX you'll find information on your questions in the SimConnect SDK.

Regards

Pete

[PhilippM]

That's not really a good reason for implementing it as a DLL. You can do what you want to do by having it started and ended automatically by a parameter in the FSUIPC INI file in any case

Thanks for pointing me at this option. Is this "program start"-capability also available to users of the unregistered version?

The main problem I sense with this approach is that 90% of the users won't read the manual where I instruct them to edit the .ini file. And from the remaining 10% who read the manual, 90% will stumble over getting the editing right, forget parameters and so on. Yes, I read about the program by Jose Olivera, but thats another tool the user would have to downlaod and deploy. I'm looking for an absolutely fool-proof solution that is totally invisible to the end-user. In a perfect world, the installer of my application would append the parameter to the FSUIPC.ini.

Writing a program to run in the same process as FS means taking great care to avoid affecting its performance. You don't have the benefit of windows operating its timesharing capabilities, nor will your code necessarily run on a different core.

I totally agree on that and I'm aware of how difficult "in-the-flightloop"-applications are to develop. Been there and done that in the X-Plane world.

It depends on whether you are talking about FS9 and before or FSX. For FS9 and before, loadable DLLs are like Gauges but with filetype DLL instead of GAU. Try writing a gauge in C and you'll get the idea. For FSX you'll find information on your questions in the SimConnect SDK.

So there is no generic approach for both sims?

Than to sum it up:

External app:

pros:

-easier on the performance

-same approach for FS9 and FSX

cons:

-modifying fsuipc.ini is beyond most users capabilities

Internal module:

pros:

-transparent to the user

cons:

-performance issues

-Separate modules for FS9 and X needed.

So if you/others have an idea how to get the "external program startup" transparent to the end-user it would be greatly appreciated.

Philipp

[Pete Dowson]

Is this "program start"-capability also available to users of the unregistered version?

I had to look that one up -- as far as I can see, yes, it is. But try it to make sure.

The main problem I sense with this approach is that 90% of the users won't read the manual where I instruct them to edit the .ini file. And from the remaining 10% who read the manual, 90% will stumble over getting the editing right, forget parameters and so on.

Yes, as they do now with FSX's EXE.XML and DLL.XML, the ways to autostart EXE and DLL's in FSX.

I'm looking for an absolutely fool-proof solution that is totally invisible to the end-user.

Unfortunately there's no such thing. There's always a fool which will prove that. ;-)

So there is no generic approach for both sims?

No. Not only that but to get anything loaded in FSX means editing those XML files -- much more error prone and fussy than an INI!

Internal module:

pros:

-transparent to the user

Except on FSX, where the DLL.XML needs editing, same as FSUIPC.INI really. Of course your installer could do such a job.

cons:

-Separate modules for FS9 and X needed.

Well you can get around that by building in both the mechanisms for FS9 and FSX into the one module. They don't conflict. You'd have two entry points, two initialisations and terminations, depending which FS it was.

Regards

Pete