Jump to content


  • Content Count

  • Donations

  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. Hi Mike,to give a somewhat solid advice, i need to know more about the original problem you are trying to solve.Here are two extreme cases of original problems to illustrate the possible solutions ..Problem A) Near some big airport, a new 1100 ft skyscraper is being built very close to waypoint Delta. Because of that, the published approach to runway X has to be changed. Your boss has invented a new one that is pretty much the same as the old one except for these minor adjustments:- Altitude at waypoint Alpha was and will be 2000 ft.- Altitude at waypoint Delta was 1000 ft but will be 1500 ft.- Altitude at waypoint Gamma was and will be 500 ft.Which means from Alpha to Delta the aircraft will have to sink slower than before, but from Delta to Gamma it will have to sink faster than before.Your job is to do a first check if that new approach looks ok or not, and so you want to look at it in FSX, and you want to try if it is possible to fly that new approach.So you create some custom scenery addon with the new skyscraper.Next, you define a flight plan in FSX that follows the waypoints of the new approach. Then you fly it in a C172 and a B747. In FSX, both have GPS and autopilot, so they can follow the track, but you have to set altitude and sink rate on the autopilot manually. Or you could write a little SimConect program that monitors position and sets altitude and sink rate on the autopilot. Or you could get some addon aircraft (e.g. from LevelD or others) that has a FMC/FMS with VNAV management.Then you could play with the weather settings in FSX to give all kinds of bad conditions and see what happens ..To the professionals: No, i dont think that ARINC 42x conforming approaches should be developed this way .. The important point in this example is, that the real world data is very loosely coupled to the simulation. We have a very small number of real world data samples (just the 3 waypoints and altitude) with lots of time between (minutes). FSX "connects the dots" using its own idea of weather and aerodynamics and cockpit systems simulation. The multimillion dollar simulators from Boing and others are most likely somewhat more precise.Problem :( After some soaring plane championship you get the pilots flight recordings and you have to check if someone has cheated by editing the recorded data. The recorded data looks like this:one sample every 10 seconds, consisting of latitude, longitude and altitude. Each sample is one line in a text file. You write a SimConnect program that reads the recorded data and sends one sample every 10 seconds to FSX. On each received sample, FSX sets the aircrafts position accordingly and lets the FSX engine run. With a locked frame rate of 20 fps, FSX will have calculated and drawn 200 frames until the next sample comes in. Most likely the simulated aircraft position, orientation and speed in FSX after these 200 frames will differ slightly from the next real world data sample. For example, in FSX the left wing touched a thermal with 3 fpm uplift, but in the real flight the right wing touched a 7 fpm thermal uplift. So in FSX the aircraft will do a small jump every 10 seconds to resync with the recorded data. It depends on your original problem, whether these small jumps just look funny but are tolerable or not. For example if you see a sudden huge jump instead of lots of tiny jumps, the recorded data smells like cheating ..In this example the simulation is coupled very tightly to the recorded data (lots of samples) with small time steps.Each problem comes with its own can of worms ..Thats why i need to know more about your original problem.What real world data is recorded ?- position (lat, lon, alt)- aircraft orientation (pitch, roll, yaw angles)- speed (amount and direction), momentum (1st derivation)- sample rate- small plane or big iron- what else ..What is important about the resulting simulated flight ?- view from outside- view from cockpit to outside- displayed values on cockpit instruments- preformance data (time enroute, fuel consumption, derivation from planned track/altitude, ...)- what simulation errors are tolerable- what errors are not tolerable- what else ..Martin
  2. Hi Mike,>3. MOST IMPORTANT... I would like the ability to be able to>take a set of data of a (real) aircraft flight and import it>into FSX and make the FSX aircraft fly the flight.With SimConnect (part of the SDK) you can read all kinds of data from FSX and as well feed data like position, speed, direction, and much more into FSX. However, you cant change physics, e.g. you cant fly the Cessna 172 at Mach 2 - but you could use slew mode.What exactly do you have in mind ?Martin
  3. >Ah Yes, "gray areas". I see you as carefully straddling the>"gray area demarcation line", but not over it. You choose your>line most carefully, and in that sense you are a true "Open>Source Hero". Umm, maybe someone from MS Aces Team (guess who i'm thinking about ..) could talk someone from MS VirtualEarth Team into some kind of special permission to use FSX/FS11 as an alternate browser for VirtualEarth ? ...For example, if TileProxy would read a flight plan defined in FSX to preload stuff it would still be some kind of interactive access ?There must be some FS addicts in the VirtualEarth Team ..Martin
  4. > In the cases I'm seeing, it is not only things like mesh or > landclass being loaded but individual scenery items...buses, > tires, >papi, etc.MS Aces uses certain conventions what they put in what bgl files (e.g. airports in APX at QMID 7, navaids in ATX at QMID 4, vector data in CVX at QMID 7, ...). I am sure these conventions are fine tuned to the FSX engine for optimal performance and minimal memory footprint.However the BGL compiler does not enforce these conventions. A somewhat clueless scenery author can throw all kind of unrelated stuff in the same bgl file. A smart scsnery author would analyze the standard scenery to learn the conventions and follow them.And then: what was ok in FS9 might be bad in FSX ..So just recompiling unchanged sources of an FS9 scenery with FSX SDK will give a working (error free) FSX scenery, but at bad performance.> And the mysterious part is that the associated textures are> never accessed.Well, textures are only needed when the thing becomes visible to the eye. Position info might be needed much earlier, e.g. when the GPS can see it ..Martin
  5. Hi Paul,>Also, I'm not entirely certain that the 'out of area' BGL loading is restricted to addon scenery. It depends on the bgl files content, e.g. the six bgl files containing geopolitical boundaries each cover 90 degrees latitude and 120 degrees longitude (QMID 2). On the other hand, APX*.bgl files (which contain airports) cover an area of only 3x3 degrees (QMID 7). ATX*.bgl contain navigation aids information and cover an area of 22x22 degrees (QMID 4). As far as I understand, each bgl file can have its own QMID level setting in the header, even wrong ones .. ;-P>So, in the discussions here, can one safely assume that "tile" refers to the QMID level 4 size?Nope, see above. However I think Phil referred to QMID 7, but i am just guessing ..It doesnt make sense to load all airport buildings of KSFO when youre sitting at KJFK. However it makes sense to load the waypoints / intersections and victor / jet airways between KJFK and KSFO ..The internal structure of each bgl file is organized like an directory. So if FSX accesses a bgl file, it might load it as a whole or just some small subset of interesting parts, e.g. when sitting at KJFK, FSK might load the bgl containing KJFK as a whole (to get all runways, taxi ways, parking spots, buildings, and whatever ...). When FSX loads the bgl file with KSFO (while still sitting at KJFK), it might extract only the ARP coordinates of KSFO and maybe the approach and transition info, and leave the rest for later when you get closer. Filemon doesnt tell you what exactly FSX reads from those files, just that FSX opened it.The standard scenery is about 12 GB, so FSX simply cannot keep it all in memory, but has to load and reload scenery info again and again to limit its own memory footprint. FSX has no other choice than to rely on the bgl header info being correct. If a bgl file says it covers area X, FSX has to load it when in area X or close to it.Now one could argue why 4.5 tiles instead of 2 or 6 ..I have no clue why 4.5 is the magic number, but im sure if MS ACES could use a smaller value they would use it, just to minimize FSX memory footprint.There are a number of different factors that determine that magic number:- how much scenery is visible to the eye from max altitude ?- what nav info is "visible" to the gps at max range ?>This is rather interesting but doesn't relate as to WHY those>files are being loaded in the first place. That is what I'm>striving to understand here.To understand what FSX is doing (and WHY !), I would recommend to turn of all addon scenery (assuming that the standard scenery files always use the smallest needed QMID), then fly from x to y and check whats happening in filemon, then look at TmfViewer to check if that makes some sense. After a while you will get a "feeling" for necessary vs. unnecessary loads.After that, you can activate addon sceneries one by one and repeat the same flight again. If something way outside the loaded standard scenery is touched, it is a very strong hint that the QMID header info in that addon scenery is to high.The latest version of TileProxy has a nice map overlay for monitoring the file access, however i dont know how to use that map thing without TileProxy. But it might help to get a "feeling" for the loading patterns ..Martin
  6. To Phil Taylor:Thanks for FSX and thanks for your unlimited patience to deal with users whose strength of judgement is reverse proportional to their knowledge ..To Paul (original poster):The fact that (except for Reno) only addon scenery leaves these big footprints in filemon is a strong hint that we have a data problem, not a code problem.Please look at the following docs in the FSX SDK:- Environment Kit / Terrain SDK / Terrain and Scenery- Environment Kit / BGL Compiler SDK / Compiling BGLThe world scenery is divided into 8x12=96 rectangular tiles (at QMID level 4). These are the four digit named subdirectories in the scenery folder. Each of these tiles is further subdivided into 8x8=64 subtiles (at QMID level 7). Most bgl files stick to this tiling scheme.Here is a somewhat simplified explanation of whats going on:FSX scenery engine needs to know when to load a bgl file. So it looks at the bgl file header to find out what area of the world that bgl file corresponds to. FSX uses an index of all scenery files to look up those areas. If the aircraft is inside or close to (4.5 tiles) that area, FSX loads the bgl file, otherwise it doesnt.It is the scenery authors task to minimize that area. Lets assume the author made a typo and defines a VOR range of 5000 nm (instead of 50 nm). Now draw a circle of 5000 nm around that VOR, then draw the smallest rectangle that contains the circle. If that rectangle overlaps the 4.5 tile neighbourhood of the aircraft, FSX has to load the bogus bgl, since the bgl wants to be loaded ...I recommend that you contact the scenery authors and ask them to fix their scenery. Maybe they have a typo in their sources, maybe they did not use the FSX SDK tools but earlier or other tools ..Martin
  7. Right click the AVG icon in the tray and launch AVG Control Center.In AVG Control Center window, double click the component Resident Shield.In the Resident Shield properties dialog, uncheck the first option. Its called: Turn on AVG Free Resident Shield protection.Click OK.The AVG tray icon turn monochrome and Windows XP complains about the security risk ..The Resident Shield component scans files on access. Whenever FSX loads some file, AVG checks if it is still ok. In theory, turning off that scan should improve I/O performance, however I didnt noticed any significant effect on FSX or other applications.
  8. Hi Pat,In FSX RTM and previous versions of FS, you could cycle to the Cockpit View by typing S, then hide the cockpit by typing W several times, and then you could use the coolie hat button on the joystick to look out of the aircraft into eigth different directions.Unfortunately that was lost in SP1 or SP2. Now most of these views are blocked by the aircraft.Hopefully it will come back in FS 11 !However, this still works with FSX SP1/SP2:Cycle to OutSide View with S, then type 1,2,3,4 or 6,7,8,9 on the keypad (number block) section of your keyboard to look at your aircraft (and the scenery beyond) from eigth different directions.Adjust the camera distance / zoom factor with +/- to see more scenery and less aircraft. Type Keypad 0 to return to cockpit view.If you have FSX Deluxe version, check the SDK. In the core utilties kit, read the document about camera configuration to learn how to define your own views. For example you could define several new views with the eyepoint a few feet above your aircrafts center.Martin
  9. >I wonder where I could find a list of detailed sceneries>which can be enjoyable to fly VFR with the default FSX &>Acceleration pack...?>I would like to fly VFR over some detailed nice places and>could not find the detailed areas listed anywhere.>>If you could recommend from your experience it's excellent as>well>Thank youFind the folder where you installed FSX. Inside you find a folder called Scenery with lots of subfolders. Look in the following subfolders:- AFRI = Africa- ASIA = Asia- AUST = Australia- EURE, EURW = Europe East/West- NAMC, NAME, NAMW = North America Center/East/West- OCEN = Oceania- SAME = South AmericaInside these folders, check the subfolder Scenery for bgl files with city names (e.g. AFRI/scenery contains cairo.bgl and capetown.bgl) to find those cities with detailed scenery. All these cities contain 3d models of buildings and other landmarks.The folder Cities contains those cities that use aerial or satellite pictures.Everything else is default scenery, generated from landclass info and elevation models.To find interesting landscape, type S to switch to the Outside View, type A to switch to Top Down View, type - to zoom out and look around ...
  10. >>I think the oceans will no longer flow off the edge. >Thats a frequent misunderstanding of those poor uninformed souls believing all that round earth propaganda !! Of course, its the ice of antarctica that stops the ocean water from flowing off the edge !!!See the proof here: http://en.wikipedia.org/wiki/Flat_Earth_Society... and if all that still doesnt convince you, just try some spherical geometry calculations to see that a round earth is a really baaaad idea ...*:-* :+ :-lol
  11. Same problem at EDDF (Frankfurt, Germany). FS ATC sometimes wants me to land on RWY 18, which in real life is used only for takeoff.The problem is that the scenery data does not (yet) contain local preferences like that. So FSX ATC has to pick the RWY according to wind direction.However you can pick a different RWY and approach. The first time FSX ATC directs you to land on RWY X, watch for the ATC menu options "select another runway/approach/transistion". Usually i get what i want, however i havent tried to pick something completely bogus yet. Might be different with heavy AI traffic and/or stronger wind.
  12. >This is not good.>>No uploads at all for anything FSX.>>Not good at all, no development...>>>alwell, all the other addon authors took a break, waiting for YOUR addon !but since youre not happy, i suggest you demand your money back !Sorry, couldnt resist ..
  13. Hi Christian,i dont know if youre already aware of it, but Adam Szofran (who gave the tip to apply for a job) is the "scenery guy" at MS Aces - you cant get any closer to the core ...
  14. I dont know exactly when position info is set, but since FSX needs the position to know which part of scenery to load, i bet that it is set pretty early.Via Simconnect, you could monitor aircraft position, heading, speed and altitude. Using the SysinternalsTools ProcessMonitor and FileMonitor ( http://www.microsoft.com/technet/sysinternals/default.mspx ) it should be possible to figure out how FSX loads the individual tiles. You could use fake tiles (e.g. red for MIB/LOD level x, blue for level y and so on) to analyze what resolution FSX actually uses depending on the distance from the aircrafts position. Using the heading and possible GPS / flight plan info it might be possible to make educated guesses what tiles and resolutions FSX will load next.Instead of hooking the file access via Linux/Samba you could use the MS IFS Kit ( http://www.microsoft.com/whdc/DevTools/IFSKit/default.mspx ). One of the samples in that kit simply monitors all file access nd redirects access to the real file system (FAT/NTFS). Maybe the SysinternalsTools use the same trick to monitor file access.To avoid the need for a second PC, you could use VmWare or MS Virtual PC - there are free versions available for both - finally the second core would be less bored then ..I wouldnt mind if i have to tell your scenery loader before start, where i want to fly. I think preloading and caching instead of load-on-demand would simplify the whole architecture of your tool (no file access hooks needed). I think you could get rid of all speed problems during flight with that architecture, cause all required scenery (tiles, bgl, etc) could be generated before flight.What are your future plans for your tool ? Will it be a payware or freeware addon ?
  15. Hi Christian,a few links that might be useful ...- NASA Worldwind is similar to GoogleEarth, but its open source and uses public data: http://worldwind.arc.nasa.gov/- Google Maps SDK: http://www.google.com/apis/maps/- Microsoft Virtual Earth SDK: http://dev.live.com/virtualearth/sdk/I would try MS Virtual Earth first, cause maybe you can talk MS into giving you a special license for MS VE access if its used for an addon to MS FSX ...Maybe a different approach for loading the tiles would be faster:Instead of hooking into the load file calls of FSX, you could monitor the aircrafts position and heading using SimConnect to retrieve and convert the tiles even before FSX actually loads them.
  • Create New...