Anpassungsmöglichkeiten für ADDONS an den FS2004

[JOBIA]

Ich habe jetzt noch mal einen neuen Thread aufgemacht, da in folgendem Thread http://www.wcm.at/forum/showthread.p...hreadid=110234 die ATP Scenery noch mit ins Spiel kam.

Ich hatte ja wie gesagt die ATP Scenery für mich persönlich schon mal grob an den FS2004 angepasst. Da ich über E-Mail und auch jetzt in dem oben genannten Thread darauf angesprochen wurde ob ich da schon weiter dran gearbeitet habe und speziell bei den Mails, ob ich da auch ev. etwas fertiges weiter geben kann, sage ich aus aktuellen Gründe auch bei den Sachen die vermutlich lizenzrechtlich möglich wären lieber generell bei allen nein. Ich erzähle aus meiner Sicht nur wo ich die Knackepunkte im FS2004 hinsichtlich Scenerydesign sehe bzw. was für Lösungswege ich gehen würde um diese Probleme zu lösen. Wen dieses nicht interessiert bitte den Thread am besten gleich wieder schliessen. Ich werde mich bemühen kurz und einfach zu fassen, da ich wie gesagt nichts mehr groß erklären wollte. Es wird aber dennoch ein längerer Text werden da ich hiermit meinen momentanen Wissenstand zu den Problemem komplett in vereinfachter Form weitergeben werde. Denn damit ist dann eigentlich alles gesagt was es zu dem Thema von mir zu sagen gibt. Alles weitere geht dann schon wieder sehr in die eigentlichen Codes.

Der Hauptgrund warum Bodenpolygone jetzt im FS2004 flackern ist unter 7) zu finden.

Was ich nicht ansprechen werde ist das Thema Landclass/Waterclass denn hier gibt es aus meiner Sicht momentan keine sinnvolle Möglichkeit die fehlerhafte Darstellung von FS2002 Landclassfiles im FS2004 direkt zu korrigieren. Momentan denke ich bliebe bei bestehenden FS2002 Files nur die Möglichkeit der Neupositionierung von Landclass bzw. bei den uns zur Verfügung stehenden Free oder Paywareeditoren das diese im Vorfeld eine grafisch im Editor programmierte Landclasscenery unmittelbar vor der Kompilierung bewusst künstlich verfälschen um diese dann möglichst genau für den FS2004 anzupassen.

Einiges bei den folgenden Texten wird verständlich sein anderes wieder nicht. Ein paar Leute denke ich werden aber Ihren Nutzen daraus ziehen können.

Zunächst zum Thema Anpassung von problembehafteten Airport ADDONS an den FS2004.

1) AI Traffic:
Was mir und vermutlich auch anderen bisher definitiv nicht möglich ist, ist das anpassen des AI Traffics. Sich da durch den quasi unbekannten Code ohne SDK durchzuhangeln ist ohne SDK aufgrund des vermutlich immensen Zeitaufwandes nicht sinnvoll, zumal sich da ja eh der Ersteller der AFCDAD Version für den FS2002 mit beschäftigt und hier auf jeden Fall wesentlich bessere Vorkenntnisse besitzt. Da habe ich mich persönlich auch noch nicht groß mit beschäftigt. Wie gesagt Gründe sind halt momentan der unbekannte Code. Das der Verkehr auf den Rollwegen momentan falsch läuft hängt vom anderen Layout der Airports ab. Der Sachverhalt ist aber eigentlich nichts neues. Alte Technik des FS2002 bekommt man hier definitiv nicht zum laufen. Zumindest haben auch Tricks keine positiven Ergebnisse gebracht.


2) Zu den versetzten ILS Gleitpfaden bei ADDONS:
Ich denke da könnte ich etwas realisieren, Ideen wie man das Problem beheben kann ohne die Kompatibilität zum FS2004 GPS und der Kartenansicht des FS2004 zu verlieren habe ich. Diese Sache würde auch keine ADDON Lizenzen verletzen.
Wobei man sagen muss, einigen ist dieses Problem noch gar nicht aufgefallen. Bei einigen ADDONS existiert es nicht, da sie quasi das gleiche Runwaylayout wie der Default FS2004 Airport haben. Bei GAP Frankfurt/Main hier als Beispiel die Runway25R landet das Flugzeug nicht in der Mitte der Runway wenn man sich stur auf dem Gleitpfad hält. Man landet dann schon stark nach links versetzt. Auch die Anflugrichtung stimmt nicht ganz überein. Grund sind zum einen das etwas verschobene Layout zwischen Default und ADDON Airport, weiterhin etwas andere Parameter bei den Gleitpfaden. Im Prinzip das gleiche Problem wie beim Traffic. Umso mehr ein ADDON Airport von Defaultairport abweicht umso höher sind die Fehler.
Die FS2002 ILS und DME Befehle funktionieren zwar im FS2002 noch, werden aber bei vorhanden sein eines Defaultairports mit der Priorität niedriger bewertet, quasi unterdrückt.. Alte Excludebefehle sind nicht in der Lage die ILS und DME Befehle des FS2004 zu excludieren.
Wie gesagt eine sinnvolle Lösung für dieses Problem habe ich im Kopf. Ob sie funktioniert muß getestet werden. Dazu muss man aber erst mal die neuen Codes des FS2004 für diese Einrichtungen interpretieren können. Da bin ich bei. Diese Lösung würde generell nur eine Beeinflussung der FS2004 Dateien zur Folge haben. Wenn ich da was weis würde ich hier die Informationen auch weitergeben. Im Ansatz habe ich auf jeden Fall schon Erkentnisse aus dem neuen Code gewonnen.


