Andy

[Ich trau mich ja fast nicht zu fragen, aber manchmal muß man Spott ertragen, wenn man blind ist. Es muß total simpel sein, aber ich find's einfach nicht: Wie kriege ich denn eine alternative Aktion unter? Also, wenn die Bedingung nicht erfüllt ist]. Edit: Hab's inzwischen. Normal eintippen und dann mit der Maus unter den Balken ziehen. Menno! Und dann noch: Wenn ich bei einer Aktion oder Bedingung auf 'kopieren' gehe, wird sie an Ort und Stelle dupliziert. Ich würde sie gerne im herkömmlichen Sinne kopieren und in einem anderen Ereignis einfügen. (also, strg-c, strg-v-mäßig). Ich nehme mal an, dass dies wegen möglichen ereignisbezogenen Einträgen nicht möglich ist, oder fehlt's einfach? verwirrte Grüße Andy

Die doppelten Anführungszeichen stellen halt eine Gefahr für Lua dar. Lua rahmt Objektnamen normal mit "..." ein. Wenn Du einfache ' draus machen würdest, akzeptiert das Lua so. Neo wird's sagen. Aber danke für die prompte Meldung. Ein anderes Objekt mit " wüßte ich jetzt nicht. Gruß Andy p.s.: Im Selektionsfenster bei der Suche, wenn nach Namen gesucht wird. Bei einer objektreichen Anlage dauert's nach dem Eintippen des ersten Buchstabens extrem lange. Da denkt man schon, MBS wäre abgestürzt (dauert aber nur, es kommt wieder!)

Ich habe noch was, was sich (bislang) noch nicht negativ ausgewirkt hat, könnte aber: Die E 10 hat im Objektnamen Anführungszeichen drin "Bügelfalte". Kann das kritisch werden?

So, das hat schön funktioniert. Zum Nachmachen: Ich habe den letzten Stand meiner V4-Anlage mit dem XML-Auswerter behandelt. In der Textdatei bei den Variablen alle mit .Block rausgezogen. Diese OV haben alle meine Schaltgleise, für den Bezug zum Block. Danach diese Liste in Notepad++ mit Textmacros gewandelt. Dann in der Anlage ein Knöpfchen, dass 'Sonderskript' heißt und beim Schalten eine Aktion Skript ruft. In dieses Skript nun den bearbeiteten Text eingefügt, sieht dann so aus layout:getEntityByName("G an Signal B10").variables["SCHALTGLEIS"] = keyword layout:getEntityByName("G an Signal B20").variables["SCHALTGLEIS"] = keyword usw. dann das Knöpfchen gedrückt und Bingo. Alle betroffenen Gleise haben nun das Schlagwort SCHALTGLEIS. 329 mühselige Einzelzuweisungen eingespart! Mittlerweile habe ich mich auch mit dem rekursiven Aufrufverhalten in der EV angefreundet. Ich kann damit die ganze kritische Kommunikation zwischen den einzelnen Komponenten rauswerfen, weil ich mich drauf verlassen kann, dass das jeweilige Gegenüber sofort reagiert. Es ist jetzt alles nur noch eine Frage, wie ordentlich man den Typ der Ereignisse setzt. Je detaillierter (eben z.B. Schlagwort) desto besser. Das schließt Nebenwirkungen aus und in der Ereignisprotokollierung läßt sich alles wunderbar verfolgen. Zu Beginn hatte ich beim 1.Einzelschritt (!) soviele (blaue) Ereignisse, dass der Anfang in der Protokollierung schon längst wieder rausgeflogen war. Jetzt wird's immer weniger, d.h. die EV wird wahnsinnig entlastet und ich hoffe, dass am Ende nicht mal mehr was ruckelt! Gruß Andy

Hallo @Neo, 1. Threads: okay, es wäre z.B. ein Thread sinnvoll, wo einfach nur alle vorhandenen Demos aufgelistet sind, damit man sich die hier nicht zusammensuchen muß. 2. Noch eine Frage zum Import, den ademes eben angesprochen hat: (ich hab's nicht gecheckt, vielleicht weißt Du's direkt): ist es immer noch nötig, dass beim Import zumindest eine Bodenplatte dabei ist? [3. ...entfernt] Lösung des Problems gefunden: siehe Anhang Das globale Skript besitzt eine Animationsfunktion mit freiem Parameter par1 Das lokale Skript ruft es parametrisiert mit einem Objekt, wobei der Name des Objekts nachträglich geändert werden kann und das Skript passt den Namen trotzdem an. Perfekt! Das bedeutet: dass auch nach Umwandlung der 'normalen' EV-Funktionen in ein Lua-Skript Objektbindungen so erhalten bleiben, dass Namensänderungen in der Anlage noch möglich sind. Das Demo zeigt außerdem schön, wie man starke unabhängige Funktionen aufbauen kann, die dann einfach parametrisiert aufgerufen werden. Hier werden wir ganze kleine Funktionsbibliotheken tauschen können. Gruß Andy Riesenrad.mbp

Es ist noch nicht einmal ein Vorschlag von mir, aber ich unterstütze die bereits geäußerte Idee noch eine Kategorie Beta-Diskussionen zu eröffnen, in der wir uns mit verschiedenen Threads versuchen gegenseitig zu helfen, wobei wir annehmen, dass Du da gar nicht großartig eingreifen mußt, um Dich etwas zu entlasten. Dann bleibt dieser Thread für echte Bugreports oder EIngemachtes, das wir noch nicht wissen. Gruß Andy

Aber der Bottleneck, der Auftragshandler mit dem Zielsucher muß es erstmal verkraften, dass zum absolut gleichen Zeitpunkt (sogar Zyklus) mehrere Aufträge auf ihn einhämmern. Er kann mit keiner Variablen festhalten, ob im gleichen Zyklus noch ein zweiter Auftrag was will, die sind alle noch unverändert dann. Noch so'ne Race Condition, die mir in V5 auch noch Probleme macht. Und dann läuft die Zielsuche auch rekursiv und kann sogar Sekunden brauchen, möglicherweise eine 'geblockt'-Meldung abliefern. Bei Fehlermeldungen müssen die Elemente dann in der Lage sein, sich selbst zu verwalten, d.h. einen neuen Versuch starten, ohne die EV permanent zu behämmern. Da wird die freie Zeit sehr schnell sehr knapp. Ich sage ja, für V4 war diese Anlage ein HiTec-Forschungslabor. Wenn mal die kritischen Dinge in Lua übersetzt sind und sauber am Stück verarbeitet werden und nicht mehr hinterlistige Schalter triggern müssen (so ein Fahrplan ist z.B. ein Schalter), sowie die keyword-Zuordnung die Anzahl der abzuklappernden Elemente stark reduziert, gibt's nicht mehr so viele belastende Zurückweisungen, die repetieren und dann wird's auch hoffentlich ruckelfreiere Fahrten geben. Und ich weiß auch, dass Du konzentrationsmäßig derzeit auf superhohem Dauerniveau arbeiten mußt und das Thema Humor da momentan in einer ganz anderen Schublade steckt. Aber hol mal kurz Luft. Ich kämpfe ja auch für V5 und beschreibe die Probleme nur. Wenn wir meine Anlage kompatibel am Laufen hätten, könnten viele Dinge als 'läuft' abgehakt werden. Wenn sich herausstellt, dass ich mit einigen Kopfständen nur Glück gehabt habe und das nicht kompatibel gehalten werden kann, sind das auch Erfahrungswerte, die wir bei Rückfragen anderer für Antworten nutzen können. Deshalb, erstmal vielen Dank für Deine Geduld mit der Beantwortung meiner Fragen. Aber nun raus hier, die anderen warten (<- beachte den emoji, frech bleibt frisch!) beste Grüße Andy

Nicht ärgern lassen Neo, da steht doch ein emoji dahinter.

Ist schon passiert. Der Sinn ist: ich habe da 20 Fahrpläne (für jede Lok einen). Jeder arbeitet eine eigene Auftragsliste ab - mit Abfahrtszeiten. Auch die Animationen laufen zeitgesteuert. Es gibt viele Fahrpläne, aber den Bottleneck Zielsucher. Da gibt's nur einen, damit mit den Pfadreservierungen nichts konkurriert. Um's kurz zu machen: jeder der 10 Subticks kann zwei Fahrpläne ticken, damit jeder Fahrplan einmal pro 'Minute' (in Echtzeit nur eine Sekunde) drankommt, durch die Phasenverschiebung der 10 Zehntel die EV aber entlastet wird. Gruß Andy

Viele meiner Probleme werden sich lösen lassen, wenn ich z.B. mal allen relevanten Objektgruppen ein Schlagwort zuordne. Das wäre auch schön, wenn das im Zuge einer Mehrfachauswahl möglich wäre. Gibt's einen Lua-Befehl, über den man ein Schlagwort zuordnen kann? Dann könnte ich mir von V4 den XML-Auswerter schnappen, die Objektvariablenliste nehmen, ein wenig Textprocessing machen, einen Table generieren, als Lua-Code einfügen und dann einmalig ein Knöpfchen drücken, das mit dieser Sysiphos-Arbeit abnimmt. Ansonsten gilt für den Export. Das geht nur mit V5 komplett. Ab in die Apollo-Jubiläums-Rakete und .. Gruß Andy

Herr und Frau Au auch!

Pffft, dann rauchen die Blumenauer ihre Pflanzen eben selbst Angesichts der Klimaerwärmung werden sie sowieso auf Kaktus umsteigen.

Wichtig, zum Starten der Anlage den roten Automatik-Knopf drücken und dann laufen lassen (oder umgekehrt). Und nochwas Neo: Wenn Du nicht auf den ersten Blick erkennen kannst, was da los ist, dann laß es! Du hast wichtigere Dinge zu tun und ich werde die V5-Version sowieso voll auf den Kopf stellen. Dann wird halt erstmal alles deaktiviert, was stört und Modul für Modul umgebaut. Ich pack das! Gruß Andy

05BB3DF4-5B0A-485E-8D0F-8A4DC23309E9 als Entwurf hochgeladen. Das ist die V4-Version, die schön läuft. Auf V5 oben gezeigte Probleme. Unten angehängt die Version, aus der ich von dieser auf V5 eingelesenen alles rausgeworfen habe, was nicht für das Problem relevant ist. Hier ist alles okay. Ergänzung: Der Ticker ist ein 0,1s - Ticker, der die Variable Subticks incrementiert. Ist sie 10, wird die genullt und wird Subticks 0 wird Minute eins hochgezählt. Dementsprechend dann auch Stunde. Beides für die hintergründige virtuelle Zeit, die nicht der EV-virtuellen-Zeit entspricht, weil das Format für Berechnungen unbrauchbar ist/war. Dann trotzdem noch zwei Bilder: das Erste zeigt ein in obiger Version zusätzlich eingefügtes Ereignis, das die EP stoppen sollte. das Zweite zeigt, dass Minute auf 60 gekommen ist und dieses Ereignis nicht eingetreten ist. TickerMinimal.mbp

Ich hänge das mal hier rein, weil es den Beta-Thread möglicherweise zu stark belasten wird. Ich habe bereits mit dem einfachen Ticker Probleme. In der Anlage gibt es einen Ordner Syncticker (der genauso auch noch in der alten V4-Anlage im Katalog ist), der Ticker läuft in V4 prima. Er läuft auch prima in V5, wenn ich alles andere rauswerfe. Siehe Log-Ausschnitt. Der Syncticker ist ein 0,1 s Endlos-Ticker. Er zählt Subticks hoch, wenn das bei 10 ist wird es wieder genullt und dann soll genau das passieren. (Bedingung siehe Bild, die zweite Bedingung ist nur Kippschalter auf Ein). [20:50:14] Subticks (_Compatibility_Delay (2)): Ereignisse, "Syncticker" [20:50:14] Modul-Variable wird gesetzt -> Ereignisse, "Subticks", 0 [20:50:14] Tick Minute [20:50:14] Minute Überlauf [20:50:14] Minute Überlauf und Stunde Überlauf [20:50:14] Tick Minute (_Compatibility_Delay): Ereignisse, "Subticks", 0 [20:50:14] Modul-Variable wird gesetzt -> Ereignisse, "Minute", 27 So soll es sein! Wenn ich alles so lasse, wie es aus der V4-Anlage kommt und nichts lösche sieht es etwas anders aus. [20:03:29] Subticks (_Compatibility_Delay (2)): Ereignisse, "Syncticker" [20:03:29] Modul-Variable wird gesetzt -> Ereignisse, "Subticks", 0 [20:03:29] Tick Minute [20:03:29] Minute Überlauf [20:03:29] Minute Überlauf und Stunde Überlauf Das Tick Minute (_Compatibility_Delay) kommt nicht. Wird jedenfalls nicht angezeigt. Klar kommen nun noch andere Dinge, aber die Delay-Meldung fällt ganz aus. Gleichwohl wird Minute tatsächlich hochgezählt. Wäre ja verzeihbar, wenn ich anhand der Delay-Meldung nachvollziehen könnte, wann das blöde Ding es schafft irgendwann mal zufällig Minute auch auf 60 zu setzen was ja vollkommen unmöglich sein sollte. Das kann eigentlich nur passieren, wenn dieser rekursiv-Algorithmus das Kommando einschachtelt und in so einem Flow zweimal dran vorbeikommt und das Minuten-Delay noch nicht zugeschlagen hat, Minute also immer noch auf 59 steht, Bedingung immer noch wahr und poff. Eigentlich müßte ich dazu Tick Minute wenigstens mal eine Ebene eingerückter vorfinden. Ist aber nicht. Ehrlich, das ist mir zu hoch. Ich mach jetzt nochmal ein Event rein, das reagiert, wenn Minute auf 60 kommt und setze irgendwas Blödsinniges rein, was das Log sofort auf Stop zwingt. Mal sehen, ob ich's so fangen kann. Ansonsten bin ich da mit meinem Latein am Ende.

Naja, es wird eine Objektvariable davon direkt beeinflusst. Und die dritte grüne Zeile bleibt auch genau so erhalten, wenn Schalterchen2 weg ist.

Hallo Neo, nochmal kurz zurück auf den oben beschriebenen Flow. Mir wär's wirklich lieber gewesen, wenn eine Aktion ein Flag gesetzt hätte, dass noch mal ein Durchlauf nötig ist und erst am Ende des Gesamtcodes alles nochmal durchlaufen wird, solange Flags gesetzt sind. Das rekursive Verhalten ist verdammt schwer nachvollziehbar und außerdem gefährlich. Gruß Andy p.s.: Anhang bringt den Stack ganz einfach zum Überlaufen. Übrigens warnt er auch nicht, wenn ich Schalterchen2 weglösche, dass dies noch in Ereignissen drinhängt (wie es in V4 der Fall war). Und den Namen behält er auch noch bei (Kippschalter Aktionen - hier jetzt rausgelöscht). kompatestV5overflow.mbp

Geben die die Polygone in Millionen an? Auf den ersten Blick sieht's doch minimal aus. Es könnten die Texturen sein, oder? Die sind vermutlich höherauflösend als wirklich nötig.

Hallo, da ich da immer noch einem äußerst üblen Bug nachjage, muß ich mir einige Beispiele zurechtmachen. Kann ich, falls interessant, hier dann auch posten. Mit den hier angehängten Beispielen mache ich zum Einen einen Kompatibilitätstest eines nicht ganz einfachen Konstrukts, und dann schauen wir mal, wie V5 intern tatsächlich arbeitet! Wen das interessiert, Konzentration einschalten, ansonsten beim nächsten Poster weiterlesen. Also: Um was geht's: Ich habe hier einen Kippschalter mit zwei Schalterchen. Lege ich den Kippschalter um, triggert er das erste Schalterchen. Das zweite ist eigentlich nur da um Nebenwirkungen zu checken. Die beiden Ordner haben je zwei Ereignisse und die Ordner sind identisch, nur die Titel sind unterschiedlich. Auch hier ist der zweite Ordner nur da, um die Situtation noch etwas zu verkomplizieren. Beide Ereignisse arbeiten mit dem _Trigger1-Trick, sollen also universell einen schaltenden Schalter verarbeiten. Die Schalterchen haben eine Objektvariable mit dem Namen Wert, der am Anfang auf nix steht. Außerdem gibt es noch eine normale Variable namens count, die einfach nur hochzählt, wie oft da wirklich was gemacht wird. 1.Ereignis: der betätigte Schalter soll seine Objektvariable von nix auf A stellen, dann drückt er sich selbst nochmal 2.Ereignis: nun von A auf B und auch nochmal drücken, was dann keine Wirkung mehr haben sollte. kompatestV4V5 kann man in V4 laden. Kippschalter schalten, das Schalterchen1 endet mit Wert B. Fein. Aber wenn man sich count mal ansieht, das steht auf 6. wtf würde der Ami sagen. Ich will da jetzt gar nicht drauf eingehen, warum. Das Endergebnis ist wichtig und das ist wie gewünscht. kompatestV4V5 nun in V5 laden. Kippschalter schalten, das Schalterchen1 endet mit Wert B. Und count steht tatsächlich auch auf 6. Hölle, hölle, aber es ist kompatibel! Jetzt schmeiße ich mal alle Kompatibilitätsdelays raus. So geschehen in kompatestV5, was sich natürlich nur in V5 laden läßt. Nun mal Ereignisprotokoll einschalten und Kippschalter schalten. Jetzt wird's interessant. Das Schalterchen1 endet mit Wert B, aber count endet nun, wie es ein 'normaler' Programmierer erwarten würde, auf 2. Es sind nur zwei agierende Aktionen nötig gewesen! Noch viel interessanter ist nun aber, wie das Ergebnis zustande gekommen ist. Wie zu erwarten, schaltet das erste Ereignis in Ordner1 das Schalterchen auf A, aber - wer nun linear 'normal' weiterdenkt, sieht sich getäuscht - es ist NICHT sofort das zweite Ereignis des ersten Ordners und es ist NICHT das zweite Ereignis des zweiten Ordners das nun von A auf B setzt. Sondern: man sehe sich den Flow in der Ereignisprotokollierung an. Hier wird nun in der Tat mit rekursiven Aufrufen gearbeitet! d.h.: das von Ereignis 1 ausgelöste Selbstschalten des Schalterchens löst einen kompletten neuen Aufruf der EV aus! Es werden nun sofort erneut alle Ereignisse ausgeführt, die sich auf das Schalten eines Schalters beziehen! Wonach dann Ereignis 2 des ersten Ordners auf B setzt (aber halt erst, nachdem nochmal - natürlich jetzt ohne Auswirkung - über das erste Ereignis gelaufen wurde!). Bis der zweite Ordner mal drankommt, ist der Käse schon gegessen. Schalterchen steht schon auf B und es muß da nichts mehr gemacht werden. Also: die Funktionsweise muß nun verinnerlicht werden, denn sie bedeutet, dass da mitten in der Aktionsliste eines Ereignisses ganz schön viel mit einer Anweisung passieren kann. Irgendwie sehe ich da allerdings auch die Gefahr einer Endlosschleife mit immer tiefer laufendem Stack - also Crash... Gruß Andy ps.: Selbstverständlich ist mit diesen rekuriven Effekten diese Programmierung des Problems alles andere als ideal, denn insgesamt kümmert er sich um 17 Ereignisse. Die Lua-Version ist da optimaler... kompatestV4V5.mbp kompatestV5.mbp kompatestV5Lua.mbp

Link Viel Spaß beim analysieren

Moin Hans, deswegen warst Du so ruhig in letzter Zeit Irgendwo im Netz gibt's ein Video, wie ein anderes Team(!) diesen Hbf mit einem anderen System aufbaut. Kannst Du mal abschätzen, wo Du stehst und was noch kommt. Direkten Link finde ich jetzt nicht wieder, aber mit dem Suchbegriff Frankfurt Hbf virtuell findest Du noch Anschauungsmaterial ohne Ende. Gruß Andy

Noch ein Beispiel zum Thema Kompatibilitätkonflikt. Es kann nämlich noch schlimmer kommen! Dann ist Neo machtlos! In V4 hatte ich z.B. Ringschuppentore erst diskret als Objekte benannt und konnte ihre einzige Animation 'Tore' einstellen. Später habe ich das verallgemeinert und benutzerdefiniert $($_Trigger2.Block).Lokschuppen als Objekt angegeben. Der Haken: weil da in Animationen noch 'Tore' drinstand, hat er's gefressen und auch gemacht. ABER: mit der späteren Objektangabe wäre es ihm selbst in V4 zu indirekt geworden. Er hätte da bei Neueintrag gar keine Animation mehr gefunden. Jo, und genau das passiert dann bei V5 auch. Fazit: ab einem bestimmten Punkt kann er gar keine Kompatibilität mehr aufbauen. Da muß der Anlagenautor eben die Anlage pflegen, wenn sie erhalten bleiben soll. Insbesondere, wenn er selbst vorher etwas inkompatibel war... Gruß Andy

Sorry, mit VB kann ich nicht helfen. Was ich aber für die Ansteuerung sagen kann: Es gibt ja zwei Kanäle. Dementsprechend solltest Du zwei Threads anlegen! An den Ereigniskanal brauchst Du nichts senden, der ist nur für die Ausgabe zuständig. Vergiß beim Senden das abschließende CarriageReturn IM Sendestring nicht, sonst ist der Befehl nicht komplett und nichts passiert. Nach dem Senden mit der Receivefunktion auf die Antwort warten. Wenn mal die erste einfache Anweisung mit Antwort funktioniert, dann ist der Rest nur konzentriertes Studium der Wiki, was gesendet werden muß. Es ist dann fast einfach. String zusammenbasteln, wegschicken, lauschen, auswerten. Und außerdem: Teste nichts mit der neuen V5-Beta. Da ist die Schnittstelle noch Baustelle. Gruß Andy

Siehst Du Manni etwa? Also...!

Eigentlich... könnten wir das mit Lua alles selbst rechnen. Aber das wäre ja wieder aktives Terraforming. Hätte man Zugriff auf die Bodenplatten höhen/löcher/textur-Daten könnte mal sehr viele Dinge selbst machen, wie z.B. meine Idee mit der 'Sprühlok', sehr exakte Schnitte, eine komplette Bodenplatten-Datenverschiebung wenn die Bodenplatte mal nach links oder hinten erweitert wird etc., es könnten etliche Feature-Wünsche gestrichen werden - und es würden Daten weder erzeugt, noch gelöscht werden. Also - harmlos! Ich meine, Neo sollte da vielleicht doch einen Gedanken dran verschwenden (wenn die derzeitigen Funktionen stabil sind!). Ich habe übrigens jetzt nicht geschaut, ob das nicht vielleicht sogar schon möglich ist. Gruß Andy ps: @Neo. Wichtig: Ich habe mal auf meine mit V4 erstellte Anlage in V5 laufend meinen Logger mitlaufen lassen. Jeder Variablenname wird da auf der Schnittstelle von je 3 Anführungszeichen ummantelt. Nur, für den Fall, dass dies noch nicht aufgefallen ist.