hmkaiser

Hallo Thomas, dir und euch ebenfalls alles Gute für 2026, dazu wünsche ich auch noch eine Portion Geduld. Es fällt mir auch nicht leicht, konsequent und systematisch immer nur an einer Stellschraube zu drehen, die Kachel neu erzeugen und sicher feststellen, welche Auswirkungen die gerade geänderte Einstellung produziert. Aber nur auf diese Weise lassen sich diese Dinge in den Griff bekommen. Diese Frage lässt ohne konkrete Positionsangabe nicht beantworten! Ich kann nicht vergleichen, wie dieser Ort in meiner Config aussieht. Außerdem - und das ist mir auch wichtig - gibt es dann keine Möglichkeit, ggf. vorhandene Unzulänglichkeiten in OSM zu korrigieren. "Harte Übergänge" stören mich auch, allerdings spielen hier viele Dinge eine Rolle. Im Simulator selbst erzeugst du dir über Tages-, Jahreszeit, Wetter, Betrachtungswinkel, etc., unterschiedlichste Bedingungen. Die Auffälligkeit einer "harten Übergangssituation" tritt meist nur in Verbindung mit einer bestimmten Konstellation, bzw. Betrachungsposition auf, die sich dann aber (leider) fest einbrennt. Dann muss natürlich das Ortho-Foto farblich und im Kontrast das darüber liegende "XPlane-Wasser" in seiner Wirkung betonen. Und schließlich sind aus OSM kommende, schnurgerade Uferlinien wenig hilfreich. Du erzeugst deine Ortho-Kacheln mit "use_masks_for_inland=yes". Du könntest als erstes probieren, "mask_zl" auf 15 zu setzen. Dadurch werden die Masken zur Abdeckung der Gewässer-Bereiche in den Orthofotos feiner. Dann würde ich wie folgt priorisieren: Ist der "harte Übergang" nur in bestimmte Konstellation sichtbar, auf's Ganze gesehen aber tolerierbar? Kann eine neu erstellte Ortho-Kachel, erzeugt mit anderer "Imagery", helfen? In OSM gerade Ufer-Linien verfeinern, danach die Kachel, inkl. Neu-Download der OSM-Daten per "Assemble Vector data", neu erzeugen.

Das ist vermutlich eher dem Umstand geschuldet, dass simHeaven+XP12.4.0b1 aus einer deutlich "schwächeren" fps-Position startet, als der Vanilla-Simulator. Allerdings fordert simHeaven in Hinblick auf die exorbitant erhöhte Anzahl darzustellender Objekte, mehr Leistung an bestimmten Stellen, als das, was XP12-Standard benötigt. Insofern könnte es hier einen Dämpfer geben Bei mir hat 12.4.0b1 unter gleichen Bedingungen mehr als 15% zusätzlichen Schub bekommen. XPlane starte ich (damit die Graka mich nicht mit Getöse nervt) mit --lock_fr=35. Die werden im laufenden Betrieb auch nicht mehr unterschritten. Dazu konnte ich mir jetzt ungestraft erlauben, MSAA eine Stufe anzuheben. Ich verwende einen UWQHD-Monitor mit 3440x1440 pix-Auflösung. Meine Einstellungen: Die Schattenqualität bleibt bei mir (ich sehe da kaum zusätzlichen Nutzen) immer auf Mittel. Beim Thema "Rendererentfernung" habe ich intensiv probiert, aber bei 2 Meter Abstand zum Monitor keinen Unterschied zwischen Maximum und hoch entdecken können. Also bleibt es bei "hoch", die CPU dankt es mir mit 1-2 frames Speicher-Laufwerke sind, sofern SSD im Einsatz sind, aus meiner Sicht im Moment eher weniger relevant: Ich habe 2 Stück m.2-SSD an jeweils 4 freien PCIe-Lanes hängen. Außer den von der Graka beanspruchten 16 PCIe-Lanes gibt es keine weitere Hardware an irgend einer Lane. Simulator und O4XP-Kacheln habe ich dazu auf jeweils einer der beiden SSD getrennt gespeichert und so theoretisch noch einmal Schub gegeben. Beim Start saugt XP12 knapp 20GB ins RAM, die Ladezeit muss ich aber immer noch in Minuten angegeben. Da wird deutlich, wie XPlane an den Vektor-Daten aus den O4XP-Kacheln zu knabbern hat. Falls du ZL=17 verwendest, könnte ein Test mit ZL=16 hilfreich sein.

Ich bin letztlich bei mask_width=10 und ratio_water=0.55 gelandet: Das ergibt den nur für meine Augen besten Kompomiss. Ausschlaggebend war dabei, dass schmale, oder klare, hier besonders Gebirgs-Gewässer, Wassereffekte zeigen. Dazu habe ich mir beispielhaft Szenen in Wilhelmshaven (Innenhafen), entlang des Lech (Reutte-Höfen), des Rheindeltas am Bodensee und des Mains, Raum Würzburg, angesehen. Außerdem möchte ich mittig die Fluss-Wasserflächen frei von Foto-Schiffen, Foto-Schatten sehen, dazu sollten sich im Gewässerverlauf keine "Brüche" entlang von Ortho-Foto-Grenzen zeigen. Dazu habe ich - das kann man schon so sagen - jahrelang mit verschiedenen Einstellungen gespielt und an Rhein und Elbe zwischen Cuxhaven und HH ausprobiert. Dafür muss ich in Kauf nehmen, dass insbesondere dem Wattenmeer der typische "Meeresgrund" fehlt und eben gerade Linien an den Gewässerrändern ins Auge springen. Ob das aber das Ende der Tüftelei ist, kann ich nicht sagen.