3) Transparenzproblem bei Texturen, hier das durchsichtige Bereiche im FS2004 einfach nicht mehr durchsichtig sind:
Hier kann ich nur damit dienen eine Anleitung zu geben wie man diese selbst überarbeiten kann insofern man sich daran stört, da hier direkt original Texturen der ADDONS überarbeitet werden müssen. Was man machen muß wurde aber auch schon wo anders erwähnt. Die Texturen sind wie gesagt eindeutig geschützt da wird man in den Lizenzen direkt drauf hingewiesen.
Dieses Problem fällt wie gesagt optisch nicht unbedingt jeden auf. Es sind auch nicht so viele Texturen die hier überarbeitet werden müssen, man muß halt nur wissen welche betroffen sind. Bei Gitterzäunen wie z.B bei Austrian Airports fällt es mir am meisten auf. Was mich übrigends etwas wundert das laut FXP die Austrian Airports in der neuen Version vor der Tür stehen. Denn auch hier wird eine 100% tige Kompatibilität erst nach Veröffentlichung der SDKs möglich sein. Auch hier wird dann nochmal ein Patch benötigt, es sei denn die Airports richten sich nach den Defaultairportlayout der FS2004 Airports insofern dieses möglich ist, denn dann kann man auch heute schon sagen man ist 100%tig kompatibel zum FS2004.

[JOBIA]

4) Das Problem der zu großen Lichter bei ADDONS z.B bei Fahrzeugen der dynamischen/statischen Scenery zum Teil auch bei Lichtmasten usw.:
Das findet man z.B bei sehr vielen ADDONS. Ursache sind hier die verwendeten Befehle die man hier über den Scenerykompiler SCASM einsetzt. Diese Befehle sind aber zu den alten SDKs konform von SCASM umgesetzt. Es ist daher ein Problem der Scenerytechik und nicht der ADDON Ersteller. Bei dem hier verwendeten SCASM "Dot(" Befehl besteht das Problem das dieser Lichtpunkt seine Größe nicht entfernungsabhängig verändert. Ein Beispiel: Befindet man sich nahe an einem dynamischen Sceneryobjekt z.B einem VW Bus der auf dem Vorfeld umherfährt, so hat dessen Licht der Rückleuchte jetzt mal angenommen eine Größe von ca. 20 Pixel auf dem Monitor. Der VW Bus bewegt sich jetzt von uns weg. Folge der Bus wird kleiner und beansprucht weniger Pixel auf dem Monitor. Das Licht der Rückleuchte wird aber nicht kleiner sondern behält das Ausmaß der 20 Pixel. Folge für uns, umso weiter wir uns von so einem Licht wegbewegen umso riesiger wirkt es für uns im Vergleich zur restlichen Scenery bevor es dann engültig aus unserer Sicht verschwindet. Abhilfe ist bedingt möglich durch ausweichen und tricksen mit anderen Befehlen. Aber hier bietet uns SCASM bzw. die alte SDK Technik leider nicht viel. Außerdem würde dieses wieder ein antasten der original ADDON BGLs nötig machen. Eine andere Möglichkeit sehe ich aber im FS2004 momentan nicht. Ich kenne auch keinen versteckten Schalter oder irgendetwas in einer *.cfg Datei wo man dieses global beeinflussen könnte. Ich denke man hat nur die Ausweichmöglichkeit auf andere Befehle die eine Linderung des Problemes bringen. Es wird aber nie etwas vergleichbares zu den FS2004 Lichtern, die man z.B dort an den Flugzeugen findet.
Hier müßte man dann vermutlich auf GMAX als Designtool ausweichen. Ich denke da wird beim FS eigentlich eh kein Weg mehr dran vorbeiführen wenn man aktuell bei der Sache sein möchte. Es sei denn der neue gibt uns in dessen kommenden SDKs Informationen dazu wie das direkt in der BGL realsiert werden kann, dann sehe ich auch Chancen für andere Designtools.

[JOBIA]

5) Das Problem von weissen Flächen bei ADDONS z.B den GAPs oder auch eckigen Polygonflächen wo eigentlich Bäume sein sollten z.B den Austrian Airports.
Ursache hier wie auch oftmals schon im FS2002 einfach fehlende Texturen. Passiert in der Regel immer dann wenn

