hmkaiser

Das kann ich so nicht ganz nachvollziehen: Fakt ist, dass in Linux-Systemen für alle installierten USB-Devices eine udev-Regel benötigt wird, damit alle, bzw. gewünschten, in dem System definierten User auf das USB-Gerät vollumfänglich zugreifen können. Für die meisten USB-Geräte werden dazu die udev-Regeln im Standard mitgeliefert. Meine Honeycomb-Produkte werden in meiner Linux-Mint Distribution allerdings nicht versorgt und können so nur über einen root-User vollständig angesprochen werden. Das lässt sich aber durch Ergänzung einer udev-Regel einfach ändern, in der die zum Ansprechen des USB-Device notwendigen Zugriffsrechte definiert werden. Meine beiden in /usr/lib/udev/rules.d gespeichertem "Honeycomb"-udev-Regeln, werden bei jedem Start des Systems ausgeführt und sorgen dafür, dass "ich" als Standard-User vollständig auf die USB-Hardware zugreifen kann. Die Erstellung einer Regel ist denkbar einfach: Es müssen lediglich die per "lsusb" (in einem Terminal ausgeführt) angezeigten Werte "idProduct" und "idVendor" ermittelt und in eine neue udev-Regel übernommen werden. Die gewünschten Zugriffsrechte werden unter "MODE", bei mir auch "0666", eingetragen. Jeweils ein schlichter Zweizeiler, das war's. Anliegend meine beiden udev-Regeln. 52-HoneycombAlpha.rules 52-HoneycombBravo.rules

Hallo Ernst, ich habe jedem dass Passwort für HMK_XPNetwork geschickt, der mich wie auch immer darum gebeten hat, nicht aber zwingend an den Fluß eines Geldbetrags geknüpft. Wie einige von euch aus direkten Diskussionen wissen, hatte ich niemals Interesse, HMK_XPNetwork, inkl. der Vorgänger-Versionen, anders als Freeware für euch bereit zu stellen. Aufgrund einiger spezieller Ereignisse und Erfahrungen in diesem Jahr, war das so aber nicht mehr möglich, deshalb blieb nur der auch in meinen Augen nicht ganz glückliche Schritt "Donationware", um einen gewissen Schutz zu erreichen. Als ordentlicher Kaufmann werde ich natürlich jedem mit dem aktuellen, letzten Stand von HMK_XPNetwork versorgen, der darum bittet.

Liebe Freunde, ich muss euch leider mitteilen, dass ich das HMK_XPNetwork-Projekt ab sofort einstelle. Alle Projekt-Archive, die das HMK_XPNetwork-Projekt betreffen, sind aus meinem Google-Drive-Ordner entfernt. Ich möchte mich bei euch allen hier im Forum bedanken. Es hat mir immer viel Freude gemacht, in diesem kleinen, feinen Zirkel unterwegs zu sein. Meine Arbeit nicht nur in diesem Umfeld, habe ich stets unter dem Motto "Ehrenamtlich" verstanden, allerdings ist mir in Hinblick auf "HMK_XPNetwork" dieser Weg seit dem Frühjahr 2026 nicht mehr möglich. Vielen Dank!

Liebe Freunde, ich möchte mich bei euch, meinen verärgerten Usern entschuldigen, dass ich mein eigenes Süppchen koche und nicht akzeptiert habe, dass meine Arbeit jederzeit von jedem, wie auch immer, für eigene Zwecke verwendet werden darf. Ich hätte mich niemals dagegen verwehren dürfen, dass von mir entwickelte, neue Eigenschaften rund um das X-Plane-network nicht frei verfügbar, für eine externe Vermarktung offen stehen. Ich möchte mich dafür entschuldigen, dass ich "HMK_XPNetwork" als "Donationware" deklariert habe, also eine wie auch immer geartete, aber nicht nur monetäre "Donation" von euch verlangt habe. Es ist mir sehr unangenehm, dass ich die Integration, sprich das Kopieren meiner network-Entwicklungen in fremde, kommerzielle Angebote, als "nicht normale Aktivität" betrachtet habe. Ich bedauere außerdem, dass ich es gewagt habe, Arbeiten fremder Dritter an der Modellierung von Stromkabeln und Seilbahnen aus XP11-Zeiten in mein HMK_XPNetwork völlig unbedacht, ohne Notwendigkeit, aber textlich kenntlich gemacht, in meine Arbeit aufgenommen zu haben. Alles in allem habe ich aber profunden Beistand ...

