WCM Forum - Einzelnen Beitrag anzeigen

JOBIA · 01.08.2003, 18:07

Ich hatte damals bei meiner Doku zum Flackerproblem der Texturen so einen Satz geschrieben in dem ich den Verdacht geäußert habe, dass bei MS ein Entwicklerteam nicht weis was das andere macht bzw. mit welchen Höherdaten dieses Team arbeitet. Ich habe das Gefühl dieses scheint generell ein Problem von MS zu sein. Denn wir hatten auch vor ein paar Monaten als der FS2004 noch nicht in Sicht war hier schon mal eine Diskussion was an ADDONS kompatibel sein wird.
Dort hatte ich meine Meinung Kund getan. Darauf hat mich Hans etwas eingebremst und auf einen Text den offensichtlich die Presseabteilung auf einer MS Seite diesbezüglich veröffentlicht hat verwiesen. Da hat sich alles sehr positiv angehört. Ich wiederrum habe dann auf Auszüge des FS2002 SDK verwiesen wo die Aussagen bezüglich Kompatibilität nicht so rosig aussahen. Im wesentlichen wurde erwähnt, dass Programmiertechniken des FS2002 zum FS2004 kompatibel sind. Alles was davor war ev. nicht. Jetzt nachdem ich mir den hier zitierten Satz von Burkhard Renk und diesen kurzen Textbeitrag auf Simflight.de zu AFCAD noch mal durchgelesen habe, beschleicht mich das Gefühl das MS zu den umkippern gehören. Heute so morgen so. Denn der Traffic in dieser Form wurde beim FS2002 neu eingeführt. Diese Variante hätte nach den damaligen Aussagen auch im FS2004 laufen müssen. Auch die neuen Taxylines die im FS2002 eingeführt worden und bis heute von den wenigsten Teams genutzt wurden, da auch diese Funktionen sehr spät in Editoren wie den SCC eingebaut wurden (SDK fehlte) ist beim FS2004 schon nicht mehr aktuell. Das ist eindeutig wiedersprüchlich was MS zum Thema Kompatibilität bisher geschrieben hat. Um auf den Verkehr zurückzukommen. Beim FS2002 gab es den optisch programmierten Airport mit seinem optischen Rollwegelayout. Dieser hatte nichts mit bewegten Verkehr zu tun. Hierfür gab es eigene BGL Dateien die die Rollwegeinformation, Gates usw. enthielten. Diese Dateien tragen im Namen der BGL fast immer die Buchstaben afd . (Diese Datei habe ich z.B bei GAP4 als eigene Scenery laufen, kann sein das sie bei original Installation im Ordner der eigentlichen Scenery integriert ist) Man müsste also schauen wenn man eine Scenery in den FS2004 kopiert, dass diese afd Datei dort auch vorhanden ist. Nur das wird einem vermutlich nichts nutzen. Diese afd Dateien tragen praktisch die Information welche Wege das Flugzeug nutzen soll. Ergo hat man beim FS2002 keine aktuellen afd Dateien für einen GAP Airport der ein anderes Rollwegelayout als der Defaultairport hat fahren sie bei dem GAP Airport entsrechend der original FS2002 afd Datei über den Rasen. Nun wie sieht es offensichtlich im FS2004 aus. Hier findet sich keine einzige Datei die Buchstaben in Form von afd im Namen haben. Es sieht in der Tat so aus als wenn die neuen Taxilines des FS2002 im FS2004 schon wieder ein alter Hut sind und nicht mehr zur Anwendung kommen. Beim FS2004 gibt es schon wieder neue Taxilines. Diese sind nicht nur optisch schöner, sie enthalten jetzt vermutlich auch die eigentlichen Rollweginformationen. Es werden keine eigenen afd Dateien mehr benötigt. Sollte sich der Verkehr des FS2004 nicht durch eine alte afd Datei beeinflussen oder überschreiben lassen bedeutet dieses, dass für sämtliche Airport ADDONS Taxiways, Aprons, Taxilines usw. ohne Ausnahme komplett neu programmiert werden müssen. Dann gute Nacht das kann dauern denn von einem SDK dafür, welches diese Funktionen erklärt habe ich noch nichts gehört. Zumal auch ein passender Editor neu gestrickt werden muß, insofern er nicht selbst schon im SDK enthalten ist.

Dieses bedeutet für uns man bekommt die Airports selbst ohne Patches im FS2004 zum laufen. Auf richtig positionierten Verkehr muß man wie auch beim FS2002 schon vermutlich in der ersten Zeit verzichten.

Der Vorteil beim neuen ist man muß nicht beides extra programmieren. Die Programmierung der optischen Elemente reicht vermutlich aus. Ein weiterer Vorteil könnte sein das wirklich alle Wege genutzt werden.

Ein großer Nachteil könnte sein, dass bisherige Editoren wie SCC ev. überhaupt nicht auf diese Techniken erweiterbar sind. Vielleicht läuft jetzt alles über GMAX. Warten wir ab was da kommt, vielleicht wissen Teams die von MS offiziell mit Betas versorgt wurden bereits mehr.

