OrbX LOWI, ESGG Ground Fix- Der Fix der überall in Prepar3D v5 funktioniert

[Simmershome]

Alle grübeln noch, ich bis heute auch. Ich habe jedoch heute herausgefunden warum in LOWI und anderen Plätzen der Ground schnippt oder nicht sichtbar, oder verschwommen ist.

Was mache ich mit dem Wissen? Da muss ich ausnahmsweise echt überlegen.

Aber hier das Beweisvideo

 

 

[AnkH]

Danke, aber die Geheimniskrämerei behagt mir nicht: wie fixt man das?

[Simmershome]

Nun, ich verstehe Dich zwar, aber drastsich ausgedrückt:

 

Den Patch gebe ich sicher frei, aber nicht gleich. Ich bin für so viele der "Oberarsch"  oder bestenfalls Bastler und werde denen, die damit Geld verdienen, nicht das Ergebnis auf dem goldenen Tablett servieren. For allem nicht OrbX, die mich aus Befindlichkeiten eines einzelen Herren, nach wie vor vom Support ausschließen.

 

Orbx hofft, dass sich der HF2 darum kümmert... und wartet einfach ab.
Da ich weiß, was die Ursache dafür ist, glaube ich nicht, daß der HF2 das Problem lösen wird.
Aber ich werde einfach warten, bis der HF2 erscheint.
LM müßte etwas an der Geländebehandlung der Stockim ändern. Werden sie das tun?
Jedenfalls wäre es einfacher, wenn OrbX etwas an seiner Methode ändern würde. Es dauert nicht länger als 10 Minuten, und es ist behoben.
Ich habe zwei zwei Tage auf meinem eigenen (fremden) Flughafen  im Russia Project  mit dem Problem gekämpft, bis ich auf die Ursachen und dann die Idee kam. Es ist 100% SDK-kompatibel. Dann habe ich es erst auf OrbX LOWI ausprobiert und es funktioniert auch dort.

 

Die Meisten werden das Problem nie haben, aber OrbX wird  seine Groundbehandlung für Prepar3D v5 Airports wohl fundamental ändern müssen. "One for all" wird eben in bestimmten Situationen nicht mehr klappen. Aussitzen und hoffen wohl eher auch nicht.

 

Aber man weiß ja nie, LM hat sich ja auch wieder breit schlagen lassen, dass getweakte alt SCASM Files wieder klaglos laufen.

Der Weg für jede Menge neue "Professionals" oder "Next Generation" ist frei.

Bearbeitet 15. Juni 2020 von Simmershome

[Simmershome]

Nachgereicht Winter. Also die Jahreszeiten funktionieren über objectflow auch. Ich habe also allem Anschein nach das Problem wirklich an der Wurzel erwischt

 

 

@AnkH

P.S. Das darf gerne im OrbX Forum gepostet werden, ich habe ja leider keinen Zugriff, bzw. will mein "Lesekonto" nicht kompromittieren sonst wäre es schon drin.

 

Hier ist der passende Thread

https://orbxsystems.com/forum/topic/191604-lowi-and-esgg-ground-texture-issue/?tab=comments#comment-1650686

 

 

Bearbeitet 15. Juni 2020 von Simmershome

[Simmershome]

Also nun ESGG Landsvetter. Die meiste Zeit verbringe ich als Nobody damit die richtigen Files zu finden. Dann dauert es 5 Minuten

 

Hier ESGG voher

 

 

ESGG nachher

 

 

Also bis zum Wochenende hat sich das sicher rumgesprochen und solange muss OrbX warten. Jedenfalls muss LM garnichts ändern. AM Wochende gibt es die öffentliche Auflösung des Rätsels. Ich trinke gerne Kaffee (ja ich bin bescheiden....manchmal)

[AnkH]

Interessant ist ja, dass ich das Problem weder auf LOWI noch ESGG habe, was ist also bei mir anders? Oder ist es mir schlicht nicht aufgefallen? Bin aber auf jeden Fall gespannt auf Deine Lösung

[Simmershome]

vor 3 Stunden schrieb AnkH:

Interessant ist ja, dass ich das Problem weder auf LOWI noch ESGG habe, was ist also bei mir anders? Oder ist es mir schlicht nicht aufgefallen? Bin aber auf jeden Fall gespannt auf Deine Lösung

 Hm, da wärst Du der Einzige in P3D v5. Drehe Dich doch mal um die eigenen Achse am Starting Point. Wenn Du vorher das Groundpoly gesehen hast, siehst Du es wegschnippen

 

P.s.

Wie zu erwarten ist der OrbX Thread closed

Das sind echte Kinder. Wäre da mal einer über seinen Schatten gesprungen, hätten sie es frei Haus gehabt.

Na mal sehen vielleicht finden Sie es ja diese Woche. und es kommt ein offizieller Patch vom Himmel

Bearbeitet 15. Juni 2020 von Simmershome

