Page 1 of 1
Posted: Tue Nov 23, 2010 3:45 am
I have a couple of questions:
1) Could I expect applications I have written for ESP to work for Prepar3d without modification? If not, could you give me the headlines regarding changes please?
2) From the user point of view, is the GUI / Menu system the same as that in ESP? I.e. menus to change airport, aircraft, time of day, weather and views etc?
Posted: Tue Nov 23, 2010 7:41 am
(1) All of our applications ported over to P3D with no changes but there was not a lot changed in the SDK (SimConnect). One change that has been helpful to us was going to a static lib instead of a DLL.
(2) The UI is very different from ESP. After using ESP for several years you get to know where everything is and to be honest it has been a pain migrating from the ESP UI to the P3D UI. All of the functionality is there and in some cases (Options -> Settings) data is a little easier to access.
Posted: Wed Nov 24, 2010 7:05 am
Thanks for the info.
Regarding the GUI, Are there are plans to allow it to operate remotely? We would like to have a separate monitor for control of P3D on our Instructor's Station and dedicated displays for OTW / Instrumentation that run through the sims main projectors.
Posted: Wed Nov 24, 2010 8:26 am
Early implementations of our new UI system were capable of running remotely, but the current version is not because some parts of the UI are too tightly coupled with the app. You might be able to leverage the multichannel capability to achieve this however.
We may eventually bring the remote capability back in some form, or expose enough app settings via SimConnect so that a remote operator interface could be developed using the SDK. It will likely depend on how big the customer need is.
Posted: Thu Nov 25, 2010 8:02 am
I am hoping that the app settings would cover our immediate requirement.
In terms of customer need, I would have thought that this is almost a mandatory requirement. We have worked on dozens of air and ground based training systems and have never seen one where the menus appear on the OTW display. In almost all training scenarios I have seen, an instructor sitting at a separate seat is in control of the simulation parameters through an IOS (Instructor's Operating System).
In many cases the OTW display is simply not suitable for use as a UI. Take - say - a target sighting system in a tank simulator. The student (who is sat in a simulated tank turret) is looking through a periscope sight and has both hands in use controlling the turret and gun. Clearly, the use of a mouse and keyboard is impossible in this scenario. It has to be done at another screen in a different location.
Posted: Fri Nov 26, 2010 10:20 am
I suggest you send and inquiry via the contact page which includes a brief description of your immediate requirements. Prepar3D can be configured in many different ways and it is likely that we can help find a way for you to leverage Prepar3D for you project.
ESP and Microsoft Flight Simulator (from which Prepar3D is derived) were origonally designed to be run on one machine and to be configurable by the end user with minimal use of configuration files. For that reason, there are many lower level system configuration settings in the UI that are channel-specific and wouldn't really belong in an IOS. Most higher level simulation parameters are controllable via SimConnect and/or are synchronized between channels when using multi-channel.
Posted: Tue Feb 15, 2011 10:23 am
I would like to second the need for remote control of the UI, and preferably the ability to hide it from screens on the training stations.
We managed to automate a lot of things with ESP, to the point where we had a couple of simulators running in a 'self service' way - so students could turn up and use them for basic training without instructors needing to be present.
The two biggest hurdles we faced were:
- SimConnect can't detect when a user station has menu items or dialogue boxes up (and can't override them).
- We found that a lot of addons, particularly 'in-process' ones from 3rd parties which were included in dll.xml, did not shut down properly when ESP quit - so we had to write code to trawl the running processes and kill them. Otherwise the addon wouldn't work next time ESP started up.