Die Frage ist: Unterstützt AuthoOrtho überhaupt solche Patches? Da bin ich jetzt nicht im Thema.

 

Weiteres problem ist: Es gibt da noch eine Alternative namens MapEnhacement, dafür müssten dann auch solche Patches erstellt werden. Da aber Osm ein Standardformat ist sollten diese Programme selbst das Unterstützen, dass die Ortho-Patches auch dort benutzt werden können - die Anfrage sollte also an die zuständigen Entwickler dieser Programme gerichtet werden (Ortho4XP ist schon lange da und sozusagen der Standard, nachzügler sollten sich dazu kompatibel stellen).

 

Ich teste gerade mal MapEnahcement und wie das letztlich funktioniert, aber ich denke nicht, dass wir für alle diese Lösungen separate Patches erstellen werden, das wäre ein signifikanter Kostenfaktor und, siehe oben, die Entwickler dieser Tools dürfen durchaus auch einen Teil zur Herstellung der Kompatibilität leisten, das kann letztlich nicht alles auf Szeneriedesigner abgewälzt werden (speziell wenn wie es sich wie bei MapEnhacement um ein kommerzielles Produkt handelt).

 

Die einfachste Lösung wäre letztlich, wenn die Entwickler der Ortho-Programme ihrerseits unsere OSM-Patches unterstützen würden. Bis dahin: Ein ordentliche festplatte mit etwas kapazität zulegen und Ortho4xp benutzen (ist letztlich ganz einfach zu benutzen, auch wenn es anfangs kompliziert aussieht, Tutorials dazu gibt es auch ohne Ende, Google hilft da weiter).

Die Vega 8 des Prozessors scheint in der Tat sehr langsam zu sein, da besteht die Möglichkeit, dass das gar nicht sauber läuft - aber eine Log.txt könnte eventuell hilfreich sein um mehr herauszufinden.

 

Da die Demo und die Vollversion von XP12 dasselbe Programm sind, einmal aktiviert, einmal nicht aktiviert, ist es interessant zu sehen, dass die Demo läuft, die Vollversion aber nicht lädt. Der schlagende Unterschied zwischen Demo und Vollversion sind die zusätzlichen Szeneriedaten, die in der Demo fehlen ergo auch nicht geladen werden müssen - wahrscheinlich reicht hier einfach der RAM/VRAM nicht, was die endlosen Ladezeiten erklären würde.

 

Aber, ja, stell mal alle Grafiksettings auf Minimum und schau, ob das besser läuft. Dann ist natürlich ein aktueller Grafiktreiber immer sinnvoll (XP12 startet mit veralteten AMD-Treibern auch gar nicht erst und gibt eine Treiber-Update-Meldung raus).

Du bekommst natürlich auch irgendwann ein Problem mit sehr kleinen Objekten, wenn die einfach nichtmehr dargestellt werden können - aber, wenn du ein Objekt modellierst für einen String kannst du im Objekt mit dem LOD-Befehl arbeiten: zB:

 

ATTR_LOD 0 10000

 

um das Objekt bis 10.000m entfernung anzuzeigen.

 

Und mein Polygon funktioniert wohl nicht, weil ich vergessen habe die Weather-Map abzuschalten, die fehlt im Paket (kannst du aber einfach auskommentieren, die Weather-Zeile).

Probier mal mein Polygon hier, kannst das ja dann mit deiner Textur ausstatten und umbennen (ist aus dem EDDK für die Runway-Markierungen, da ist es bis weit hinten sichtbar). Wenn das bei dir auch nicht funktioniert stell mal die Renderdistanz in den Settings höher und schau, ob das etwas verändert.

 

Ground_Marking_White.zip

Den komischen Schatten kann ich jetzt bestätigen - allerings ist die ganze Szenerie noch voller anderer Dinge, die recht zeitaufwändig zu fixen sind, weshalb das Update erstmal auf Eis liegt, da kümmere ich mich drum, sobald ein paar andere Projekte fertig sind (ist sonst einfach zuviel durcheinander).

 