[AnkH]

Rainer, wie siehts aus? Ich habe Deine Message auf simmershome gesehen, ebenfalls die peinliche Threadschliessung im ORBX Forum, echt nur erbärmlicher Zug von ORBX. Das Gute: es wird noch den einen oder anderen Thread geben bis sie mit einem Patch rauskommen, das wird sie ordentlich nerven. Mehr kann man ja nicht tun, leider. Freue mich weiterhin auf Deine Anleitung, da es mich tatsächlich interessiert, wo das Problem liegt (weiss gerne solche Dinge ;-)). 

[Simmershome]

Das Problem habe ich schon in einem Artikel hier liegen, weil es auch später auftreten wird. Aber ich werde OrbX nicht vorab verraten, was zu tun ist. Da müssen sie schon selber suchen. Der Artikel erscheint nachdem OrbX die eigene Lösung gefunden hat. Auch dann ist er nützlich, denn ich gehe davon aus, dass sie der Öffentlicheit nicht mitteilen, wie sie es machen.

Mir bekannte Mitglieder haben die Möglichkeit den Patch per Konversation abzufordern über meinen privaten FTP Zugang, in dem alle Patches sind, die ich für mich privat mache.

Bearbeitet 22. Juni 2020 von Simmershome

[Simmershome]

Heute hat OrbX zumindest LOWI gefixt , nachdem sie Wochenlang behauptet haben, das müsste der Hotfix 2 von LM tun.

 

Hier meine Lösung, wie sie funktioniert hat und schon lange etliche User erfreut.

 

LM hat uns mit Einführung von Prepar3D v5 ein korrektes Terrain geliefert. Auf diesem Terrain liegen die Stock Runways. Diese können nicht nur komplett sloped sein, sondern eben auch einer steigenden oder fallenden linearen Höhe von einem Startpunkt zum anderen Startpunkt folgen.

Es gibt viele Plätze, so auch LOWI, wo dies so ist.

Groundpolys arbeiten in der v5 genau dann korrekt, wenn man den ARP des Platzes auf die Höhe des höchsten Punktes der Stockrunway setzt. Das realisiert man in ADE mit dem Parameter sloped.

In den von mir getesteten Fällen, wo Fehler auftraten und Bestandteile des GP schnippten, lag die Höhe des ARP immer zwischen den beiden realen Höhen. Es betraf auch nur transparente und überlagerte Bestandteile, wie zum Beispiel Lines etc. Es tritt ferner nur auf wenn das betroffene GP nur aus einem gesamten Element besteht.

 

Also, das Groundpolygon (Basis) war immer vorhanden, aber überlagerte Teile darüber verschwanden.

 

Es ist ein erheblicher Aufwand den ganzen Platz neu anzupassen.

 

Hier kam mir folgender Ansatzpunkt, den wir alle kennen und mit MCX realisieren können, zu Hilfe.

Wenn ich davon ausgehe, dass sich unter mir eine schräge Fläche befindet und ich darauf eine gerade Fläche lege, dann wird die obere Fläche instabil und schnippt eben weg, wie eine Wippe.

Ist die obere Fläche transparent wird sie unsichtbar und ich konnte nachvollziehen, dass sie bei „slew“ aus etwas größerer Höhe wieder sichtbar wurde.

 

Mathematisch gesehen braucht man die obere Fläche nur in so kleine gleichmäßige Teile zerlegen, dass die Steigung oder ein Gefälle darunter keine Auswirkung hat, weil sie bezogen auf die Länge des Abschnittes, zu gering ist.

 

Dieses Werkzeug bietet der GP Wizzard von MCX uns schon immer.

Zunächst muss man eine eventuelle Placement Datei des GP entfernen oder deaktivieren und das GP direkt platzieren inklusive exakter Höhe. Diese Datei sichert man als Basis. Danach wird sie im GP Wizzard genügend klein gruppiert, jedoch keinesfalls sliced. Das Maximum war bei mir 50m , in einem Falle sogar nur 10m.

 

Größere Gruppierungen (500m) waren erfolglos. Man muss es austesten

Ich habe drei Airports, auf welche die oben genannten Gegebenheiten zutrafen behandelt und alle drei laufen danach ohne Probleme.

 

Ob meine Theorie richtig ist, weiß ich nicht, weil ich intern keinen Einblick habe. Es funktioniert aber offensichtlich in der Praxis und das ist der einzige relevante Punkt für mich.

 

Fazit:

• Bei Neubau eines Airports gleich auf der richtigen Höhe bauen und die Runway als sloped definieren sollte funktionieren.
• Bei Nachrüstung / Update sehr klein gruppieren funktioniert nachgewiesener Weise
• Eine Erklärung warum sich das darunter liegende GP ohne Transparenz nicht verändert habe ich nicht. Es ist mir aber auch egal.

Bearbeitet 26. Juni 2020 von Simmershome