hervesors

Yes that should be easier (probably only 2-5 changes per AIRAC cycle)..now, I don't know if they are ready for that Indeed..but still around 700 runways that were renumbered since P3DV5 release. I think original P3DV5 database is not so recent

I'm unsure they can provide such a list since this would require a comparison between the simulator "starting status" and the current AIRAC status. Below is a list of runway designator changes I identified between the stock FSX/P3Dv1-4 files and the current 2203 AIRAC data (nearly 2,000 changes). Situation is a bit better for P3Dv5. Of course, this list will grow up in the future List includes airport ICAO identifier and affected runway (default stock runway number) but NOT new runway identifier https://www.aero.sors.fr/releasenotes/Renumbered_Runways.txt

Here is another technique that may have some advantages (No BGL decompilation/compilation, sim compatibility, associated taxi signs, ILSs, approaches and terminal waypoint renumbering). https://www.aero.sors.fr/documentation/Runway_Renumbering.pdf Hervé

As explained by Dan, many navaids that are part of the low/high airway system do not necessarily have a reception range that permits conventional radionavigation alone and are used as waypoints by the FMS without such restrictions Although you can change navaid range as explained above, a more realistic practice is to use designated operational coverage when published by AIP or standard ICAO service volume according to navaid type when DOC is not available Regarding navaids quoted above, you can refer to Brazil AIP https://www.aisweb.aer.mil.br/?i=publicacoes&p=aip ENR 4.1 ADA DOC is 80 NM SAT DOC is 128 NM BFR DOC is unpublished (could be set to 50 NM, H NDB) TBE DOC is 25 NM Hervé

Literally, astronomical is IMO a bit pessimistic. Depends on what the aim and profit could be (because it is payware anyway)..there's around 150,000 airports world wide but probably only 10,000- with IFR capabilities (whatever the precision/non precision approach is), that is those we are mainly interested with. For big companies with 20+ designers, and let's say a 1 year dead line, it could be possible adequately priorizing data changes (I didn't make the work load calculation though..). Let's dream

Installer has now been updated (v7.30) and made available. I needed some tests before but there's no drastic registry inscription changes between V2 and V3 (except of course string data). He is true. It is important to distinguish between current magnetic variation at aircraft position (as provided for us by the magdec.bgl table) and navaid calibrated station declination that may affect GPS/FMC/VOR approach courses, radial interceptions as reported by instruments and/or visual displays. First one is what it is at a given date on earth, so it is important to have it updated as far as possible, second one depends on when navaid has been calibrated (could be well before actual date) and is included in the navaid records. Some more details on this concept in FAQ 10 on my forum with some explanatory links http://aerosors.freeforums.net/thread/5/faq-answers-related-navaid-updates There have been at least 50+ runway id changes in the US on major airports and much more world wide, not talking about changed/added/deleted ILSs..For those not using dedicated sceneries correcting that (the preferred solution), you may give a try to regional ILS/Rwy updates I provide and that have been built so as to update everything on a regular basis (except of course general airport design), that is Rwy Ids (when they exist and their position didn't change), ILSs, PAPIs/VASIs. However, be aware some data may be "broken" mainly integrated GPS approaches and AI behavior. However, it could help improve realism especially for those who do use real current data and regret FS/P3D data are still 10 years old (but as n4gix said and explained, these stock data will probably never been updated)

It should as far as I don't think the magdec.bgl file structure has changed from what it was in FSX and/or is used differently (the same is true for P3D). Anyway you may give it a try. It will not hurt as far as you backup the original.

