Warum werden keine im FSX oder FS9 erstelle Proceduren erkannt

[AFTRS 2]

Guten Tag,

ich bin seit vielen Jahren Besitzer des FSCommander, mit entsprechenden Updates. Eigentlich eine schöne Software.

Wenn da nicht ein kleiner Wermutstropfen wäre:

Alle Proceduren und Waypoints, die zwar im MS-Simulator, egal, ob FS9, oder FSX erscheinen werden leider auch nicht in der neuen 9er Version dargestellt. Dargestellt werden nur die gegen monetären Aufwand zu erwebenden SID/STARS.

Eine Begründung, wie seit Jahren gegeben, dass dies die offiziellen seien, stimmt zwar, aber leider nur oberflächlich betrachtet.

Jeder, der mühsam für eine Flugplatz die geltenden Proceduren gemäss Chart implementiert, welche nicht Bestandteil der sogenannt korrekten Distribution der kostenpflichtigen SID/STAR für den FS(9/X) jemals sein können, kann die Software FS Commander nicht gebrauchen.

Ist völlig nutzlose software für die Zielgruppe.

Mich habt Ihr als Kunden und auch als Software-Entwickler verloren.

Schade, war eine schöne Software. Da hat wohl die Ignoranz gesiegt.

Christian

AFTRS.

AFrican Transport Systems

[OPabst 2091]

Hallo Christian,

ich kenne zwar FSC nicht im Detail, aber das Produktfeature

•SIDs/STARs and customizable route segments

lässt darauf schließen, dass es durchaus möglich ist, spezielle, nicht im offizellen Updates verfügbare zusätzlich Anpassungen in der FSC Datenbank vorzunehmen.

Auch die Tatsache, dass die NAVDATA Imports ein gängiges verwenden, lässt den Schluss zu, dass ein Import über ein solches (sicher auch dokumentiertes) Format möglich ist.

Und für dich als Software-Entwickler sollte es kein unüberwindbares Problem darstellen, die von Dir ohnehin erstellten Proceduren in dieses Format zu überführen und somit als Import zur Verfügung zu stellen..

Und ich bin sicher, die Entwickler von FSC stehen Dir bei Problemen dabei in Ihrem Supportforum gerne unterstützend zur Seite.

[Sascha Felix 5]

Hallo Christian,

folgt man dem Prinzip "wenn ich nicht kriege, was ich will, dann sind die Entwickler Ignoranten", hast Du sicherlich Recht. Aber vielleicht sollte man mit solchen Aussagen etwas vorsichtiger sein, vor allem dann, wenn man sich offensichtlich in der Materie nicht sonderlich gut auskennt.

Zur Sache: bei der Entwicklung eines Programms wie dem unsrigen muss man sich grundsätzlich entscheiden, ob man die Daten aus dem FS ausliest, oder ob man sich an "real-world" Daten orientiert. Es herrscht nun sowohl unter Entwicklern als auch unter Usern seit vielen Jahren Konsens darüber, dass man - soweit dies eben möglich ist - auf "real-world" Daten stützt, die aktualisiert werden können und somit eine leidlich realistische Flugplanung ermöglichen. Das machen nicht nur wir so, sondern ALLE mir bekannten Programme, vor allem die Flugzeug-"Hersteller" wie PMDG, Level-D, etc sowie IVAO, VATSIM, und auch vergleichbare Flugplanungprogramme. Die Daten des FSX sind nunmehr mehr als 4 Jahre alt, die des FS 2004 7Jahre; sie sind also hoffnungslos veraltet.

Würden wir nun als einzige die FS Daten nehmen, wäre unser Programm inkompatibel mit allen anderen Programmen; d.h. man könnte unsere Flugpläne weder für IVAO/VATSIM verwenden, noch für die gängigen Flugzeuge à la PMDG. Mit anderen Worten, unser Programm wäre nur mit sich selbst kompatibel und würde sich komplett von der restlichen Flusi-Szene abkoppeln. Dass das nicht sonderlich sinnvoll wäre, versteht sich von selbst.

