Posts by Benny (BH2)

    Hallo zusammen,

    nachdem ich schon ein Paar Bilder und ein Paar Videos im Schnappschuss-Faden gezeigt habe, wird es nun Zeit für ein eigenes Thema. Da ich durchaus mit ein paar Antworten und Nachfragen rechne, will ich den Schnappschuss-Faden damit nicht (nochmal) "überschwemmen".


    Seit dem Erscheinen von EEP15, also seit knapp einem Jahr bastele ich immer wieder mal an einer USA-Anlage. Dabei beschränke ich mich auf die Modelle, die in EEP15 direkt nach der Installation zur Verfügung stehen - also keine Shop-Modelle, keine Freemodelle und auch keine View-Only-Modelle. Ab EEP15 enthält der Grundbestand auch einige amerikanische Modelle, wodurch dieses Anlagenthema überhaupt erst möglich wurde.


    Gestern habe ich ein drittes Video der Anlage auf Youtube hochgeladen, das den vor kurzem fertig gestellten Automatikbetrieb der Anlage im Zeitraffer zeigt.



    Der Vollständigkeit halber binde ich hier auch die beiden schon gezeigten Bilder und Videos dieser Anlage nochmal ein.







    Wenn Interesse besteht (und ich Zeit finde), kann ich noch ein paar Bilder aus der Entstehungsgeschichte zeigen und meine Gedankengänge und Überlegungen beschrieben.


    Viele Grüße

    Benny

    Was genau ist denn jetzt dein Problem?

    Wenn alles funktioniert, nur die DKW-Laterne beim Fahrstraßen-Stellen nicht mitgestellt wird, würde ich vermuten, dass beim Stellen des Fahrstraßensignals mit Lua die 1 am Ende (Aufrufen der Callback-Funktion; das gilt bei Fahrstraßensignalen auch für alle dadurch gestellten Signale und Weichen) fehlt.


    In deinem Anfangsbeitrag steht aber etwas von "Züge fahren nicht los trotz grünem Signal" und "Weichen sind dauernd in Bewegung". Das sind für mich zwei ganz andere (und separate) Probleme.


    Viele Grüße

    Benny

    Hallo Peter,

    ein paar allgemeine Optimierungsvorschläge (nicht nur) für dein Skript:

    1. Formatierung
      Dazu zähle ich sinnvolle Einrückungen, einheitliche Leerzeichensetzung und sinnvolle Zeilenumbrüche (nicht mehrere Anweisungen in eine Zeile schreiben). Das macht nicht nur anderen Usern, sondern auch dir das Lesen leichter
    2. Wiederholungen vermeiden
      Abläufe, die in mehreren Funktionen vorkommen, würde ich in eine separate Funktion auslagern, hier insbesondere das Herausfinden der Liniennummer und "Beschriften" der Fahrzeuge.
      Auch beim Beschriften der Fahrzeuge kannst du Wiederholungen vermeiden (und zusätzlich mehr als zweiteilige Züge ermöglichen), wenn du die Anweisungen nur für einen Wagen schreibst, und das in eine Schleife packst.
    3. Nur einbinden, was du brauchst
      Du bindest am Anfang meinen TaskMemorizer ein, ich sehe aber nicht, dass du den irgendwo verwendest. Gleiches gilt für die SlotNames, die in der nächsten Zeile durch SlotSugar wieder überschrieben werden.
    4. SlotNames statt SlotSugar verwenden
      Namen statt Zahlen machen den Code besser lesbar. Was du bei einem Umstieg alles ändern musst, sollte auf meiner Homepage beschrieben sein.

    Auch sonst könnte man einige Zeilen sicherlich noch vereinfachen, aber das würde an dieser Stelle vermutlich zu weit führen.

    Gut finde ich, dass du alle Beschriftungsvarianten in einer zentralen Tabelle gespeichert hast.


    Viele Grüße

    Benny

    Du kannst keine Fahrzeuge direkt ins virtuelle Depot einfügen, sondern nur auf der Anlage vorhandene Fahrzeuge aufnehmen.

    Um neue Fahrzeuge ins Depot zu bekommen, musst du sie also zuerst auf die Anlage stellen, und kannst sie dann ins Depot aufnehmen.


    Viele Grüße

    Benny

    Leider wurde das Ursprungsthema geschlossen, während ich diesen Beitrag geschrieben habe. Ich würde einen Admin oder Moderator bitten, diesen Beitrag an das Ursprungsthema anzuhängen und dieses im Idealfall wieder zu öffnen, damit die angesprochenen Personen wenigstens die Möglichkeit haben, zu antworten.




    Auch ich habe mich schon öfters über (unnötig) große Signaturen aufgeregt, die teilweise auch deutlich größer sind als der eigentliche Beitrag. Peters Beitrag #6 ist dafür ein schönes Beispiel. (Nichts gegen dich, Peter.)


    Ich denke, solche Signaturen ließen sich schon dadurch deutlich verkleinern, dass Leerzeilen und Zeilenumbrüche entfernt werden. Ich erlaube mir mal, Peters Signatur zu zitieren:



    Mit ein paar weniger Leerzeilen wird das ganze deutlich kompakter:

    Komprimierte Signatur von ameisenbaer wrote:

    Viele Grüße,

    Peter


    eep13 expert, eep11, eep6 (hat sich aufgehängt), Modellkonverter

    Notebook Medion Erazer P7647 Core(TM) i5-7200 U CPU @ 2.50GHz, 8GB RAM, NVidia Geforce GTX 950M, Windows 10, 64bit

    Freunde kommen und gehen, aber ein richtiger Feind bleibt Dir ein Leben lang erhalten. (Hägar der Schreckliche)


    Ralfs Signatur bietet auch noch Verbesserungspotential:

    Komprimierte Signatur von tycoon wrote:

    Windows 7 Home Premium 64 bit, Intel Core i7-4790, 4 x 3,60 GHz - RAM 16 GB - NVIDIA Geforce GTX 1060


    EEP 13.2 und EEP 14, Keine Zusatztools

    Freemodellkatalog - alle EEP-Seiten - Konstrukteursliste - alle EEP-Treffen - Modellwunschkataloge - tycoon-live

    Peter und Ralf, bitte nicht falsch verstehen, ich will euch hier nicht anprangern oder soetwas. Eure Signaturen boten nur ein gutes Beispiel für das, was ich zeigen wollte.


    Als Trennlinie habe ich hier jeweils das HTML-Element <hr> verwendet, dass leider nur in der HTML-Ansicht eingegeben werden kann. Wenn es sonst keine Leerzeilen gibt, hat eine einzelne Leerzeile aber fast die selbe Wirkung wie eine Trennlinie.

    Und wenn ihr eure Signaturen anpasst, schaut auch mal, ob die eingetragenen EEP-Versionen noch aktuell sind.



    Achja, eine Sache noch:

    Sie stören ungemein den inhaltlichen Lesefluss

    Meinen Lesefluss stören die Signaturen eigentlich überhaupt nicht mehr, weil ich sie gedanklich völlig ausblende. Trotzdem bin ich dafür, die Signaturen kompakter zu gestalten.


    Viele Grüße

    Benny

    Hallo Frank,

    tut mir leid, ich kenne mich damit auch nicht aus. Vielleicht kann H2812 nochmal helfen (falls er hier nochmal reinschaut)?


    Es ist schon ein Weilchen her, dass ich es versucht habe, aber ich hatte damals keinen Erfolg mit LuaSocket in EEP. Das lag wohl hauptsächlich daran, dass EEP keine "Endlos-Funktionen" mag (wie sie Server oft sind). Ich will nicht ausschließen, dass man die Sockets auch irgendwie mit der EEPMain kombiniert kriegt, aber ich habe es in meinen (unvollständigen) Versuchen nicht geschafft.


    Viele Grüße

    Benny

    Ich denke mal, dass die Fahrzeuge das Signal ignorieren, weil es zwischendurch auf Fahrt gestellt wird.


    Wenn nämlich nur manche der überprüften Straßenstücke besetzt sind, werden die beiden letzten if-Bedingungen gleichzeitig erfüllt. Und dann wird das unsichtbare Signal erst auf Fahrt, und gleich anschließend auf Halt gestellt.


    Dein Problem hier ist einmal die Logik (bei so vielen Verneinungen, ands und ors blicke ich auch nicht mehr durch), und die Verwendung von drei unabhängigen ifs (statt elseifs). Nur weil du denkst, dass die nächste Bedingung das Gegenteil der vorherigen ist, ist das noch lange nicht so. Genau deshalb wurden else und elseif "erfunden".


    Ich würde folgenden Code vorschlagen:

    Die ersten beiden Fälle kann man natürlich zusammenfassen, da beidesmal das gleiche passiert (Signal auf Fahrt). Ich habe es aber so gelassen, falls du die prints nochmal aktivieren willst.

    Außerdem habe ich das "Ausrechnen", ob Gegenverkehr kommt, vorgezogen und das Ergebnis in einer Variablen gespeichert.*

    Dabei habe ich auch die vielen == true weggelassen, da sie nichts ändern (true == true ist true, aber true selbst ist auch schon true).


    * Das in-Variablen-Speichern von Zwischenergebnissen ist generell empfehlenswert, weil man den Variablen sinnvolle Namen geben kann. Dadurch wird der Code übersichtlicher und selbsterklärend, auch ohne Kommentare.

    Schau dir mal den folgenden Code an:

    LUA Source Code
    1. local Geradeaus = (StellungLA12 == 1)
    2. local Gegenverkehr = (LAData34 or LAData35 or LAData36 or LAData37 or LAData38)
    3. if Geradeaus or not Gegenverkehr then
    4. EEPSetSignal(663, 1)
    5. else
    6. EEPSetSignal(663, 2)
    7. end

    Alles klar? Hoffentlich. Sonst war mein Beispiel nicht so gut.



    Viele Grüße

    Benny

    Dein Ziel kannst du auch mit der Gleisvervielfältigungs-Funktion erreichen. Die kann auch layerübergreifend vervielfältigen.

    Ich will nicht sagen, dass der direkte Weg ist, aber zumindest muss man EEP nicht verlassen.


    Viele Grüße

    Benny


    Edit: Matthias war schneller. Leider kriegt man hier beim Abschicken keine Warnung, dass zwischenzeitlich schon ein anderer Beitrag geschrieben wurde.

    Ich habe jetzt nicht nochmal den gesamten Thread von Anfang an durchgelesen, daher könnte diese Antwort unpassend sein.

    Gibt es weitere Lösungen?

    Du könntest ganz auf virtuelle Depots verzichten, und (wie bei jeder normalen Modellbahn) einen unterirdischen Schattenbahnhof anlegen.

    Dabei kannst du sogar (im Gegensatz zu einer normalen Modellbahn) auf lange Zufahrtsstrecken verzichten, und stattdessen "virtuelle Verbindungen" einsetzen. Die sind weniger komplex als virtuelle Depots, und sollten daher auch weniger Probleme machen.

    Viele Grüße

    Benny

    Sind das denn wirklich Straßen, oder nicht doch vielleicht "als Straßen getarnte Gleise"? Rausfinden kannst du es, indem du ein anderes Gleisstück daran andockst. Klappt das bei Straßen oder bei Gleisen?


    Unabhängig davon kann den vorgegebenen Gleisstil nur der Kon ändern.


    Viele Grüße

    Benny

    Nein.

    Die Achsen von Immobilien (oder in dem Fall Gleisobjekten) lassen sich weder mit anderen Dingen koppeln noch überhaupt per Kontaktpunkt "abfragen". Das Abfragen geht nur per Lua.


    Wenn du ohne Lua auskommen willst, musst du eine Stufe vorher ansetzen, und dafür sorgen, dass Brücke und Signale immer gleichzeitig angesteuert werden.

    Du könntest entweder an jeden "Brücke auf"-KP auch einen "Signal rot"-KP setzen (und beides in einen Gruppenkontakt packen).

    Oder du machst einen kleinen Schaltkreis mit einem Signal. Sobald das Signal auf Fahrt geschaltet wird, fährt ein Schaltauto los und löst alle erforderlichen Aktionen (Signal rot, Brücke auf, usw.) aus. Dann musst du an allen anderen Stellen nur noch jeweils einen KP setzen ("Schaltkreissignal auf Fahrt"). Dieses Signal kannst du auch von Hand ansteuern.


    Viele Grüße

    Benny

    Wie wäre es damit?

    Das dürfte die Vorteile von Variante 1 bzw. 2 (Lesbarkeit) und Variante 3 (es muss nicht in jedem EEPMain-Durchlauf ein String zusammengebastelt werden) kombinieren:

    LUA Source Code
    1. local function t(h, m, s)
    2. return h*3600 + m*60 + s
    3. end
    4. Variante3 = {
    5. Tafel = "#3",
    6. -- [t(hh,mm,ss)] = {"Feld1", "Feld2", "Feld3", "..."},
    7. [t(15,07,45)] = {"Abfahrt", "Eilzug", "Amsterdam", "..."},
    8. [t(17,38,00)] = {"Abfahrt", "Personenzug", "Brilon Wald", "..."},
    9. }


    Viele Grüße

    Benny

    versuche dies mit dem Befehl string.gsub zu lösen jedoch ohne Erfolg.

    Der Nicht-Erfolg wundert mich nicht sonderlich. string.gsub ist für das Ersetzen zuständig, nicht für das Zusammenfügen.

    Zum Zusammenfügen gibt es den ..-Operator, wie von kaffeschluerfer und eepnolie gezeigt.


    Viele Grüße

    Benny

    Dennoch würde ich immer noch gerne wissen, wo das 'end' im zweiten Bild fehlt

    Das end ist zwar vorhanden, aber an der falschen Stelle. An der "richtigen Stelle" fehlt das end aus Lua-Sicht also.

    Das hat Götz ja schon erklärt, nach einem return in Lua muss der jeweilige "Block" (Funktion, if, for, sonstwas) sofort beendet werden, es dürfen danach keine weiteren Anweisungen (in diesem Block) kommen.

    Und das ist nicht nur in Lua so.

    Sondern auch in C, C++, C#, Java, Python ...

    Doch, Lua hat hier eine Sonderrolle. In allen anderen Sprachen ist es erlaubt, auch nach return noch weiterzuschreiben. Das ist in anderen Sprachen zwar auch nicht sinnvoll ("unreachable code"), aber nur in Lua gilt das als Syntaxfehler.


    In Goetz' Beispiel funktioniert es zwar, aber wenn man es sauber programmieren will sollte es so aussehen:

    "Sauberer Code" ist natürlich immer ein Stück weit Geschmackssache, aber in meinen Augen ist in deinem Beispiel das letzte return überflüssig, weil "unreachable". Eines der beiden returns darüber wird auf jeden Fall ausgeführt.

    Anders sähe es aus, wenn es kein reines else gäbe, z.B. so:


    Viele Grüße

    Benny

    Ohne deinen Code zu sehen, kann ich dir auch nicht sagen, wo ein end fehlt. Ich bin mir aber sicher, dass eins fehlt, sonst würde EEP (bzw. Lua) das nicht behaupten :ae_1:


    Bedenke, dass nicht nur Funktionen mit einem end beendet werden müssen, sondern auch andere "Blöcke" wie if, for und while.


    Viele Grüße

    Benny

    Gibt es dort Regelungen oder Festlegungen, dass dieses Beispiel nur in der EEPMain() funktioniert oder wo könnte da schon wieder der Haken sein?

    Das Beispiel funktioniert auch außerhalb der EEPMain. Zumindest dann, wenn du das Skript genau um 10 Uhr 10 und 10 Sekunden neu lädst. Denn der Code außerhalb der EEPMain (oder anderer Funktionen) wird genau dann einmal ausgeführt, wenn das Skript neu geladen wird (oder beim ersten Wechsel in die 3D-Ansicht nach dem Laden der Anlage).


    Überlege dir nochmal genau, was da im Code steht, übersetzt auf Deutsch:

    Falls der Stundenzeiger auf 10 und der Minutenzeiger auf 10 und der Sekundenzeiger auf 10 steht, führe die folgenden Anweisungen aus.

    Beachte das Wort am Anfang: "Falls", nicht "Sobald". Wenn die Bedingung nicht erfüllt ist, werden die Anweisungen auch nicht ausgeführt.

    Um trotzdem ein "Sobald" zu erreichen (das ist ja das, was du willst), kannst du den entsprechenden Code in die EEPMain schreiben. Dann wird laufend (bei jedem EEPMain-Durchlauf) geprüft, ob es gerade 10:10:10 ist. Und wenn es soweit ist, werden die entsprechenden Anweisungen ausgeführt.


    Viele Grüße

    Benny