Das ist interessant... 🙂

Da wurde wohl mal eine halbherzige Runway-Umbenennung gemacht bei der die Schilder vegessen wurden, vermute ich... Das mit dem Schub ist in der tat merkwürdig, prüfe ich mal. Davon abgesehen stimmt noch einiges nicht bei den VDGS und Jetways (haben einen versatz von Metern zum Terminal, VDGS schweben teils frei in der Luft neben dem Poller). Das durchscheinende Polygon muss ich auch noch püfen, würde mich aber nicht wundern, da kommt eine bunte Mischung aus Texturen zum Einsatz, möglicherweise stimmt da die Draw-Order nicht oder wurde nicht definiert.

 

Das ganze ist in jedem Fall etwas aufwändiger als erwartet und mit dem Baum-Fix ist es da nicht getan.

 

Update:

 

• Durchscheinende Bodentexturen habe ich keine gesehen bei 24R -> hier wäre ein Screenshot hilfreich
• Schub geben verursacht bei mir keine Probleme, der Sim stürzt nicht ab

Ja, dann wird's Zeit. 😉

 

Scherz beiseite: Mein Aufruf richtet sich an die Leute die die Szenerie haben und die Probleme kennen... ich bin da halt nicht so ganz im Thema, hatte den Flughafen bis eben auch nicht und zum richtigen Benutzen und Testen fehlt mir gerade die Zeit (bei normaler Nutzung finde ich am ehesten Fehler).

Nochmal kurz zur Information:

 

Das Ändern des Headers der Library.txt von 800 auf 1200 bewirkt überhaupt gar nichts - das wurde mir von Ben Supnik bestätigt und entspricht auch meinen Erfahrungen mit den Libraries und Jahreszeiten.

 

Wenn irgendwas mit den Jahreszeiten nicht stimmt liegt der Fehler auf jeden Fall woanders.

Ich hab mir jetzt den Zugriff auf die Szenerie organisiert und einen groben Überblick verschafft. Jetzt habe ich aber ein paar Fragen:

 

Was genau ist da jetzt an Problemen, abseits der Bäume (das ist erledigt). Kann da mal jemand folgendes prüfen (mir fehlt die Zeit dazu gerade, ich schieb das hier zwischen 5+ Projekte):

• Funktionieren die SAM-Jetways und Marshaller?
• Funktioniert der GroundTraffic bzw. ist der überhaupt vorhanden?
• Wie genau sieht das mit den Runway-Bezeichnungen jetzt aus? Bing- und Google-Maps wie auch eine allgemeine Suche nach den Infos ergeben bei mir, dass 06/24 korrekt ist - da stimmen jetzt nur die Taxi-Signs nicht?
• Funktioniert der KI-Traffic am Flughafen?
• Stimmt sonst irgendwas nicht?

 

 

 

 

 

Soll nicht heißen, dass ich die alten 2D-Bäume in einer XP12-Szenerie für gut halte... nur solange sie prinzipiell noch funktionieren ist die Szenerie rein technisch nicht Verursacher des Problems. Ich schau da aber mal, ob da nicht ein Update der Szenerie gemacht werden kann... das dauert dann aber einige Zeit bis das erledigt ist.

 

 

Okay... Wenn Heinz Bäume in der Szenerie hat dann sind die Bäume prinzipiell im Simulator noch da, aber irgendein AddOn ersetzt sie durch Platzhalter... Der Fehler liegt dann prinzipiell bei dem AddOn, welches die Platzhalter verteilt.

Das hab ich mir schon gedacht mit dem offiziellen Update... meine Glaskugel sagt mir, dass da noch so einiges nicht richtig ist...

 

🙂

Danke für die Infos... das wird aber wohl ein echtes Update brauchen, ich kläre das mal nächste Woche mit dem Projektmanager, ob ich da was machen kann - ich weiß grad nicht, welches Team dafür zuständig ist.

 

Aber, wegen des "Convert to": Das müsste funktionieren, wenn NUR alle Bäume, nicht aber deren Gruppe und auch sonst nichts, markiert wird. So mache ich das bei Updates eigentlich immer und das funktionierte auch bisher ausnahmslos.

