Warum Lua

!!! Please ensure, that your contribution or question is placed into the relevant section !!!
Questions about rolling stock, for example, do not belong in "Questions about the Forum". Following is perhaps the right area where your question will be better looked after:
General questions to EEP , Splines, rolling stock, Structures in EEP, landscape elements, Signalling system and controlling, designers, Europe-wide EEP meetings , Gossip
Your cooperation to keep the forum clear is appreciated.
  • Hallo,


    Nachdem ich mit einigen Usern über Lua diskutiert habe, bin ich zu folgenden Schlüssen gelangt.

    • Das das EEP-Team sich entschlossen hat Lua als Programmiersprache zur Verfügung zu stellen hat einiges für sich...
      1. Die Sprache ist in der Struktur eine Script, welche die Funktionen einfach erreichen lässt.
      2. Sie ist im Prinzip einfach erlernbar
      3. Sie beinhaltet sehr mächtige Befehle
      4. Sie beruht in sich auf nur einem Datentyp, was dem User einiges an Gedankenarbeit und Wissen erspart.
      5. ist nicht so strikte wie z.B. PASCAL, welches z.B. jede Variable als vor-gängig deklariert verlangt.
      6. Unterbindet im Gegensatz zu C oder andere Prozessor-Nahe Sprachen (bez. gar Assembler welches direkt mit dem Prozessor kommuniziert), Speicher- und insbesondere Prozessor-Zugriffe.
    • Was spricht gegen Lua? Im Prinzip ja nichts...


      • Nur - Ich persönlich fände für den Durchschnitt-User von EEP eine Graphische Oberfläche viel geeigneter
        1. Script-Sprachen sind sehr abstrakt und erschliessen sich daher vielen nicht
        2. Visuelle Darstellung:
          • erleichtert einfache Abläufe zu realisieren.
          • sind viel leichter nachvollziehbar
          • sind von Natur aus besser Strukturiert, da zusammengehörige Funktionen zwangsläufig in direkter Abfolge erscheinen.
        3. Eine gute Strukturierung ist in Scripts nur mit Fleissarbeit erreichbar.
        4. Das nachträgliche Korrigieren oder Erweitern ist, insbesondere bei fremd entwickeltem Code, oft sehr schwer realisierbar.
          • Davon können die Programmierer nun wirklich ein Lied singen...


    Ich lasse das jetzt mal so stehen. Mögen jene, welche dazu etwas zu sagen haben, sich dazu äussern.

    EEP v13.2 Patch 1, Plugin 1&2

    hat ein klein wenig Ahnung von System-Programmierung :bn_1:

    https://picload.org/image/dddgolpr/gueter.png


    Windows 10 Pro 64-Bit

    HP Compaq 8100 Elite CMT PC / Intel(R) Core(TM) i5 CPU 760 @ 2.93GHz RAM 12GB

    HP Prolient Debian 9.6

    GeForce GTX 1050 Ti 2 * 23" Wide LCD Monitor & 1*25" LCD

    The post was edited 1 time, last by Marino ().

  • Eine grafische Oberfläche gibt es bereits: Schaltkreise.

    Das ist in meinen Augen aber keine "gleichwertige Alternative".


    Ein weiterer Punkt, der mMn berücksichtigt werden sollte (und von Trend berücksichtigt wurde): Lua gibt es schon, und lässt sich relativ einfach in bestehende Programme integrieren.

    Eine "grafische Oberfläche", wie du sie dir vorstellst, hätte vermutlich komplett neu entwickelt werden müssen. Das hätte vermutlich viel zu viel Arbeitszeitg der Entwickler gebunden.


    Viele Grüße

    Benny

  • Ich persönlich fände für den Durchschnitt-User von EEP eine Graphische Oberfläche

    Was meinst Du damit: Ein grafisches Front-End für Lua oder etwas anderes? Was soll unter der Oberfläche sein?

    Eine solche Graphische Oberfläche ist z.B. in vielen SPS-Programmiertools verwirklicht => IEC 61131-3.

    Dabei werden grundsätzlich 2 Prinzipien unterschieden.

    • FBD Function Block Diagram
      • Dabei sind unter die FNK (Headerlose Funktionen) und und FB
        (Funktionsbausteine) einfach Graphisch dargestellt und können so direkt mit einander verknüpft werden.
    • SFC Sequential Function Chart
      • Hier sind die einzelnen Schritte graphisch dargestellt.
      • Das Ganze gliedert sich:
        1. Schritte
        2. Aktionen
        3. Transitionen

    Dahinter liegt in der Regel eine Standard-Sprache - könnte hier Lua sein.

    • In den Tools die ich in der Regel für die Automation nutze finden sich hier C , PASCAL, ST

    Es ist mir natürlich klar, dass eine solche Benutzeroberfläche einigen Aufwand mit sich bringt.

    Und ich mache es nun wirklich auch niemandem zum Vorwurf, dass Solches hier nicht realisiert vorliegt.

    Ich denke aber, dass solches für die Zukunft doch ins Auge gefasst werden sollte.


    ps


    Der Vorteil dieser Programmierart ist insbesondere, dass man über das Zugreifen auf die FB und FNK diese editieren, sowie neue erstellen kann. So kann die Bibliothek von jedem User seinen Bedürfnisse angepasst werden...

    EEP v13.2 Patch 1, Plugin 1&2

    hat ein klein wenig Ahnung von System-Programmierung :bn_1:

    https://picload.org/image/dddgolpr/gueter.png


    Windows 10 Pro 64-Bit

    HP Compaq 8100 Elite CMT PC / Intel(R) Core(TM) i5 CPU 760 @ 2.93GHz RAM 12GB

    HP Prolient Debian 9.6

    GeForce GTX 1050 Ti 2 * 23" Wide LCD Monitor & 1*25" LCD

    The post was edited 1 time, last by Marino: Ergänzung ().

  • ist nicht so strikte wie z.B. PASCAL, welches z.B. jede Variable als vor-gängig deklariert verlangt.


    Das empfinde ich persönlich als Nachteil, denn es ist eine nicht zu verachtende Quelle für Fehler durch Tippfehler.


    Das nachträgliche Korrigieren oder Erweitern ist, insbesondere bei fremd entwickeltem Code, oft sehr schwer realisierbar.


    Das wird Einem sogar in selbstgeschriebenem Code passieren, wenn man diesen nicht gut dokumentiert hat.

    Gruß

    Georg


    EEP15 P3, Modellkatalog, Tauschmanager, Hugo, BilderScanner, ModellExplorer, ZugExplorer, EEP6 + Modellkonverter

    Win 10 Pro (64 Bit) - Release 1809, I7-4790, 32 GB RAM, NVidia ASUS ROG Strix GeForce GTX 1080 8GB, Win + Prg: 512GB SSD Samsung EVO850, Daten: Samsung 1TB 970 EVO


    Erfolgreiche Händler versuchen den Wünschen des Kunden nachzukommen.

    Sie versuchen nicht den Kunden an ihre Wünsche anzupassen.

  • Hallo Marino,


    vielen Dank für diesen Ansatz, es ist genau der Grund warum viele LUA nicht benutzen wollen older können. Der EEP-Benutzer braucht nicht bis ins letzte Detail zu wissen wie das Programm seine Funktionen realisiert, die verschiedenen Optionen und Funktionen muss das Programm einfach wie bisher, mit der grafischen Oberfläche in 2D oder 3D, zur Verfügung stellen. Leider haben die Verantwortlichen diesen Schritt nicht gewählt und eine abstrakte Programmiersprache halbherzig in EEP integriert. Eine GUI (grafische Oberfläche) für LUA wird es wohl nicht mehr geben.


    Grüße,

    redrookie :af_1:

    EEP6 bis EEP15. PlanEx 3.2, ResuEx 2.90, Kontakt-Explorer 1.2.0.0, Tauschmanager 2.0.2.8, Hugo, Berta, Helga
    Bulkinstaller, Anlagenverbinder 3, Freemodellkatalog 2.6.13 und Tools, EEP_ModellKatalog.
    Laptop Acer 8942G mit Windows 7 Ultimate 64-Bit, Intel© Core™ i7, 8GB RAM, ATI HD 5850 1 GB Graka, 18.4" Full HD.

    Laptop Acer, Windows10, Intel© Core™ i7-7820HK, 64 Gb RAM, NVidia GTX1080, 17" 4K-Auflösung.

  • Hallo,


    es ist aus meiner Sicht egal ob graphische Oberfläche oder nicht. Die Logik die dahinter steckt ist

    immer die gleiche, selbst beim Schaltkringel. Wenn ich mir diese nicht erarbeite wird es nichts.

    Aber habe ich das geschafft, dann ist Lua wesentlich flexibler und übersichtlicher.


    Gruß

    Frank

    Windows 7 Ultimate64 / Intel i7-6700 3,4 GHz / 32 GB RAM NVIDIA Geforce GTX 980 Ti / 6 GB GDDR5 DirectX 11.0

    Acer Windows 10 Home64 I7-6700HQ 2,6 GHz / 16 GB RAM Geforce GTX 960M 4096 MB GDDR5

    EEP bis 15

  • Also ganz ehrlich Leute!

    Als ich erstemal mit EEP angefangen habe, habe ich auch nur den Kopf geschüttelt.

    Und das ganz ohne LUA. Denn das gab es da noch nicht.

    Habe lange gebraucht, um mit EEP klar zukommen. Denn es gibt doch jede Menge Eigenschaften, die man erst mal für sich erarbeiten muß!

    Da gab es auch keine große Hilfestellung (Zumindest für mich, Lesen ist das eine, Probieren das andere)

    Heute gibt es mittlerweile jede Menge Hilfe zu EEP und auch zu Lua.

    Also, wo ist das Problem? Wer mit EEP klarkommt und mit Schaltkringel, sollte sich auch mal für Lua intressieren:ae_1:

    mfg

    Reinhard
    Der Oldenburger :bd_1:

    EEP 6 Pro / 9.1 / 10 / 11 / 12/ 13 / 14 / 15| Home-Nos 5/8/13/14| Moodellkatalog | Bilder Scanner |Modell Explorer

    Desktop: Gigabyte Z270-HD3P|Intel i5-7400 | Corsair Venegance 16 GB DDR4 | Gigabyte GeForce GTX 1050Ti |

    Samsung SyncMaster S27D390 + Samsung SyncMaster P2450 + Samsung SyncMaster 931BF | Win 10 Pro

    Laptop Acer Aspire E17 | Display 17 Zoll FullHD | i5-6200U | 12 GB DDR4 | GeForce 940mx 2GB DDR5 | 256GB SSD | 1TB HD | Win 10 Home

    Mein youtube Kanal

  • Da mir Benny die Schaltkreise als Grafischste aller denkbaren Oberflächen schon vorweggenommen hat bleibt nur noch eins für mich.

    Punkt 5 ist kein Vorteil. Das ist aber Nebensache.


    :aq_1:Gruss Jürg

    Samsung Series 9 Laptop / Lenovo Z50 - 70 Laptop
    Intel i5 1.7 Ghz / Intel i7 2.0 Ghz
    4 Gb Speicher / 8 Gb Speicher
    Intel HD Graphics 4000 / NVIDIA Geforce 840M
    Windows 10 64 /Windows 10 64
    EEP15 / EEP14, EEP15
    AnlagenBau / AnlagenLaufLass

    ________________________________________________________________________

    Gehe sofort zurück zum Thema. Lasse keine weiteren Statements los. Ziehe nicht 4000 Dislikes ein. (A.D. Mistrator)

  • Eigentlich bräuchte es gar kein Lua oder angebappte Wizards, wenn die wirklich schlechte Anwenderoberfläche von EEP alle Funktionalitäten enthalten würde, um vernünftig Fahrstraßen, SIgnale und Zugdepots u.s.w. zu realisieren.

    Was fehlt ist tatsächlich eine richtig gute grafische Oberfläche für alle von der Modellsuche bis zur Fahrtraßenautomatisierung.

    Das geht ja beim HomeNos zur Modellerstellung weiter...

    Aber das ist eben EEP. Da wird keiner mehr was dran ändern, nur noch kleine Optimierungen ohne allzu großen Aufwand.


    Gruß

    Thomas

    EEP14, HomeNos13, Modellkatalog, Blender, Tauschmanager, Hugo :aq_1:

  • Die grafische Oberfläche als Allheilmittel zweifle ich an. Wenn wir uns die Komplexität der bisher vorhandenen Möglichkeiten die Lua bietet vor Augen halten, dann würde diese grafische Oberfläche sehr komplex. Egal, wie clever diese programmiert wäre.


    Neben wir als Beispiel das schon vorhandene Stellpult. Dass das jetzt grad als exzellentes Ergebnis hoher Programmierkunst angesehen werden soll will ich ja nicht behaupten. Aber es funktioniert im Wesentlichen.


    Aber....

    Viele User sind damit überfordert.


    Mir persönlich wäre es ziemlich Wurscht in welcher Weise ich überfordert würde. Grafisch oder textgesteuert. :ad_1:


    :aq_1:Gruss Jürg

    Samsung Series 9 Laptop / Lenovo Z50 - 70 Laptop
    Intel i5 1.7 Ghz / Intel i7 2.0 Ghz
    4 Gb Speicher / 8 Gb Speicher
    Intel HD Graphics 4000 / NVIDIA Geforce 840M
    Windows 10 64 /Windows 10 64
    EEP15 / EEP14, EEP15
    AnlagenBau / AnlagenLaufLass

    ________________________________________________________________________

    Gehe sofort zurück zum Thema. Lasse keine weiteren Statements los. Ziehe nicht 4000 Dislikes ein. (A.D. Mistrator)

  • Hallo zusammen,


    "Warum Lua?" so lautet der Thread-Titel.

    Das eigentliche "Problem" ist doch, dass EEP vielfältige Möglichkeiten bietet. Damit kann jeder einfache oder komplexe Szenarien erstellen, die er dann möglichst automatisiert steuern möchte. Genau diese automatische Steuerung macht EEP noch komplexer und bringt einen manchmal zur Verzweiflung.



    Für die Steuerung "vor" Lua, gab es dafür Kontaktpunkte. Für einfache Szenarien reichten die Kontaktpunkte auf den Fahrwegen locker aus. Jeder der möchte kann einfache Szenarien weiterhin mit Kontaktpunkten ablaufen lassen.


    Die Kaufanlagen boten immer komplexere Szenarien. Also entstand die (wirklich geniale) Idee mit den Steuerstrecken. Mit denen konnte man die Abläufe komplexer gestalten. Allerdings war man auf die Möglichkeiten der Kontaktpunkte begrenzt. Aber jeder der will, kann mit Steuerstrecken seine komplexen Szenarien steuern.

    Meine Meinung zu Steuerstrecken:
    Mir persönlich waren Steuerstrecken immer zu aufwändig, da die Signale und Weichen an der einen Stelle waren, die dazugehörenden Steuerstrecken aber einer anderen Stelle der Anlage. Nie habe ich die passenden Kontaktpunkte gefunden.


    Mit Lua nun wird einem die Möglichkeit geboten einfache und noch komplexere Szenarien ohne Steuerstrecken selbst zu schreiben. Es ist halt eine Programmiersprache, die interessanterweise in einigen anderen Computerspielen für Modifikationen (Mods) verwendet wird, da sie einfach, klein und schnell ist.

    Wer sich einarbeitet, der kann eigene Programme schreiben (ich habe eine Lua-Bibliothek geschrieben, die komplette Ampelkreuzungen mit vielen Fahrspuren steuert, wer sie benutzen möchte, findet Infos unter Möglichkeiten mit LUA beim Straßenverkehr).


    Meine Meinung:

    Vermutlich bin ich als Programmierer kein Maßstab, aber ich finde den Freiheitsgrad von Lua genial!
    In Lua kann ich schreiben, was ich will. Ich habe viel mehr Freiheitsgrade was den Ablauf angeht.

    Jeder kann in Lua schreiben, was er will!


    Viele Grüße,

    Andreas Kreuz.

    EEP: Version 14 - PC: Intel Core i7-4790, 16 GB RAM, NVidia Geforce GTX 1080 Ti, Windows 10 - Notebook: MacBook Pro 2015, mit ATI Radeon R9 M370X, Windows 10


    Webseite: Lua-Bibliothek für EEP (mit Tutorials)

  • ---

    Eine "grafische Oberfläche", wie du sie dir vorstellst, hätte vermutlich komplett neu entwickelt werden müssen. Das hätte vermutlich viel zu viel Arbeitszeitg der Entwickler gebunden.


    Viele Grüße

    Benny

    Ganz so, ist es denn doch nicht...



    solches gibt es, wie Ihr oben sehen könnt für Lua schon...


    Nur für die Zwecke von EEP müssten da schon noch ein paar Handgriffe vorgenommen werden.

    Ich will nun nicht behaupten, dass das so einfach wäre, aber so pessimistisch wie einige Voten hier, sehe ich es nicht.

    Das Entwicklerteam tut wirklich einiges um es uns angenehm zu mache. Das da manchmal etwas daneben geht, ist schliesslich nicht zu vermeiden

    Ich bin schon seit den 70ern mit Programmierung beschäftigt und habe schon sehr oft frustriert das Erarbeitete verärgert in eine Ecke geschmissen, weil neu Updates erschienen unter denen meine Codes nicht mehr richtig liefen.

    Wer sich z.B. mit Windows bedient, kann davon doch sicherlich einiges mitbekommen haben.


    Glaubt Ihr, dass solche Umstellungen nicht auch den Entwicklern von EEP das Leben oft sehr schwer gemacht haben?...

    Ich für meinen Teil habe wirklich Verständnis, dass vieles einfach lange dauert um realisiert zu werden, weil oft schlicht die Ressourcen fehlen.

    EEP v13.2 Patch 1, Plugin 1&2

    hat ein klein wenig Ahnung von System-Programmierung :bn_1:

    https://picload.org/image/dddgolpr/gueter.png


    Windows 10 Pro 64-Bit

    HP Compaq 8100 Elite CMT PC / Intel(R) Core(TM) i5 CPU 760 @ 2.93GHz RAM 12GB

    HP Prolient Debian 9.6

    GeForce GTX 1050 Ti 2 * 23" Wide LCD Monitor & 1*25" LCD

  • Ich hab früher mal programmiert, aber bewusst damit aufgehört.

    Es stiehlt mir die Zeit von der wirklich kreativen Arbeit, die mir ein Computer

    oder eben EEP bietet.


    Vieles was über LUA gelöst wird, könnte sehr einfach mit einem KP erledigt werden

    wenn es diese gäbe.

    Rückwärts zählen, freies Gleis oder Gleisabschnitt finden usw.


    Vieles komplexes kann man besser mit LUA erledigen, wenn man es beherrscht,

    wobei für mich hier eine Überfrachtung mit Unbedeutetem statt findet


    Zitat LUA - "Ändert den Tag-Text einer Immobilie".


    warum das? wenn es die einfachsten Funktionen für KPs nicht gibt?


    Die Suche darf nicht nach dem kürzesten und damit unverständlichstem LUA-Befehl sein,

    die Suche muss nach dem geringstem Aufwand für das darzustellende Ereignis sein

    um dann weiter kreativ Anlagen zu gestalten.


    Das kann LUA ODER ein KP sein.

    Ein KP ist ja schon ein fertiges Programmschnipsel, das muss ich aber in LUA neu erfinden.


    Grafisch wäre es durchaus möglich sehr viele dieser Aufgabe auch einfach mit KPs zu lösen

    wenn diese Funktionen auch mit KP zur Verfügung stehen würden.


    -Eigenes Fenster für Steuerstrecken

    -KPs die das können, was LUA EEP-Spezifisch kann

    -ein virtuelles Schaltauto, was wesentlich schneller fährt als 400 kmh


    viele Grüße Max

    H0, TT in der Vitrine - N analog auf der Platte -EEEC, EEP2-6, EEP 7 und 9, EEP 14, Konverter

    Meine Texte und Hinweise haben keinen Anspruch auf Richtigkeit und allgemeine Gültigkeit.

    Kinder! macht das nicht zu Hause

  • Mich überfordert die Programmierung einer Anlage mit Schaltkreisen, weil ich mir alles Kontaktpunkte, Signale etc ansehen muss, damit ich weiß was in welchem Zusammenhang steht.

    In Lua kann ich manche Dinge in 3-4 Sätzen lösen wozu ich 10 mal so viel Steuerkreise brauche.

    Gruß

    Georg


    EEP15 P3, Modellkatalog, Tauschmanager, Hugo, BilderScanner, ModellExplorer, ZugExplorer, EEP6 + Modellkonverter

    Win 10 Pro (64 Bit) - Release 1809, I7-4790, 32 GB RAM, NVidia ASUS ROG Strix GeForce GTX 1080 8GB, Win + Prg: 512GB SSD Samsung EVO850, Daten: Samsung 1TB 970 EVO


    Erfolgreiche Händler versuchen den Wünschen des Kunden nachzukommen.

    Sie versuchen nicht den Kunden an ihre Wünsche anzupassen.

  • Zitat LUA - "Ändert den Tag-Text einer Immobilie".

    warum das? wenn es die einfachsten Funktionen für KPs nicht gibt?

    Weil du den Text mit Lua dynamisch ändern kannst, mit einem Kontaktpunkt hingegen nicht.


    Damit ist gemeint:

    Ich kann in Lua situationsabhängig den Text zusammenstellen, der aktuell passt.

    Im KP müsste ich einen starren Text vorgeben. Oder vielleicht eine lange Liste von möglichen Texten. Wobei dann die Frage ist wie der KP entscheidet, welcher Text wann fällig ist.


    (Ich vermute übrigens dass du eigentlich den Texture-Text meinst. Also das, was auf Zielanzeigen, Infotafeln etc. erscheinen soll. Bei den wirklichen Tag-Texten ist der Sinn völlig verloren, wenn man die nicht frei und dynamisch erzeugen kann.)

  • Es stiehlt mir die Zeit von der wirklich kreativen Arbeit, die mir ein Computer

    oder eben EEP bietet.


    Programmieren ist nicht kreativ? Interessante Ansicht. Ohne Kreativität gäbe es EEP und andere Simulationen nicht. Programmierer müssen viel Vorstellungskraft haben, das übersehen leider viele Menschen.

    Gruß

    Georg


    EEP15 P3, Modellkatalog, Tauschmanager, Hugo, BilderScanner, ModellExplorer, ZugExplorer, EEP6 + Modellkonverter

    Win 10 Pro (64 Bit) - Release 1809, I7-4790, 32 GB RAM, NVidia ASUS ROG Strix GeForce GTX 1080 8GB, Win + Prg: 512GB SSD Samsung EVO850, Daten: Samsung 1TB 970 EVO


    Erfolgreiche Händler versuchen den Wünschen des Kunden nachzukommen.

    Sie versuchen nicht den Kunden an ihre Wünsche anzupassen.

  • zu #1

    Was meinst Du wohl, warum unter Lua z.B. keine echten Arrays implantiert sind. (Ist mir in der Zwischenzeit klar geworden)

    Sicherlich ist einer der Hauptgründe darin zu finden, dass Arrays in sich sehr gefährliche Gebilde sind.

    Ein über die Deklaration hinaus adressierter Zugriff, kann das ganze System zum Absturz bringen, weil so in fremde Speicherbereiche geschrieben wird.

    In Lua passiert da aber nichts Schlimmes, wenn Du aus Versehen über-adressierst...


    Tippfehler sind aber bei praktisch allen Hochsprachen, wenn sie zufällig gültig sind, möglich.

    In C wird bei gültigem Code einfach eine neue Variable erzeugt, und daher wirst Du da auch keinen Kompiler- Fehler zurückerhalten, aber trotzdem ein unbefriedigendes Resultat haben.


    PASCAL schützt nur insoweit, wenn eine nicht deklarierte Variable angesprochen werden soll.

    Andere Fehler, die an sich gültigen Code erzeugen, sind so auch nicht abgefangen.


    zu#2

    Das meinte ich eben, wenn ich von Hochsprachen-Code sagte, dass nur mit konsequenter Fleissarbeit die Portierung für späteren Gebrauch noch tauglich sein soll. Aus Erfahrung weiss ich aber, dass da sehr oft die Dokumentirrung auf den St.-Nimmerleinstag hinausgeschoben wird.

    EEP v13.2 Patch 1, Plugin 1&2

    hat ein klein wenig Ahnung von System-Programmierung :bn_1:

    https://picload.org/image/dddgolpr/gueter.png


    Windows 10 Pro 64-Bit

    HP Compaq 8100 Elite CMT PC / Intel(R) Core(TM) i5 CPU 760 @ 2.93GHz RAM 12GB

    HP Prolient Debian 9.6

    GeForce GTX 1050 Ti 2 * 23" Wide LCD Monitor & 1*25" LCD