Wenn du trotzdem an deinem Wunsch festhältst und auch andere dies wollen, könnte ich eine weitere Option namens printVersionInfo hinzufügen, die dann die gewünschte Info ausgibt.
Hallo Benny :)
das handhabe ich genauso und wäre ganz in meinem Sinne.
Die Rangelei um Lokale Variablen ist unnötig weil im Profi-Bereich, in allen Programmiersprachen, immer Lokale bevorzugt werden.
Da zeigt sich halt der wahre Profi
Gruß Ingo
immer Lokale bevorzugt werden.
vor allen Dingen, wenn und weil es da erfrischende und/oder berauschende Getränke und Geselligkeit gibt. 
Hallo Ingo ( schlingo ),
der wahre Profi zeigt sich darin, dass er die Version, global/local, einsetzt, die für das aktuelle Problem die beste Lösung ist.
Und da können auch globale Variablen sinnvoll sein.
Ich möchte nur als Beispiel Programmeinstellungen nennen, die einmalig, z.B. beim Programmstart, eingelesen werden und in verschiedensten Funktionen verwendet werden.
Da werden in den seltensten Fällen bei jedem Funktionsaufruf die Einstellungs-Werte als Parameter übergeben (durchgeschleift) oder in den Funktionen jedesmal die Einstellungs-Werte neu gelesen.
Aber das Problem mit den Kontaktpunkt-Funktionen mit Parametern wäre schon lange keines mehr, wenn das Manko, ich möchte es den Fehler nennen, sofort nach dem Feststellen in EEP behoben worden wäre, als dieser durch die User festgestellt wurde.
So verlässt man sich von Seiten Trend einfach auf ein Dauer-Work-Around, der den Fehler behebt.
Hallo Benny,
den Wunsch lasse ich mal so stehen, auch wenn ich diesen nicht mehr benötige, denn Du hast ja eine Zeile spendiert.
print("Die Version von BetterContacts ist " .. table.concat(require("BetterContacts_BH2")._VERSION, "."))
Bei mir steht es halt so da.
Grundsätzlich habe ich immer 2 EEP-Versionen aktiv mit separaten LUA-Ordnern, da kann man schon mal ein Update in einer Version vergessen.
Des weiteren kommen auch mal User und haben eine Herausforderung (Problem), da ist es hilfreich für mich, wenn das Skript geladen wird, welche Module mit welcher Version aktiv sind. Das nur als Hintergedanke von mir.
Mir persönlich reicht die eine Zeile außerhalb des Skriptes. 
Heute ist das Plugin 3 für EEP16 erschienen, nun übergibt EEP bei einem Kontaktpunktaufruf auch die ID des Gleises, auf dem der Kontaktpunkt liegt, an die aufgerufene Lua-Funktion.
Mir fällt dafür zwar kein Anwendungsfall ein, der nicht durch BetterContacts besser abgedeckt würde, aber meine mangelnde Fantasie soll euch nicht abhalten:
Ab sofort gibt es auf meiner Homepage (und auf GitHub) die Version 1.1.0 von BetterContacts!
Mit der neuen Option varnameTrackID kann nun ein Variablenname festgelegt werden, unter dem die Gleis-ID innerhalb des Kontaktpunkt-Eintrags zur Verfügung stehen soll . Standardmäßig ist kein Variablenname vergeben (ein vorgegebener Name könnte eine globale Variable gleichen Namens verdecken, das wäre ein Breaking Change); um die Gleis-ID nutzen zu können, müsst ihr also erstmal selbst einen Variablennamen vergeben.
Und wo ich schonmal dabei war, habe ich auch noch gleich die schon länger versprochene Option printVersionInfo implementiert.
Ein Minimalbeispiel, das beide Neuerungen zeigt:
Eintrag im Kontaktpunkt: print("Zug ", Zugname, " auf Gleis ", TrackID)
Ausgabe im Ereignisfenster (mit Plugin 3 zu EEP16):
Wer das Plugin 3 nicht hat, kann BetterContacts v1.1.0 übrigens trotzdem nutzen. In diesem Fall bleibt die Variable mit der Gleis-ID halt einfach nil.
Im Ereignisfenster sieht das dann so aus (EEP16 ohne Plugin 3):
Ich hoffe, ihr könnt damit etwas anfangen 
Rückmeldungen sind wie immer gerne gesehen, allerdings finde ich vermutlich erst morgen Abend wieder Zeit, ins Forum zu schauen.
Viele Grüße
Benny
Ich möchte das Kompliment von Bottazzoli ergänzen. Es ist eine elegante Lösung für eine fehlende Einrichtung, die nahtlos funktioniert. Danke.
Ich glaube auch nicht, dass varnameTrackID allzu wichtig ist.
Trotzdem wundert es mich, dass nach meinem Test im neuen EEP 17 für TrackID auch nur nil geliefert wird, bzw. eine globale Variable TrackID nicht geändert wird. Ich dachte, dass EEP alle Plugins von EEP 16 enthält.
Hallo Frank,
bei mir funktioniert alles unter EEP17.
Ich habe aber die Variablen abgeändert nach meinen Wünschen schon in EEP16.
Sieht dann so aus:
Im Kontaktpunkt steht dann z.B.
Bei mir wird immer die richtige Tabellen-Position gefunden, denn die Gleis_ID ist gleichzeitig eine Untertabelle, welche weitere Untertabellen beinhaltet.
Hallo Frank,
Trotzdem wundert es mich, dass nach meinem Test im neuen EEP 17 für TrackID auch nur nil geliefert wird, bzw. eine globale Variable TrackID nicht geändert wird. Ich dachte, dass EEP alle Plugins von EEP 16 enthält.
Ich habe es gerade probiert, und ich bekomme mit meinem Beispiel von oben (aus #25) auch in EEP17 die Gleis-ID ausgegeben.
Hast du daran gedacht, TrackID als Variablennamen festzulegen? Dass und warum das nötig ist, habe ich ebenfalls in #25 beschrieben.
Eine globale Variable sollte generell nicht mehr geändert werden (es sei denn, du hast explizit deprecatedUseGlobal eingeschaltet. Dann ist der Variablenname für den Zugnamen festgelegt, und es lässt sich auch kein zweiter vergeben).
Viele Grüße
Benny
Asche auf mein Haupt, kaum macht man es richtig funktioniert es - und ich weiß nicht was ich gestern beim Eintippen falsch gemacht habe.
Vielen Dank für's bestätigen.
Schönen Gruß
Frank
Hallo Benny,
habe gerade Deine Funktionserweiterung getestet, funktioniert genial, wie alles, was Du programmierst...
Schönes Wochenende
Gruß Frank
