ps1flyer
-
Posts
17 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Posts posted by ps1flyer
-
-
Sehr genial. Vielen Dank für das Zeigen der Bilder.
Markus
p.s.
Die Google-Earth-Bilder vom T1 zeigen deutlich die Flieger auf dem Dach des Terminals...
-
I think that this is not possible in this case. The FMS data disks are very small extracts out of the world wide nav database. Also they are tailored down to the FMC Manufacturer (Honeywell, Colins, Smith) and the airline that uses the data.
Thanks for the comment. I am aware of the data used in FMS data disks. What I am trying to say is that the professional version might include appropriote software to read and convert FMS data disks to an AFS2012 format. There is existing software around, namely for the Aerosim FMS trainer, which does exactly that; it converts airline (and FMC) specific data for use in a training software.
However, to make this tool working and useful, the FMS simulation must be able to handle the variety of procedures using different coding styles and must also handle different data quality. There is some effort required to make this work but it can be done.
> There are also big differences in data quality of these three providers.
This is surely true. ;-)
Markus
-
Mathijs,
although many valid points have been mentioned, but please let me add my own comment which is based on plenty of experience with converting an ARINC-424 database to the Aerowinx PS1.3 file formats. Please excuse me when repeating some statements.
First, there is the real world which consists of electronic navaids (VORs, NDBs, ILSs, MLSs (!), DMEs (which may be separated from the VOR or ILS, localizer and glideslope positions ...) and then there is data inside the FMS box which is basically a model of the real world. If you aim for the general solution, you'll have both data sets seperated or a field within the database which distinguishes whether a VOR position of frequency is valid for the real world, the FMS data or both. Another aspect of separating real world data and FMS data is that things like reception range can be precisely modeled but the FMS only needs to know whether a VOR is High, Low or Terminal. Besides, Navdata within the FMS can be incorrect... ;-)
Furthermore, real world FMS computers usually contain only a partial coverage of the worlds. This is in particular true for short range aircraft e.g. the A320 (sure, it depends on the company) but also long rang aircraft like the 747-400 contain only a selected number of airports which have SIDs/STARs/IAPs (this is a company option and depends on the NavData supplier) while the airway coverage is global.
If you keep the station list separate or distinguishable from the FMS data, you are able to model this. But make sure that both data sets correlate, because this is one of the shortcomings of FS2004.
Second, with regard to SIDs, STARs and Instrument Approaches, I urgently recommend to implement the full ARINC-424 standard. To be more precise, try to handle all possible combinations of the leg types within the Path-and-Terminator (PT) concept which includes easy stuff like TF (track to a fix) waypoints, but also conditional waypoints, vectors, DME arcs, that paired with all transitions for SID/STAR/IAP. (Note: the PSS databases are basically a dump of an ARINC-424 database but the processing of PSS is not really good for complex procedures)
If you can achieve this, you should be pretty much independent from a specific supplier of NavData. Also, you should in theory be able to e.g. read real-world FMS data disks so can you specifically use company specific data for the pro version of AFS2012.
Best regards and all the best for the project,
MArkus
-
Und die Behauptung von Markus für die ABSAM Daten sei die Position N47* 17.3167' E11* 30.1000' richtig, kann ich weder in den Anflugkarten von 2003, die man auf VACC-Austria finded noch auf der 2007er Variante die dem Produkt beiliegt, eine Bestätigung finden. Da findet sich genau die Position, die im AFCAD angeblich inkorrekt sein soll.
Hm.... Jeppesen teilt mit der aktuell gültigen Karte 10-3A allerdings meine Ansicht über die Position von Absam:
Gruß,
Markus
-
Hallo Johannes,
zunächst einmal vielen herzlichen Dank für Deine fabelhafte Innsbruck-Szenerie. Sie gehört zu den besten Bereicherungen für meinen Flugsimulator seit langem!
Zu meinem Anliegen:
ich bin gestern Abend den LOC DME West von Kühtai kommend geflogen. Während des Abstiegs ins Tal habe ich mich zunächst gewundert, daß ich deutlich südlicher als erwartet den Flughafen passiert habe. Weiterhin ist mir aufgefallen, daß trotz sauberer Mittellage auf dem Localizer das Absam NDB nicht direkt überflogen wurde. Genau das sollte eigentlich bei 4.4 DME OEJ passieren.
Ich habe mir daraufhin das AFCAD AF2_LOWI_by_giannisworld.bgl genauer betrachtet und bin zum Schluß gekommen, daß drei Funkfeuer zu ungenau plaziert sind. Für INN ergibt sich z.B. eine Ablage von ca. 0.3' = 555 Meter.
INN (Innsbruck NDB)
korrekt: N47* 13.8000' E11* 24.1167'
AFCAD: N47* 13.4800' E11* 24.0700'
AB (Absam NDB)
korrekt: N47* 17.3167' E11* 30.1000'
AFCAD: N47* 17.1900' E11* 30.0600'
OEJ Localizer:
korrekt: N47* 18.8667' E11* 36.1333'
AFCAD: N47* 18.5229' E11* 36.0846'
Die als "korrekt" markierten Daten stammen aus einer mir zugänglichen Real-World-Datenbank, sind abe auch mit Standard-FS9 und Jeppesen-Karten abgeglichen. Im Detail findet sich dort für OEJ: N47°18'52' E011°36'08'', INN: N47°13'48'' E011°24'07'', AB: N47°17'19', E011°30'06''.
Ich vermute, daß folgendes passiert ist: (am Beispiel INN): es kam zu einer Verwechslung der Bogensekunden als dezimaler Anteil der Minuten (.48) mit dem
korrekten "echten" Wert der Bogensekunden (48''). So wurde aus N47° 13' 48' == 47° 13.8 der fehlerhafter Wert 47° 13.48.
Eine Wechselwirkung mit anderen LOWI-Addons kann ich definitiv ausschließen. Diese sind deaktiviert. Eine Wechselwirkung mit anderen FS9-Dateien habe ich noch nicht ausgeschlossen, aber ich vermute, daß die Ursache tatsächlich in der AF2_LOWI_by_giannisworld.bgl liegt.
Es wäre nett, wenn Du Dir das mal ansehen könntest.
Merci vielmals,
Markus
-
Huch... danke für die Aufklärung Sasa. Da dachte ich doch tatsächlich, dass der FSX da aufgrund des geänderten Modells da anders aufgestellt wäre.
Ciao,
Rainer.
Hm... da muß ich jetzt aber doch nachhaken. Als Polarflug-Fan (seit dieser Lektüre -> Lesetipp: "Notes on Antarctic Aviation", http://www.crrel.usace.army.mil/library/cr...rts/CR93_14.pdf ) habe ich das vor längerer Zeit ausprobiert und konnte den Pol in FSX ohne Problem erreichen. Die Koordinatenanzeige im Slew-Mode steht dann auf z.B. N90°. Ich hätte da auch noch einen Screenshot dazu.
Ich wage allerdings zu behaupten, ob man dann auch (sinnvoll) Szenerie dort plazieren kann.
Aber als potenzieller Käufer (und das wäre mein erstes FSX-Produkt...) habe ich noch eine andere Frage. Welchen Sinn macht es, großflächig Luft- bzw. Satellitenbilder einzusetzen? Mein Verständnis von Polarfliegerei ist, daß es die Hauptschwierigkeit beim Mangel an Textur liegt, daß man also nur über weiße Flächen fliegt und dort keine Konturen ausmachen kann. Gerade dann sehe ich eigentlich keine Notwendigkeit für Luftbilder. Für Küstenregionen trifft das natürlich nur eingeschränkt zu...
Danke und Gruß,
Markus
-
> Bedankt und gekauft!
Auch von mir vielen Dank. Die obige Aussage kann ich nur wiederholen: ... und gekauft.
Gruß,
Markus
-
Leider hängt es nicht mit der Kreditkarte zusammen. Die Summe von €16,17 ergibt sich bei allen 3 Möglichlichkeiten, die Zahlung abzuwickeln (Paypal, Kreditkarte und Banküberweisung).l
Gruß,
Markus
-
Hallo!
Ich habe gleich eine weiter Frage in Richtung Fa. Aerosoft.
Gemäß Produktinformation liegt der Preis der Updateversion bei €14,95. Wenn ich allerdings über die Webseite von Aerosoft die Downloadversion des MAF X auswähle und in den Aerosoft-Shop-Warenkorb lege, erhalte ich die Möglichkeit die Updateversion zum Preis von €16,17 zu bestellen. Darin sind €2,58 MWSt enthalten.
Die "Bestätigungsseite" im Aerosoft-Shop weist dabei klar aus, daß die Überprufung meiner Box-Seriennummer des MAF 2004 erfolgreich war: "Mega Airport Frankfurt: Produkt Überprüfung erfolgreich! Sie brauchen nur den Update Preis bezahlen!".
Meine Frage: wieso werden im Aerosoft-Shop €16,17 ausgewiesen, auf der Aerosoft-Seite nur €14,95?
Vielen Dank und Gruß,
Markus Vitzethum
-
Hallo,
das gleiche Probleme habe ich seit heute auch. Bei jedem Neuaufruf einer Forumsseite beschwert sich die (neue) Version 8 von Avira AntiVir (Free Personal Edition) über den den angeblichen (?) Trojaner JS.RedirectA. Ich denke, das Problem tritt erst seit heute nachdem automatischen Einspielen der täglichen Updates auf.
In den anderen Webforen, die ich täglich besuche ist mir das Problem noch nicht aufgefallen (weiß aber auch nicht, ob irgendwo anders die gleich Boardsoftware verwendet wird).
Markus
-
I had a rather similar performance issue with EDDK 2007, so maybe it helps if I describe my experiences.
Since it seems to be performance related, I'll first describe my system and software configuration:
P4 3.0 GHz
1 GB RAM
ATI X850 Graphics Board with 256MB RAM.
FS2004 with (relevant for the EDDK area)
- Flight1 Ultimate Terrain Europe
- LOD9 Freeware SRTM mesh
- German Landmarks X (for FS9)
- EDDK 2007.
- Very dense AI Traffic, mostly manually installed (with TTools)
In this configuration I got the following nasty performance problem. Whenever switching to another task away from FS9 running in full screen mode e.g. to Active Sky, to Windows Explorer or to the Windows Desktop and then switching BACK, I only got the wireframe models display by FS9. ALL (!) textures had been lost, e.g. they were not buffered as usual. It took then about 30sec up to 2 minutes for the textures to reload. First the textures of the ground polygons reappeared, then the building textures, the AI traffic textures, then clouds ... you get the idea. It really took a long, noticeable time.
I am not aware of this particular problem at any other airport e.g. MAP EDDF, yet.
I partly found a solution to this issue, that is, by de-activating German Landmarks, at least the EDDK area (Nordrhein-Westfalen). Since German Landmark's VFR objects are disabled arond EDDK, the performance issue described above is much better. After task switching, FS9 seems to keep the textures in memory and does not reload ALL of them. However, it still see effect occasionally (e.g. after calling a FsPassengers menu), but with much shorter reload times (< 10 seconds).
Up to now, this performance problem seems to be unique to EDDK 2007 on my system. I don't see it with other airports with similar design so my conclusion was that it is indeed related to EDDK. Since disabling German Landmarks really improved the situation, I conclude that I reach a critical performance load e.g. on texture memory here.
Hope this helps,
Markus
EDDS - Stuttgart 2010
in Aerosoft Szenerie Allgemeines
Posted
Das finde ich auch: tolle Screenshots. Die Vorfreude ist mindestens genauso groß wie bei München. Mir gefällt auch, daß Bernhausen mit dem Real-Supermarkt, Tower und sogar Wohnhäusern dargestellt wird... (oder sind die Wohnhäuser Autgen?)
Danke fürs Zeigen,
Markus