Liebe Freunde, ich habe mir eben X-World Pro gekauft und installiert und muss feststellen, dass wesentliche Teile und Features aus meinem HMK_XPNetwork-Paket darin enthalten sind, ohne das es dazu eine Vereinbarung gibt, oder dies von mir in irgendeiner Form authorisiert worden wäre. X-Plane steht für ein sehr offenes System. Viele Dinge, gerade rund um das Scenery-Design sind für uns User völlig transparent sicht- und nachvollziehbar, damit auch einfach kopierbar. Ich habe seit über 2 Jahren nahezu täglich und mehrstündig an der Entwicklung meines Network-Projekts, vor allem Dank eurer tollen Rückmeldungen mit (meist) viel Freude gearbeitet, natürlich auch, weil ich immer wieder einen deutlichen Mehrwert für mich und meinen Simulator gesehen habe. Mir wird aber jetzt meine Arbeit einfach so weggenommen. Es macht daher keinen Sinn mehr, an Dingen weiterzuarbeiten, die bei nächster Gelegenheit anderswo auftauchen, dann auch noch zu Gunsten fremder Dritter verkauft werden. Es ist mehr als bedauerlich.

Hallo Bernd, das ist natürlich eine gute Idee ... würde aber eine Reihe von Nachteilen produzieren. Mir ist wichtig, dass mein HMK_XPNetwork innerhalb einer Kachel unterbrechungsfrei bleibt. Nur auf diese Weise lässt sich durchgängiger, fließender Verkehr realisieren. Würde man eine "NoGo-Area" über einen Airport legen, würden betreffende OSM-Straßen, darauf verlaufender Traffic, aber auch die statischen Elemente und ggf. die Beleuchtung wären abgeschnitten. Stellt man sich dazu einen Parkplatz vor, der außerhalb eines Airports gerade zur Hälfte in die "NoGo"-Area hineinragt ... Ich hatte mir schon überlegt, OSM-"aeroway=aerodrome"-Flächen dazu heranzuziehen. Aber leider sind diese Flächen an bestimmten Punkten auch oft so grob abgefasst, dass "Rest"-Bereiche des öffentlichen Straßenverkehrs bereits innerhalb, anderseits nicht-öffentliche Service-Straßen teilweise noch außerhalb der OSM-Fläche angesiedelt sind. Stimmen dazu dann auch die zugewiesenen Eigenschaften eines einzelnen "highway" nicht, passt nichts mehr. Es macht aber einen sichtbaren Unterschied, ob der ein Airport-Terminal versorgende Highway Bestandteil von HMK_XPNetwork ist, oder nicht. Dazu kommt, dass ich mir über die OSM-Straßen auch das Beleuchtungsmodell für die Scenery erzeuge. Die sind gerade im unmittelbaren, äußeren Umfeld eines Airports (Parkplätze) besonders wichtig, oftmals leider auch vom gleichen Typ, wie die Straßen, die in OSM innerhalb einer "aeroway=aerodrome"-Fläche verwendet werden. Egal wie ich bisher das Blatt auch gewendet hatte: Eine eierlegende Wollmilchsau ist mir noch nicht auf die Füße gefallen, obwohl mich diese Dinge besonders nerven. Ich habe mittlerweile eine Reihe zusätzlicher Kriterien in meine Überleitungsregeln eingebaut, die mit dem nächsten Update eine weitere, deutliche Reduktion fehlgeleiteter Trecker, Fahrzeuge, Passanten, nicht nur innerhalb von OSM-"aeroway=aerodrome"-Arealen bringen wird. Und die werde ich anhand Deiner Beispiele auf Wirksamkeit überprüfen. Danke!

