1.6 die Arbeitsumgebung
Ich weiß, Ihr wollt endlich loslegen. Trotzdem möchte ich noch ein paar einführende Worte dazu verlieren, wie man sich für die Lua-Entwicklung eine „Arbeitsumgebung“ schafft, die die Vorteile vorhandener Tools nutzt, insbesondere zu den Themen Editoren und dem Ethos Simulator.
Wer sowieso bereits programmiert, wird seinen „Lieblingseditor“ weiter nutzen wollen. Wer eher am Anfang steht und sich fragt, welchen Editor er nutzen sollte, dem möchte ich zwei (Windows) Empfehlungen geben:
Ein Open-Source/Free-Software-Projekt, das weit verbreitet ist. Vorteile sind einfache Anwendung, „Lua“-Unterstützung (farbliche Markierungen/Hervorhebungen des Codes), portable, etliche Zusatz-AddOns etc. Definitiv weit verbreitet und willkommen, wenn schnelle Einarbeitung und einfache Anwendung über der Anzahl der Features steht.
Wie der Name vermuten lässt, stammt Visual Studio Code aus dem Hause Microsoft. VS Code ist ebenfalls kostenlos und funktional noch umfangreicher als Notepad++. Wer seine Projekte auf GitHub veröffentlichen möchte, ist bei VS Code erst recht gut aufgehoben, da hier Add-Ons existieren, um Dateien direkt mit Git abzugleichen (push/pull/commit etc.).
VS Code lässt sich extrem individualisieren, was allerdings eine entsprechende Einarbeitung in die Config-Dateien erfordert. Die Lua-Code-Unterstützung „out of the box“ ist noch umfangreicher als bei Notepad++, zum Beispiel sieht man bereits farblich, ob definierte Variablen oder Funktionen im Code überhaupt genutzt werden (farblich ausgegraut).
VS Code besitzt mehr Funktionalitäten als Notepad++, erfordert jedoch auch mehr Einarbeitungszeit. VS Code ist für diverse Betriebssysteme verfügbar (Windows, Linux, macOS).
[VS Code Webseite](https://code.visualstudio.com/) 
Der Ethos Simulator ist ein hervorragendes Tool, um seine Scripts während der Entwicklungsphase zu testen, ohne den Sender zu benötigen. Zum einen besitzt der PC, das Notebook oder der Mac deutlich mehr Performance, was insgesamt zu einem flüssigeren Arbeitsablauf führt. Die „Coden > Testen > Analysieren > Coden“-Zyklen sind am Simulator einfach schneller. Zudem nutzt sich der Sender nicht so schnell ab.
Zum anderen hat man natürlich die Einschränkung, dass nicht restlos alle Funktionen (z.B. Trimmbedienung, bestimmte Telemetrie-Situationen) nachgestellt werden können (Stand Ethos 1.5.x). Ich persönlich nutze zu rund 90% der Entwicklungsaufwendungen den Simulator.
Der aktuellste Simulator ist im jeweils aktuellen Ethos Release (latest) auf GitHub zu finden. Bedient wird der Simulator hauptsächlich via Maus. Bedienelemente wie Schalter, Sticks etc. werden über die Tastatur emuliert.
Um am Simulator die Telemetrie nachstellen zu können (nur Fixwerte), muss am Simulator das RF-Modul eingeschaltet sein. Sollte der Modellspeicher noch keine Telemetriesensoren besitzen, dann können diese im Telemetriemenü per Suche definiert werden. Es werden alle typischen Sensoren gefunden.
Ab Version 1.5.12 wurde die Verwendung von Ordnern bzw. die Pfade erheblich umgestaltet. Zuvor wurden Modellfiles zentral in der Benutzerumgebung abgelegt, und der Simulator selbst lief mit allen weiteren Ordnern (audio, bitmaps, scripts, usw.) in seinem Installationspfad. Für jede „Umgebung“, wie z.B. spezifische Sim-Releases, Betas, Arbeits- und Entwicklungsumgebungen, war eine eigene Installation notwendig, die sich ein Modellverzeichnis teilten.
Dies führte bei gleichzeitiger Verwendung von Simulatoren unterschiedlicher Releasestände zu Problemen. Nun, ab Version 1.5.12, wird eine hardware-spezifische „Userumgebung“ unter dem Ordner .ethos im Windows-Benutzerpfad angelegt.
Sie enthält die Ordner logs, models und scripts, sowie die radio.bin-Datei inkl. Sendersettings. Alle restlichen Ordner befinden sich im Installationspfad.
Ab Version 1.5.12 kann beim Start eines Simulators über Parameter bestimmt werden, welcher spezielle Ordner für welchen speziellen Zweck (audio, system, scripts, usw.) verwendet werden soll (Re-Routing).
-
--system-directory: System-Verzeichnis (z.B. i18n, bitmaps) -
--user-directory: Die typischen User-Verzeichnisse (logs, models, usw.) -
--scripts-directory: Ordner für Scripts -
--radio-settings: Legt dedizierteradio.bin-Datei fest
set SIMEXE=D:\Programme_U\Ethos\x18.12
set SIM=0 environment A
d:
cd %SIMEXE%
simulator.exe --system-directory "D:\Programme_U\Ethos\x18 n\%SIM%\system" --user-directory "D:\Programme_U\Ethos\x18 n\%SIM%" --scripts-directory "D:\Programme_U\Ethos\x18 n\%SIM%\scripts"
### Struktur des Ordners der Arbeitsumgebung „0 environment A“:
Der Ordner „0 environment A“ sollte dann so aussehen:
- **soundfiles**: Eigene Sounddateien
- **modelfiles**: Modelldateien
- **scripts**: Lua-Scripts
- **radio.bin**: Die dedizierte `radio.bin`-Datei
Eine weitere Arbeitsumgebung ließe sich einfach und ohne zusätzliche Simulator-Installation durch eine angepasste Batch-Datei und einen weiteren „Umgebungs-Ordner“, z.B. „0 environment B“, erstellen.