A: Installationsroutinen nicht richtig funktionieren was natürlich der Fall sein kann, da diese unter Umständen das FS2002 Verzeichniss als Installationspfad verlangen.

B: Wenn Scenerien einfach von den FS2002 in den FS2004 kopiert werden, bzw. einfach in der Scenerybibliothek des FS2004 die Pfade auf den FS2002 verlinkt werden.

Man sollte sich schon darüber im klaren sein was für eine Scenery eines ADDONS benötigt wird. Leider geht dieses Wissen verloren, da alle nur noch einfache Installationsroutinen haben wollen und dieses sogar bei Tests als Plus ausgewiesen wird. Dabei wäre ein einfaches ZIP/selbstentpackendes File mit einer kurzen Erklärung bei weitem ausreichend. Denn sehr komplex ist die Geschichte nun wirklich nicht. Es würde auch jeder wissen was abläuft. Es gäbe damit viel weniger Probleme als bei den ganzen tollen Routinen die doch des öfteren Probleme bereiten. Das hat uns die Erfahrung im FXP Forum ja nun des öfteren gezeigt.

Nun was kann man hier machen. Im wesentlichen nur die Empfehlung die Scenery einfach aus dem FS2002 in den FS2004 rüberzukopieren, da wo es möglich ist ev. die Pfade auf den FS2002 zu verlinken. Das was Probleme macht, also fehlende Texturen wenn man weis um welche es sich handelt diese einfach in den FS2004 an die betreffende Stelle nachzukopieren. Hat man keinen FS2002 mehr ev. als Tipp die Installation oder Extrahierung in ein Dummyverzeichnis (sprich irgendeinen leeren Ordner in dem man im schlimmsten Fall eine nachgebildete FS2002 Ordnerstruktur erstellen muss) insofern die Installationsroutine nicht auch hier verweigert. Bei einigen ADDONS müßte man dann in der Tat in der Registry manipulieren. Auf jeden Fall kommt man über diese Umwege auch an die fehlenden Texturen.
Hier könnte man wie gesagt Anleitungen zu geben.
Ich vermute das GAP Patch welches Ende August veröffentlicht werden sollte, dürfte sich im wesentlichen mit den Punkten 3) und 5) die ich hier erwähne beschäftigen.

Zurück zu den weissen Flächen bei GAP. Diese werden wie gesagt durch fehlende Bodentexturen verursacht. Sie fehlen wie gesagt nicht in den Texturordner der einzelnen GAP Scenerien sondern im Hauptexturordner des FS2004. (z.B bei mir X:\FS2004\Texture). Sicherlich hätte das GAP Team diese fehlenden Texturen auch in den mehrfach in den jeweiligen GAP 1 bis 4 Textureordern unterbringen können. So hat man aber den Vorteil das man sie nur einmal benötigt für alle GAP Versionen. Dieses ganze mit fehlenden Texturen ist aber nichts neues sondern das hatte ich im Frühjahr 2003 schon mal erwähnt als jemand dieses Problem hatte. Nun muß man fragen warum gibt es dieses Problem bei dem einen GAP Airport überhaupt nicht bei einigen nur an manchen Ecken bei anderen auf fast dem ganzen Airport? Gute Frage. Es gab da seit dem FS2002 ein kleines Problem. Die Rasenflächen der FS2002 Defaultairports waren nicht über bekannte FS2000 Polygontechnik realisiert sondern über die neue damals unbekannte VTP2 Polytechnik. Hier wurden übrigends keine Texturen direkt zugeweisen sondern über Umwege der Datei terraintextures.cfg Landclassnummern die wiederrum über die Steuerung der LCLOCKUP.BGL Datei Texturen zuwiesen. In einem Sceneryfile waren wie auch jetzt im FS2004 zum Teil mehr als 40 Airportrasenflächen integriert. Diese neue Technik reagierte aber nicht auf Excludebefehle sprich man wurde die Rasenflächen nicht ohne Probleme los. (Ausnahme Fotoscenery) Also musste man sich dazu entschliessen diese Rasenflächen komplett mitzunutzen, wenn es zufälliger Weise halbwegs vom Format passte. So wurde es durchweg bei sehr vielen ADDONS gemacht auch bei den meisten GAP Airports. Auf so einem Airport findet man in der Regel kaum weisse Flächen. Bei einigen Airports war aber das Defaultpoly zu klein, da man selbst noch keine VTP2Polys programmieren konnte (auch heute noch benutzen viele Designteams diese Technik nicht) hat man die passende FS2002 Textur einfach rausgesucht und hier ein eigenes Bodenpoly nach alter Technik programmiert. Bei einigen Airports nur in Teilbereichen bei anderen so groß das man flächenmäßig das Default komplett überschreibt. Tja und fehlen einem diese Texturen dann hat man eben je nach Größe der nachprogrammierten Polys mal kleine weisse Flächen und dann mal wieder riesige. Beim FS2004 verhält es sich mit den Defaultpolys bei Großairports wieder genauso wie beim FS2002. Auch hier wird über Umwege der jetzt nur noch terrain.cfg Datei heissenden Datei und der lclockup.bgl gearbeitet. Nur bei dem FS2004 kommt hier eine zusätzliche Funktion dazu. Diese hat bei den Großairports einen neuen Effekt den ich schon mehrfach als Chamäleon Effekt bezeichnet habe. Je nach Inhalt der verwendeten Landclasscenery die sich unter dem Airport befindet passt sich das Rasenpoly hinsichtlich Texturzuweisung an das Landclassfile an und zwar nicht großflächig sondern auch innerhalb der Polygonfläche. Sprich liegen z.B Landclasstexturen mit bräunlichen Kornfeldern unter dem Rasenpoly so verwendet dieses auch bräunliche Texturen. Liegen grüne Wiesen in Bereichen des Rasenpolys verwendet das Rasenpoly hier auch grüne Texturen. Diese Technik ist Geschmackssache. Man könnte hier Eingriffe in der terrain.cfg vornehmen oder die Steuernummer in den VTP Polys selbst ändern um direkt auf eine andere Rasenlandclass umzuschalten. Fakt ist aber, das es unmöglich ist hier jederman passende Tauschtexturen für diese weisse Flächen zu nennen, da man nie wissen kann was der User für Landclassfiles besitzt.