Meine letzte "Kachel-Auffrischung" habe ich rund um den Jahreswechsel 25/26 gemacht und da lief die OSM-Abfrage über Ortho4XP noch durch. Ortho4XP generiert beim Erzeugen einer Kachel eine "Overpass"-Abfrage, die dann an OSM zur Datenselektion übergeben wird. Vermutlich blocken die OSM-Macher Abfragen, die "von der Seite" kommen. Zur Zeit ja noch nicht, weil meine Auffrischungen erst in ein paar Monaten wieder dran sind. Allerdings sehe ich für mich keine Probleme, weil ich ja ohnehin an OSM arbeite, die Datenbank-Extrakte von Geofabrik und auch die Tools (Osmium) zur Offline-Bearbeitung von OSM-Extrakten verwende. In Hinblick auf die Geofabrik-Datensätze fehlt mir nur ein Script zur automatischen Erzeugung der jeweils von Ortho4XP benötigten 5 einzelnen Auszüge. Das würde ich mir schnell zusammenbraten, wenn es soweit ist. Allerdings bin ich ja in Linux zuhause. Für eine einzelne Kachel könnte man zur Not auch die Overpass-Abfrage in JOSM nutzen. Darin müssten dann der Reihe nach die 5 einzelnen Datenselektionen mit den unterschiedlichen Selektions-Kriterien ablaufen und unter dem Ortho4XP-konformen Namen/Format gespeichert werden. Ich mache das in dieser Weise für meine laufenden network-Test-Arbeiten.

Ein kleiner Nachteil ist, dass die angebotenen pre-baked OSM-Daten wohl erst einmal auf dem Stand vom 24.07.2026 stehen werden. Seit Jahren erzeuge ich mir meine "Kern-Kacheln" für Mittel- und Westeuropa meist rund um den Jahreswechsel neu, ausschließlich weil sich die OSM-Datenbasis stetig verbessert und mehr Details liefert. Insbesondere Gewässer, Uferlinien punkten in den O4XP-Kacheln, bzw. der gesamten XP-Landschaft stark, wenn anstelle z.B. einer vorher nur über 4 Eckpunkte erfassten, rechteckigen OSM-"natural=water"-Fläche, detaillierte Uferlinien zur Verarbeitung kommen.

Es ist da einiges in Bewegung, z.B. https://forums.x-plane.org/forums/topic/349696-is-this-the-end-of-ortho4xp/, wobei die einzelnen Projekte unterschiedliche Aspekte in den Fokus nehmen. Für mich war der Ansatz von @CheckCanopy erst einmal interessant, weil darin die aktuelle OSM-Verfügbarkeits-Klippe auf simpelste Weise geschliffen wird.

Du nicht, aber ich: Da habe ich völlig falsch formuliert: Nach dem Speichern der extern gelieferten OSM-Daten dürfen diese Daten vor Erzeugen einer neuen Kachel nicht per "Erase cached data" gelöscht werden. Der Schritt "Assemble Vector Data" muss aber zwingend ausgeführt werden. Wie bei den .hgt-Höhendaten diskutiert, verwendet Ortho4XP immer bereits gespeicherte, als im Cache befindliche Daten, statt diese Daten über das Netz nachzuladen. Sorry! Da kann ich leider keine Antwort geben, weil ich aktuell noch keine Kachel mit diesen "Pre-baked"-OSM-Daten erzeugt habe. Ich vermute, dass die Abfrage zur Selektion der "pre-baked"-OSM-Daten einfach nur präziser abgefasst ist. Ich gucke mir in den kommenden Tagen mal einen "pre-baked"-OSM-Satz per JOSM an. Mal sehen, ob ein Vergleich mit den von Ortho4XP gezogenen OSM-Daten etwas zeigt. Allerdings hocke ich gerade noch in größeren network-Untiefen.

