Jump to content
The simFlight Network Forums

SeanMcLeod

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

0 Neutral

About SeanMcLeod

  • Rank
    Member
  • Birthday 01/01/1970

Contact Methods

  • Website URL
    http://
  1. 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. Cheers
  2. Hi 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? Cheers
  3. 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? 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: Cheers
  4. 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". Cheers
  5. 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.
  6. 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. Cheers
  7. Hi Yes, I'm looking for a solution that will work on FS2004 and FS2002. 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. Thanks
  8. Hi I'm looking to read the aircraft's current ground track via FSUIPC. I've found a variable which gives the aircraft's heading, but can't find one for the ground track. Is there one I'm missing, or do I need to calculate it myself based on: 0x3190 Z - forward/back velocity and 0x3198 X - left/right velocity Thanks
  9. Maybe FS2004 decides at installation time based on whether it detects a HT enabled CPU whether to adjust it's process affinity from the norm of running on all CPUs and not each time it starts. Do they people who see big gains by manually adjusting the processor affinity for FS2004 remember whether they had HT enabled when they installed FS2004?
  10. 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.
  11. 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. 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. Thanks
  12. 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.: 2E98 - ELEVATOR_DEFLECTION (FLOAT64) 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 Cheers
  13. Thanks for the speedy (7 min delay) reply! :)
  14. Hi Is there going to be an updated FSUIPC SDK? If so do you have an estimated timeframe? The download from http://www.schiratti.com/dowson.html is dated Feb 1st 2003, version 15. Thanks
  15. 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?
×
×
  • 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.