Gruss

Sascha

[AFTRS 2]

Hallo Christian,

folgt man dem Prinzip "wenn ich nicht kriege, was ich will, dann sind die Entwickler Ignoranten", hast Du sicherlich Recht. Aber vielleicht sollte man mit solchen Aussagen etwas vorsichtiger sein, vor allem dann, wenn man sich offensichtlich in der Materie nicht sonderlich gut auskennt.

Zur Sache: bei der Entwicklung eines Programms wie dem unsrigen muss man sich grundsätzlich entscheiden, ob man die Daten aus dem FS ausliest, oder ob man sich an "real-world" Daten orientiert. Es herrscht nun sowohl unter Entwicklern als auch unter Usern seit vielen Jahren Konsens darüber, dass man - soweit dies eben möglich ist - auf "real-world" Daten stützt, die aktualisiert werden können und somit eine leidlich realistische Flugplanung ermöglichen. Das machen nicht nur wir so, sondern ALLE mir bekannten Programme, vor allem die Flugzeug-"Hersteller" wie PMDG, Level-D, etc sowie IVAO, VATSIM, und auch vergleichbare Flugplanungprogramme. Die Daten des FSX sind nunmehr mehr als 4 Jahre alt, die des FS 2004 7Jahre; sie sind also hoffnungslos veraltet.

Würden wir nun als einzige die FS Daten nehmen, wäre unser Programm inkompatibel mit allen anderen Programmen; d.h. man könnte unsere Flugpläne weder für IVAO/VATSIM verwenden, noch für die gängigen Flugzeuge à la PMDG. Mit anderen Worten, unser Programm wäre nur mit sich selbst kompatibel und würde sich komplett von der restlichen Flusi-Szene abkoppeln. Dass das nicht sonderlich sinnvoll wäre, versteht sich von selbst.

Gruss

Sascha

Hallo Sascha,

mit solchen Aussagen über das Know How wäre ich vorsichtig.

Zum eigentlichen Thema:

Worum es mir insbesonders geht:

Sehr viele Entwickler entwickeln auch den "AFCAD" Teil ihrer Flugplätze, sprich die aus den "Charts" übertragenen Daten zum Flugplatz. Macht sehr viel Mühe mit allen Transitions, Höhendaten, etc. Klar kann man dieselbe Procedure nochmals im FSC definieren, aber nur unter/mit zusätzlicher Mühe.

Bin damals von der anderen Warte her auf das Produkt umgestiegen: Hatte die Charts und habe zu den nicht berücksichtigten Flughäfen die User-Prozeduren im FSC geschrieben.

Heute entwickle ich vor allem für den afrikanischen Kontinent Flugplätze, historisch angepasste "Signaleinrichtungen", Flugrouten, etc. Sowohl für den heutigen Zeitraum, als auch für die längst verschwundene Aera der 50-60er Jahre.

Bei letzter wird jeder sagen, was interessiert Dich dann SID/STAR. Richtig, eigentlich nur perifer, sollte man meinen. Kommen aber mühsam erstellte VOR oder Waypoints ins Spiel, wird es etwas komplizierter.

Zu berücksichtigen sind dann auf einmal Punkte, die, damit was auf dem Airport "los ist", sich primär eigentlich nur auf AI-Verkehr beziehen.

Nicht vergessen möchte ich aber all meine Kunden nicht, die durchaus mit dem GPS fliegen; native Navigation war damals etwas schwieriger, insbesonders, wenn die "Funkeinrichtungen" kein Resultat mehr im Empfänger bringen (Reichweiten/Kreiseldrift-Problem).

Lange Rede kurzer Sinn:

Mit dem Ansatz des Produktes schliesst Ihr doch alle diejenigen Flugplätze aus, für die, von mir oder Kollegen, unter der Berücksichtigung von realen Charts Lösungen erstellt wurden. Vielleicht nicht immer zu den "Main-Stream" Flughäfen, aber zum Rest der Welt.