Hallo Michael, das Problem ist bekannt und beschäftigt einige XPlaner u.a. hier https://forums.x-plane.org/forums/topic/347657-osm-server-rejections-galore-lately-stale-settings/ Insbesondere dank @CheckCanopy gibt es eine Lösung, an die von Ortho4XP benötigten OSM-Daten anderweitig zu gelangen. Dazu müssen die 5 einzeln benötigten OSM-Datensätze "..._airports.osm.bz2", "..._big_roads.osm.bz2", "..._coastline.osm.bz2", "..._small_roads.osm.bz2", "..._water.osm.bz2" vorab aus dem Internet gezogen und in den passenden Ortho4XP-Subverzeichnissen ".../OSM_data/xxx_yyyyy/" gespeichert werden. Das einzeln, oder per Batch über Ortho4XP angeschobene Erzeugen einer Kachel, erfolgt dann unter Auslassung(!) des ersten Schritts "Assemble Vector Data" von "Erase cached data - OSM data". Ortho4XP greift dann auf die vorab gespeicherten OSM-Datensätze zu, die restlichen Arbeitsschritte bleiben wie gehabt. Unter https://xpconnect.me/orthoforge-data.html stehen bereits aktuelle OSM-Datensätze als "Pre-baked OSM-Data-Tiles"für eine direkte Verwendung in Ortho4XP zur Verfügung.

Ich habe bisher außerhalb "Autobahnen" auf die Verwendung 4+x-spuriger Straßen-Modelle, bzw. 2+x-spuriger Einbahnstraßen-Modelle, in HMK_XPNetwork-Europe verzichtet. Diese Straßen weisen eine erhebliche Breite auf und produzieren tendenziell den Effekt "übereinander gestapelter Straßen". Aktuell arbeite ich an einer deutlichen Verschlankung dieser Straßen-Modelle und neu abgefassten Regeln, ab wann diese Straßen in der Überleitung zugewiesen werden. Im Bild mein aktueller Arbeitsstand am Beispiel der B 431, Osdorfer Landstraße, zwischen Iserbrook und Osdorf, Hamburg. Im unteren Bereich liefert OSM eine einzelne Straße mit 4 Fahrspuren, im oberen Bereich (Osdorf) sind es zwei einzelne Einbahn-Straßen mit 2 Fahrspuren, wobei sich im Verlauf der B 431 dieses Wechselspiel laufend wiederholt. Einige Straßen-Anbindungen sehen schon ganz gut aus, andere sind noch nicht so prickelnd. Alleine die Primary-Straßen bestehen aus 20 Varianten, dazu kommt die Interaktion mit allen anderen Straßen-Typen. Ich möchte aber nicht auf diese Varianten komplett verzichten, denn diese markanten "Pfade" sind - aus dem Cockpit betrachtet - schon markante Wegmarken.