Das sieht so aus... als würde die Szenerie noch alte XP11-Bäume verwenden, die aber im XP12 wie es aussieht durch unsichtbare Platzhalter ersetzt werden. Im WED ließe sich das beheben, allerdings zerschießt dir das deine Szenerie, also probier mal folgendes:

 

• Kopier die ganze Szenerie, so dass du sie zweimal hast und benenne das Duplikat um in zb "LEBL Tree Fix"
• Öffne im WED den duplizierten Flughafen
• Suche nach allen Bäumen "lib/g10/tree" (ohne die 3 im Namen, falls es noch andere Bäume gibt) oben rechts im Suchfenster
• Markiere alle gefundenen Bäume und Erstelle eine Gruppe "Trees"
• Lösche alles außer der Gruppe mit den Bäumen
• Markiere jetzt wieder alle Bäume und dann geh auf "Edit > Convert to > Forest Points"
• Die Bäume sollten nun alle zu Forests konvertiert werden "maple_medium.for" - das kann so bleiben
• Speichere das ganze ab und exportiere die Szenerie.

 

 

Anschließend musst du aus der Tree-Fix-Szenerie noch die apt.dat löschen, da WED das nicht macht (WICHTIG). Wenn du das alles gemacht hast kannst du die Tree-Fix-Szenerie in der Scenery_Packs.ini über der LEBL-Szenerie platzieren und die Bäume werden daraus dann hinzugefügt.

 

 

Ja... im Detal weiß ich da ach nicht bescheid, ich hab das Tool selbst nie benutzt da ich keine orthos verwende. Ich hatte es aber mal genutzt um zu schauen, was es da macht, mit irgendeinem Test-Mesh, meine ich, da mein manuelles Einfügen der Jahreszeiten in alte Meshes erstmal nicht geklappt hatte (blöder Fehler bei mir, das Tool macht genau das, was ich im Sinn hatte, nur richtig).

 

 

Also... laut Autor funktioniert das so (und Verknüpfungen funktionieren tatsächlich nicht):

 

Installation:

• If you have my gfsm or my o4xp_Seasons_Manager plugin installed disable them
• Download the binary for your platform and place it in the root folder of XP 12
• Open a shell window (cmd on Windows) there
• Run o4xp_2_xp12 ( o4xp_2_xp12.exe on Windows)
• If no o4xp_2_xp12.ini is found one is created that should work for 90% of the user community, for special setups change accordingly
• Run tool as described above
• This is a command line tool and must be started in a shell window (e.g. cmd for Windows). Double clicking will do nothing!

 

Hast du jetzt versucht die exe per Doppelklick zu starten? Laut Anleitung musst du in der CMD das Tool starten, damit es funktioniert. Im XP12-Ordner hast du es abgelegt, ja? Sonst würde es wohl die Pfade gar nicht finden.

 

Also:

• Öffne ein CMD-Fenster (Windowstaste drücken, CMD eintippen, dann Enter)
• Dann einmal das Laufwerk angeben, in dem das Tool liegt (zb "G:" eintippen, dann Enter, nach deinem letzten Screenshot hast du XP12 jetzt dort)
• Anschließend tippst du "cd X-Plane 12" und bestätigst wieder mit Enter
• Nun solltest du mit der Eingabe "o4xp_2_xp12.exe" und wieder Enter das Programm starten können.

 

Hoffentlich klappt das jetzt endlich. Ich gehe hier davon aus, dass "o4xp_2_xp12.exe" direkt im XP12-ordner liegt, wenn es noch einen eignenen Unterordner haben sollte muss der auch noch in den Pfad rein.

 

Ja... vergib mal einen Laufwerksbuchstaben und versuch es auf diesem Weg.