Da das Produkt an sich in meinen Augen immer noch sehr gut ist, würde ich mich freuen, wenn man die Wahl hätte, die "Add ON Scenery" schlicht und einfach einzulesen.

Christian

.

[horst18519 231]

Mir ist kein einziges AddOn bekannt (zumindest in unserem Sortiment), welches spezielle Approaches oder ähnliches in der AFD-Datei programmiert hat. In 99% der Fälle verändern Entwickler darin lediglich das Layout des Platzes, Frequenzen, Nav-Einrichtungen,...

Insofern macht FSC genau das richtige: es liest diese Dinge ein und nutzt für alles andere die eigenen Daten, welche realistischer sind als das FSX/FS9-Material.

[AFTRS 2]

Nö macht er nicht.

Ich schicke Dir gerne die Flugplätze. Selbst mit Unterscheidung des Flugplatzes in den "nichtsichtbaren Teil" letzendlich AFCAD und den sichtbaren Teil in zwei unterschiedliche xxx.bgl Dateien liest er es nicht ein.

Kaufte mein Kunde nun meinen Flugplatz, kann er FSC nicht benutzen, wenn er Flugpläne oder GPS via FSC verwenden will.

Sorry, das ist nicht wegzudiskutierender Fakt.

Im FS-GPS und im FS-Flugplaner taucht das alles auf, selbst bei nur einem xxx.BGL File.

Die unterschiedlichen Leg-Definitionen von IF-CF-TF-xx-xx-xxxxxx-xxxxx funktionieren. AI funktioniert. So what?

[Sascha Felix 5]

Hallo Christian (und die anderen)

Ehrlich gesagt, ich weiss nicht, was ich noch sagen soll, ohne mich zu wiederholen.

Zunächst mal zu den Fakten (die auch im Manual stehen). Der FSC bzw. Datenbank Manager holt sich alle distanz-sensiblen Daten direkt aus dem FS (2004 oder X). Dazu gehören Flugplätze einschliesslich Runways, Taxiways, Aprons, Parkpositionen, und ILS'e. Die werden natürlich auch aus den Add-on Szenerien ausgelesen, wenn jemand solche hat. Alle Wegpunkte, d.h. VORs, NDBs, intersections und GPS Fixe sowie SIDs, STARs, transitions und airways sind "real-world" Daten, die sich über Navigraph monatlich updaten lassen. Die Lufträume stammen noch aus DAFIF-Zeiten, weil derzeit Navigraph entsprechende Daten noch nicht zu Verfügung steht. Einen Sonderfall stellt die magnetische Variation dar, aber das lasse ich jetzt mal weg.

Soweit die Faktenlage. Die Zweiteilung in FS-basierte und "real-world"-basierte Daten hängt damit zusammen, dass es natürlich einen Riesenunterschied macht, ob ein Runway, Taxiway, ILS 500m weiter links oder rechts steht, während es weitgehend egal für die Navigation ist, ob etwa ein VOR in der realen Welt ein bisschen anders steht als im FS. Insofern können wir bei den Flugplätzen nicht die "real-world" Daten verwenden, da der FS eben in vielen, wenn nicht den meisten Fällen nicht der realen Welt entspricht.

Die Entscheidung - und jetzt wiederhole ich mich - "real-world" Daten zu verwenden, entspricht einerseits dem Konsens der Szene und garantiert andererseits Kompatibilität zu anderen Programmen, insbesondere Flugzeugen.

