Jump to content

hmkaiser

Members
  • Posts

    486
  • Joined

  • Last visited

Everything posted by hmkaiser

  1. Also wenn ich das noch richtig in Erinnerung habe, müssen GroundTraffic-Routen in der Textdatei "GroundTraffic.txt" definiert sein.
  2. Da kann ich dich beruhigen: Jeder von uns steht immer wieder als "Neuling" vor der nächsten Herausforderung. Die Herausforderung besteht darin, sich die richtige Fragestellung zu erarbeiten, um die passende Antwort zu erhalten. Das Schöne ist ja, dass "passenden Anworten" in den meisten Fällen schon da sind und nur auf meine aktuelle Frage warten. Tutorials helfen mir da eher weniger, weil gerade das, was ich genau jetzt wissen will, so nicht explizit ins Auge springt.
  3. Es ist - wie so oft - eine Frage der persönlichen Präferenzen. Ich versuche möglichst präzise alles rund um meinen XPlane "unter Kontrolle" zu behalten. Dazu gehören dann auch die relativ wenigen AddOn-Sceneries, die noch mit dem Open-Source-GroundTraffic-Plugin arbeiten. Plugins sind immer eine potentielle "Gefahrenquelle", wie viele Beispiele zeigen. Der Aufwand, den ich dazu treiben muss, ist natürlich größer, weil ich zusätzlich auch die Diskussionen dazu, oftmals in englischer Sprache im X-Plane.Org-Forum geführt, nachvollziehen muss. Immerhin ist der Thread im X-Plane.Org-Forum, den wir hier verlinkt haben, 8 Seiten lang und behandelt alle Fragen, die sich rund um die Thematik GroundTraffic-Vulkan, Installation, ranken. Erst auf Seite 4 findet sich die aktuelle Version des modifizierten GroundTraffic-Plugins. Deshalb kommt für mich u.a. ein Update eines Open-Source-Plugins nur "zu Fuß" in Betracht. Als Vorteil empfinde ich dann aber, dass ein deutliches Plus im Verständnis des eigenen, komplexen XPlane-Systems erreicht werden kann, auch wenn ich mit der Plugin-Programmierung selbst nichts am Hut habe. Das zahlt sich in meiner Wahrnehmung immer dann aus, wenn XPlane mal wieder nicht so will, wie ich will.
  4. Ich habe dir die beiden zip-Files vorhin per Mail geschickt. "Plugins.zip" enthält die neue Win64-Variante 2.2 von GroundTraffic. Du brauchst nur in den jeweiligen Scenery Sub-Ordnern .../plugins/GroundTraffic/64/ "GroundTraffic.xpl" durch diese neue Version ersetzen. "Batch_Update GT_22.zip" enthält alles, was benötigt wird, um alle in deinem System installierten Custom-Sceneries, die das GroundTraffic-Plugin 1.52 enthalten, in einem Rutsch auf GroundTraffic 2.2 zu aktualisieren. Ist also die "Komfort-Lösung" zur gleichen Thematik.
  5. Du musst dich schon anmelden, wenn du etwas downloaden möchtest. Unter dem Link sind alle Informationen vorhanden, inkl Github-Adresse, unter der nst0022 seine Modifikation des Plugins im Quellcode veröffentlicht hat. Dazu auch Hinweise, wie aus dem Quellcode ausführbare Plugins für die einzelnen Plattformen erstellt werden können. nst0022 ist reiner Linux-Nutzer. Er kann die ausführbare Win64-Variante also nicht selbst erzeugen. Das hat aber Aviator74 freundlicherweise auf seinem Windows-System gleich gemacht und so die Win64-Variante als "Plugins.zip", zusammen mit "Batch_Update GT_2.2.zip", zur Verfügung gestellt. Marginal, der Autor von groundtraffic ist aktuell nicht aktiv. Das originale Plugin ist aber nicht kompatibel zu Vulkan.
  6. @CountCrash, hier der Thread zu dem Thema: https://forums.x-plane.org/index.php?/forums/topic/210452-groundtraffic-plugin-for-x1150-vulkan/&page=4 nst0022 hat seinen Fork-Quellcode auf GitHub bereit gestellt, Aviator74 stellt das compilierte Win64-Plugin direkt als Download bereit.
  7. Problem gelöst: Es lag an meiner eigenen Dämlichkeit. Ursächlich ist die AS-EDDK-Scenery. Die bringt ihren einen eigenen Ortho- und Mesh-Layer mit. Den Mesh-Layer hatte ich wohl in 2019 ausgeknipst, aber im EDDK-Config-Tool die Einstellung Anzeige "Ortho inkl. Surroundings" auf ON belassen. Erschwerend kam hinzu, dass in dem Config-Tool die Ortho-Qualitätsstufe nur auf "mittel" stand. Der Sache bin ich erst auf die Spur zu kommen, nachdem wirklich alle Ortho-Kacheln aus custom scenery entfernt waren. Und auch dann habe ich erst noch den ganzen PC umgekrempelt, bevor ich auf den Trichter kam, AS-EDDK unter die Lupe zu nehmen. Mir ist es überhaupt nicht in den Sinn gekommen, dass die AS-EDDK-Orthos so eine große Fläche überspannen. Haut natürlich gewaltig in die Kerbe: Man sollte auch mal einen Blick ins Handbuch werfen ... Übrigens: Der Rhein sieht heute in Bonn-Oberkassel und Leverkusen-Rheindorf richtig klasse aus. Sorry, dass ich euch mit diesem Kram behelligt habe.
  8. Definitiv nicht. Danke dir! Dann ist klar, dass bei mir etwas faul sein muss. Auch dafür vielen Dank! Allerdings wäre das der letzte Reißaus. Ich muss wissen, wo das Problem liegt. Bin gerade wieder an der Kachel +51+006: Da ist es mir erst nach 2 Stunden gelungen, die OSM-Daten fehlerfrei zu bekommen. Praktisch jede OSM-Einzelanfrage wird mehrfach rejected und auch geskippt. Da lauert der Teufel im Unterholz.
  9. Kann nicht sein, generiere mir alle Kacheln mit Mask_for_inland=True Nein, Wasser ist schon da, die Art der Darstellung des Wassers ändert sich. Sturm gepeitschte See wechselt über einen breiteren Übergang auf Badewannen-Wasser. Es gibt auch Spiegelungen auf dem Badewannen-Wasser, allerdings scheint dieses Wasser in "Schmalspur" generiert worden zu sein. Und zwischen Bonn-Oberkassel und Leverkusen-Rheindorf gibt es Unterschiede. Wird mir jetzt erst richtig deutlich in Leverkusen-Rheindorf +51.054 +6.9198: Die im Rhein deutlich abgesetzte Grenzlinie setzt sich über Land auf beiden Seiten fort: Den da entstehenden Land-Flächen fehlen die Decals auf den Orthofotos. Ist eindeutig. Der Verlauf der Grenzlinie scheint zufällig, in OSM gibt's jedenfalls nichts, was das verursachen könnte. Links, schwarzer Pfeil, Fläche mit Decals, rechts davon die Landflächen, roter Pfeil, ohne Decals. Versuche das gerade mal zu überblicken, aber es sieht so aus, als wären alle Gewässer innerhalb der Decal-freien-Zone Badewannen, außerhalb davon peitscht der Wind die Wellen. Es hilft nichts, diese Macke mit der Kachel +51+006 kann definitiv nur auf oder vor meinem Rechner sein. Ortho4XP läuft als Scriptversion, Stand Juni 2019, abgesetzt unter Linux. Muss mal gucken, ob da noch irgendwo etwas gecacht wird (außer in den Unterverzeichnissen von Ortho4XP), bzw. die Ortho4XP-Installation genau prüfen. Irgendwann hatte ich mal etwas mit nvcompress ...
  10. Bin mir auch sicher, dass es an OSM liegen muss. Der Rhein ist an den Stellen noch mit allerlei zusätzlichen OSM-Elementen ausgestattet. Im Bereich Bonn-Oberkassel gibt es z.B. eine innere Fläche "seamark_type=fairway", dazu genau an der Stelle eine "route=boat", alles allerdings älteren Datums. Dazu sind Einzel-Nodes im "waterway=river" auch noch mit allerlei "seamark:XYZ..."-Informationen getagt. Ich hatte da schon probehalber Nodes mit "seamark:XYZ..." aus dem waterway entfernt, sprich daneben gesetzt. In Leverkusen-Rheindorf ist die Situation etwas anders, weil genau in dem Beritt zwei Flächen "natural=water, water=river" aneienander stoßen, dazu gibt es aber in jeder der beiden "natural=water"-Flächen am linken Rheinufer eine Fläche "leisure=nature_reserve", die sich bis zur Flussmitte des Rheins erstreckt. Die sind erst in 2019, bzw. 2021 erfasst worden. Außerdem ist mir aufgefallen, dass einer Fläche "boundary=protected_area" fehlt. Wird mir jetzt erst so richtig deutlich, dass diese "leisure=nature_reserve" einen genaueren Blick verdienen. Trotzdem, ich lasse die Hackerei in OSM erstmal sein und warte auf dein Ergebnis.
  11. Die Ferranti +50+007.hgt hat nichts gebracht. Anliegend noch einmal ein Shot aus +50.713 +7.1612, also die Stelle in Bonn-Oberkassel. Deutlich zu erkennen, dass die Art des dargestellten Wassers wechselt.
  12. Bonn-Oberkassel: https://www.openstreetmap.org/#map=18/50.70440/7.16709 Leverkusen-Rheindorf: https://www.openstreetmap.org/#map=18/51.05421/6.91885 Die Übergangsbereiche sind bei mir deutlich als ca. 50-100 Meter breite Zone ausgebildet. Ich habe die Einzel-Flächensegmente des Rheins zwischen Bonn und Leverkusen in OSM kontolliert. Es gab im Verlauf des Rheins 3, oder 4 Flächen, die zusätzlich zu "natural=water, water=river" auch noch mit "waterway=riverbank" getagt waren, darunter war auch eine Fläche, die aus Südost kommend, den Übergangsbereich in Leverkusen-Rheindorf tangierte. Allerdings war das nicht im Raum Bonn der Fall. "waterwy=riverbank" habe ich letzte Woche aus den betroffenen OSM-Flächen entfernt. Was mich auch erstaunt: Ich habe nirgends einen Hinweis entdecken können, dass ein anderer User schon einmal über dieses Phänomen gestolpert ist. Das würde darauf hindeuten, dass die Sache nur bei mir entsteht, bzw. ich selbst das Problem bin. Meine Kacheln (ca. 200) sind alle in ZL16, masks, imprint masks to dds, decals, Sonny-.hgt generiert. Die Kachel +50+007 habe ich in den letzten Tagen mehr als 15x mit unterschiedlichen Ortho-Configs erstellt. Ich werde jetzt noch einmal die Kachel ohne Sonny-.hgt, im Standard, erzeugen und dann, falls das nichts bringt, auf ZL17 gehen.
  13. Und noch die Maske für den betroffenen Bereich Leverkusen-Rheindorf, direkt nordwestlich Einmündungsbereich Wupper
  14. Hier Masks und OSM für +50+007 aus dem Cache. 5504_8512.png ist die Maske für den betroffenen Bereich in Bonn-Oberkassel. OSM+50+007.7z Masks+50+007.7z
  15. @DaikanHallo Daikan, vielleicht kannst du mir auf die Sprünge helfen: Ich habe mit Ortho4XP zwischen Bonn und Leverkusen diese Probleme mit "use_masks_for_inland=true" Bonn-Oberkassel: Blick nach Süden. Die Darstellung der Wasseroberfläche südlich der Markierung entspricht der "normalen" XPlane-Wasseroberfläche mit Wellenmuster, abhängig von den Wetterbedingungen. Nördlich dieser Stelle ist der Rhein über die Maske eine absolut glatte Fläche, Spiegelungen sind aber aus extremen Winkeln sichtbar. Zwischen Bonn-Oberkassel (+50+007) und Leverkusen-Rheindorf (+51+006) bleibt die Darstellung Wasseroberfläche des Rheins unverändert, bis zu diesem Punkt: Leverkusen-Rheindorf: Blick nach Norden. Die Darstellung der Wasseroberfläche wechselt wieder auf "Normal". Ich habe verschiedene Dinge erfolglos ausprobiert: Diverse Korrekturen in OSM hinsichtlich der Wasserflächen (u.a. Entfernung des Rheins aus einer Brücken-Ralation "Kennedybrücke") Einstellungen Ortho4XP: mask_zl, mask_width, masking_mode, Wechsel Sonny-.hgt-version, unterschiedliche curvature_tol, water_smoothing. Die Masken sind vollständig in /Masks geladen, das Log gibt mir keinen brauchbaren Hinweis, außer dass es früher mal in +50+007.hgt zwei Fehler gibt, Ortho4XP da die Höhe auf 0 gesetzt hatte, aber Schnee von gestern. Ich benutze die aktuelle Ortho4XP 1.30, Script-Version. Hast du eine Ahnung, was ich falsch mache? Log.txt
  16. Dann würde das Problem nicht "nur in machen Spielen" auftauchen, schließlich ist das Verschieben von "Sichten" über eine gedrückt gehaltene Maustaste eine Standardfunktion. Ja, allerdings spielt hier etwas anderes hinein, die Maus ist nur Überbringer der Botschaft "etwas stimmt nicht". Vielleicht, das wäre die simpelste Lösung, kommen sich Controller und Maus ins Gehege. Es ist jedenfalls eine spezifische Konstellation auf diesem einen Rechner, die Probleme macht.
  17. Hallo PilotX, du hast es ja in deinem Eingangs-Posting treffend beschrieben: "in manchen Spielen, habe ich trotz hoher FPS (50-60) ruckeln... Allerdings nur mit meiner Maus, nicht mit Pfeiltasten oder Controller. In XPLANE11 das Selbe..." Ist also kein Thema von XPlane. Trotzdem: Man muss in diesen Fällen versuchen, logisch die Sache einzukreisen: Die geschilderten Probleme treten bei "manchen Spielen" auf, sonst funktioniert die Maus fehlerfrei. Es ist also nach deinen Worten klar, dass die Maus selbst nicht ursächlich sein kann. Dazu kommt, dass das "Ruckeln" nicht entsteht, wenn die Sichtveränderung über Keyboard-, oder Controller-Tasten gesteuert wird. Also hast du eigentlich alles, was du zur Lösung deines spezifischen Problems brauchst: Es kann sich nur um einen Konflikt handeln, der bei Aufruf einer Funktion über eine Maustaste entsteht. Zuerst sind die an deinem Rechner über USB angeschlossenen Geräte als "Störquellen" auszuschließen, insbesondere der Controller! Also aushängen und gucken, ob sich eine Veränderung in XPlane zeigt. Wenn das nicht zum Erfolg führt, muss die Win-Installation überprüft werden. Der Maustreiber (auch Keyboard) sollte der Standardtreiber sein, ich würde alle anderen Treiber für die Fehlersuche entfernen. Und bei der Gelegenheit Autostart entrümpeln. Gerade für Flugsimulationen kann ich nur empfehlen, alle nicht unmittelbar für die Simulation benötigten Gimmicks offline zu lassen. Dann hilft nur konsequent Schritt für Schritt vorzugehen und dabei das Internet quälen, bis du die richtige Fragestellung gefunden hast, die dir die Problemlösung liefert.
  18. "content=wastewater", zusammen mit "silo/storage_tank" habe ich über ganz Deutschland gescreent und ca. 50 Objekte auf "natural=water, water=wastewater" korrigieren können, dazu "storage_tanks" in "slurry_tanks", oder "digester" umgewandelt und erstmals einen "underground_tank" gefunden, der jetzt seiner eigentlichen Bestimmung als "landuse=basin", "basin=detention" übergeben werden konnte. In Summe waren nur 2 Kläranlagen über die overpass-Selektion komplett auffällig. Allerdings gibt es eine Reihe weiterer Stilblüten, u.a. auch mit "landuse=basin".
  19. Ja, ist mir bekannt. Ich werde das auf alle Fälle über "content=wastewater" und "building=silo" or "building="storage_tank" or "man_made=silo" or "man_made=storage_tank" per overpass zielgenau abgreifen und kontrollieren. In den Fällen, wo "content" fehlt, bleibt nur die Einzelkontrolle über alle "man_made=wastewater_plant". In OSM sind "silo", "storage_tank" einfach zu zahlreich erfasst, als das man darüber sinnvoll eine Selektion laufen lassen könnte. Ich hatte in Deutschland ja schon über Wochen mit tausenden "X-Europe-Silo-Kisten" das Vergnügen, verursacht durch falsch getagte OSM-"silo", die aber "bunker_silo" hätten sein müssen. Dazu war die Hälfte der Dinger zusätzlich auch noch mit "building=yes" getagt. Und dann die Aktion mit den "generator"-Kisten ... Und da fallen mir auch gleich noch OSM-"silo" ein, die in Wirklichkeit "digester" sind.
  20. Hallo Pitt153, vielen Dank für den Tipp, zusammen mit der Abfrage! Leider hilft deine Abfrage im konkreten Fall nicht weiter, da die Klärbecken als "buildings", bzw. "man_made" mit yes, silo, storage_tank getagt waren (und das führt ja zu dem Darstellungsproblem in X-Europe). Kann man gut am konkreten Fall "Klärwerk Mönchengladbach-Neuwerk", https://www.openstreetmap.org/#map=17/51.24184/6.46412 , erkennen. Das Problem: Wie selektiere ich nur die falsch getagten Klärbecken, ohne gleichzeitig die überwiegend korrekt getagten silo, storage_tank, usw. mit in die Auswahl zu bekommen? In diesem konkreten Fall (offenbar OSM-User spezifisch), waren einige, aber nicht alle Klärbecken zusätzlich mit "content=wastewater", bzw. "=sewage" getagt. Darüber ließe sich eine overpass-Abfrage entwickeln: Selektiere alle "building" und/oder "man_made" die mit "content=wastewater", oder "=sewage" getagt sind. In den meisten anderen Fällen fehlt eine "content="-Angabe - und da ist dann guter Rat teuer. Erschwerend kommt noch hinzu, dass vor einer OSM-Korrektur, die Gesamt-"wastewater"-Anlage noch nachgeladen werden muss, damit man auch wirklich alle problematischen Konstellationen erwischen kann. Da schlummern meist auch noch andere Fallstricke, wie z.B. die korrekte Verwendung von "storage_tank".
  21. Ich habe beide Areale in OSM korrigiert. Kannst dir das ja mal angucken, ggf. die drei nördlichen, jetzt als "water" deklarierten Areale in der Kläranlage nahe Knickelsdorf korrigieren. Ist für mich als Ortsfremder nur schlecht über die Fotos erkennbar, ob das Klärbecken, oder eine Art "bunker_silo" sind. Diese OSM-Korrekturen sind ein Klacks. Vielleicht könntest du auch mithelfen, "OSM-Fehlbesetzungen" gemäß der OSM-Wiki-Definitionen zu beseitigen. In OSM gibt es nämlich noch jede Menge zu tun.
  22. Da sind die Tags in OSM falsch gesetzt. Z.B. Klärbecken sollten gem OSM-Wiki mit "natural=water, water=wastewater" getagt sein. Wenn diese Dinge über "building" getagt werden, geht die Sache in die Hose. Ich ändere das nachher ab, "wirkt" aber erst mit dem nächsten X-Europe-Update.
  23. Bei mir brennen die Lampen trotz CorfuEXCL noch ... Wie dem auch sei: Verursacher des Problems sind die "man_made=mast", "tower:type=lighting" aus OSM, die sich in unmittelbarer Nähe der Anflug-Befeuerung befinden. Natürlich könnte man salopp das Problem lösen und die nervigen Nodes in OSM enfernen, aber ... das sollte man besser über die WED machen. OSM ist die Basis für das X-Europe-Autogen. Wir müssen aber damit leben, dass OSM nicht nur für XPlane gemacht wurde, sondern eine Vielzahl anderer Interessen an OSM bestehen. Das führt zwangsläufig dazu, dass mancher Edit in OSM uns in XPlane vor die Füße fällt. So wie ich Heinz verstanden habe, ist aber FlyTampa-Corfu so großflächig angelegt, dass die hier auffälligen OSM-Eigenarten über die Scenery, sofern in korrekter Reihenfolge aktiv, glatt gebügelt werden.
×
×
  • Create New...