The new XPNetwork for Europe is available.Perfect dynamics in the XPlane 12 Europe world based on a new, up-to-date and complete network of roads, railways and waterways. HMK_XPNetwork-Europe delivers a new level of realism for XP12-Europe: A detailed, continuous road network based on the OSM database, as of April 01, 2026, consisting of motorways, expressways, primary, secondary, tertiary and other roads, plus graphically redesigned road types for e.g. residential areas, or raceways. Realistic left- or right-hand traffic on the level of a 1° x 1° tile. Additional static elements such as parked vehicles, pedestrians, bushes, etc. Additional dynamic autogen car objects for Europe, varied driving speeds for dynamic autogen objects. Near-perfect realistic scenery lighting Train traffic, including additional dynamic autogen rail objects moving at varying speeds, as well as static elements such as stationary railcars, bushes, etc. Differentiated maritime, ferry, and inland waterway traffic using over 150 vessel objects. More Screenshots are available here https://drive.google.com/drive/folders/1cWiJBNag50H85KeYUbdIUbvIZFCi7qqV?dmr=1&ec=wgc-drive-hero-goto HMK_XPNetwork-Europe is donationware, so I ask for a donation of any kind before I will send the password to unzip the two main archives. All packages - such as the flyer containing additional information - are available for download here: https://drive.google.com/drive/folders/1P9Ym7UNclnBG0lHcwsN1uPKdFH8WNX-k?dmr=1&ec=wgc-drive-hero-goto. The HMK_XPNetwork-Europe scenery system consists of more than 1,600 .dsf tiles along with the specifications and objects contained in the HMK_Network_Library. In addition, the HMK_XPN_LocalAdds_Library is optionally available for local variations, such as country-specific police vehicles. Installation information in the form of .txt files is included with every .zip archive. I have been working on this project for more than two years and am constantly active on the "German side" here: https://forum.aerosoft.com/index.php?/topic/184997-xpnetwork-europa/

Ein kleiner Blick ins Nähkästchen: OSM liefert in etlichen Fällen nicht die Informationen, die das Vorhandensein, oder auch Nicht-Vorhandensein einer bestimmten Eigenschaft eindeutig und konsistent über den gesamten Datenbestand aufzeigt. Das trifft z.B. auf das Thema "Straßenbeleuchtung" zu. Zwar gibt es dafür in der OSM-Welt einen Schlüssel, allerdings wird der nicht durchgängig verwendet. Damit das Bild in X-Plane trotzdem einigermaßen stimmig ist, muss ich über Umwege versuchen, Lücken zu füllen, wobei "Umwege" das Verwenden mehrerer andere Schlüssel meint, die mit dem eigentlichen Thema eigentlich gar nichts zu tun haben. In Hamburg (meine Testwiese), umschließt die Straße "Am Rosengarten" unmittelbar das Südwest-Ende von EDHI. Und die ist - das ist mir direkt ins Auge gefallen - leider zu großzügig mit einer Straßenbeleuchtung versehen worden. Dazu kommt (das fällt einem danach auf), dass die komplexe Kreuzung "An der alten Süderelbe"-"Nesseldeich"-"Am Rosengarten", aus mehreren unterschiedlichen Straßentypen besteht, die "unglücklich" zusammengesetzt sind. Ich habe schon einige Zeit gebastelt, um die Trefferquote für die Ergänzung von Eigenschaften zu verbessern, bzw. näher an die Realität zu rücken. Der Blick auf den aktuellen Projektstand zeigt, dass mit meinen aktuellen Test-Übernahme-Regeln die Straße "Am Rosengarten" frei von Lampen, Fußgängern und geparkten Fahrzeugen ist. Die Kreuzung sieht auch deutlich "schlanker" aus, wenn auch noch nicht perfekt. Jetzt kommt es darauf an, dass nicht nur im Detail, sondern im großen Bild die Dinge in die richtige Richtung gehen.

Eine Kleinigkeit habe ich übersehen: Autogen-Fahrzeuge zweier Fahrzeug-Mischungen haben sich im gestrigen Update der HMK_XPNetwork_Library nicht an örtliche 50 kmh-Geschwindigkeitsbegrenzungen auf einfachen Landstraßen-Abschnitten, außerhalb von Ortslagen gehalten. Es ist aber gut möglich, dass diese rüpelhafte Fahrweise überhaupt nicht auffällt, zumindest habe ich aus dem Cockpit-Fenster nichts bemerkt. Trotzdem ist das korrigiert, die aktualisierte Library neu hochgeladen.