[JOBIA]

Was kann man tun. Zum einen könnte man Minilandclassfiles programmieren die nur unter dem Airport liegen und bedingt durch Ihre Priorität gewährleisten das der FS beim Defaultrasenpoly immer die selbe Rasentexturverwendet. So könnte man auch eine passende Ersatztextur ermiteln.
Aus diesem Grunde hätte es mich ja auch interessiert welchen Lösungsweg das GAP Team gehen würde.

Ich würde folgenden gehen. Da wo es sinnvoll ist den Einsatz von transparenten DXT1 Tauschtexturen. Es gäbe keine keine weissen Flächen die Funktion der Defaultpolys bliebe mit Chamäleoneffekt blieben bestehen. Störende Übergänge wie das bei Einsatz von bisherigen Standardtauschtexturen der Fall wäre würden erst gar nicht entstehen. Ev. falls nötig könnte man eine Nachprogrammierung eines Zusatzpolygones nach aktueller Technik machen.

Bei Kleinstairports sind die Rasenpolys übrigends semitransparent ausgelegt. Sie weisen nicht diesen Chamäleoneffekt auf.

Übrigends auch die störende Trassen der Hochspannungsleitungen werden über ähnliche Techniken verursacht. Kann man wie gesagt auch beseitigen.

[JOBIA]

6) Zum Thema flackernde Bodentexturen bzw. Bodenpolygone und zur Anpassung des ATP AddPack2:
Die Hauptgründe warum es jetzt im FS2004 flackert sind unter Nummer 7) zu finden.
Optisch wird es dadurch verursacht das die Grafikkarte keine eindeutigen Informationen bezüglich des Z Wertes geliefert bekommt. Es gibt Probleme das sie nicht eindeutig die Information bekommt welche Oberflächen im Vorder/Hintergrund bzw. oben oder unten liegen sollen.

Die Gründe warum es dazu kommt können sehr unterschiedlich sein.

Was war das Problem im FS2002. Nun hier zum einen Problematiken der Flattentechnik, sprich der abgeflachten Bodenflächen die eine bestimmt Höhe haben sollen. Im wesentlichen benötigen alle alten Polygon/Texturtechniken flache Oberflächen um nicht zu flackern. Optimalerweise sollten diese Bodenpolygone direkt auf diesen geflatteten Oberflächen liegen. Auch ein Grund warum die Exportfunktion bei D-Sat5.0 nie optimal funktioniert. Befand man sich im flachen Nordeutschland war alles erträglich. Kam man aber nach Süddeutschland mußte man die Texturhöhe dieser nicht meshkompatiblen Fotoscenery künstlich über jeden anderen Bereich des Mesh anheben, sonst verschwand die Fotoscenery oder flackerte heftig. War sie allerdings sehr hoch positioniert konnte man druch sie hindruchfliegen wie durch eine Wolke. Geländeformen des Mesh konnte sie nicht annehmen, da diese Texturtechnik halt flache Böden benötigt. Genau das Problem trat im FS2002 auf wenn es flackerte Die entsrechenden Texturen bzw. Polys sind nicht meshkompatibel die Rasenflächen des FS2002 waren es durch die neuere FS2002 VTP2 Polytechnik. Warum war nun im FS2002 aber der eigentlich geflattete Boden uneben (wir sprechen hier von wenigen cm die das Problem auslösten). Grund waren einer der beiden Runwaybefehle und Taxilinebefehle des FS die Mesheffekte auslösten wenn es Höhenunterschiede zwischen z.B Runway und Flattenpolygon gab. Dadurch wurde der Boden uneben, das VTP2 Rasenpoly konnte dem unebenen Boden folgen ein Taxiwaypolygon nach alter Technik nicht. Folglich konnte der Grafikkarte keine sinnvolle Daten mehr geliefert werden welches Poly nun oben (in der Priorität höher) liegen soll. Extrem ungünstig wurde das ganze dadurch beeinflusst das im FS2002 eine neue auf eine alte Flattentechnik trafen. Hier gab es je nach Startsituation bzw. Anflug zu dem Problemflughafen noch Schalteffekte zwischen diesen Techniken. Dann kamen noch ein paar kleine Bugs des FS2002 dazu die dieses Begünstigten. Weiterhin das der FS2002 und auch der FS2004 bei der alten Area16N Flattentechnik Prioritäten vertauscht. Tja und beim neuen FS2004 kommt eine dritte Flattentechnik dazu die Probleme bei den Gewässern schafft welches eine 100tige Überarbeitung des ATP Addpacks 2 für den FS2004 schwierig macht, dazu später vielleicht mehr. Denn Gewässer wie Seen die eine eigene Höhenangabe besitzen sind im Prinzip nichts anderes als Flattenpolygone aktueller Technik die noch zusätzliche Informationen tragen.


