hmkaiser

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 ...

Morgens, am 23.11.25, gegen 8:00 Uhr Ortszeit, muss es wohl noch einen Polizei-Einsatz auf der Elbe, unmittelbar westlich Hamburg gegeben haben: Ein Polizeiboot fuhr mit hoher Fahrt einem auslaufenden, kleinerem Containerschiff hinterher. Im unmittelbaren HH-Hafenbereich dagegen normaler Betrieb: Ein Kümo läuft ein, während ein dicker Pott Hamburg Richtung Übersee verlässt. In Koblenz dagegen tuckeln ein Binnenschiffer, gefolgt von einer Personenfähre, auf dem Rhein flussabwärts, während auf der Mosel gerade ein Flusskreuzfahrer in der Schleuse zur Einfahrt in den Rhein angehoben wird, zwei Binnen-Frachtschiffe sich flussaufwärts Richtung Trier auf den Weg machen. Mit der Fähre "Michael", Ingelheim und Oestrich-Winkel verbindend, habe ich schon öfter den Rhein überquert. Deshalb kann die auch in XPlane hin und her fahren. Es könnte bis Weihnachten etwas werden.

Zink betrifft ausschließlich PlugIns, die eine in OpenGL geschriebene Grafikausgabe besitzen. Und das tangiert eigentlich nur AMD-Grafikkarten, weil deren Architektur im direkten Zusammenspiel zwischen Vulkan und OpenGL Nachteile generiert. Zur Verbesserung der AMD-Performance ist daher eine zwischengeschaltete Zink-Bridge hilfreich. nVidia geht in der Einbindung von OpenGL-Code einen eigenen, geschlossenen Weg. Nach meinen Erfahrungen bringt Zink zusammen mit einer nVidia-Karte überhaupt nichts, sondern im Gegenteil nur Nachteile. Ich rate daher davon ab, die Zink-Bridge zu aktivieren, wenn eine nVidia-karte im eigenen Rechner steckt. Die "3D_people_library" ist nur eine Sammlung von Objekten. Die werden vom XP-Vulkan-Renderer, ohne OpenGL zu fragen, direkt auf den Bildschirm geworfen. Die 3D_people_library lässt sich in der library.txt einfach abschalten, in dem die einzelnen people-Objekte mit vorangestelltem "#" deaktiviert, dafür dann das "#" vor der einmaligen Zuordnung "blank.obj" entfernt wird. Wie in der library.txt auch beschrieben.

Hallo Wolfgang, hast du, wie in der Readme_DE.txt beschrieben, die notwendigen symbolischen Links erzeugt? Du kannst außerdem in "Screenshot.jpg" sehen, wie nach Erzeugung der noch benötigten Links, das Verzeichnis ../X-World_Highway_Library/ aussehen muss.

Es steht ein neues Update der X-World_Highway_Library zum Download bereit. Zwei wesentliche Änderungen sind darin eingeflossen: Korrektur eines Darstellungsfehlers ausgelöst durch eine falsche Anweisung für das Rendern lokaler Einbahnstraßen Übernahme der aktuellen LR-Shader-Definitionen für das gesamte network. Dadurch werden jetzt auch nasse Autobahnen (Motorways) dargestellt. Der November kommt in den Simulator Und soviel sei verraten: Ich arbeite seit einigen Wochen an einer größeren Baustelle und hoffe, die in meinen Augen letzte "Fähigkeits-Lücke" des noch aus dem XPlane10-Zyklus stammenden networks schließen zu können. Ich brauche aber noch etwas Zeit.

