Jump to content
The simFlight Network Forums


  • Posts

  • Joined

  • Last visited

Posts posted by SeanMcLeod

  1. Hi

    Before posting my announcement I checked the SimForums FAQ, http://forums.simflight.com/faq.php to see if there was any mention about announcing new products on the forums.

    There was no specific mention about not allowing announcements for products (payware or freeware). The only reference to spam was in the section on 'private messaging' about people using the email from facility to spam individuals.

    If there are more specific forum rules that I've missed please point me to them.


  2. Hi

    We have developed a glass cockpit PFD add-on for Microsoft Flight Simulator 2002 and 2004. The accurate high-detail PFD can be displayed on the same PC that MSFS is running on (on the same monitor or a separate monitor) or it can be run on separate PC with a network connection.

    The current PFD is modeled on the Airbus A320 but can be used with any of the MSFS aircraft.

    Take a look at the following link for screenshots and to download a demo version.



  3. Hi

    We have developed a glass cockpit PFD add-on for Microsoft Flight Simulator 2002 and 2004. The accurate high-detail PFD can be displayed on the same PC that MSFS is running on (on the same monitor or a separate monitor) or it can be run on separate PC with a network connection.

    The current PFD is modeled on the Airbus A320 but can be used with any of the MSFS aircraft.

    Take a look at the following link for screenshots and to download a demo version.



  4. In other words what used to be called "hacking",

    Or "reverse engineering" :wink:

    I've done just enough disassembly to know how painful it can be :shock:

    This is more than likely a FAQ, but does anyone know why MS don't provide an SDK offering access to the set of variables you support etc.?

    Given the number of interesting MSFS add-ons using your fsuipc, e.g. Project Magenta etc. and even my upcoming add-ons :wink: you'd think MS would want to support and encourage such development by providing a full-featured SDK, rather than relying on you dissambling their stuff to provide a public sdk.


  5. Hi

    I actually have to monitor the writes to many many things and use the written data in parameters to calls into assorted FS DLLs.


    Sometimes an apparently simply thing takes several calls to several hacked entries in several different DLLs.

    How do you figure out what FS DLLs to call into etc.? The only documentation I've come across from MS in terms of an SDK is for the gauges SDK.

    Or is it just trial and error by looking at the exported functions and classes exposed by the various FS DLLs?


  6. FSUIPC doesn't stop you writing to them, but I don't think that does you much good. Have you tried? Let me know if you can make it do anything.

    I tried (using FS2002) writing to viewpoint angle variable but it had no effect. On subsequent reads of the variable I would see the value I'd written, but there was no visual difference in FS2002.

    I tried changing the view option in FS in case it only worked in certain views like virtual cockpit etc., but that made no difference.

    So I guess either the write isn't working, or maybe there is some other variable that has to be written to first to enable the view changes?

    Since ActiveCamera already does such a good job, I know not how, this isn't really an area I would dedicate time to. Sorry. Let's solve new problems, not try to reproduce other's solutions, eh?

    If your platform (FSUIPC) supported this then yes it would enable other developers to produce direct competitors to ActiveCamera, but it would also open the possibility of some developer coming up with a new and innovative add-on using these variables :wink:


  7. Hi

    I noticed the viewpoint variables (0x5B0 and 0x5D2) recently. Now if they could be written to (SDK-17 doc says they're read-only) it should be fairly easy to create something like ActiveCamera.

    Although what seems to be missing is a viewing angle in the vertical/pitch plane. Currently the SDK lists a 3D position (lat,lon, altitude) and a view direction which I presume is the direction in the horizontal plane.

    I'd be interested in hearing if you find a way to make the variables "writeable".


  8. The value labelled "TRK" in degrees magnetic in the GPS is defitiely track, not heading. I don't know who said it wasn't, but I think they are wrong.

    I was specifically refering to the GPS window in MSFS 2002, I can't test in MSFS 2004 at the moment.

    In FS2002 it's definitely the heading that is displayed and not the ground track, e.g. in the autopilot I select a heading of 185 and then add a wind component in the weather interface and after adding the wind component the GPS TRK is still 185.

    More than likely this has been fixed with the whole new GPS interface in FS2004.

  9. Seems to work as expected. I've only tested on FS2002 so far. First test was to compare my calculated track with MSFS's heading in the absence of wind, they should be identical and they were to a good number of decimal places.

    Then I added some wind via MSFS's weather interface and sure enough there was now a difference between my computed track and the heading I'd selected for the auto-pilot to follow.

    I opened the GPS window which displays the ground speed and a value labeled TRK, although as I'd seen mentioned somewhere else the value displayed for TRK is erroneous and is actually the aircraft's heading. So I couldn't use it's value as a cross-reference.

    However taking the groundspeed value, the airspeed value I'd entered in the weather interface and performing some simple trig. the angle from the trig. computation matched the difference in the angle between my computed track and the selected heading.

    So these variables do seem to be the aircraft's velocity in the world axes after the wind etc. has been applied.


  10. Hi

    Yes, I'm looking for a solution that will work on FS2004 and FS2002.

    The track is provided by the INS...

    The FSUIPC SDK docs state that:

    0x3190, 0x3198 Z - forward/back velocity, X - left/right velocity

    are relative to the world axes.

    And I presume the values are the overall result after MSFS has applied the wind to the aircraft?

    If so then they would essentially act as INS data that I could use to calculate the track from.


  11. If the performance drop is so severe with HT then I'm suprised MS didn't change the process affinity when FS2004 starts up and detects a HT enabled CPU.

    Especially since HT cpus shipped before FS2004 shipped and since pretty much all the new high-end Intel cpus will ship with HT from now on.

    It is also possible to tell the difference between a HT setup and a more regular SMP setup and so also possibly only change the process affinity in the HT case if the regular SMP case doesn't show a performance drop.

  12. That's an INDICATOR, You can't move the elevators by modifying the indicator, nor for that matter changing the "elevator deflection" readout. Surely this should come as no surprise? Indicators indicate.

    Reason I thought it may be possible was because those appeared to be the only variables referencing flight control surface's positions, plus the docs said they were 'writeable'. I assumed if they were really just 'indicators' then they would've been read-only.

    To move the control surfaces you use the controls.

    Not real autopilots :D The controls stay fixed and the computer sends independent commands to the control surface's actuator.

    Plus I don't want slight pilot 'bumps' of the controls to be intefere with the autopilot's inputs. Although I see on further reading of the SDK doc there is a special byte at 310A to allow for disconnecting the joystick.

    Also what about the case of FBW planes like the B-777, A320 etc. where the pilot's control input is heavily filtered and possibly limited etc. before actually moving the control surfaces?

    Even non-FBW aircraft like B-737s etc. have some filtering applied to the pilot's control input based on airspeed etc.

    So to wrap up, if I want to control the elevator surface from my autopilot code I should: ?

    1. Disconnect the joystick by using variable 310A

    2. Write to 0BB2 - Elevator control input

    Will this combination also allow my autopilot to move the control surface without being filtered by an aircraft's FBW system?

    And if I wanted to implement my own FBW control laws:

    1. Disconnect joystick by using variable 310A

    2. Read pilot's control input from 3328 - Elevator axis input

    3. Apply my FBW control filtering and write to 0BB2 - Elevator control input

    I'm not sure that I fully understand the relationship between Elevator axis input (3328) and Elevator control input (0BB2) correctly and when how MSFS's FBW control logic would be in the chain.


  13. I'm busy looking into something similar, basically implementing an auto-pilot, although in my case my auto-pilot code will run on the same machine as MSFS and not on an external RTOS machine.

    I have some experience using FSUIPC on a previous university project that I helped out on for a motion platform driven from MSFS. In that one I basically wrote some code that used FSUIPC to extract some relevant data from MSFS (aircraft attitude, aircraft accelerations etc.) run that through some transformation filters to determine what position the motion platform should be put into and then communicated with a D/A board to send the final analog signals to the motion platform's motors to get it to drive the platform.

    See the following link for a short 30 sec video of the motion platform that was built.

    If you look at the FSUIPC SDK docs and let me know what subset of the variables you need as input, e.g. aircraft attitude (pitch, roll, yaw), aircraft accelerations etc. then I could write a small program that runs on the MSFS PC that used FSUIPC to read the variables and would send them to your RTOS platform as a custom tcp/udp packet.

    Similarly the small interface program would listen for custom tcp/udp packets returned from your RTOS with position info for the flight surfaces and it would then again use FSUIPC to update the positions of the flight surfaces based on your calculations.

    So if your RTOS includes tcp/udp support then all you'd need to concentrate on would be the actual algorithms for translating the aircraft input data into new flight surface positions.

    On the flight surface positions I actually have a question for Pete. Your SDK docs list of number of variables for the flight surface position/deflection, e.g.:


    However there is no comment on the range or type of units. Is it the same range for all aircraft or does it vary from aircraft to aircfract?

    Or am I looking at the wrong variables and should rather be modifying something like:

    0BB4 - Elevator position indicator


  14. That sort of slow down seems like the real worst case.

    With hyper-threading enabled run FS2004 and then use Task Manager to set the FS2004's process affinity to just CPU0.

    Processes tab in Task Manager and then right click the FS2004 process and select "Set affinity..."

    And see whether the frame rates improve.

    Any one else with a hyper-threaded CPU who can confirm similiar slowdowns?

  15. Looking at other benchmarks some multi-threaded apps can achieve upto a 30% performance boost with hyper-threading enabled, but others can suffer a performance drop and actually run slower.

    Really depends on the access paterns/contention between the different threads which dictates whether the hyper-threading shows a boost or decline in performance.

    Since hyper-threading CPUs arrived before FS2003 was released I'd imagine MS would've done some performance tests on hyper-threaded CPUs.

    And if it showed a big performance drop with hyper-threading enabled they would've either tuned/modified their code or they could've resorted to changing their process affinity mask to prevent their threads from trying to use both 'logical' CPUs, i.e. forced all their threads to only execute on the main CPU, which should result in roughly the same performance as disabling hyper-threading in the BIOS.

    Does anyone have any FS2003 benchmarks on a hyper-threading system that started with a clean Windows XP install and then tried disabling hyper-threading in the BIOS?

  16. The FSUIPC SDK docs state that the AI traffic information in FS2002 is read-only. Does anyone know if the AI traffic will be writable in FS2004?

    And if it is writable will it be possible to also specify the AI aircraft's attitude (pitch, bank, heading) in addition to it's lat/lon/altitude?

    If not am I missing some other mechanism that is available that allows a programmer to inject 1 or more additional aircraft into the sim and be able to specify their attitude as well as their 3D position?

    I guess maybe I should look at the multi-player SDK, maybe that will allow me to inject another plane programatically?


  17. Hi

    I'm looking to retrieve the current Angle of Attack (AoA) from FS2002.

    The SDK docs have the following to say about the AoA value:

    "Angle of Attack. This is actually a relative value, giving in %*32767 the difference between the current AofA and the maximum angle of attack for the current aircraft. For a relative measure of AofA calculate 100-(100*#/32767), where # is this number. (Thanks to Sergey Khantsis for this clarification)."

    My question is where do I find the maximum AoA for the current aircraft so I can calculate the actual current AoA? I looked at the .air files and the .cfg files but didn't see it listed.

    Can someone point me to a table listing the maximum AoA for the different aircraft in FS2002?


  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.