[FSX:SE] Exzessiver Autogenkahlschlag um EDAZ

Diese Seite ist ohne Werbung und die Angebote sind frei für alle Mitglieder verfügbar. Bitte unterstütze uns.

  • Erst:
    Danke für EDAZ (und Strausberg!).
    Ich war gestern zum ersten Mal überhaupt während einer Radtour am Flugplatz und fand ihn schön gelegen, weil quasi fast im Wald.



    Jetzt stelle ich aber fest, dass der Wald, jedenfalls in der FSX-Version, anscheinend abgeholzt wurde.



    Mit etwas trial&error habe ich EDAZ_MISC_OBJ.bgl und EDAZ_Airport_OBJ.bgl als die Verursacher festgestellt. Ohne die beiden Dateien sieht der Platz drumherum aus, wie er aussehen soll:



    Ich dachte zuerst an ein zu groß geratenes Exclusion-Rechteck in einer der beiden Dateien, aber nur EDAZ_Airport_OBJ.bgl beinhaltet eins und ohne dieses Rechteck in der BGL ändert sich bezüglich Autogen absolut nichts.
    Daher vermute ich, dass irgendwas in den MDL-Dateien der verwendeten Libraries dafür verantwortlich ist.


    Tritt dieses Problem in der P3D-Version auch auf?


    Hast du 'ne Idee, was dafür verantwortlich sein könnte? So objektmäßig?
    Irgendwas großflächiges das von den Dateien referenziert wird?

    • Offizieller Beitrag

    Hallo Bjoern,
    bei P3D ist das nicht.
    Was ich da sehe, ist Autogenunterdrückung im FSX:SE. Wird aber das Grundpoly, die Runway sein . Die von Dir genannten Dateien eher nicht. Zudem spielen auch noch Addon ne Rolle. Stelle Dich einfach mal an Parking 1 und wechsle dann den Standort (nicht slew) . Ich habe keinen FSX mehr. Es wird aber für meine Szenerien keine FSX Updates mehr geben. Schaffe ich einfach nicht. Für SE habe ich zudem noch nie etwas gemacht, meine Sznenerien wurden nie in SE getestet. Mache ich auch nicht, weil Steam für mich das "rote Tuch" schlechthin ist. Da bin ich ganz ehrlich. Aber das ist Ansichtssache. :smiling_face:

  • Danke für die Antwort. Updates erwarte ich auch nicht, nur etwas Hilfe zur Selbsthilfe.


    Habe den/die Übeltäter inzwischen gefunden: EDAZ_AN2_Static.bgl, EDAZ_bo105.bgl und EDAZ_StaticL60.bgl.


    Dachte zuerst, dass der Model-Radius ähnlich wie bei KI-Fliegern hier eine Rolle spielt, aber eine Änderung hat nichts bewirkt.
    Allerdings sind diese drei die einzigen Modelle unter den statischen Fliegern, die noch Animationen haben...also mal mit ModelConverterX die Animationen gelöscht und siehe da, ich habe mit den Dingern im Simulator wieder volles Autogen!


    Wieder was gelernt.


    Jetzt muss ich mich bloss noch um die flimmernden Run- und Taxiways kümmern...

    • Offizieller Beitrag

    Danke für die Mühe und die Hinweise, wird sicher andren auch helfen. Auch wenn ich mir nicht vorstellen kann, dass diese schuld sind, es sei denn die Animationen waren weit entfernt und die Bounding Box dadurch sehr groß. Aber egal wichtig ist, dass es weg ist. Wie gesagt SE kann ich keinerlei Aussage treffen.


    Runway und Taxiway flimmern bei mir auch nicht und auch nicht bei den Testern. Allerdings war die FSX Version ein reines Nebenprodukt. Ich kann nur für P3D sprechen.


    Was du machen kannst, die Boundig Boxes überprüfen und mit dem mdl Tweaker vom MCX eventuell mal verkleinern.
    Möglich wäre auch noch das Groundpoly erneut mit andren Optionen in MCX zu compilieren.

  • Die Boundingboxes hatte ich testweise mit dem Radius bei der Anna auf 0 gestellt, aber es hat, wie gesagt, nichts gebracht. Nur das Einfrieren/Entfernen der Animationen.
    Wer weiss wie der FSX sowas handhabt.




    Die Runways flimmern nur bei quasi senkrechtem Betrachtungswinkel, am Boden geht's. Der FSX mag das Sandwich aus Fototapete, Groundpolys und ADEX-Datei vielleicht einfach nicht.

    • Offizieller Beitrag

    Ne schlag mich tot, das Problem gibt es in vielen FSX Szenerien, aber ich weiß die Ursache nicht. Hier kommt hinzu , dass ich in P3D nach SDK entwickelt habe und dann die Szenerien abwärts transferiert wurden. Ich konnte nur in P3D v1 testen, was dem FSX entsprach.
    Heute noch machen es die meisten umgekehrt, entwickeln im FSX transferieren und verkaufen es als P3D.


    Beide Möglichkeiten sind eigentlich blanker Mist. Man entwickelt in einem System und sollte auch dann nur dieses daraus bedienen. Deswegen mache ich nur noch Prepar3D 64 Bit, also ab v4

  • FSX -> P3D macht theoretisch mehr Sinn als umgekehrt, da man so größtmögliche Kompatibilität hat (vom 32-/64-bit Problem mal abgesehen).


    Glaube der FSX braucht ein paar Millimeter Abstand zwischen dicht überlagerten Objekten, damit das Layering in z-Richtung ohne Tricksereien bei den Materials (z-Testing) funktioniert.
    Wenn ich die Muße habe, teste ich das mal an den Ground Polys.

    • Offizieller Beitrag

    FSX -> P3D macht theoretisch mehr Sinn als umgekehrt


    Weder so noch so macht wirklich Sinn, nicht umsonst hat jeder sein eigene SDK. Beim FSX muss man die Schatten selbst machen, bei P3D geht das automatisch nach Licht Verhältnissen. FSX arbeitet mit positiven Z- Bias , P3D mit negativen und und und.


    Der Wandlungsblödsinn hat Euch seit dem FS9 Addons gebracht, die nie native waren aber immer wieder neu dem Kunden angedreht wurden, mit missliebigen Folgen. Die Foren sind voll davon.
    Aber wie gesagt, der FSX ist, zumindest bei meiner Entwicklung, Geschichte. ich mache da nichts mehr. Auch nicht an den alten Addons. Da supporte ich nur die P3D Version weiter.
    Aber noch ein Tipp, schaue mal nach der Wirkung der globalen Addons, die dort alle ne LC haben und u.U. mitspielen
    Wenn man ein P3D ein Addon hat und im FSX sieht, ist es nicht P3D.


    Du kannst aber gerne basteln wie Du willst, nur Unterstützung gibt es nicht. Am Groundpoly rum zu frickeln empfehle ich eher nicht, da Du keine Quelltexte hast und der Platz über ein eigenes Mesh verknüpft ist.