In der library.txt der X-World_Highway_Library finden sich entsprechende Hinweise. Man kann die verwendeten "3D-People-".obj teilweise, oder vollständig durch Austausch gegen "blank.obj" ausknipsen. Genau so einfach, lassen sich auch "3D-People"-Objekte gegen andere austauschen. Ich habe passenderweise am 6.11. die X-World_Highway_Library aktualisisiert, weil in der Vorversion "blank.obj" im Stammverzeichnis fehlte. Über die 3D-People, wie auch den Shrubs entlang von Straßen außerhalb der Ortschaften, möchte ich einfach nur lineare Strukturen "aufreißen". Durch das völlig zufällige Auftauchen dieser Objekte, werden die darunter liegenden, öden XP-Straßensegmente "aufgelockert" und verlieren dadurch ihre linearen, "Lego-Beton-Baukasten-Charme". Technisch wäre das überhaupt kein Problem, aber Arbeitsaufwand und Nutzen stehen an dieser Stelle in keinem (jedenfalls für mich) erträglichen Verhältnis. Ich differenziere ja bereits in mehrere 3D-People-Objekt-Gruppen: Auf den Bürgersteigen entlang von secondary-Straßen ist die Abmischung der "3D-People" eine andere, als z.B. bei "highways", die über OSM als Fußgänger-, oder Fahrrad-Weg in das expnetwork einfließen. Anders sieht es bei den Autogen-Fahrzeugen, bzw. Autogen-Zügen aus: Da sind regionale Kachel-Zonen definiert, die z.B. mit typischen regionalen Einsatz-Fahrzeugen ausgestattet werden können. In den Deutschand-Kacheln verwende ich z.B. "Polizei", "Feuerwehr"-Fahrzeuge, während außerhalb dieser Kacheln die Standard-"Police"-Autos erscheinen. In GB sehen die Züge anders aus, als in D. Könnt ihr mal gucken. Na ja und dass über den expnetwork-Layer z.B. in GB konsequent Linksverkehr realisiert ist, dürfte schon lange bekannt sein.

Eine neue Version von X-World_Europe-8-expnetwork steht zum Download auf https://drive.google.com/drive/folders/1P9Ym7UNclnBG0lHcwsN1uPKdFH8WNX-k?dmr=1&ec=wgc-drive-hero-goto zur Verfügung. Neben der aktuellen OSM-Datenbasis vom 04.11.2025, sind in der Umsetzung für XP12 einige Korrekturen, aber auch kleinere Optimierungen eingeflossen, die zwar nicht immer unmittelbar auffällig sind, 8-expnetwork aber weiter "abrunden". Wesentlich sind aber etliche Ergänzungen "unter der Haube", die allerdings erst mit dem kommenden Update der X-World_Highway_Library das Licht der Welt erblicken werden.

Damit handelt es sich eindeutig um eine spezielle Geschichte, die nur Deinen Computer, bzw. die Software-Installation auf Deinem Computer betrifft ... und das ist gut, weil änderbar. Als erstes würde ich prüfen, ob die CPU-Temperatur dieses Verhalten auslöst. Dazu das PC-Gehäuse komplett öffnen, dann XPlane, parallel dazu CPU-Z, oder ein ähnliches Tool, starten, um während der Ausführung von XPlane die Entwicklung der CPU-Temperatur im Auge zu behalten. Sowohl CPU, als auch GPU, werden i.d.R. während des Betriebs gedrosselt, sobald die Temperatur einen bestimmten Grenzwert übersteigt. Der 7900X kann, wenn ich das noch richtig im Kopf habe, 170 Watt Wärmeleistung produzieren, die sicher abgeführt werden müssen. Mein 7600X3D begnügt sich mit deutlich weniger, trotzdem ist mein PC-Gehäuse immer offen. Führt das nicht zum Erfolg, müssten danach aus der XPlane-Installation alle Plugins entfernt werden, die nicht zum Standard gehören. Anschließend sollte XPlane zusammen mit dem Task-Manager laufen, wobei über den Task-Manager beobachtet werden kann, welcher Prozess wann wieviel CPU-Leistung beansprucht.

Der neue Installer verlangt mindestens für die Ausführung der Funktion "Szenerie online aktualisieren" ein vorhandenes X-Plane-Konto. Deshalb geht bei mir die alte Version noch einmal in die Verlängerung.