Das läuft aber über symbolische Verknüpfungen von externen Laufwerken, die nach C:\Devices verlinkt sind? Falls ja, dann gib mal den wirklichen Pfad an zum externen Laufwerk. Den vollen Pfad kannst du im Explorer sehen, wenn du oben in die Adressleiste recht ins weiße Feld neben dem Pfad klickst, der Verknüfpungspfad funktioniert möglicherweise nicht (je nachdem, was für ein Link die Verknüpfung letztlich ist).

Du brauchst dazu nichts weiter zu installieren, Python ist lediglich die Programmiersprache, in der das programmiert ist und das wird normal mitgeliefert, wie bei ortho4xp auch. Du konntest ja auch das Programm starten und ausführen, es hat nur erstmal nichts gemacht weil wahrscheinlich deine Konfigurationsdatei (die ominöse Ini, die erstellt wurde laut logfile) nicht zu deinem externen Laufwerk führt.

 

Deine Ini-Datei sieht so aus:

 

[DEFAULTS]
xp12_root = C:\Devices\Flugsimulatoren\XP12
ortho_dir = C:\Devices\Tapeten\
work_dir = C:\Users\Micha\AppData\Local\Temp
num_workers = 10

[TOOLS]

 

Da trage mal unter "ortho_dir" deinen Speicherort für die Orthos korrekt ein. Dein externes Laufwerk dürfte wohl nicht mit "C:" beginnen, das ist üblicherweise das Windowslaufwerk. Prüfe auch mal, ob dein "xp12_root" wirklich zum Simulator führt - diese Pfade oben sehen für mich jetzt etwas unorthodox aus, "C:\Devices\..." macht für mich keinen Sinn... oder hast du deinen XP12 wirklich dort installiert?

 

Trage dort mal sinnvolle Pfade zu den Ordnern ein und starte das Programm nochmal... wenn es korrekt funktioniert sollte sich die Kommandozeile nicht einfach wieder schließen sondern irgendwelche Operationen anzeigen, die es durchführt.

 

 

  

vor 33 Minuten schrieb Reiner C.:

ich nutze für Ortho4XP die Version 1.4.07. Hier sind diese Pakete schon integriert.

 

Das würde aber bedeuten, dass Michael seine 2 TB Luftbilder neu erzeugen müsste, daher der Umweg über das Update-Tool.

Ich hab das tool selbst noch nicht benutzt... möglicherweise musst du in der automatisch erzeugten Ini-Datei den Pfad zu deinem Ortholaufwerk irgendwo angeben? Das könnte ich mir vorstellen. Deine Logdatei sagt, dass das programm startet, diese Datei erzeugt, dann aber nichts macht und sich beendet, Fehler werden aber keine gemeldet - ich schätze daher, dass es deine Orthos nicht findet.

 

Im Zweifel poste mal diese Ini-Datei hier und ich schau da mal rein, was da so drin steht...

Ja... das Tool musst du herunterladen und auf deine Tiles anwenden. OpenSceneryX sollte eigentlich nicht dein Primärproblem sein, wenn du mit Simheaven in Europa unterwegs bist.

Probier mal mit diesem Tool deine Meshes zu aktualisieren:

 

https://forums.x-plane.org/files/file/88328-o4xp_2_xp12-converter-for-ortho4xp-to-xp12/?page=3&tab=comments

 

Das Program fügt die Rasterdaten aus der Basiszenerie in ortho-Meshes ein, so dass man die nicht selbst erzeugen muss. Wenn deine Orthos noch aus 2022 sind dürften die noch großenteils mit Ortho4xp 1.30 gemacht worden sein und haben entsprechend die Rasterdaten nicht - hier sollte das Programm abhelfen können.

 

Bezüglich OpenSceneryX: Wenn du nur eine Zip-version hast sollte das vermutlich kein Problem sein... falls du aber mal die Installer-Version für XP11 verwendet haben solltest und diese dann nach XP12 kopiert... könnte da noch diese Option aktiv sein.

 

Die Installer-Version gibt es übrigens nach wie vor zum Download (Achtung: Die Installer-Version ist 2.7.0, das ist aber nicht die Library-Version, die ist dann auch bei 4.x oder so):

 

https://www.opensceneryx.com/

 

 

Ach und noch etwas:

 