Diese oben genannten Bugs können auch im FS2004 vorkommen. In der Regel wird dieses durch den aktuellen Runwaybefehl bzw. die Taxiwaybefehle des FS2004 abgefangen. Es gibt da aber noch ein paar Fälle wie z.B Calden (Kassel/Calden) Defaultairport FS2004 hier hat mich ein Bekannter drauf aufmerksam gemacht. Hier können die Helipads nicht angeflogen werden. Auch sie flackern bzw. verschwinden. Hier tippe ich eher auf das Höhenproblem. Diese Polys haben eine feste Höhe die offensichtlich nicht mit dem Flatten übereinstimmen. Ein feste Oberfläche wie die neue Taxwaytechnik haben sie nicht. Ihr Code scheint daher anders zu sein.

Kommen wir jetzt zu dem Problem warum es z.B auf dem GAP Airport Hannover und auch anderen ADDONS flackert die bisher im FS2002 einwandfrei liefen. In der Regel ist es hier ein neues Problem. Optisch auch wieder versursacht durch falsche Tiefeninformation für die Grafikkarte.

[JOBIA]

Die Gründe sind wie gesagt anders. Hier muß ich noch mal kurz auf den Begriff Layer zurückkommen der übersetzt für Schicht steht. Bei der Gelegenheit können wir auch gleich das ATP Problem mit erschlagen.
Diese Layer versachen auch Probleme beim ADDPack2. Im Prinzip könnt Ihr euch das vereinfacht mal so vorstellen.
Ich lasse jetzt mal die ganze Meshgeschichte außen vor. Stellt euch einen Overheadprojektor vor. Auf diesen legt Ihr einen Block mit Klarssichtfolien. Der erste Block hat 63 Seiten. Diesen nenne ich SubLayerB. Darauf kommt noch ein Block mit 100 Seiten diesen nenne ich SubLayerA. Dieser SubLayerA existierte schon zu FS2000 Zeiten. Der SUBLayerB wurde beim FS2002 eingeführt und einfach unter den SubLayerA gelegt. Nun welchen Weg geht das Licht. Immer von unten zuerst durch das unterste Blatt welches ich Layer0 nenne bis rauf zu Blatt/Layer63 des SubLayerB danach durch Blatt0 des SubLayerA bis es zuletzt bei Blatt/Layer 100 des SublayerA die Klarischtfolien verlässt und über den Spiegel des Overheadprojektors an die Wand geworfen wird. Und die Wand ist in userem Fall das Bild was uns die Grafikkarte zeigt. Dreidimensionale Objekte wie Gebäude lassen wir bei dieser Betrachtung auch mal außen vor. Nun nehmen wir vereinfacht mal folgendes an. Ich male jetzt nur im unten liegenden SubLayerB. Ich nehme mir ein transparenten bläulichen Stift hiermit male ich die Meere aufBlatt/ Layer0. Jetzt male ich auf Blatt/Layer1 mit grünen und braunen Stiften die Kontinente mit Ihren Wiesen/Wäldern und Wüsten. Auf Blatt 4 male ich die Rasenflächen für die Airports, auf Blatt 31 die Straßen usw. Hm jetzt möchte ich innerhalb eines Kontinentes einen See haben, diesen sehe ich aber nicht, da ja mein Licht nach dem Gewässer noch durch meine gemalte Wiese die Rasenpolys und Straßen fällt. Die Rasenpolys und Straßen stören uns in der Regel nicht, da sie sich ja nicht da befinden wo Wasser sein soll. Also mache ich jetzt eines ich nehme eine Schere und schneide ein Loch in meinem Kontinent und schon sehe ich wieder meine Gewässerschicht des Blattes 0. So werden im Prinzip Gewässer gemacht. Das ist auch das Problem jetzt beim ADDPACK2 man kann so ein Gewässer nicht einfach excluden sondern man muß im Prinzip das ganze File entfernen welches diese Lochinformation enthält bzw. man muß dieses Loch durch eine neue Information flicken. Zusätzlich ist das Hauptproblem das man so einem Gewässerloch eine eigene Höhe nämlich eine Flatteninformation mitgeben kann. Diese muß weg im FS2004 bevor man sinnvoll das ADDPack2 hinsichtlich Gewässer überarbeiten will da diese Angaben im FS in den seltensten Fällen zum Mesh passen (falsch positionierte Seen usw.). Leider hat diese zusätzlich gegenüber dem FS2002 zusätzlich eingeführte dritte Flattentechnik eine höhere Priorität als die des Fs2002 das macht es schwierig da wir in der des FS2004 aufgrund des fehlenden SDK nicht programmieren bzw. manipulieren können. Für den Insider. Remesh funktioniert im Fs2004 dort wo vorhandene aktuelle Informationen vorliegen nicht richtig. Auch das großflächige zuflicken eines Sees durch so genannte AreaFill Befehle funktioniert im FS2004 nicht mehr. Rainer Duda hatte ja herausgefunden das diese Befehle bei geöffneten GPS Fenster oder Wetterkarte den FS crashen lassen. Hier kann man sich wie gesagt behelfen in dem man z.B den AreaFill1x1 Befehl durch zwei Dreiecks LWM POlys ersetzt. Was uns wegen des Höhenproblemes ohne neues SDK bliebe wäre das rausnehmen des entsprechenden Blattes und ersetzen durch ein eigenes. Das würde aber im Falle des ADDPACKS2 bedeuten das man hier auch sehr große Bereiche Deutschlands mit überarbeiten müsste. Tja nun passiert aber folgendes da arbeitet ein Ranier Duda im selben Bereich wie das ATP Team. Wer darf dann wessen Blatt antasten. Schon gibt es die ersten Konflikte. Wenn dann auch noch die Höhenproblematik ins Spiel kommt wird es haarig. Einiges können wir mit der bekannten FS2002 Technik hinsichtlich Gewässern auch im FS2004 zaubern nur das mit der Höhenmanipulation habe ich persönlich noch nicht 100%tig im neuen Code des FS2004 manipulieren können im Ansatz schon. Ich vermute das ATP Team auch noch nicht denn dann gäbe es vermutlich schon eine Anpassung für den FS2004. Das bedeutet wir können zwar das AddPack2 einsetzen haben aber mit der meshbeinflussenden Gewässerhöhe die gebirgige Steilhänge verursacht zu leben. Da könnte man eine Anpassung erst dann bieten wenn man den Gewässer bzw. Flatten Code des neuen besser verstehe würde es sei denn man will diesen Weg des löschens und der Neuprogrammierung gehen.

