Auch LLH Creations (bekannt für die anspruchsvoll anzufliegenden Altiports) haben ihre Szenerien nun für P3D v4 fit gemacht. Die Dateien sind auf Nachfrage beim Entwickler selbst unter contact@llhinfo.com zu erhalten. Genauere Angaben sind nicht gemacht, es schadet aber sicher nicht, einen Nachweis mitzusenden, dass und welche Szenerien man gekauft hat. Ein Wort der Warnung nachfolgend: [Update, neue Installer]
P3D v4 verwendet ein neues Encodingformat für die ganzen cfg Dateien, also auch für die Scenery.cfg. LLH ignoriert dies jedoch und rät, auf UTF-8 umzustellen, bevor man die Szenerien installiert.
Mein Rat wäre, sich ein Backup der Szenery.cfg zu machen, dann zu installieren, dann die aktuelle Szenery.cfg wegzuschmeissen, weil die dann total verhauen ist, dann das Backup zurückspielen und dann die LLH Szenerien manuell in die Bibliothek einzufügen.
Update 05.07.
Es gibt neue Installer, die (hoffentlich) nichts mehr zerschießen.
Man gelangt über diesen Link dorthin, muss sich natürlich anmelden.
Danke Günther, ich habe die komplette LLH-Kollektion und hatte schon darauf gewartet. Schöne Szenerien sind das in einer wundervollen Landschaft.
Vielen Dank für den Tipp, obwohl ich da schon etwas ungläubig den Kopf schütteln muss. Es gibt ja einige Fußangeln bei Prepar3d4, aber dass der Programmierer nicht in der Lage ist, an das neue Codierungsformat anzupassen, würde ich schon, wie soll ich sagen, bemerkenswert nennen. Ich werde das wie von Dir beschrieben machen, da bin ich auf der sicheren Seite.
@Autor: Wäre es nicht schlauer, wenn man schon im Ordner ist, einfach die scenery.cfg zu sperren, also “alt+Enter” und dann auf “Schreibgeschütz”/”Read Only” stellen. Dann auf “Apply” (der Knopf unten rechts), Fenster bleibt offen und im Vordergrund. Scenery installieren, die .cfg wieder entsperren, also Häckchen weg und OK. Scenery nur noch manuell einfügen. FERTIG. (Kein Löschen, kein kopieren, weniger Schritte)
Hm, Backup sind folgende Klicks:
STRG+c, STRg+V, Enter, (Installation), DEL, Langsamer Doppelklick, (umbenennen), Enter
Sperren:
Linksklick, Menüklick, Schreibschutzklick, Enter, (Installation), Linksklick, Menüklick, Schreibschutzklick, Enter.
Meine Methode hat 7 Klicks, Deine 8 … einigen wir uns auf Unentschieden?
😉
Der Autor meinte nun, dass LM den Fehler gemacht hat.
Letztlich auch egal, jedenfalls muss man Vorsicht bei der Installation walten lassen.
Was mich wundert, dass die Entwickler es nicht hinbekommen das SDK zu lesen. Die ganze Registrierung kann die Prepar3D.exe übernehmen. Ein paar Parameter angehängt und fertig. Und dann muss kein installer in der .cfg rumschreiben.
Am Einfachsten ist es wohl, einen etwas “über dem Standard” stehenden Texteditor zu verwenden, wenn man schon in der scenery.cfg herumwerkeln will, wie z.B das Freeware-Tool Notepad++ https://notepad-plus-plus.org/ . Damit kann man fast jede beliebige Text-Codierung laden und wieder speichern oder konvertieren. Eine “zerschossene” scenery.cfg, die in UTF-8 gespeichert wurde, kann damit auch wieder nach UCS-2 LE (die Codierung, die LM jetzt benutzt) zurückverwandelt werden. Alles halb so schlimm ! 😀
Ich redigiere meine scenery.cfg jeglicher Provenienz seit Jahren damit und es ist noch nie zu irgendwelchen Fehlern gekommen.
Toll, Flugsimulation für Anfänger 😉 ich staune nur mehr ;-)ich glaube ich gehe jetzt dann erst mal wieder in einen PC-Kurs an der VHS 😉 irre.
Da hier jeder macht was er will, schiebe ich die scenery.cfg auf den Desktop und melde dann per Hand an. Der Schreibschutz nützt gar nichts wenn der Installer als Admin ausgeführt wird oder sogar Trusted Installer Rechte hat.
Das Chaos ist doch größer als vorher. Der eine installiert nach SDK, der nächste weiter im eigenen Verzeichnis innerhalb (Simmarket voran), der Dritte in Ecosystems (AS), der Vierte in Dokumente, aber gleich alles. Zusammen mit ProgrammData müllt sich die Systemplatte (ich habe ne 256 GB M2) völlig sinnfrei voll, selbst wann man alle Programm woanders installiert.
Ich werde wohl meine Registry manipulieren und Dokumente, Bilder sowie ProgrammData an einen anderen Ort verbannen. Aber auch das kann Probleme machen wenn ein Installer mit absoluten Pfaden arbeitet. Es gibt ja auch weiterhin welche, die nicht mal eine Pfadanpassung zu lassen.
Nur als kleine Bemerkung: Du mußt nix an der Registry ändern um Dokumente, Bilder, Videos etc. zu verschieben. Mit Rechtsklick auf das jeweilige Verzeichnis -> Eigenschaften -> Reiter “Pfad” kannst Du diese speziellen Verzeichnisse wunderschön verschieben.
Vom ProgramData solltest Du unbedingt die Finger lassen. Auch M$ rät dringend davon ab dieses Verzeichnis wie auch immer zu verschieben. Da drohen mittelschwere Katastrophen nach einem Windows-Update.
Und OrbX habe ich vergessen, die sich sowieso um nix scheren.
Ich habe Eric Majeras auf das Thema Installer von LLH Creations angesprochen. Er hat mit bestätigt, dass es neue Installer geben wird, die den geänderten Umständen von P3D V4 voll Rechnung tragen werden. Also nur noch ein bisschen Geduld und die Sache ist gegessen.
@simmershome: Da gebe ich dir recht, das Chaos, das mit dem neuen Installationsssystem angerichtet wurde, ist nicht dazu angetan, übertriebene Sympathien für LM zu wecken… 😀
Das Hauptproblem ist wohl, dass die Leute bei LM dieses System für die Anwendung von Szenerien nicht zu Ende gedacht haben. Während das System für alle andern Add-Ons durchaus Sinn machen kann, ist es für Szenerien unumgänglich, eine Priorisierung (Layerung) anzubieten. Und genau diese fällt weg, wenn mit dem propagierten “Packages” system installiert wird. Damit fallen nämlich die Einträge in die scenery.cfg weg, und die so installierten Szenerien stehen in der Scenery Library unverrückbar an erster Stelle.
Für mich ist es nachvollziehbar, dass sich ORBX darum futiert hat, weil eben deren Installationen sehr stark von der richtigen Layerung abhängig sind.
Gem. SDK können in den add-on.xml auch Layer eingefügt werden. Nur ist das mehr als umständlich und nicht sehr nutzerfreundlich. Wenn es LM schafft eine ähnliche Funktion wie in der scenery library in die options/addons console zu integrieren, wäre ja schon viel geholfen.
Gemäss SDK schon, aber das hat noch niemand gemacht, geschweige den zum funktionieren gebracht. Zumal die add-ons.xml definitiv der falsche Ort ist, um einen Layer zu definieren. Solange die scenery.cfg existiert und damit eine Priorisierung vorgibt, muss jedes Add-On auf die bestehende Priorisierung achten. Dies in der add-ons.xml bewerkstelligen zu wollen, ist ja wohl die dämlichste Idee von allen. Sie wird nämlich nicht aktiv verwaltet, sondern vom Installer geschrieben und dann von P3D verarbeitet, d.h. bei Szenerien in die scenery add-ons.xml übertragen. Damit müssten bei jeder Installation alle bestehenden add-ons.xml auf ihren Layer überpfrüft und allenfalls angepasst werden. Und genau das ist im bestehenden Konzept schlicht nicht möglich.
Ich bleibe dabei, LM hat mit diesen System unglaublich geschlampt. Ich bin mal gespannt, wie sie sich da aus der Affäre ziehen wollen. Ich für meinen Teil lösche alle add-ons.xml nach der Installation und trage die Szenerien in die scenery.cfg ein – je nach Lust und Laune direkt oder via scenery-library.
Gegen das “neue” xml-System – mit Layering – ist an sich nichts einzuwenden. Gegen das “alte” aber auch nicht. Was das Chaos komplett macht, ist m.E. die Zweigleisigkeit, die LM zulässt. Ich warte nur darauf, dass das erste über xml installierte Flächenaddon kommt, das sich – natürlich ohne Layer – bei den xml-Addons einnistet. Und dann kommt ein Airport in dem Gebiet, der sich in der scenery.cfg einträgt. Ich bin gespannt, wie das gelöst wird.
Im LM-Forum gibt es übrigens einen guten Beitrag dazu (Nr. 6, “Frank”):
http://www.prepar3d.com/forum/viewtopic.php?f=6312&t=125600
Ich hoffe, den verinnerlicht jemand von LM. So gut Prepar3d4 ist, an der Stelle haben sie wohl tatsächlich einen Bock geschossen.
Naja, Layering ist natürlich auch ohne scenery.cfg möglich – nämlich komplett innerhalb der Scenery Library. So war es vermutlich auch mal angedacht, ist aber aus irgendeinem Grund nicht zu Ende gedacht worden. Man kann natürlich die ganze Prioritätenverwaltung innerhalb der Scenery Library bewerkstelligen. Dazu gehört aber noch ein nicht unerheblicher Programmieraufwand, bis es so weit ist. P3D muss dann eben die Prioritätsverwaltung komplett selbst übernehmen und dabei sowohl die scenery.cfg als auch alle add-ons.xml Dateien berücksichtigen. Das geht natürlich auch, wenn es denn mal fertig programmiert ist. Zum jetzigen Zeitpunkt ist das aber noch nicht “in Betrieb”. Somit bleibt als einzige Möglichkeit der Priorisierung der nachträgliche Eintrag in die scenery.cfg.
Man fragt sich dabei natürlich, warum sie dann überhaupt noch eine scenery.cfg benützen. Ich vermute mal, dass dies schlicht Bequemlichkeit war, um die Standard-Szenerieen richtig einzuordnen. Die gegenwärtige starre Handhabung der Einträge ausserhalb der scenery.cfg ist jedenfalls so schlicht NICHT brauchbar. Manchmal frage ich mich wirklich, was die Jungs geraucht haben… 😀
Den Betatestern kann man keinen Vorwurf machen. Die Art und Weise der Add-On Installationen kann während des Betatest wohl mangels passender Installer nicht richtig beurteilt werden.
Ist das was ich mir hier bröckchenweise zusammenreime irgendwo zusammenhängend beschrieben? Also wie P3D4 die Registrierung von Szenerien vorsieht und wie es manuell anzupassen ist?
Es ist in der SDK-Dokumentation beschrieben, die richtig gut versteckt ist. Gehe in Dein P3D-Verzeichnis und öffne die Datei “Learning Center.chm”. Das ist eine Windows-Hife-Datei, wo es einen Abschnitt “SDK” gibt, und darunter einen namens “Addons”. Das alles natürlich in englisch. Ich weiß jetzt leider nicht, ob Du dafür das eigentliche SDK herunterladen und installieren mußt. Ich mach’s immer automatisch 🙂
Jetzt habe ich zu guter Letzt noch eine interessante Entdeckung gemacht ! 😀 Ich habe mich ja von Anfang an nie um die Codierung der scenery.cfg gekümmert, weil dies mein Notepad++ getan hat. Versuchsweise habe ich jetzt mal die Scenery.cfg auf UTF-8 codiert (das sieht man daran, dass sie nur noch halb so gross ist wie UCS-2) und P3D gestartet…
Alle Szenerien wurden korrekt erkannt und P3D V4 ist ohne Fehlermeldung ganz normal aufgestartet. Nach Beendigung des Simulators war die scener.cfg immer noch gleich gross und in UTF-8 (was ja auch logisch ist, da ohne Manipulation der Scenery Library die Datei nicht neu geschrieben wird).
Also alles nochmal von vorne und die Reihenfolge in der Scenery Library geändert. Nach Beenden des Simulators was die scenery.cfg dann wieder doppelt so gross und in UCS-2 LE codiert… 😀
Also alles halb so wild ?!?!? P3D V4 kann offensichtlich UTF-8 immer noch LESEN. Ich muss dazu allerdings sagen, dass ich keinerlei Umlaute benütze – weder in Namen noch Pfaden (DOS lässt immer noch grüssen). 😀 Den Versuch mit Umlauten überlasse ich jemand anders…. 😀
Hallo Oski,
kann deine Beobachtungen nur bestätigen, das Format ist egal.
Das Thema addon.xml ist, wie Du richtig sagst, ist ein Ansatz, der aber nicht zu Ende gedacht ist. Es ist eine Basis, die aber mindestens bis V5 braucht, je nach Weiterentwicklung, bis sie voll anwendbar ist.
Das ist auch LM bewusst, den aus dem gleichen Grund wurde,trotz 64 bit Umstellung, der BGLC Code nicht völlig entfernt. Denn die nun endlich zur Verfügung stehende Zugriffsmöglichkeit auf Environment Variablen zur Steuerung von Scenery Objekten ist ein (leider noch nicht Bugfreier) Ansatz zur Ablösung des BGLC Codes, aber NOCH kein 100% Ersatz. Den gilt es nun im Livecycle von V4 zu schaffen.
Und dann sind vielleicht auch alle Addons in die Lage versetzt, dass Produktverzeichnis ausserhalb es Sims halten, ohne Seiteneffekte mit anderen Addos, die eine Ordnung (Layering) erfordern.
Das setzt aber voraus, das ORBX u.a. nicht mehr in den default cfg’s rumfuschen kann und alle anderen damit “leben” müssen.
Hotfix 1 hat aber auch gezeigt, das LM nicht mehr nur den Voll-Reinstall als Updateoption sieht. Also hinzulernen aus allen Seiten.
Zu den neuen Installern: ich habe gestern alle meine Produkte heruntergeladen (man muss sich bei LLH melden und kriegt dann einen Download-Link). Die neuen Installer richten nun keinen Schaden mehr an und die Flugplätze sind in alter Frische verfügbar. Die Installer bieten die Installationsmöglichkeit für FSX, P3D V3 und P3D V4. Keine Ahnung, wie es mit FSX Steam Edition steht, aber da gibt’s sicher auch eine Möglichkeit zur Installation.
Hi, ich habe mir jetzt auch mal COURCHEVEL + MERIBEL gekauft und mit dem neuen Installer in v4 installiert.
Leider musste ich feststellen, dass sich der Boden und allgemein die form der Berge beim Vorbeiflug drastisch verändern.. ? Habe ftx global base und open LC EU bereits installiert. Kann das mit FTX zusammenhängen, hat jemand damit schon Erfahrung?
Nun, das ist ja eigentlich keine neue Erkenntnis. Je nach Leistung deines Computers wird das Mesh eben früher oder etwas später angepasst. Das ist im wesentlichen ein Nebeneffekt des Multi-LOD Mesh bei FSX/P3D. Ich habe diesen Effekt bei meiner Maschine nicht, kenne ihn aber von andern Installationen. FTX ist ja im wesentlichen nur “aufgehübschte” Landclass. Erst die FTX-Regionen haben ein eigenes Mesh.
Die LLH-Plätze haben natürlich ein eigenes, lokales Mesh, das auch geladen und dargestellt werden muss. Normalerweise geschieht dies aber unbemerkt, weil der Anteil am ganzen Mesh klein ist.
Joa, kurz zu meiner Maschine:
Habe einen Skylake 6700K auf 4,7 GHZ OC HT OFF, eine Geforce GTX 1070 8 GB, 32 GB ram, P3D und Windwos 10 64 Bit jeweils auf SSD’s getrennt.
Das ist mir schon klar dass das keine neue Erkenntnis ist, jedoch ist das bei Courchevel schon heftig. Nicht nur die Form der Berge verändert sich laufend, auch die Gebäude und Bäume kommen und gehen beim nahen Vorbeiflug wie sie wollen.
Habe in der Scenery lib Courchevel + Meribel auch ganz oben und es spinnt trotzdem.
Und wenn das “normal” sein soll und so einfach verkauft wird, dann fress ich n Besen 😀
Hatte das selbe Problem mit genau der gleichen Scenerie auch in P3D v3, habe das Paket dann damals wieder “zurückgegeben” und mein Geld zurück erhalten. Dachte durch P3D V4 und damals durch meine Reklamation hätten sie das Problem vielleicht behoben.
Scheinbar nicht? Habe jetzt auch nochmal LLH kontaktiert..
“Normal” ist es so, wie du beschrieben hast, sicher nicht. Wie gesagt, ich habe diesen Effekt nicht so, wie du ihn beschrieben hast. Ich schlage mal vor, du experimentierst ein bisschen mit der Mesh-Auflösung und ein paar andern Grafik-Reglern. Da offensichtlich nicht alle User dieses Problem haben (es ist nicht IMMER der Hersteller… 😀 ), könnten durchaus veränderte Einstellungen Abhilfe schaffen.
Oski, ich habe dieses Problem auch bei verschiedenen Szenerien, ein Paradebeispiel war immer ORBX Catalina, wo der Boden aus Pudding war, aber auch verschiedene andere Szenerien, auch von anderen Herstellern. Immer in Bergen natürlich.
Ich habe das Problem seit LM die Tesselation eingeführt hat (ich glaube Prepar3d2) und seither in verschiedenen Neuinstallationen und verschiedenen Maschinen immer wieder gehabt. Ich habe derzeit eine Maschine auf Basis Intel i7-6700K 4.0 GHz, 32 GB Kingston DDR4 RAM, mehreren SSDs und einer EVGA 1080 Ti 11 GB. Sicher keine Spitzenmaschine, aber auch keine Niete.
Ich habe einmal (noch in Prepar3d3) einen halben Tag systematisch mit verschiedenen Einstellungen experimentiert (LOD, Tesselation, Mesh Resolution usw.), es hat überhaupt nichts gebracht. Ich akzeptiere, dass es Nutzer gibt, die das Problem nicht haben, aber es gibt zahlreiche Forenbeiträge (auch bei LM), in denen das Problem immer wieder aufgeworfen wird und die ergebnislos geendet haben.
In Prepar3d4 könnte es endlich einen Parameter geben, der das Problem zumindest lindert: Man kann hier wohl endlich den LOD in der prepar3d.cfg über den Maximalwert der GUI hinaus erhöhen. Dadurch wird eher (also in weiterer Entfernung) zu dem höher aufgelösten Mesh übergegangen und die Tiles springen dort schon an die richtige Position. Wenn mich meine Plcebobrille nicht trügt, hilft das (ich nutze derzeit LOD 14.5), beseitigt den Effekt aber auch noch nicht ganz. Ich muss auch gleich sagen, dass auch das umstritten ist, denn es gibt Leute, die behaupten, der LOD wäre nach wie vor auf 6.5 gelockt. Leider habe ich als Noob auch auf hartnäckige Anfrage im LM-Forum von den Einzigen, die es sicher wissen müssen, keine Antwort bekommen.
Ich bin auch “betroffen” …
Hat bei mir allerdings nichts mit LLH Szenerien zu tun, sondern passiert auch mit meinem FS Global Mesh überall.
Nervt mich seit Jahren. Auch ich hab alle Settings durchprobiert.
Den LOD teste ich mal, aber da wird doch was in die Knie gehen, oder?
Tja, offensichtlich habe ich mich in der Zwischenzeit derart an diesen Mesh-Aufbau gewöhnt, dass er mich nicht mehr stört. Ich glaube allerdings nicht, dass dies eine P3D spezifische “Eigenart” ist. wenn ich mich recht erinnere, hatten wir schon vor 12 (!) Jahren während des FSX-Betatests die ersten Anzeichen dieses Verhaltens. Justin Tyme/FSGenesis hat während der Betazeit immer wieder neue Meshes verschickt, die bereits dort mit dem SDK als Multi-LOD kompiliert wurden.
Mit meinem FS-Computer halte ich es wie mit den Autos: einfach solide Mittelklasse und bisher habe ich deswegen keine wesentlichen Leistungseinschränkungen gesehen. Wie gesagt, der “springende” Meshaufbau ist mir bestens bekannt, aber ich empfinde ihn nicht als störend, weil er sich relativ diskret bemerkbar macht und – das ist für mich das Wesentlichste – wenn sich das Mesh um einen bestimmten Punkt einmal in seiner vollen Auflösung aufgebaut hat. bleibt es auch so und ändert sich nicht mehr, solange ich die entsprechende Gegend nicht verlasse.
Günter, zumindest auf meinem System hat der hohe LOD keine nennenswerten Auswirkungen z.B. auf die fps. Auch die höher aufgelösten Texturen übrigens nicht. Erweiterungen des Autogen-Radius dagegen schon. Aber wie gesagt, die Auffassungen über die LOD-Erhöhung (die ich keineswegs “entdeckt”, sondern bei anderen gelesen habe) gehen auseinander und die Erfahrungen sind in der kurzen Zeit sicher auch noch beschränkt.
Ich habe mehrere Versionen Pilot’s Mesh, da tritt das in bergigen Gegenden überall auf. Und eben auch bei ORBX und anderen. Ich fliege hauptsächlich GA. Mich stört das Problem – seit Jahren schon – erheblich und ich finde das alles andere als diskret. Ich habe jedenfalls noch in keinem realen Flugzeug gesehen, dass der Boden um mich irgendwie “wackeln” würde. Erdbeben ausgenommen vielleicht 🙂
Die Anmerkung von Oski über den FSX ist interessant, ich hatte das immer auf die Tesselation geschoben. Allerdings bin ich schon seit Jahren nicht mehr FSX geflogen, also durchaus möglich, dass es das Problem da auch schon gab/gibt.
Ja, es ist schon so, dass der FSX diesen Effekt “schon immer” hatte. In den allermeisten Fällen tritt er aber nicht störend auf, da wir Simmer ja sehr häufig mit Dickblech von Grossflughafen zu Grossflughafen unterwegs sind. Sobald es aber VFR ins Gelände – sprich in die Alpen – geht, wird dieses Verhalten auffälliger, egal mit welcher Szenerie man unterwegs ist, massgebend ist das Mesh. Multi-LOD Meshes wurden damals entwickelt, um das “Durchscheinen” bei hoch aufgelösten Meshes zu verhindern. Zu FS9 Zeiten brauchte es dazu ein Buffer-Mesh mit tieferer Auflösung, das man darunterlegte.
Meiner Ansicht nach müsste man den Aufbau-Algorithmus des Meshes ändern, um diesen Effekt zu verhindern, aber das würde Eingriffe in die tiefere Programmstruktur erfordern, auf die wohl auch LM nicht unbedingt Lust hat. Es ist ja auch unerheblich, von welchem Hersteller das Mesh stammt. Als Faustregel gilt, je höher die Auflösung, desto stärker der Effekt. Die Qualität eines Meshes richtet sich ja ohnehin einerseits nach der Verfügbarkeit der Höhendaten und andererseits nach deren Aufbereitung, sprich Fehlerkorrektur bezüglich Spikes, Schattenlöchern etc. Aber grundsätzlich ist es nur ein Array aus Punkten verschiedener Höhe.
Wie sich die Tesselation bei P3D auf die Geländedarstelung auswirkt, habe ich noch nicht herausgefunden und ich werde das auch schön bleiben lassen. Ich glaube nicht, dass in der Darstellung wesentliche Unterschiede sichtbar sind. Aber vielleicht ist der Rechenaufwand grösser und damit die Darstellungsgeschwindigkeit betroffen. Hier müssen Grafik-Fachleute ans Werk…. 😀
Oski hat das sicher auf den Punkt gebracht. 80 % fliegen Boeings und Airbus, fast alle Großflugplätze sind auf ebenem Grund, und wenn sie über den Alpen oder Rockies sind, sind sie so hoch, dass sie von dem Effekt kaum oder gar nichts mehr merken.
VFR-Flieger wie ich sind dagegen arm dran. Ich brauche nur den kurzen Trip von KSFO nach KHAF in 2000-3000 Fuß Höhe über die Hügel zu machen, da “schnappt” es an verschiedenen Stellen. Aber wie gesagt, ich habe den Eindruck, das lässt sich jetzt in Prepar3d4 über den LOD entschärfen, da dann schon in größerer Entfernung zu dem höher aufgelösten Mesh geschaltet wird. Wenn ich einmal Zeit habe, werde ich dem systematischer nachgehen.
Um zum Thema zurückzukommen: Der Autor der Altiports kann dafür ebenso wenig wie ORBX oder Pilot’s. Wie schon Oski schreibt, müsste da LM ran – wenn sie denn wollen.
Habe aufjedenfall eine starke Besserung durch Mesh Resolution auf 38m bekommen, jedoch dann gerade bei courchevel, einen komischen Berg links an der Piste zu beklagen.
Für mich erstmal erledigt und einen refund bekommen.
Mesh Resolution auf 38m mag helfen, aber dann frage ich mich, wofür ich 80 Euro für das Pilot’s NextGen Mesh ausgegeben habe, das mit Auflösungen bis zu 1m wirbt. Vermutlich lautet die Antwort, selber dran schuld.