Nun zu den Prozeduren. Obwohl ich das schon dutzendmal im Forum geschrieben habe, hier nochmal Sids, STARs, transitions (und natürlich auch airways) sind offizielle von den Luftfahrtbehörden publizierte Routen. Diese kann man verwenden oder auch auch nicht, ansonsten hat der User seine Finger davon zu lassen, weil er eben keine Luftfahrtbehörde ist. Aus diesem Grunde kann man etwa ein SID in unserem Programm auch nur als gesamtes löschen, aber niemals einen einzelnen Wegpunkt, Denn, würde man das tun, wäre es kein SID mehr. Wenn man up-to-date sein will, kann man monatliche Updates bei Navigraph bekommen, wobei ich davon ausgehe, dass die Navigraph Daten - etwa im Gegensatz zum früheren DAFIF - vollständig und korrekt sind, unter dem Proviso "nobody is perfect ". (Selbst bei DAFIF - und das ist ein Militärdienst - gab es hin und wieder kleinere Fehler).

Analoges gilt natürlich auch für die Wegpunkte. Man kann nicht etwa sein eigenes VOR definieren. Entweder es gibt das VOR, dann ist es in den Navigraph Daten enthalten oder es gibt es nicht, dann ist das eben so.

Da die meisten Flugplätze, insbesondere die kleinen, ohnehin keine SIDs bzw. STARs und transitions haben, haben wir die sog. Route Segments als allgemeine Spielwiese eingefügt. Hier kann sich der User nach Herzenslust austoben und definieren, was ihm gerade in den Sinn kommt - ob vernünftig oder nicht. Er muss dann selbst mit seinen Ergebnissen leben.

Insofern sehe ich - wie es in der Politik so schön heisst - keinerlei Handlungsbedarf. Die Flugplatzdaten (s.o.) werden aus dem FS ausgelesen, die übrigen Daten stehen über Navigraph als aktuelle Updates zur Verfügung. Und bei letzteren gibt es nichts, zu editieren, hinzuzufügen oder zu löschen.

Gruss

Sascha

[AFTRS 2]

Moin,

dutzendmal wiederholt macht noch keine Lösung des Problems.

Klar, unumstritten: Der Rückzug auf die allgemein gültige Definition der "weltumspannenden" Daten gelingt immer in der Art und Weise der Argumentation.

Da gibt es keinen Zweifel daran.

In Bezug auf den FS-Simulator frag ich mich, all diejenigen User in das Kalkül gezogen, die nicht online fliegen, sondern durchaus nur für sich: haben die keinerlei Existenzrecht in in der Freiheit, wie sie Ihre Software einsetzen möchten?

Wenn es nur eine allgemeingültige Online-Fliegerei unterstützende Software sein soll, würde ich darum bitttn, das dann entsprechend anzumerken.

Dann gibt es mit Sicherheit keine "Missverständnisse" seitens der Kunden mehr.

Sind denn all die User nicht interesant, welche auch Eure Produkte nutzen, die nicht im FSC erscheinen. Siehe auch Eurowings, vertreibt Ihr doch auch.

Insgesamt finde ich es nicht als adequart, oder in englischen Gedankengut "fair", so, wie oben zu argumentieren.

Technich ist und bleibt es kein Problem, die definierten Navigationspunkte einuzulesen. Wenn man natürlich, aus welchem Grunde auch immer,. nicht WILL, ist das eine ganz andeer Sache.

Pseudo Logik erscheint mir hier fehl am Platze,

[Sascha Felix 5]

Hallo Christian,

um es nochmal zu sagen: der FS Commander wird auch in Zukunft auf "real-world" Daten und nicht auf FS Daten beruhen, wie in meinem letzten Post beschrieben. Das war so, das ist so und das wird in Zukunft so sein.

Damit ist dieser Thread für mich beendet.

Sascha

[horst18519 231]

Christian, ich kann verstehen, dass Du nicht glücklich bist wenn ein AddOn nicht 100% mit Deinem selbst programmierten Flugplatz kompatibel ist. Aber Du solltest nicht den Fehler machen Deine Methode als die allgemein gültige hinzustellen. 99% der AddOn-Szenerien kommen eben nicht mit eigenen Transitions, Approach-Legs,... sondern arbeiten mit den Möglichkeiten, die der FSX standardmäßig bietet. Diese 99% aller AddOns harmonieren perfekt mit dem FSC.

Damit ist alles zu diesem Thema gesagt.