[JOBIA]

Bei der Gelegenheit können wir auch die anderen Probleme des ADDPacks gleich mit erschlagen. Bei dem Blatt 31 welches z.B die Straßeninformationen enthält gibt es spezielle Excludebefehle. Diese ermöglichen praktisch das die alten Straßen unsichtbar werden und nur unsere eigenen gezeichneten sichtbar werden. Und hier gibt es beim neuen halt Probleme. Die Straßen die beim alten noch auf Blatt31gemalt waren sind jetzt auf Blatt7 zu finden. Wenn wir also die bisherigen Excludebefehle des ADDPack2 nutzen machen wir gar keine Straßen im FS2004 unsichtbar sondern ev. irgendetwas anderes. Daher findet man jetzt sowohl die Defaultstraßen als auch die des ADDPacks2 vor.

Man muß also die Excludefiles anpassen. Ich habe mal nachgedacht diese für den FS2004 überarbeiteten denke ich dürfte ich euch zur Verfügung stellen, denn jeder hat das recht Excludefiles zu programmieren. Zumal diese schließlich nur Defaultinformationen des FS2004 vernichten werde es aber aus besagten Gründen denoch nicht tun.

Was man generell nicht anbieten kann sind auf den richtigen Layer korrigierte ATP Straßen für den FS2004 da hier dann die original Dateien des ADDPacks2 angepasst auf die neuen Layer zur Verfügung gestellt werden müßten.Aus lizenzrechtlichen Gründen wie gesagt nicht möglich. Das gleiche trifft für andere Liniendefinitionen wie z.B Bahnlinien usw. zu. Wie gesagt es muß nicht unbedingt Störungen im FS2004 zur Folge haben wenn die Straßen usw. noch in den Layern des FS2002 liegen. Nur sicher sein kann man nicht.