OpenSceneryX hat eine Option im Installer "Incorporate Global HD Forests" - diese MUSS im XP12 abgeschaltet werden, sonst verteilt die Library global die XP11-HD-Forests aus SAM_Seasons_SDK, was zur Darstellung veralteter 2D-Bäume ohne XP12-Jahreszeiten führt. Das ganze sollte bei Verwendung mit SimHeaven aber lokal begrenzt sein und sich auf Bereiche außerhalb der installierten SimHeaven-Regionen beschränken, da dessen Vegetation einen Großteil dieser Wälder gar nicht nutzt und eigene Verteilt.

Das Dingen mit SAM ist etwas komplizierter, wenn das Plugin bei dir funktioniert und keine Probleme macht kannst du es weiter nutzen. Prinzipiell funktioniert es mit XP12 noch, hat aber einige Probleme hier und da und in der Steam-Version funktioniert es leider nicht mehr, warum weiß ich nicht.

 

Lasst aber bitte die Finger von SAM Colors + Seasons im Plugin-Menü, das macht im XP12 keinen Sinn und könnte für unschöne Überraschungen bei Verwendung älterer XP11-Szenerien führen, wenn sie das unterstützen.

 

SAM_Seasons_SDK ist ein Projekt für XP11 und dient der Unterstützung von SAM Seasons, der Ordner selbst ist erstmal ganz harmlos, die Inhalte, das ist korrekt, können vom SAM-Plugin gesteuert werden - das spielt aber im XP12 für dessen Jahreszeiten überhaupt keine Rolle und kann komplett ignoriert werden. Die SimHeaven-Vegetation greift für ein paar ganz wenige Dinge wie Weinplantagen noch auf diese Inhalte zu, die aber auch in diesem Fall nicht über SAM gesteuert werden, Armin hat schlicht den ganzen alten Ordner aus der XP11-Version der Library übernommen, dabei aber alle Inhalte über das XP12-System, in der library.txt neu angesteuert, SAM ist da ganz raus und hat keinen Einfluss auf irgendwas.

 

Die Simheaven-Vegetation für XP12 ist prinzipiell okay und braucht keine SAM-Steuerung, Armin war da eigentlich nie ein Fan von, irgendwas über SAM laufen zu lassen und SAM_Seasons_SDK ist in der Library nur drin, weil ich daraus damals die XP11-Library zusammengezimmert habe, die dann auch SAM-Jahreszeiten unterstützte. Allerdings gibt es da auch noch diesen Thread, wo ebenfalls ein Problem mit der Simheaven-Vegetation und Jahreszeiten festgestellt wurde, da ist irgendwas nicht ganz korrekt wie es scheint.

 

Wenn irgendwas mit deinen Jahreszeiten nicht stimmt liegtder Fehler wahrscheinlich woanders. Mögliche Ursachen sind zB fehlende Maps in alten ortho4xp-Tiles (die Jahreszeiten werden über Rasterdaten im Mesh gesteuert) oder Szenerien mit eigener Vegetation, die keine XP12-Jahreszeiten unterstützen. Außerdem hängen die Jahreszeiten im XP12 auch von der Klimazone ab, irgendwo in der Südsee hast du zB immer Sommer und das wird im Sim auch so dargestellt, irgendwo in Deutschland solltest du aber irgdnwann Anfang/Mitte Oktober den Übergang zum herbst festellen und im Dezember dann zum Winter.

 

 

Allgemeine Gründe für fehlerhafte Jahreszeiten können sein:

• Rasterdaten fehlen im Mesh (sorgt für falsche Farben der Vegetation, Änderungen sind aber sichtbar)
• Szenerie unterstütz Jahreszeiten nicht (sorgt für gleichbleibende Farben von Bodentexturen und/oder Vegetation)
• Szenerie ist falsch konfiguriert (Jahreszeiten werden dargestellt aber nicht stimmig oder falsch)

Und, alle Punkte betreffen nur AddOns, die Standardszenerie ist natürlich sauber aufgebaut und da funktioniert alles.