Beiträge von Dietmar

    Nochmal zurück, warum Little Navmap einen Fehler meldet:


    Der Fehler liegt nicht im Little Navmap Programm, sondern in fehlerhaften apt.dat einiger Szenerien.
    Und zwar beim Code 21.
    21 Lighting objects VASI, PAPI, wig-wags, etc.


    Bei EDHL Luebeck-Blankensee steht:
    21 53.80415969 010.71028239 2 71.9800 3.00
    21 53.80639289 010.72762917 2 251.9800 3.00


    Das ist unvollständig. Nach der Spezifikation sollte es so aussehen, ein Beispiel:
    21 Row code for a lighting object 21
    47.53666659 Latitude of lighting object in decimal degrees Eight decimal places supported
    -122.30585255 Longitude of lighting object in decimal degrees Eight decimal places supported
    2 Code for type of lighting object Integer Lighting Object Code (see below)
    150.28 Orientation of lighting object in true degrees (looking toward object) Two decimal places recommended
    3.30 Visual glideslope angle in degrees Two decimal places. 0.00 if not required. Default is 3.00
    13L Associated runway number (required for VASI/PAPI, etc) One to three characters
    PAPI-2L Description of lighting object (not used by X-Plane Short text string (optional)


    Nach obigem Beispiel sollte also der vollständige Code 21 so aussehen:
    21 47.53666659 -122.30585255 2 150.28 3.30 13L PAPI-2L


    Somit hätte es zumindest bei EDHL so aussehen müssen:
    21 53.80415969 010.71028239 2 71.9800 3.00 07
    21 53.80639289 010.72762917 2 251.9800 3.00 25


    In allen bei mir gefundenen, fehlerhaften apt.dat wurden schlicht und einfach die dazugehörigen Runwaynummern weggelassen.
    Ei verdibscht!

    Alex Barthel arbeitet daran! Es muß also etwas in den apt.dat geben, welches er bisher nicht berücksichtigt hat.


    Beim Abspeichern eines Flugplans (fms) wird darauf hingewiesen, dass SID, STAR und User Waypoints (für VFR) nicht abgespeichert werden.


    1. Userwaypoints für XP 11 können in der Version 1.6.3 eingegeben werden.


    2. Auch SID und STAR können im Flugplan erscheinen, ist aber nicht direkt eingebbar.
    Man lässt sich SID und STAR anzeigen und fügt die gelb unterlegten Waypoints dem Flugplan zu. Kann sein, dass Alex daran auch noch bastelt.

    Von meinen 2623 Szeneriedateien waren es drei, welche Little Navmap zum Absturz veranlassten.
    EDHL Luebeck-Blankensee
    LOWS Salzburg
    RJOO Osaka


    In den apt.dat ist da etwas enthalten, was Little Navmap überhaupt nicht mag.
    X-Plane 11, WED und OE haben damit keine Probleme.


    Ich werde diese 3 apt.dat mit den jeweiligen aus der default apt.dat ersetzen.
    Diese sind mittlerweile auch sehr gut und ausgereift.

    Es herrscht ein gewisses Chaos mit FlyWithLua (FWL)!


    Ab Version 2.6.x sind (waren) die Private Data Refs gesperrt und LUA stoppt mit einer Fehlermeldung in der FlyWithLua_Debug.txt.


    Sieht so aus:
    [005337] FlyWithLua Error: The DataRef "sim/private/controls/clouds/cloud_shadow_lighten_ratio" can not be accessed from FlyWithLua, as it is a private DataRef. Reading or writing private DataRefs is prohibited by Laminar Research.


    [005338] FlyWithLua Info: Ben Subnik told us this: (Please see http://developer.x-plane.com/2…ls-are-an-active-volcano/ for more details.)


    [005339] FlyWithLua Info: The art controls are not a public interface to make X-Plane add-ons. They are an internal development tool. They are unsupported, undocumented, unsafe, and most importantly subject to change with every patch of X-Plane.


    [005340] FlyWithLua Info: If you create an add-on that requires reading or writing the art controls, you can expect that your add-on will stop working when X-Plane is updated. When your add-on breaks, please do not complain or file a bug.


    Reading or writing private DataRefs is prohibited by Laminar Research. (prohibited = verboten)


    Nana, starker Tobak ist das. Also, was steckt dahinter?


    Klar ist, dass ein Prvate DataRef (z.B.: set( "sim/private/controls/clouds/cloud_shadow_lighten_ratio", 0.3) ) von Laminar geändert, entfernt oder sonstwie behandelt wird, und damit nicht mehr seinen Zweck, für den es im LUA-Script gedacht war, erfüllen kann. Diese Einschränkung muß vom User bedacht und respektiert werden.


    Vor einiger Zeit wurde von Laminar ein Private DataRef geändert und nun funktionierte RTH (Real Terra Haze) nicht mehr und die sauren User haben Laminar und möglicherweise auch den Entwickler von FWL (Carsten Lynker aka X-Friese) mit nicht ganz sauberen Worten überzogen.


    Deshalb haben vor einigen Wochen X-Friese, Ben Supnik und Philipp Münzel beschlossen, dass in zukünftigen Versionen von FWL diese Private DataRefs "gesperrt" werden.


    Kurz darauf hat aber Ben Supnik dieses PrivateDataRef fog/fog_be_gone zur Anwendung empfohlen.
    Aber wie?
    Nun, man kann es mit dem DataRefEditor machen, hat aber den Nachteil, dass dieses bei jedem Neustart von XP erneut ausgeführt werden muß:


    Weitere Möglichkeit ist, dass sich der User ein LUA-Script schreibt und darin auf XPLM's zugreift. Wenn man googelt, findet man da auch solche snippets. Ich hab mir auch so etwas zusammengeschrieben, es funktioniert auch prima.


    Das ist aber keine Lösung für den Normalanwender, der mit Programmcodeschreiben nichts am Hut hat.


    Das hat auch X-Friese erkannt und nun seine Meinung erneut geändert. Er hat für diejenigen, welche gerne auf solche PrivateDataRefs zugreifen (er nennt sie Hacker) eine "komplette" neue Version von LUA, welche die bisherigen Einschränkungen des Zugriffs auf die Private DataRefs aufhebt, auf die org geladen, hier:
    http://forums.x-plane.org/inde…s-linux-mac-os-x-version/


    Die LUA-Version mit den Einschränkungen nennt er Core Edition, hier:
    http://forums.x-plane.org/inde…s-linux-mac-os-x-version/


    Somit kann nun jeder selber entscheiden was er so machen möchte, mit PrivateDataRefs oder lieber nicht.
    Aber bitte beachten: Wer sich für die Complete Version entscheidet, darf keinen Support erwarten oder herumheulen, wenn es zu Fehlern mit diesen privaten DatsRefs kommt und der X-Plane sich sogar verabschiedet.

    Mit dem Update von XP11 auf die Version 11.0.2.1 hat uns Ben ein ArtDataRef spendiert, mit dem die Dunstzwangsbeglückung aufgehoben bzw. abgemildert werden kann.
    Das ArtDataRef nennt sich: fog/fog_be_gone
    Die Werte können zwischen 0.0 (kein Dunst) und 1.0 (max. Dunst) liegen. Default = 1.0


    Mit dem DataRefEditor kann man sich einen passenden Wert einstellen. Allerdings muß das nach jedem Neustart von XP11 wiederholt werden.
    Gleichzeitig damit wird auch selber das ArtDataRef fog/std_deviation_cutoff geändert.


    Besser ist es ein LUA-Script zu erstellen oder schon ein bereits vorhandenes zu ergänzen.
    Dort trägt man folgendes ein: set( "sim/private/controls/fog/fog_be_gone", 0.3) -- default 1.0 0 keine 1.0 max


    Ich habe für mich den Wert 0.3 genommen, da ich als VFR-Flieger auch was in der Landschaft sehen möchte.
    Mit diesem Wert hat nun das ArtDataRef fog/std_deviation_cutoff automatisch den Wert 0.345 anstatt 1.5000 angenommen.

    Deswegen glaube ich weniger an eine Absicht der Entwickler, sondern an ein Problem des Overlay Editor mit der Brückenkonstruktion.


    Sehr gut gesagt Joachim,
    es ist wohl so, dass die Entwickler diese Brückenkonstruktion dem vorhandenen Mesh angepasst haben und somit negative Höhenwerte für die Vertexe der Brückenobjekts entstanden sind.


    Und das mag der OverlayEditor gar nicht!


    Alles was unterhalb der Höhe 0 des Airports liegt wird radikal abgeschnitten.


    Also mit dem WED arbeiten, aber keine earth.wed.xml erstellen lassen, das kann zu Schwierigkeiten bei sehr umfangreichen Szenerien führen.

    Cessna...................ILS?


    Ja doch, Hermann.
    Ist schon seit FS3 von MS und auch bei X-Plane in der Cessna drin. Ist nur eine Frage der Knete welche du ausgeben möchtest.


    Und jetzt für Peter:
    1. Am Update auf 11.0.1.2 liegt es nicht, das funzt.
    2. An der GraKa wird der ILS-Ausfall auch nicht liegen.
    3. Ich vermute da irgendeinen Konflikt mit den NAV-Daten.


    Was steht eigentlich im Verzeichnis ..\X-Plane 11\Custom Data ? ist das leer?


    Hast du in Custom Scenery den Ordner ..\X-Plane 11\Custom Scenery\Global Airports\Earth nav data drinnen, dann sperre oder umbenenne die Datei earth_nav.dat in earth_nav.org.
    Kannst aber den vorherigen Stand bei Bedarf wieder herstellen.

    Jedoch sind keine statischen Flugzeuge vorhanden.


    Warum wohl?
    Nun ganz einfach, dieses LSZH ist für den XP11 konzipiert!
    Daran ändert auch ein DSF-Update von AS nichts. Dort wurde nur auf ein eigenes xxx.for zurück gegriffen, das Szeneriekonstrukt ist nach wie vor XP11.


    Deshalb sind auch die statischen Flieger nicht zu sehen.


    Wie bekommt man diese trotzdem in den XP10?
    1. Voraussetzung: Das Häkchen bei den Rendering Options ist bei draw parked aircrafts at airports neben number of objects gesetzt,
    2. Beschafft euch den neuesten WED 1.6.0
    3. Kopiert, wenn ihr das noch nicht gemacht habt, die LSZH-Ordner nach XP10.
    4. Startet den WED und wählt als gültiges Verzeichnis X-Plane10 aus.
    5. Wählt dann Aerosoft LSZH Airport Zurich V2.0 a aus, die earth.wed.xml ist schon vorhanden, es wird sofort die apt.dat und alle Objekte in der DSF angezeigt.
    6. Bei File - Export Target wählt ihr X-Plane 10.50. Nur das garantiert die Sichtbarkeit der statischen Flieger.
    7. Nun noch bei File Export Scenery Pack wählen.
    8. Fertig!


    Was lehrt uns das?
    Was für den XP11 kreiert wurde wird auf XP10 noch lange nicht funzen.


    Man kann auch sagen: Es wurde ziemlich geschludert, ist aber verständlich wenn man sowohl an XP11-er wie auch an XP10-ner verkaufen möchte.

    Bei Aerosoft sollte die aktuelle Version ja für XP10 und XP11 gehen.


    Das stimmt so nicht, dort steht in der Dokumentation LSZH ist für XP11.


    In der +47+008.dsf steht POLYGON_DEF lib/g10/forests/AG_trees_EU1.for


    Dieses AG_trees_EU1.for gibt es nur in XP11. Es handelt sich hier um ein x.for und einer Textur aus der XP11 Library.
    Kopiert man das zu XP10 hinzu, funzt es.
    Kann ab er auch noch sein, dass da was anderes nicht geht.


    AS wird das sicherlich wissen, aber XP11 ist nicht XP10!

    Funkt bei mir auch nicht im XP10


    Diese Unbill ist natürlich sofort zu beseitigen!


    Also, so geht es:


    1. Kopiere AG_trees_EU1.for von ..\X-Plane 11\Resources\default scenery\1000 autogen\forests nach ..\X-Plane 10\Resources\default scenery\1000 autogen\forests


    2. Kopiere ag_trees_eu_ALB.png von ..\X-Plane 11\Resources\default scenery\1000 autogen\forests\textures nach ..\X-Plane 10\Resources\default scenery\1000 autogen\forests\textures


    3. Füge die beiden Zeilen:


    # AG vegetation
    EXPORT lib/g10/forests/AG_trees_EU1.for forests/AG_trees_EU1.for


    am Ende von library.txt des Ordners ..\X-Plane 10\Resources\default scenery\1000 autogen ein.


    Das isses und LSZH erstrahlt in vollster Pracht auch im XP10!

    Na ja, dann kauft man bei denen eben nichts mehr


    Das wird in fast allen Flusiforen schon seit zig Monaten wärmstens empfohlen.
    Die Praktik dieser "Firma" ist schon vielen Käufern ihrer Produkte auf den Keks gegangen und die haben sich natürlich, teilweise unflätig, über deren Gebaren grob geäußert. Das stört aber die CEO's dieses Ladens überhaupt nicht.


    Ich hab von denen auch mal so ein Wetterprodukt bestellt, das hat aber nur die fps in den Keller geschickt und mir unerwünscht das GIZMO aufgespielt.
    Das will ich nicht haben, es scheint ein LUA-Script zu sein, aber mit der höchst möglichen Verschlüssellungstechnik ausgestattet, welche es für Privatanwender gibt. Was macht dieses GIZMO, was ich nicht wissen darf?


    Jeder muß aber selber wissen, was er so tut, genauer was er kauft!