Aber es gibt da noch ein weiteres Problem. Man kann bei den Linien zwar excluden. Dieses excluden löscht aber quasi nur die optische Texturinformation sprich man sieht eine Straße optisch nicht mehr.
Wie Ihr aber wisst pressen die neuen kleinen Flüsse Ihr eigens Bett, die Straßen an Hängen Ihre eigenen Schneisen ins Mesh. Dieser Vorgang ist vor dem Exclude bereits anhand der Default Liniendefinitionen erfolgt denn der FS arbeitet seine Informationen narürlich nicht nur nach der Scenerbibliothek und Layern sondern auch logisch ab . Dieses mit dem Mesh kann man nicht mehr rückgängig machen. Es sei denn man verzichtet ganz auf diese Technik die auch wieder in der terrain.cfg des neuen gesteuert wird. Oder aber man muß wieder in den Straßendefinitionen des FS2004 rumhacken und gezielt bestimmte Bereiche auf eine andere Zuweisungsnummer umswitchen. Oder aber was am einfachsten wäre komplette Files umstricken. Man hätte dann ein sauberes Mesh in Österreich und dafür die alt bekannten schräg am Hang klebenden Straßen z.B in dem Bereich wo die ATP Scenery keine Straßen neu erzeugt. Es wäre auch ein leichtes die ATP Straßen auf diese neue Technik aufzupeppen. Aber wie gesagt ein Lizenzproblem.

Ein kleines Excludeproblem gibt es noch. Man hat jetzt leider die Hochspannungsmasten mit Ihren Trassen mit anderen Liniendefinitionen in einen Layer gepackt. Bedeutet excludiert man Straßen verschwinden auch die Hochspannungsmasten. War nur ein Beispiel ich habe nicht mehr im Kopf was sie da zusammengepackt hatten. Abhilfe hier bevor man excludiert müßte man die Hochspannungstrassen in einen anderen Layer bringen. Wobei sich die Frage stellt warum verdichet MS beim FS2004 alles nahezu in den ersten 10 Layern des SubLevelB. Das muß theoretisch Gründe haben die sind doch nicht blöd. Daher vermute ich mal das hier irgendetwas unbekanntes steht was uns noch Probleme bereiten wird. Ev sogar diese Chamäleoneffekte bei den Rasenpolys. Daher zitiere ich mich hier selbst:

" Wie gesagt es muß nicht unbedingt Störungen im FS2004 zur Folge haben wenn die Straßen usw. noch in den Layern des FS2002 liegen. Nur sicher sein kann man nicht."

Damit wäre das wesentliche zum ATP Problem gesagt was man aus lizenzrechtlichen Gründen veröffentlichen dürfte, weiterhin was möglich wäre aber aus lizenzrechtlichen Gründen nicht veröffentlicht werden darf.

[JOBIA]

7) Die Hauptgründe warum es zum flackern von Bodentexturen im FS2004 kommt. Man sollte den Text unter 6) gelesen haben wenn man hier Verständnisprobleme hat.
Kommen wir jetzt endlich zu dem Problem warum es z.B auf dem GAP Airport Hannover und auch anderen ADDONS flackert die bisher im FS2002 einwandfrei liefen. Optisch auch wieder versursacht durch falsche Tiefeninformation für die Grafikkarte. Und hier kommen nun die Layer 0 bis 100 des SublayelA zur Sprache. Das Problem taucht nur auf wenn der Defaultairport des FS2004 aktiv ist. Ich kann euch keine 100tige Aussage geben was dieses Problem verursacht denn dazu müßte man gezielt Defaultfiles manipulieren können. Ohne SDK wie gesagt schwierig.
Fakt ist die neuen Airportscenerien nutzen Layer die auch die bisherigen Airportscenerien genutzt haben. Da kommt es jetzt zu Störungen in den Layern. Das ganze hängt auch noch ein bischen von der Fläche ab die Bodenpolygone abdecken. Speziell die alten Rasenpolys werden durch Informationen der Defaultscenery offensichtlich in Ihrem Layer beeinflusst. Nun ist es so das man bisher bei der Programmierung über SCASM nicht sehr pingelig sein mußte hinsichtlich Layervergabe bei der Programmierung. Man konnte eigentlich fast ganz drauf verzichten Layer zu vergeben. Bisher hat sich dieses eigentlich allein schon durch die Programmierreihenfolge ganz gut ausgeregelt sprich wann die einzelnen Polygone in welcher Reihenfolge geladen wurden.

Tja beim FS2004 ist das anders, dieser würfelt hier alles hinsichtlich Layer offensichtlich durcheinander. Verursacht durch irgendetwas seiner Defaultscenery (welches nicht auf die bisherigen Excludebefehle der FS2000 Technik reagiert genausowenig wie das bei den Default ILS des FS2004 nicht der Fall ist).

Nun wie kann man das beheben. Ganz einfach in dem man gezielt so einen ADDON Airport umprogrammiert und deren Polygone über den SCASM Befehl "LayerCall(" in ein festes Korsett zwingt. Dieses ist die optimale Methode. Kann ich aber niemand mit dienen da wieder Lizenzen verletzt werden.