Ich habe eben die aktualisierten Version der HMK_XPNetwork_Library und HMK_XPN_LocalAdds_Library zum Download unter https://drive.google.com/drive/folders/1P9Ym7UNclnBG0lHcwsN1uPKdFH8WNX-k?dmr=1&ec=wgc-drive-hero-goto bereitgestellt. Die Schritte zur Installation, bzw. Durchführung des Updates bleiben gegenüber den Vorgänger-Versionen unverändert und sind in den enthaltenen Text-Dateien beschrieben. In den Vorschriften zur Generierung des networks sind Änderungen enthalten, die erst mit dem kommenden Update von HMK_XPNetwork-Europe greifen werden. Sichtbar sind aber eine Reihe von Anpassungen und Objekt-Ergänzungen, wie z.B. die Aufnahme von Motorrädern in die verschiedenen Autogen-Fahrzeug-Mischungen. In Hinblick auf die Einsortierung der von OSM gelieferten Straßen, haben sich noch einige Möglichkeiten ergeben, die - so meine Hoffnung - die Zuordnung in die X-Plane-Welt weiter verbessern. Ich werde das zeitnah ausprobieren. Die gerade hochgeladenen Libs sind dafür vorbereitet.

Vielen Dank für die Rückmeldungen. Das, was ich zum Hochladen vorbereite, speichere ich auf einer schon leicht angegrauten Festplatte, die ich ausschließlich als isolierte Daten-Drehscheibe in meinem lokalen Netzwerk benutze. Vermutlich liegt da das Problem. Die beiden Libs mit den neuen Objekten (inkl. Motorräder) sind fertig für den Upload, allerdings ist mir nach Analyse bestimmter Datenkonstellation in OSM noch eine Sache auf die Füße gefallen, die mindestens einen, möglicherweise aber auch zwei neue Straßentypen erfordern. Dazu müssen die .net-Verarbeitungsvorschriften geändert werden und das möchte ich vorher noch einarbeiten.

Ich habe das Archiv "HMK_XPNetwork-Europe_1.1.zip" noch einmal neu erzeugt und schiebe es gerade wieder hoch.

Vielen Dank für die Rückmeldung! Es könnte durchaus sein, dass noch weitere, mit "gleicher Macke" behaftete Kacheln unentdeckt schlummern. Ich habe daher das Archiv "HMK_XPNetwork-Europe_1.1.zip" noch einmal komplett abgeglichen und hochgeladen. Im Falle des Falles also noch einmal downloaden und installieren. In den letzten Wochen sind noch einige Dinge hochgekocht, die Änderungen am Regelwerk zur Übernahme der OSM-Daten in die X-Plane-Welt notwendig machen. Das betrifft z.B. die bereits diskutierten, Zutritts-beschränkten Feldwege, aber auch die sehr komplexe Thematik, wie die in der OSM-Welt gehandhabte Bandbreite von Eigenschafts-Definitionen "treffsicherer" nach X-Plane überführt werden können. Das betrifft insbesondere Straßenabschnitte, mit besonderen OSM-Eigenschafts-Mixturen in Hinblick auf "Bürgersteig/Straßenlampen/Geschwindigkeitsbeschränkung". Hört sich spröde an, macht aber in X-Plane einen deutlichen Realistik-Unterschied. Es wird also ein Update von HMK_XPNetwork-Europe geben müssen, bevor ich an andere Kontinente denken kann.

... scheint wohl eine kleine Sensation gewesen zu sein: Trotz strömenden Regens haben sich die Leute auf den Bürgersteig bewegt, um erstmals ein vorbeifahrendes Motorrad zu bestaunen 🤗.

Hallo Christian, nach Überprüfung habe ich feststellen müssen, dass die Kachel +60+011.dsf fehlerbehaftet ist. Ich habe gerade "HMK_TileUpdates_3006.zip" mit der jetzt hoffentlich fehlerfreien Kachel hochgeladen. Bitte diese Kachel in das Verzeichnis ../HMK_XPNetwork-Europe_1.1/Earth nav data/+60+010/ extrahieren, dabei die vorhandene Datei überschreiben. Ich würde mich über eine Rückmeldung freuen, ob nach Austausch der Kachel das Problem, inkl. "Traffic ... um den Airport" behoben ist.

