Achte bitte darauf, dass Du mit deinem Thema bzw. mit deiner Frage im richtigen Bereich bist.
Die Bereiche sind: Einstellungen im Forum, EEP aktuell ab EEP7 , Splines, Rollmaterialien, Immobilien, Landschaftselemente, Signale und Schaltung, Anlagenvorstellungen, Schnappschüsse Konstrukteure, EEP Treffen , Laberecke, Online - Handbuch EEP Vielen Dank für die Unterstützung das Forum übersichtlich zu halten.
Bilder/Fotos aus dem Internet sind nur als Link gestattet. Eigene Fotos, also Fotos aus dem realen Leben, sind erstens mit Eigenes Bild als Quellenangabe zu kennzeichnen und zweitens nur als Dateianhang im Beitrag zulässig. Bilder ohne Quellenangaben und Bilder dessen Quelle das Internet wie z. B. Google ist, werden gelöscht.
  • 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-15.1 [x64] Patch 2 / EEP-17 in Installation

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

    https://abload.de/img/zglbrckqhkzh.jpg

    Windows 10 Pro 21H2 64-Bit V -19044

    HP Z2230 Tower-Workstation Intel CPU E3-1225v3 @ 3.2 GHz

    HD1..4 je 2GB Micron 133MHz / RAM 8GB

    Monitor: Samsung 33-inch 2*HDMI Intel HD Graphics P4600

    Windows 11 V21H2 64-Bit

    HP OMEN 40L Desktop-PC GT21 - AMD Ryzen 7 5700G

    RAM 16GB - Speicher 2*8GByt Kingston 3.2GHz

    Video NVIDIA GeForce RTX 3060 TI - Monitor: HP M34d WQHD

    Einmal editiert, zuletzt von Marino (5. Januar 2019 um 08:34)

  • 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 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-15.1 [x64] Patch 2 / EEP-17 in Installation

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

    https://abload.de/img/zglbrckqhkzh.jpg

    Windows 10 Pro 21H2 64-Bit V -19044

    HP Z2230 Tower-Workstation Intel CPU E3-1225v3 @ 3.2 GHz

    HD1..4 je 2GB Micron 133MHz / RAM 8GB

    Monitor: Samsung 33-inch 2*HDMI Intel HD Graphics P4600

    Windows 11 V21H2 64-Bit

    HP OMEN 40L Desktop-PC GT21 - AMD Ryzen 7 5700G

    RAM 16GB - Speicher 2*8GByt Kingston 3.2GHz

    Video NVIDIA GeForce RTX 3060 TI - Monitor: HP M34d WQHD

    Einmal editiert, zuletzt von Marino (5. Januar 2019 um 11:10) aus folgendem Grund: 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.

  • 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 EEP17.1. PlanEx 3.2, ResuEx 2.90, Kontakt-Explorer 1.2.0.0, Tauschmanager 4.1.7.0, Hugo, Berta, Helga
    Bulkinstaller, Anlagenverbinder 3 und Tools, EEP_ModellKatalog, EEP-Modell Explorer
    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.

    Laptop Acer, Windows11, Intel© Core™ i9-9980HK, 64 Gb RAM, NVidia RTX2080, 17" Full HD

  • 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 10 Pro Version 2004 / Intel i9-9900K 8x3,6 GHz / 64 GB RAM NVIDIA GeForce RTX 2080 SUPER / 8 GB GDDR6 DirectX 12.0

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

    EEP bis 16.4 Plug-In 1-4

  • 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:

    Gruß Reinhard

    Der Oldenburger :bd_1:

    EEP 9 - 17.2/2 | Home-Nos 17 und Blender 2.79 & 3.6 |Moodellkatalog | Bilder Scanner | Modell Explorer

    Desktop: Gigabyte Z790 Gaming | Intel i5-13600K | Corsair Venegance 32 GB DDR5 | Gigabyte GeForce RTX 4060 |1TB M.2 SSD + 2TB M. 2SSD + 2 x 1TB SSD

    LG 34WQ75X + Samsung S34J550WQR 3440x1440 | Win 11 Pro

  • 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

    Es ist müssig, dauernd den Weltuntergang heraufzubeschwören. Man muss auch aktiv etwas dafür tun. :bn_1:

  • 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

    EEP16.1 Patch 2, HomeNos15, Modellkatalog, Blender 2.8, 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

    Es ist müssig, dauernd den Weltuntergang heraufzubeschwören. Man muss auch aktiv etwas dafür tun. :bn_1:

  • 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.

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

    Mein Rechner

    EEP: Version 17 - PC: AMD Ryzen 5800X, 32 GB RAM, NVidia Geforce GTX 1080 Ti, Windows 11

  • ---

    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...

    LUA-Editor

    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-15.1 [x64] Patch 2 / EEP-17 in Installation

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

    https://abload.de/img/zglbrckqhkzh.jpg

    Windows 10 Pro 21H2 64-Bit V -19044

    HP Z2230 Tower-Workstation Intel CPU E3-1225v3 @ 3.2 GHz

    HD1..4 je 2GB Micron 133MHz / RAM 8GB

    Monitor: Samsung 33-inch 2*HDMI Intel HD Graphics P4600

    Windows 11 V21H2 64-Bit

    HP OMEN 40L Desktop-PC GT21 - AMD Ryzen 7 5700G

    RAM 16GB - Speicher 2*8GByt Kingston 3.2GHz

    Video NVIDIA GeForce RTX 3060 TI - Monitor: HP M34d WQHD

  • 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

  • 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.

  • 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.

  • 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-15.1 [x64] Patch 2 / EEP-17 in Installation

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

    https://abload.de/img/zglbrckqhkzh.jpg

    Windows 10 Pro 21H2 64-Bit V -19044

    HP Z2230 Tower-Workstation Intel CPU E3-1225v3 @ 3.2 GHz

    HD1..4 je 2GB Micron 133MHz / RAM 8GB

    Monitor: Samsung 33-inch 2*HDMI Intel HD Graphics P4600

    Windows 11 V21H2 64-Bit

    HP OMEN 40L Desktop-PC GT21 - AMD Ryzen 7 5700G

    RAM 16GB - Speicher 2*8GByt Kingston 3.2GHz

    Video NVIDIA GeForce RTX 3060 TI - Monitor: HP M34d WQHD