Mir ist aber aufgefallen das es in der Regel ausreicht das flächenmäßig sehr große Rasenpoly zu entfernen. Da bei meisten Großairports ja überwiegend auch keine eigenen Rasenpolys genutzt werden wäre das nicht tragisch. Mir ist eh damals aufgefallen das bei den ADDONS die eigenen mitbrachten eh nicht viel mit der Realität übereinstimmten. Der neue hat komplett neue Rasenpolys vielleicht sind die sogar besser. Ansonsten könnte man welche nach neuer Technik auf die Schnelle programmieren denn diese verursachen keine Störungen da sie eh in einem amderen SUBLayer liegen. Das mit dem SUBLayer stammt übrigends von mir zwecks besserer Erklärung, damit man weis das wir hier von verschiedenen Layerstrukturen reden. Denn in einem SDK kommt der Begriff so nicht vor.

Diese Lösung mit dem Entfernen des Rasenpolys reicht im Regelfall aus und ist die schnellste. Wie gesagt für jedermann innerhalb zwei Minuten mit dem Hexeditor zu erledigen wenn man ihm den Bereich nennt der auszuschneiden ist. Aber da original BGL Dateien angetastet werden gibt es keine Anleitung dazu von mir. Es sollen hier nur die Lösungen aufgezeigt werden.

Klar hat man nur einen Kleinstairport dann ist die Rasenfläche des Defaultairport in der Regel für ein ADDON zu klein. Hier kommt man nicht drum hin ein eigenes Poly neuer Technik zu programmieren. Es sei denn man geht den Weg der Überarbeitung mit LayerCall Befehlen.

Das war es von mir zu den Problematiken von Scenery ADDONS im FS2004. Andere Probleme kenne ich bisher nicht. Wie gesagt vieles ist machbar im hinsichtlich Anpassung von ADDONS zum FS2004. Leider nicht für die Allgemeinheit.

[JOBIA]

Eines hatte ich zum Thema Anpasung ATP an den FS2004 oben noch vergessen. Ich erwähnte ja das aus meiner Sicht momentan der neue unbekannte Gewässercode des FS2004 das Hauptproblem ist. Auch das ich diesen noch nicht eindeutig interpretieren und in dem Maße überarbeiten kann wie es z.B für eine 100tige Anpassung nötig wäre. Durch einen Trick ist es aber auch heute schon möglich den FS2004 so vorzubereiten, dass das ADDPACK2 auch hier einwandfrei arbeiten würde. Ich erwähnte ja an anderer Stelle schon das sich das Layout der Gewässer und der Höhenangaben von FS2002 und FS2004 nicht unterscheidet zumindest habe ich bisher bei deckungsgleichen Screenshots in der Vogelperspektive keine Unterschiede gefunden (der BGL Code ist natürlich verschieden). Es wäre daher folgendes machbar. Deaktivieren der Defaultgewässerfiles die mit der Austria Prof. Scenery kollidieren. Leider haben diese FS2004 Files flächenmäßig andere Abdeckungen als die des FS2002 ansonsten hätte man die FS2002 Files 1 zu 1 übernehmen können. Man müßte daher die enstrechenden Informationen aus den FS2002 Files zusammen suchen und als neue mit dem FS2004 deckungsgleiche Files zusammenstellen. Hat man dieses gemacht kann man diese Files (deren Code uns ja aus dem FS2002SDK bekannt ist) so an die ATP Scenery anpassen das es hier keine Kollision mehr gibt. Selbstverständlich müsste man drauf achten das keine AreaFill Befehle aus dem FS2002 SDK verwendet werden, wenn man nicht irgendwann einen Crash bei geöffneten GPS usw. haben möchte.

Damit hat sich für mich das Thema ADDONS im FS2004 erst mal erledigt.

Jetzt werde ich mal was anderes machen und schauen was man beim FS2004 hinsichtlich Straßen und Eisenbahnlinien bezüglich Texturen machen kann. Vielleicht geht beim neuen bei den Defaultcodes ja mehr als beim FS2002.

Was ich aber machen werde, ist das ich auf meine Homepage demnächst irgendwann mal universelle Transparenztexturen in den verschiedenen gebräuchlichen FS Texturformaten legen werde (keine Sondergrößen). Diese kann dann jeder für sich nutzen wenn er mal etwas weghaben möchte was ihn stört ohne das er hinterher gleich fehlerhafte Darstellungen im FS hat. Wie gesagt Anwendungsgebiete für so was gibt es ja genug. Man muß dann nur diese Transparenztextur nach dem Namen umbenennen den die ursprüngliche Textur trägt die man weg haben möchte.

[Stefan Söllner]

Wow Jobia! Vielen Dank. Erstklassige Abhandlung!

@FXP-CHEFFES:
Vielleicht sollte man diesen Thread als "Sticky" immer oben halten, damit er nicht im Nirwana untergeht (in der Designer-Ecke?)