Ich hätte besser formulieren müssen: Es sind wie hier meist keine "Fehler", sondern nicht ausreichende Spezifizierung, die am Ende ein ungünstiges Resultat produzieren. Die highways innerhalb des Flughafen-Areals waren formal völlig korrekt als normale Straßen, ausschließlich als "unclassified" deklariert. Besser wäre gewesen, wenn die betreffenden Straßen in die überlicherweise an solchen Orten verwendete highway-Klasse "Service", eingeordnet wären. Und wenn man es genau nimmt, darf der Hinweis auf die Zugangsbeschränkung für den öffentlichen Verkehr, z.B. per "access=private", auch nicht fehlen.

Den habe ich in OSM korrigiert: Falsche Straßen innerhalb des Flughafen-Areals. Mit dem nächsten Update wird es besser. Es gibt soviel zu tun ...

Hallo Micha, DRT ist ein "normales" PlugIn, läuft also während der Ausführung von XP permanent im Hintergrund. Nach dem Update sind die Frames bei mir abgesackt, dazu dann die Ruckler. Über den XP12-VRAM-Profiler war sofort erkennbar, dass etwas nicht stimmt. XP12 verlangte deutlich mehr VRAM und schob dazu auch noch einige GB ins RAM. Im log.txt fanden sich ungewöhnliche Einträge auf DRT i.V. mit der ausgewählten Standard-C172. Ich habe allerdings nicht lange gefackelt, DRT 2.5.0 gegen die Vorversion 2.4.1 getauscht und alles ist wieder gut. Im Nachgang habe einen Hinweis auf ein "DRT-VRAM-Leck" in einem Post zum Update auf XP12.3.0b6 im Org-Forum gelesen. Bei mir steht die Zibo seit Jahren im Hangar, bin aber schon lange damit nicht mehr geflogen. Mir sind aber keine besonderen Probleme in der Kombination DRT-Zibo bekannt. Und im Org-Zibo-Forum werden diverse Einstellung per DRT laufend diskutiert. Gibt es eventuell in deiner log.txt einen Hinweis?

Ein Kampf gegen Windmühlen-Flügel. Ich muss ja irgendwie "zum Loche raus" und entscheiden, ob OSM "highway=service" in die Übernahme-Prozeduren nach XP aufgenommen werden, oder nicht. Gefühlt gibt es mit >98% der innerhalb von Airport-Arealen enthaltenen "highway=service" keine Problem, weil die mit einer Zugangs-Einschänkung wie "access=private" ausgetattet sind. Und das kann ich ausfiltern. Ist aber nichts eingetragen, ...

Das aktuelle DataRefTool 2.5.0 verträgt sich nicht mit meinem XP12.3.0b6 unter Linux Mint 22.2. Es gibt ein reproduzierbares VRAM-Leck, XPlane reduziert automatisch die Texture-Auflösung, in Summe fehlen bis zu 10 fps. Dazu gibt es auch eine deutliche Ruckelei. Das DataRefTool 2.4.1 läuft dagegen problemlos.

Hallo Bernd, sorry, ich hatte den Leuten vor Ort verraten, dass du heute in LFRS erwartet wirst Spaß beiseite: Wie immer sind es die Probleme mit der Datenbasis. Einige der im Airport-Areal befindlichen "highway=service", sind nicht mit den hier erforderlichen Keys für einen eingeschränkten Zugang, z.B. "access=private", ausgestattet. Dadurch landen bei Überleitung in eine .dsf, diese Straßen in der falschen Schublade. Nach dem nächsten Update ist das erledigt.

Du sprichst mir aus der Seele! Ein Grundverständnis für die hierarchische Aufbau-Struktur des XPlane-Scenery-Systems, ist aus meiner Sicht von großem Vorteil. Tools wie den Organizer betrachte ich daher als kontraproduktiv, weil sie verhindern, dass man sich mit dieser Thematik auseinander setzt. Bei mir schwirren Tools ohne Ende durch die Computer, aber die scenery_packs.ini bekommt nur mein Editor zu Gesicht.

