Jump to content

Beschränkung seit FlyWithLua 2.6.0 im Zugriff auf private DataRefs


X-Friese

Recommended Posts

Seit der Version 2.6.0 erlaubt FlyWithLua keinen Zugriff mehr auf DataRefs, deren Referenzname mit "sim/private/" beginnt.

 

Klingt erstmal nicht dramatisch, denn diese privaten DataRefs sind von Laminar Research nicht dokumentiert und vor allem nicht garantiert. Das bedeutet, dass mit einem Update von X-Plane ein privates DataRef plötzlich fehlen kann oder die Funktion eine andere ist, ohne dass Laminar Research sich offiziell dazu äußert.

 

Aus diesem Grund habe ich mich dazu entschieden, den Zugriff zu beschränken und Scripte beim Versuch auf "sim/private/..." zuzugreifen mit einem Fehler zum Stoppen zu bringen. Ich habe diesen Schritt nicht leichtfertig mal kurz gemacht, sondern lange überlegt und mit Laminar Research besprochen. Es kann in den Anfangszeiten neuer Hauptversionen von X-Plane zu häufigen Änderungen im undokumentierten Teil kommen, und ich möchte Ben Supnik bzw. Laminar Research hier den Freiraum geben, den sie benötigen. Man erlaubt den Zugriff über das C/C++ API (die Schnittstelle zu den DataRefs), sagt aber gleichzeitig deutlich, dass man sich so in die Karten schauen lässt, aber keine "neuen Mitspieler" bei der Gestaltung von X-Plane wünscht.

 

Würde man mit einem Lua Script auf "sim/private/..." zugreifen, dann könnte sich dieses Script als extrem beliebt herausstellen, aber das betroffene DataRef ist vielleicht nur ein vorübergehender Versuch von Laminar Research und verschwindet in einer der nächsten Updates wieder. Sofort hätte man tausende wütender Nutzer, die den technischen Hintergrund nicht kennen und einen Shitstorm lostreten dass X-Plane sehr unzuverlässig sei und man nie sicher sein kann ob Updates einen vorwärts oder zurück katapultieren. Das schadet dann langfristig auch uns, die wir als Community diesen doch sehr offenen Simulator sehr schätzen.

 

Und was bedeutet das jetzt für den Nutzer?

 

Wenn ein Script FlyWithLua zum Stoppen bringt, dann sollte man zuerst in das Log.txt sehen (kann man als Entwicklerkonsole direkt in X-Plane einblenden lassen). Wird dort darauf hingewiesen, dass der Fehler durch einen unerlaubten Zugriff hervorgerufen wurde, kann/sollte/darf man folgendes nicht machen.

 

  • Mir eine Mail oder PN schicken, denn ich werde euch nicht helfen.
  • Einen Shitstorm lostreten, denn das hat noch nie die Welt besser gemacht.

 

Ist die Lage also hoffnungslos?

 

Nein, natürlich nicht. Es gibt verschiedene Möglichkeiten für Nutzer mit dieser Situation umzugehen.

 

1. Möglichkeit: Autor des Scripts kontaktieren

 

Grundsätzlich sollte man für ein nicht (mehr) funktionierendes Script nicht mich (als Hauptentwickler von FlyWithLua) auf das Script hinweisen, denn ich kann mich darum nicht kümmern und möchte andere Autoren auch nicht bevormunden.

 

Der Autor oder die Autorin eines Scripts kann natürlich Hilfe von mir erwarten, wenn er oder sie sich an dieses Forum oder das englischsprachige auf x-plane.org wendet. Bitte keine direkte Mail oder PN, ich lese beide Foren regelmäßig, versprochen. Mails oder PNs, die auch im Forum als Posting möglich wären, lösche ich ohne weitere Rückmeldung. Bitte akzeptiert dies, ich entwickel FlyWithLua ehrenamtlich und meine Familie und mein Arbeitgeber gehen vor, meine Tage haben nur 24 Stunden.

 

2. Möglichkeit: FlyWithLua 2.5.3 weiternutzen

 

Für den ersten Moment werden betroffene Scripte sofort wieder nutzbar, allerdings kann man nicht mehr von der weiteren Entwicklung an FlyWithLua profitieren. Eine Übergangslösung ohne langfristige Perspektive.

 

3. Möglichkeit: Beschränkung entfernen

 

Ja, richtig gelesen. Diese Möglichkeit ist für C/C++ Kenner. FlyWithLua ist auf GitHub im Quellcode veröffentlicht und ich habe es ganz bewusst unter die MIT Lizenz gestellt. Wer will kann sich dort den Code herunterladen und FlyWithLua selbst compilieren. Bevor jetzt aber tausende Forks entstehen, schaut euch vorher unbedingt den Quelltext an. Um aus der offiziellen Version eine inoffizielle "Black Edition" zu machen, die den Zugriff auf die privaten DataRefs nicht begrenzt, genügt eine Compiler Direktive.

 

Laminar Research ist damit einverstanden, dass jemand, der sich mit C/C++ auskennt und ein C/C++ Plugin schreiben könnte, sich dennoch FlyWithLua bedient, denn er oder sie könnte es sonst ja auch direkt in C erstellen. Wollen sie das nicht mehr, müssten sie das SDK bzw. die API ändern, was ihnen ja freisteht.

 

4. Möglichkeit: Eine "Black Edition" aus dem Darknet?

 

Blödsinn, dank der MIT Lizenz braucht es keine illegale Plattform, jeder könnte ein modifiziertes FlyWithLua ganz offen anbieten. Befürchten müsste man nur sich bei Laminar Research nicht unbedingt beliebt zu machen. Von meiner Seite aus sehe ich das ganz entspannt, werde aber keinerlei Support geben. Mal abgesehen von der Möglichkeit der Compiler Direktive, die ich ab Version 2.6.1 eingeführt habe und im offiziellen Code beibehalten werde.

 

Was bleibt jetzt zu tun?

 

Die Community muss sich einig werden wie es weitergehen soll. Einige Autoren entwickeln bereits einen Weg auch mit der offiziellen Version von FlyWithLua durch direkten Zugriff über die Einbindung von C Code mittels der FFI Schnittstelle des JIT Compilers LuaJIT (das eigentliche Herz von Lua in X-Plane) an die privaten DataRefs heran zu kommen. Ich persönlich halte diesen Schritt für umständlich aber machbar.  Ob jemand die Freiheit der MIT Lizenz nutzt und eine Black Edition pflegt und veröffentlicht?

 

Hier könnt/solltet ihr bitte eifrig diskutieren. Eure Meinung interessiert mich sehr, und Laminar Research vielleicht auch. Durch respektvollen Umgang werden wir diesen Simulator mit Sicherheit weiter voranbringen. Und das kann nur im Sinne aller sein, der Anwender und des Herstellers.

Link to post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...