jedenfalls das als Kontrast: es fehlen die GK-VFR-Brücken (samt Foto-Schatten), dafür aber mit winterlich aktuell besser passenden "Laub"-freien Laubbäumen, Und dann mal der Blick von oben: Alles in ZL16, ohne GO2, dafür in @EUR. Gerade Uferlinien sind dann natürlich ein Thema, aber die lassen sich in OSM feiner gestalten ... und stehen dann sofort für eine neu Ortho4XP-Kachel zur Verfügung. Leider gibt es nicht "die eine" Lösung. Euch allen ein frohes Weihnachtsfest!

Das sind die "Kleinigkeiten", auf die man sich in Linux einlassen muss. Als Dank dafür bekommt man ein schlankes, von jedem unnützen Ballast befreites System und - so meine Wahrnehmung - sogar 3,4 Frames dazu.

Dann musst du prüfen, ob, bzw. wo "sasl" installiert ist. Ich habe das leider nicht auf meinem Rechner, kann also nicht prüfen. Möglich ist auch, dass sich das "sasl"-PlugIn direkt im betreffenden Aircraft-Verzeichnis befindet. Dann müsste "ldd" dort entsprechend laufen.

Die "sound bank"-Fehlermeldung tritt nach meiner Erfahrung immer dann auf, wenn ein Flieger nicht aktiviert ist. Gibt es kein "Aktivierungs-Fenster", fehlen wahrscheinlich in deinem Linux noch einige Dinge, die SASL benötigt. Erster Anlauf ist die Prüfung, ob alle notwendigen System-Libs für SASL installiert sind. Das lässt sich für das SASL-Linux-PlugIn "lin.xpl" einfach feststellen: Dazu in ../X-Plane12/Resources ein Terminal-Fenster öffnen und per ldd-Anweisung "ldd plugins/sasl/64/lin.xpl" checken, welche Libs benötigt werden. Fehlt etwas, gibt es einen Hinweis ".. not found". Außerdem ist es vorteilhaft, XPlane aus der Konsole heraus zu starten. Probleme, die das Betriebssystem tangieren, werden dir so in dem Terminal-Fenster angezeigt. In meinem Mint-XFCE kann ich dazu im Starter "X-Plane 12.desktop", Reiter "Starter", die Option "im Terminal ausführen" ankreuzen. Und nebenbei rate ich jedem Linux-User dazu, den Standard-XPlane-Installationsordner "X-Plane 12" in "X-Plane12" zu ändern. Es gibt einige PlugIns, die sich an dem Leerzeichen stören.

Hallo Micha, es gibt hier noch einen anderen, in meinen Augen bedeutenden Aspekt: Das zum Betrieb der AFL King Air 350 benötigte xjet-PlugIn ist ein - gelinde gesagt - problematisches Konstrukt. Extrem negativ fällt mir auf die Füße, dass xjet in Java geschrieben ist, aus einem riesigen, unübersichtlichen Code-Sammelsurium besteht und während der Laufzeit von XPlane, mit der schon anspruchsvollen King Air 350 selbst, über den Java-Interpreter läuft. Mich würde es nicht überraschen, wenn einige der von Dir beschriebenen Performance-Probleme, diesem Umfeld zuzuschreiben wären. Näherungsweise ließe sich das auch durch Test-Flüge mit einem anderen Flieger, aber voll aktivierten Orth4XP-Kacheln abschätzen. Ich bin gebranntes Kind, weil die wesentlichen zur Verfügung stehenden "OSM- in XP.dsf"-Umsetzungs-Tools in Java geschrieben sind. Da steht Java für "extrem Langsam und RAM-hungrig", für mich verbunden mit einer Menge zusätzlicher Arbeit! Ich habe mir leider kürzlich die AFL KA 350 gegönnt, allerdings habe ich den Vogel gleich wieder den Hangar geschoben, weil mir xjet in meinem Mint 22.2-System die gesamte XPlane-Beleuchtung und Kalibrierung meiner Pedals reproduzierbar zerschießt.

Es sind nur relativ wenige Dinge nötig, um länderspezifische Besonderheiten zu betonen. Über die Lib_EU_net_RoadTraffic sind ab sofort ein mobiles DHL-Fahrzeug und ein baugleiches Modell von DPD, zusätzlich zu einem bereits vorhandenen TNT-Fahrzeug, für Paket-Auslieferungen zuständig. https://drive.google.com/drive/folders/1P9Ym7UNclnBG0lHcwsN1uPKdFH8WNX-k?dmr=1&ec=wgc-drive-hero-goto