01.08.2003, 18:07	#18
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	Ich hatte damals bei meiner Doku zum Flackerproblem der Texturen so einen Satz geschrieben in dem ich den Verdacht geäußert habe, dass bei MS ein Entwicklerteam nicht weis was das andere macht bzw. mit welchen Höherdaten dieses Team arbeitet. Ich habe das Gefühl dieses scheint generell ein Problem von MS zu sein. Denn wir hatten auch vor ein paar Monaten als der FS2004 noch nicht in Sicht war hier schon mal eine Diskussion was an ADDONS kompatibel sein wird. Dort hatte ich meine Meinung Kund getan. Darauf hat mich Hans etwas eingebremst und auf einen Text den offensichtlich die Presseabteilung auf einer MS Seite diesbezüglich veröffentlicht hat verwiesen. Da hat sich alles sehr positiv angehört. Ich wiederrum habe dann auf Auszüge des FS2002 SDK verwiesen wo die Aussagen bezüglich Kompatibilität nicht so rosig aussahen. Im wesentlichen wurde erwähnt, dass Programmiertechniken des FS2002 zum FS2004 kompatibel sind. Alles was davor war ev. nicht. Jetzt nachdem ich mir den hier zitierten Satz von Burkhard Renk und diesen kurzen Textbeitrag auf Simflight.de zu AFCAD noch mal durchgelesen habe, beschleicht mich das Gefühl das MS zu den umkippern gehören. Heute so morgen so. Denn der Traffic in dieser Form wurde beim FS2002 neu eingeführt. Diese Variante hätte nach den damaligen Aussagen auch im FS2004 laufen müssen. Auch die neuen Taxylines die im FS2002 eingeführt worden und bis heute von den wenigsten Teams genutzt wurden, da auch diese Funktionen sehr spät in Editoren wie den SCC eingebaut wurden (SDK fehlte) ist beim FS2004 schon nicht mehr aktuell. Das ist eindeutig wiedersprüchlich was MS zum Thema Kompatibilität bisher geschrieben hat. Um auf den Verkehr zurückzukommen. Beim FS2002 gab es den optisch programmierten Airport mit seinem optischen Rollwegelayout. Dieser hatte nichts mit bewegten Verkehr zu tun. Hierfür gab es eigene BGL Dateien die die Rollwegeinformation, Gates usw. enthielten. Diese Dateien tragen im Namen der BGL fast immer die Buchstaben afd . (Diese Datei habe ich z.B bei GAP4 als eigene Scenery laufen, kann sein das sie bei original Installation im Ordner der eigentlichen Scenery integriert ist) Man müsste also schauen wenn man eine Scenery in den FS2004 kopiert, dass diese afd Datei dort auch vorhanden ist. Nur das wird einem vermutlich nichts nutzen. Diese afd Dateien tragen praktisch die Information welche Wege das Flugzeug nutzen soll. Ergo hat man beim FS2002 keine aktuellen afd Dateien für einen GAP Airport der ein anderes Rollwegelayout als der Defaultairport hat fahren sie bei dem GAP Airport entsrechend der original FS2002 afd Datei über den Rasen. Nun wie sieht es offensichtlich im FS2004 aus. Hier findet sich keine einzige Datei die Buchstaben in Form von afd im Namen haben. Es sieht in der Tat so aus als wenn die neuen Taxilines des FS2002 im FS2004 schon wieder ein alter Hut sind und nicht mehr zur Anwendung kommen. Beim FS2004 gibt es schon wieder neue Taxilines. Diese sind nicht nur optisch schöner, sie enthalten jetzt vermutlich auch die eigentlichen Rollweginformationen. Es werden keine eigenen afd Dateien mehr benötigt. Sollte sich der Verkehr des FS2004 nicht durch eine alte afd Datei beeinflussen oder überschreiben lassen bedeutet dieses, dass für sämtliche Airport ADDONS Taxiways, Aprons, Taxilines usw. ohne Ausnahme komplett neu programmiert werden müssen. Dann gute Nacht das kann dauern denn von einem SDK dafür, welches diese Funktionen erklärt habe ich noch nichts gehört. Zumal auch ein passender Editor neu gestrickt werden muß, insofern er nicht selbst schon im SDK enthalten ist. Dieses bedeutet für uns man bekommt die Airports selbst ohne Patches im FS2004 zum laufen. Auf richtig positionierten Verkehr muß man wie auch beim FS2002 schon vermutlich in der ersten Zeit verzichten. Der Vorteil beim neuen ist man muß nicht beides extra programmieren. Die Programmierung der optischen Elemente reicht vermutlich aus. Ein weiterer Vorteil könnte sein das wirklich alle Wege genutzt werden. Ein großer Nachteil könnte sein, dass bisherige Editoren wie SCC ev. überhaupt nicht auf diese Techniken erweiterbar sind. Vielleicht läuft jetzt alles über GMAX. Warten wir ab was da kommt, vielleicht wissen Teams die von MS offiziell mit Betas versorgt wurden bereits mehr.