Gestern, am späten Abend, wurde es auf einmal so dunkel ... also habe ich in meiner Werkstatt an der Beleuchtung der neuen HMK_XPNetwork-Motorräder gearbeitet: Dies die "schnelleren Varianten", dazu kommt noch die "Cruiser"-Variante, rechts im Bild. Mittlerweile sind alle im HMK_XPNetwork unterwegs. Die Anzahl auftauchender Motorräder soll dabei im Jahresverlauf unterschiedlich ausfallen. @hnau64 hat mir gestattet, Objekte aus seiner aktuellen Hamburg-City-Scenery, https://forums.x-plane.org/files/file/93577-hamburg-city/, verwenden zu dürfen. Für das HMK_XPNetwork besonders interessant sind Alsterschiff und Barkassen, die ebenfalls gestern Abend noch in der Werft waren. Ausgestattet mit Dampferlicht, Hecklaterne und Lampen auf dem Passagierdeck sind die auch mittlerweile mobilisiert. Die Barkassen auf Flüssen, die von Seeschiffen befahren werden, während das Alsterschiff, im Bild unten Mitte rechts Richtung HH-Landungsbrücken fahrend, nur die beiden Hamburg-Kacheln beackert. Vielen Dank, Heyno! Das Update der HMK_XPNetwork_Library kommt.

Ja, wie immer spuckt mir da OSM in die Suppe: In einer längeren, 16,76 km langen Seeweg-Abwicklung, bestehend aus genau 10 einzelnen Segmenten (Vektoren), sind mittendrin 2 davon, der eine 789,88 Meter, der andere immerhin 2,30 km lang, für den Seeschiffsverkehr freigegeben. Zum Heulen ... Die Fähren habe ich auch an eine enge Leine gelegt. Das macht mir aber wieder Schwierigkeiten an anderer Stelle.

Das Thema Schiffsmodelle "allgemeine Seefahrt" ist für mich durch. Es sind noch einmal rund 15 Exemplare dazu gekommen und das sollte jetzt reichen. Heute lief die "Hermit Power" als letzter Vertreter dieser Klasse in Hamburg ein. Das Update der "HMK_XPNetwork_Library" mache ich fertig und lade es kurzfristig hoch. Jetzt etwas in Richtung "eigene Sache": Als kleines, privates Abfallprodukt, habe ich Blohm&Voss in meiner XP-Welt Reparaturaufträge vermittelt und zwei Schwimmdocks neu befüllt. Je ein Frachter und eine Fregatte müssen auf Vordermann gebracht werden. Dazu habe ich bei mir die Fahrstraßen der Elbe von allen statischen @hnau64 Elementen befreit.

Das hängt davon ab: Für die "Freedom of the Seas" habe ich das frei verfügbare Objekt-Mesh für MSFS 2020 verwendet, "Tag"- und "Nacht"-Textur habe ich mir per Gimp zusammengestellt, Mesh und Texture in Blender verbandelt, dann per ModelConverter das Model ausgerichtet. Zum Schluss etwas nervig NavLights und Mastbeleuchtung zu Fuß ergänzt. Mittlerweile sind es mehr als 140 Schiffsobjekte, verteilt auf mehrere Objektklassen, wobei die "Seeschifffahrts-Kiste", bestehend aus Fracht- und Passagier-/Kreuzfahrt-Schiffen mit 67 Objekten den Löwenanteil bekommen hat. Allerdings gibt es immer noch, bedingt durch die langsame Fahrgeschwindigkeit der Schiffe, die Gefahr, dass ein Objekt mehrfach in einer Szene auftaucht. Übrigens gehört der blaue Hafenschlepper in die Kategorie "Boats and Tugs", die aktuell 7 Objekte umfasst. Wesentlich für einen realistischen Gesamteindruck ist die Mischung. Auf der Elbe tummeln sich Objekte, die aus 5 Objektklassen kommen.