Nach Durchsicht einer log.txt noch einmal der Hinweis, dass X-World_Europe-8-expnetwork eine komplett neu abgestimmte Straßen- und damit Szenerie-Beleuchtung beinhaltet. Separate Mod-AddOns für europäische Straßen werden nicht mehr benötigt und sollten, um unerwünschte Überlagerungen auszuschließen, nicht verwendet werden. In Hinblick auf das von mir nicht verwendete Tool "Xroads", vermute ich anhand der Beschreibung, das ein gleichzeitiger Einsatz zusammen mit X-World_Europe-8-expnetwork nicht möglich ist. "Xroads" erzeugt demnach eigene roads.net-Vorschriften, die das durch X-World_Europe-8-expnetwork eingeführte Regelwerk wieder komplett außer Kraft setzen dürfte. Transparente Straßen stehen noch auf meiner Agenda.

Dein PC dürfte nicht das Problem sein, ich benutze eine etwa gleich schnelle AMD 7600X3D-CPU, dazu eine RTX 3080 mit nur 10GB VRAM. Zusammen mit meinem 3440x1440 Monitor sacken meine Frames nur in ganz seltenen Fällen bis auf 28 ab. Ruckler gibt es aber überhaupt nicht. Dabei habe ich mit Ausnahme RCAS (aus), Schattenqualität (mittel), Rendererentfernung (hoch) und 2xMSAA-Antialiasing alle Regler rechts. XPlane ist aber nicht alleine auf dem PC unterwegs. Das Betriebssystem selbst belegt über eine Vielzahl aktiv laufender Prozesse ebenfalls die Ressourcen deines PC. Kommen dann noch weitere, automatisch gestartete Programme hinzu, kann es vereinfacht gesprochen dazu kommen, dass z.B. mehrere Anforderungen gleichzeitig den Hauptspeicher, oder Laufwerke in Beschlag nehmen wollen und das Betriebssystem dann regeln muss, wer zuerst dran kommt und wer warten muss. Für mich ist immer besonders wichtig, meinen Flusi-PC (ja der ist nur dazu da) vollständig von allen Prozessen, Diensten, Tools, Virenscannern, etc., zu befreien, die nichts mit XPlane zu tun haben. Du hast deinen externen Virenscanner deinstalliert. Das könnte bedeuten, dass der Windows-Virenscanner jetzt (oder immer noch) aktiv ist. Du könntest als erstes prüfen, ob die XPlane-Verzeichnisse ausgeklammert sind. Und dann über den Taskmanger gucken, was alles so läuft. Da lassen sich einzelne Prozesse über die rechte Maustaste auch direkt killen.

Wichtig ist natürlich auch, dass es eine zufällig gemischte, ausreichende Varianz an Objekten gibt. Es soll ja alles so authentisch wie möglich wirken, trotz etlicher Unzulänglichkeiten, die ich nicht ändern kann. Hier begegnen sich Personen-Fähre und Binnen-Containerfrachter. Beide Schiffe fahren dabei auf unterschiedlichen Wasserstraßen.

Nein, aber der Schiffsverkehr wird dynamisch sein: Andre testet gerade meinen aktuellen Arbeitsstand. Mittlerweile habe ich zu jedem Wasserstraßen-Typ mindestens einen passenden Objekt-Typ. Es geht jetzt u.a. darum, richtig abzumischen. Hört sich einfach an, ist aber sehr schwierig, weil sich die Schiffsobjekte sehr langsam bewegen, XPlane in bestimmten Abständen, an bestimmten Punkte, Autogen-Objekte injiziert. So war vorhin in Wesel relativ wenig los, obwohl hier gerade ein Motoboot flussaufwärts fahrend, einem Frachter begegnet. Allein das Setzen der Positionslichter, Mast-Beleuchtung, hat mir weit mehr als eine Woche Arbeitszeit abverlangt.

Ich hatte mich auf deine Vermutung in Richtung der AS-EDDB und AS-EDDH bezogen. Beide Sceneries laufen bei mir unauffällig. Zumindest aber hast du jetzt nichts mehr von "Aussetzern" geschrieben.

Die sind auch, allerdings völlig unauffällig, zusammen mit den Ortho-Kacheln, simheaven, meinen exp-Layern in meiner Config. Ich glaube nicht, dass hier die Ursache deiner FPS-Aussetzer liegt. Der Rat von @Guenni99zeigt in die richtige Richtung: Im Win-Betriebssystem sind jede Menge Ressourcen-Killer versteckt, die XPlane zwischendrin mal auf den Parkplatz schicken können. Gefühlt die Hälfte meiner Flusi-Zeit habe ich damals u.a. damit verbracht, die vielen unnötigen Windows-Dienste, automatisch gestartet, zu bändigen. Den externen Müll will ich gar nicht erwähnen, jedenfalls ist in Windows der Onboard-MS-Virenscanner mehr als ausreichend. Jedenfalls bin ich heilfroh, den Wechsel zu Linux gemacht zu haben: Diese Ärgernisse sind verschwunden, allerdings ärgere ich mich jetzt über den nervtötenden Aufwand, um bewegliche Objekte in XPlane perfekt zu beleuchten ...