Die Wieder-Aufforstung östlich Neheim ist abgeschlossen Anliegend die Kachel +51+007 zum Austausch gegen die alte Kachel in .../X-World_Europe-7-expforests/Earth nav data/+50+000/ Parallel habe ich "X-World_Europe-7-expforests" in meinem Google-Drive-Verzeichnis aktualisiert. Es dürften sicherlich noch weitere Flächen fehlen. Sofern das aber nicht allzu auffällig ist, würde ich Korrekturen "gesammelt" erst mit dem nächsten Update einfließen lassen. Es gibt, wie an obigem Screenshot erkennbar ist, noch großes "Präzisierungs"-Potential an der Quelle. +51+007.dsf.zip

Kommt diesmal zwar nicht aus dem Verkehrsstudio, aber die Kachel +54+010 ist wieder für den Auto- und Schienenverkehr freigegeben. Die Ursache ließ sich zwar leicht lokalisieren, allerdings - und das ist schon etwas fies - nur durch die Isolierung auf den 10ten Längengrad. Damit ich das network erzeugen kann, muss jeder Kontinent in Längengrad-Einzelstreifen aufgeteilt werden. Nur in diesen Streifen lässt sich die extrem RAM-hungrige Java-App osm2xp zu einer erträglichen Mitarbeit überreden. Beim Aufteilen in Längengrad-Streifen werden allerdings OSM-Vektoren, die sich über mehrere Längengrade erstrecken, komplett mit in diesen Streifen-Datensatz aufgenommen. Ich muss daher nach erfolgter Überführung in das network, alle unvollständig erzeugten .dsf-Kacheln, die nicht zu dem gerade betrachteten Längengrad-Streifen gehören, gleich wieder löschen. Dazu habe ich mir ein Linux-Shellscript gebastelt, das mir Längengrad-streifenweise diese zusätzlichen Fremd-Kacheln löscht und die dann verbliebenen, zum betrachteten Längengrad gehörenden Kacheln in den Ordner .../X-World_Europe-8-expnetwork/Earth nav data/"Earth nav data/ schieben soll. Zum Herausfiltern der nicht erwünschten Nachbar-Kacheln hatte ich +- 5 Längengrade vorgesehen, also guckt das Shellscript bei Betrachten des Lübeck-Längengrad-Streifens +010, ob Kacheln von +005 - +009 und Kacheln +11 - +015 da sind und löscht diese. Abschließend werden alle verbliebenden Kacheln des Streifens +010 nach expnetwork kopiert. Die jetzt verwendeten OSM-Daten vom 08.10., haben aber in der Kachel +54+010 Vektoren geliefert, die bis in den Kachelstreifen +017 reichten, umgekehrt dann eine Kachel in Streifen +017 den gleichen Vektor zurück in Kachel +54+010. Damit ist dann die +-5 Längengrad-Toleranz gerissen, die vorab korrekte Kachel +54+010 wurde durch eine nicht gelöschte, fast leere Kachel aus dem Streifen +017 ersetzt. Damit das nicht mehr passiert, ist die Toleranz jetzt auf +-15 Längengrade angehoben und das sollte wohl reichen. Alle network-Kacheln zwischen +000 - +018 sind gerade neu gemacht, das Update von "X-World_Europe-8-expnetwork" steht für euch zum Download zur Verfügung.

Hallo Dirk, herzlichen Dank für Deine Worte und die umfangreiche Rückmeldung! Ganz klar, ohne Euer Feedback habe ich keine Chance, den großen Datenberg auf Vollständigkeit, gravierende Lücken, oder markante Fehler zu prüfen und ggf. zu reparieren. Die expnetwork-Kachel +54+010 ist, wie ich eben leider feststellen musste, komplett leer. Es handelt sich also um einen Fehler bei Erstellung dieser Kachel, oder des Längengrad-Streifens. Ich habe mich aufgemacht und mit der Suche begonnen.