I think everything here is normal and you shouldn't worry about it. In FSX (default scenery) the true 01L runway heading in Arlanda is 010.4° and 2010 magnetic variation is E4.8° so the FSX runway magnetic heading is 005.6°. This value is ok (Jepp charts and Navigraph data indicate 005° and a MV of 5°E). ILS heading in AFX is a TRUE value (as runway heading), so do not change it to 005° - 10.4° is correct. Now there could be a problem with the scenery you use I do not have. Also do not expect to have a perfectly centered ILS when using the FS start positions. Usually the heading is correct, but there is often a small lateral offset from runway center line. Enough to have a 1-2 dots localizer deviation, considering the localizer antenna is very close. Finally it is likely that the latest Navigraph release has updated the ILS course by 1°. Jepp charts for ESSA have been updated in Feb-April 2011 and foot-note changes are: Var, Rwy bearings.Hope it will helpHervé

Hi all,We noticed a few years ago with Ron (how time flies..), that FS9 didn't take into account (as regard resulting lift and drag effects) more than the first 4 flap sections (e.g flaps.0 to flaps.3). Any additional sections (flaps.4 and higher) seem to have no measurable effect. My questions are:1) What is your knowledge about that in FSX?2) If such sections are still ignored, why did some designers (an example is the PMDG 747 model) include them?Thanks for the feedbackHerv

>FS9 and FSX have new non FSX SDK documented sections that>might achieve what you are looking for.This is interesting Jean Luc. Which ones?Herv

>Do the new FSX aircraft have (including the>heavies)different airframe numbers, compared to their>equivalents in older sims?I don't know but I don't think it will have any effect on gear drag.Also check for a 1540 record in your airfile. The Cdg value at 1540#10 (it's a double), if any, will override the 1101 value. No more idea ;-)Herv

This is unusual indeed since gear drag coef (for full extension) has not changed (1101:22h) in FSX as compared to previous versions of the sim and there is no additional aircraft.cfg parameter. Are you sure the gear was really extended in your tests since there is an inhibition speed limitation defined in the contact points section of the aircraft.cfg file (see SDK)? Typically max gear drag for such heavy aircrafts will range from 100 to 150 (0.05-0.075).Herv

I'm very sad to inform our community that Ron Freimuth has died a few weeks ago. Considering his contribution to the FS Flight dynamics knowledge, this is a cruel loss. I make the wish we will never forget what he taught us. I also hope AVSIM will announce this sad event in its news.God rest his soulHerv

OK JC..this is a rather difficult problem to apprehend at the sim level For further details, I will suggest you read over again the very comprehensive chapter 6 of the Naval test pilot school noteshttp://perso.orange.fr/hsors/docs/NTPS_notes.zipThe general relationship between turn rate and bank is:w = g*(Tan(theta) + Ny/(cos(theta))/TAS(w: turn rate ; theta: bank angle ; Ny:Side force load factor (=Fy/Weight); TAS: true air speed)As far as a constant bank turn is "coordinated" there is no side force and Ny=0 (see figure 6.6) ; the equation therefore simplifies to:w= g*Tan(theta)/TASIt is not easy at all to calculate in FS the side force load factor. Consequently, AFSD calculates1) the "theoretical" coordinated turn rate from bank and TAS using the above formula (bank and TAS are both easily available)2) the true turn rate (I incorrectly called "uncoordinated") , calculated from heading change and time using a precise timer (no more no less).Comparison of the 2 values gives a rough idea of the level of turn coordination.Indeed, FS aircrafts perform more or less well as regard turn coordination and unfortunately, in my experience, a centered ball doesn't always indicate a truly coordinated turn. Numerous air file variables (Cn_beta Yaw moment, Cn_da and Cn_p) and some tables probably have effects on coordination but I didn't investigate that in detail. May be Ron could comment more precisely on thatHerv

For those who wonder why there could be some problems editing or tuning this aircraft, just have a look in the aircraft.cfg (fuel) section to the "RightMain" fuel tank parameters. This is what I have:RightMain = -6.4, 16.8 0.0, 2040,0 //Longitudinal (feet), Lateral (feet), Vertical (feet), Usable(gallons), Unusable (gallons)Without a comma after the lateral offset (16.8), everything goes wrong. So check your file (I suspect it could be different according to the FSX version you have) and, if needed, add the appropriate missing comma :-(Herv