BahnLand

Hallo Henrik, einen Punkt solltest Du auf keinen Fall aus den Augen verlieren: 3) LoD-Stufen! Ohne diese zwingt nämlich Dein Prachtsück - vor allem wenn es in mehreren Exemplaren und anderen solchen Kalibern zum Einsatz kommen sollte - die PCs ziemlich schnell in die Knie. Wenn Du die Polygone und Eckpunkte Deiner Lok in LOD1 und LOD2 jeweils auf etwa 1/3 der vorherigen LoD-Stufe reduzierst und damit in LOD2 auf unter 5000 Polygone kommst, kann jeder die Lok auf seiner Anlage einsetzen, ohne befürchten zu müssen, nur noch Standbilder zu sehen - und der Filigranität Deiner Ursprungslok tut das keinen Abbruch, weil sie im Nahbereich in voller Schönheit betrachtet werden kann. Viele Grüße BahnLand

Eigene Protokoll-Ausgaben im Ereignisprotokoll ganz einfach selbstgestrickt Hallo zusammen, wenn man in einer Ereignissteuerung einen Fehler oder ein unerwartetes Verhalten diagnostizieren möchte, sind zusätzlich bewusst eingestreute Protokollausgaben meist sehr hilfreich. Ich möchte hier zwei kleine Bespiele zeigen, wie man solche Protokollausgaben mit minimalem Aufwand selbst produzueren kann: 1. Beispiel Man definiere in der Ereignisverwaltung ein Benutzerdefiniertes Ereignis und füge diesem ein paar Parameter vom Typ "Text" hinzu. Es brauchen keine Inhalte (Bedingungen, Aktionen, ...) hinzugefügt zu werden. In den Ereignisdefinitonen, wo Protokollzeilen ausgegeben werden sollen, fügt man nun Aufrufe dieses "leeren" Ereignisses hinzu. Entsprechend der Anzahl eingerichteter Parameter in der Ereignisdefinition "Print" stehen nun beim Aufruf diese Parameter zum Ausfüllen zur Verfügung. Man kann auch Parameter leer lassen. Dann wird einfach der Leerstring "" hergenommen. Man kann als Parameter aber auch Referenzen auf Objekte hinterlegen und beispielsweise deren Bezeichnungen ausgeben lassen. Dort werden dann im Ereignisprotokoll die (Bezeichungen der) tatsächlichen Objekte ausgegeben. Leider sticht die Ausgabe im Protokoll nicht "besonders" hervor, weil es sich "nur" um die Protokollierung eines aufgetretenen Ereignisses (unter vielen) handelt. Dennoch kann man die zusätzlivchen Protkollausgaben am Namen der hierfür verwendeten Ereignisdefinitoon (hier "Print") erkennen. 2. Beispiel Dieses untescheidet sich vom 1. Beipiel nur dadurch, dass man der Ereignisdefinition "Print" eine Zeile "Lua-Code" verpasst: Das "print"-Statement bekommt genau jene Parameter verpasst, die das Print-Ereignis "nach außen" anbietet. Die Aufrufe aus den obigen Bildern bleiben unverändert. Doch die print-Anweisung in der Lua-Ereignisdefinition gibt nun zusätzlich die im Ereignis-Aufruf übergebenen Parameterwerte in grüner Schrift aus, welche hier deutlicher hervortritt. Nachteilig wirkt sich hier allerdings aus, dass das Protokoll der Ereignis-Auslösung trotzdem noch ausgegeben wird, sodass jetzt jeder "Print"-Aufruf zu einer doppelten Ausgabe führt. Frage an @Neo: Wäre es eventuell möglich, so etwas Ähnliches etwa in einer solchen Form ... ... direkt in der Ereignisverwaltung anzubieten, wobei dann tatsächlich nur die Ausgabe selbst (ohne Ereignisbezeichnung) im Ereignisprotikoll (in einer auffälligen Farbe) ausgegeben wird? Am einfachsten wäre es natürlich, wie beim "Kommentar" etwas in das Lua-Script einzufügen (nämlich die im vorletzten Bild gezeigte Hintereinander-Reihung der Parameter in der Lua-print-Anweisung anstelle des Kommentartextes in der Form "--text" oder "--[[ text --]] , ohne die "Trace"-Überschrift zu protokollieren). Viele Grüße BahnLand

Hallo Max, laut dieser Info (auf "Siehe mehr" klicken) hat Roco dem ÖBB-Krokodil einen "schweizerischen Lichtwechsel" verpasst und hierfür nur die Lampe in Fahrtrichtung "hinten rechts unten" rot ausgeleuchtet. Mehr Information habe ich leider nicht gefunden. Wenn diese Aussage auch für das Vorbild zutrifft, ist sicher eine rote Filterscheibe mit im Spiel. Leider konnte ich sonst keine Informationen zu diesem Thema finden. Viele Grüße BahnLand

Hallo zusammen, ich habe dieses Feature meistens eingeschaltet. Aber wie oben schon erwähnt wurde, kann man ja zumindest bei der Bergfahrt die Geschwindigkeit mittels der EV etwas drosseln (und nachher in der Ebene wieder auf den Standard zurückstellen). Deshalb würde ich auch ohne dieses Feature zurecht kommen. Übrigens konnte man zur Dampflokzeit deutlich hören, wenn ein Zug in die Steigung einfuhr. Da wurde die "Taktfrequenz" merklich langsamer (habe ich selbst erlebt). Und Schiebebetrieb (z.B. an der Geislinger Steige) gab es ja auch im Elektrozeitalter noch, um den schweren Güter- und früher sogar auch noch Personenzügen auf den Berg zu helfen. Also so abwegig ist die Geschwindigkeitsdrosselung am Berg beim Vorbild nicht. Mag ja sein, dass die heutigen modernen Loks genug "Reserve" besitzen, um auch am Berg die "normale" Geschwindigkeit fahren zu können. Viele Grüße BahnLand

Hallo @BauerHeini, kleine Ergänzung zu @fzonk's anschaulichem Beispiel: Wenn Du das Ereignis "Benutzerdefiniert" umbenennst in "Benutzerdefiniert xyz" und dann auch im Aufruf (in der Aktion) "Benutzerdefiniertes Ereignis auslösen" als adressiertes Ereignis "Benutzerdefiniert xyz" einträgst, wird es vielleicht etwas deutlicher. So wie es dasteht könnte man nämlich fälschlicherweise den Begriff "Benutzderdefiniert" als "Schlüsselwort" interpretieren. Es ist aber tasächlich die Bezeichnung dieser konkreten Ereignisdefinition, neben der es theoretisch auch noch weitere andere benutzerdefinierte Ereignisse mit anderen Namen geben könnte. Viele Grüße BahnLand

Hallo Michael, es ist nur scheinbar bloß ein Kamerawechsel. Tatsächlich gibt es eine dritte Kamera, die ihren Standort und ihre Ausrichtung mit dem Klick auf den Button immer von einer der festen KAmeras auf die andere wechselt. Insofern hat @Andy hier ein interessantes Beispiel, wie man mittels Lua Positionen einzelner Objekte mittels der EV modifizieren kann. Auch @EASY hat so etwas in seinem "Schattenbahnhof" gemacht, wo die Güterzüge neu zusammengeewürfelt werden (leider kann ich momentan den entsprechenden Beitrag nicht mehr finden). Viele Grüße BahnLand

Hallo zusammen, vielen Dank für Eure lieben Worte! Ich werde natürlich weitermachen. Viele Grüße BahnLand

Hallo Frank, Deine "Tss 4" ist ein Prachtstück!!! Viele Grüße BahnLand

Hallo @quackster, vielleicht hätte ich die "Dreiecke" unsichtbar machen sollen. Dann wäre aber die Längenmodifikation des Kopfbahnhofgleises durch den Anwender mit Beibehaltung der Funktionalität nicht mehr mit wenigen Handgriffen möglich gewesen. Dass hier "gefühlte 1000" Gleiskontakte (mit identischer Funktionalität) auf den Gleisen liegen, die man im Simulationsmodus sowieso nicht sieht, die ich aber für die automatische Steuerung des Kopfbahnhofsgleises benötige, lassen sich leider nicht vermeiden, wenn ich - wie hier geschehen - diese Funktionalität erzielen möchte, ohne selbstgeschriebene Lua-Scripts einzusetzen. Die Ereignissteuerung dieses Bausteins ist zu 100% mit der grafischen EV-Schnittstelle realisiert - ich habe keine einzige eigene Lua-Zeile dazu beigesteuert! Die komplette Ereignissteuerung des Bausteins besteht übrigens aus nur 11 Ereignisdefinitionen mit insgesamt nur 78 (also im Durchschnitt 7) Bedingungen und Aktionen, welche die gesamte Funktionaliät realisieren. Eigentlich verfolge ich mit der Veröffentlichung dieser Bausteine gerade das Ziel, es für den Anwender dadurch einfacher zu machen, dass die "Standard-Funktionalitäten" eines solchen Bausteins in der Ereignissteuerung bereits fertig implementiert sind, und der Anwender sich deshalb darum nicht mehr zu kümmern braucht. Deshalb gibt es ja auch zu jedem Baustein eine ausführliche Gebrauchsanletung (als Beschreibung zum importierten Haupt-Ereignismodul), welche neben der Beschreibung der Funktionalität auch zeigt, wie man den jeweiligen Baustein "bedient" (siehe hierzu auch die jeweils beigefügten Beispiel-Anlagen). Dass ich mein Ziel bei Dir offensichtlich verfehlt habe, tut mir sehr leid. Sollte dies auch die Mehrheit der anderen Hobby-Kollegen so sehen, bitte ich um Verzeihung und um entsprechende Informationen, wie ich die Module zukünftig besser machen kann. Es macht ja keinen Sinn, dass ich hier Anlagen-Bausteine zur Verfügung stelle, von denen nur ich meine, dass sie den Nutzern die "Arbeit" beim Bau ihrer virtuellen Anlage erleichtern. Ich fände es jedenfalls schade, wenn deshalb die Herstellung und Veröffentlichung solcher Anlagenbausteine nicht mehr gewünscht werden sollte. Ich habe etwas Probleme damit, komplexere Vorgänge mit wenigen Worten auszudrücken. Genauso fällt es mir manchmal schwer, sehr kurze Beiträge in diesem Forum zu verstehen - vor allem dann, wenn der Schreiber viele seiner Gedanken zwischen den Zeilen versteckt. Deshalb möge man mir meien manchmal etwas längeren Beiträge verzeihen. Übrigens: Auch ich gehöre zur "Rentner"-Generation in dieser Community (sonst hätte ich überhaupt nicht die Zeit, mich so intensiv nicht nur mit dem Modellbahn-Studio selbst, sondern auch mit dem Forum.zu beschäftigen). Viele Grüße BahnLand

Hallo Jan, die 218 in TEE-Lackierung hatte ein rotes Dach: https://www.bahnspezl.de/images/pictures/deutschland/diesellokomotiven---db/218-_v-164_-_-225_8/218-217-8/218-217-8-1981-05-09-hof_-foto-peter-wittmann.jpg Übrigens gab es auch eine (einzige) 218 in ozeanblau-beige mit blauem Dach: https://i.pinimg.com/originals/10/76/3c/10763c02aa53dfa709a5ab4bc018ae57.jpg Viele Grüße BahnLand

Hallo Frank, schau Dir bitte mal das "ziemlich einfache" Beispiel an, das nur ais einer einzigen Ereignisdefinition besteht: Pfad-Vervielfältigung.mbp Ich habe hier einen Hauptpfad mit 3 hintereinander gereihten "Bedingungen", bei denen jeweils der "Erfüllt"-Pfad "normal" durchlaufen wird, während der "Nicht-Erfüllt"-Pfad jeweils eine weitere Bedingung enthält, wo in beiden Pfaden eine Zeitverzögerung eingebaut ist. Als "Inhalte" habe ich jeweils nur einen Kommentar eingefügt - genauso zwischen den Bedingungen des Hauptpfads. Und das war's dann auch schon. Insgesamt besteht die Ereignisdefinition aus 31 Einträgen. Wenn Du jetzt das dazugehörigre Lua-Script anschaust, wirst Du dort 128 Zeilen anstelle der 31 Einträge in der grafischen EV-Derfinition finden, wobei die Mehrzahl der Zeilen als "Wiederholungen" auftreten. Dies liegt daran, dass das Modellbahn-Studio die sich in der grafischen Ereignisdefinition wieder vereinigenden Pfade in Lua nicht ebenfalls wieder vereinigen kann. Der Grund liegt darin, dass auf eine Zeitverzögerung folgende Aktionen ablauftechnisch in einem neuen "Ereignis" abgearbeitet werden. Und dort müssen dann natürlich auch alle Pfade komplett hinterlegt sein, die im Anschluss an die Zeitverzögerung abgearbeitet werden sollen. In der grafischne EV nach einer Zeitverzögerung sich wieder vereinende Pfade müssen also in Lua jedem der Zeitverzögerungs-Ereignisse separat zugeordnet werden, wo sie durchlaufen werden sollen, und werden daher notgedrungen vervielfältigt. Wenn also in der grafischen EV viele Verzweigungen, in denen unterschiedliche Zeitverzögerungen eingebaut sind, später wieder in gemeinsame Pfade einmünden, werden diese entsprechend vervielfältigt. Treten dann solche Verzweigungs-Konstellationen noch mehrmals hintereinander auf, führt das zu einer entsprechenden Multiplikation (nicht nur Addition!) der Vervielfältigungen aus den EInzelkonstellationen, was dann letztendlich zu einer "Explosion" der nach Lua umgewandelten Ereignisdefinition führt. Und genau das ist bei Deiner Ereignisdefinition passiert! Viele Grüße BahnLand

Hallo @Timba, diese Weisheit gefällt mir! Viele Grüße BahnLand

Hallo Henrik, die Lok wird ein Prachtstück! Man sieht richtig die Arbeit, die Du da bisher hinein gesteckt hast. Viele Grüße BahnLand

Hallo FeuerFighter, Danke für die aufklärende Antwort. Wieder was dazu gelernt. Viele Grüße BahnLand

Hallo, Frage eines Unwissenden: Sind die Arbeitsmonturen der Feuerwehrleute und der THW-Einsatzkräfte - abgesehen von der Farbe und eventuellen Aufschriften und Aufnähern - eigentlich nicht identisch? Läge es da dann nicht näher, anstatt völlig neuer THW Figuren besser die bestehenden Feuerwehr-Einsatzkräfte mit tauschbaren Texturen zu versehen und eventuell damit "bekleidete" THW-Menschen dann als Variationen der gleichartigen Feuerwehrleute anzubieten? Nur so eine Idee (weniger Arbeit für den Erbauer, größere Anwendungsmöglichkeiten für den Benutzer, weniger Katalogeinträge). Ja. Dies gilt aber nur, solange die Freigabe noch innerhalb der 30-Tage-Frist der Entwürfe erfolgt. Andernfalls gibt es zwischen dem Ablauf der 30-Tage-Frist und der tatsächlichen Freigabe durch @Neo eine zeitliche Lücke, in der die Modelle dann nicht (mehr) zur Verfügung stehen. Um sicher zu gehen, dass man zumindest die 30-Tage-Frist noch voll zur Verfügung hat, kann man das Modell unmittbar vorher noch einmal als Entwurf veröffentlichen (lässt meines Wissens die 30-Tage-Frist wieder von vorne starten) und dann die "richtige" Veröffentlichung nachziehen. Viele Grüße BahnLand

Hallo Brummi, auch ich lerne bezüglich Sketchup immer noch was dazu! Danke für den Hinweis auf die mir bisher noch nicht bekannte Funktion für Einzelkanten! Viele Grüße BahnLand

Hallo, auch ich weigere mich beharrlich, den "Social-Media"-Vereinen beizutreten. Bevor ich mich da beispielsweise für ein bestimmtes Video zuerst anmelden muss, verzichte ich dann lieber darauf, dieses anzuschauen. Viele Grüße BahnLand

Hallo @SputniKK, ich kann's Dir leider nicht sagen - ist weit über 50 Jahre her. Der unten abgebildete Farbton passt am ehesten zu meiner ziemlich verblassten Erinnerung. https://www.lanemotormuseum.org/media/zoo/images/nsu_prinz_1000_1967_web01_9eef9402a993bf42f37fa762b8b7824b.jpg Über die Farbkennzeichnungen bei den Autos weiß ich nichts. Aber greife doch die Farbe einfach vom Bild ab und und spiele dann ein bisschen mit der Helligkeit und Farbsättigung herum. Nach "Gefühl" wirst Du dann sicher einen "passenden" Farbton finden. Viele Grüße BahnLand

Hallo @SputniKK, eine Tante von mir hatte einen grünen. Da durfte ich mal auf der Rückbank mitfahren. Viele Grüße BahnLand

Hallo @Goetz, Danke für die Korrektur. Ich hatte mich da wohl missverständlicherweise bei der "Verkürzung" des Begriffs "Objektvariable" (vom Typ Liste oder Tabelle) auf "Variable" selbst reingelegt. Wäre die Objektvaribale vom Typ "Objekt" gewesen, hätte es wahrscheinlich funktioniert. Ein Parameter vom Typ "Liste" oder "Tabelle" kann im aufgerufenen Script wohl grundsätzlich nicht verändert zurückgegeben werden? Oder gibt es da eine andere Möglichkeit? Viele Grüße BahnLand

Hallo Karl, das "Glätten" wirkt sich nur auf in Sketchup markierte Gruppen aus. Besitzt die Bauteil-Gruppe Untergruppen, werden diese nicht berücksichtigt (müssen also bei Bedarf separat gelättet werden). Du kannst die Millchkanne natürlich auch komplett als Gruppe zusammenfassen. Dann müsste es eigentlich funktionieren. Viele Grüße BahnLand

Hallo Frak, nachdem ich das Video gesehen habe, kann ich nur noch sagen: WOW WOW ! Viele Grüße BahnLand

Hallo, Mit einem zusätzlich eingebauten "Ereigniszähler" konnte ich nun nachweisen, dass die Ereignisse "Gleiskontakt 1/2/3 wird beim Betreten asugelöst" tatsächlich (zufällig) mehrmals ausgelöst werden. Warum dies so ist, und weshalb dieses Phänomen beim meiner Testanlage nur bei der Fahrt im Uhrzeigersinn auftritt, während gegen den Uhrzeigersinn alles korrekt abläuft, ist mir allerdings ein Rätsel. Hier noch einmal die Testanlage, nun mit dem eingebauten Ereigniszähler: Fahrzeuglisten 2.mbp Viele Grüße BahnLand @EASY: Danke für Deinen Test. Das lag dann bei mir tatsächlich an den "rechts herum" nur mit positivien Geschwindigkeiten gefahrenen Versuchen.

Hallo @Goetz, vielen Dank für Deine sehr hilfreiche Antwort. Erst hierdurch bin ich darauf gekommen, dass ich bei den Gleiskontakten 1 und 2 als erstes Argument nicht ein Objekt, sondern eine Variable ( "([Gleiskontakt].Fahrzeugliste)" und "([Gleiskontakt].Fahrzeugtabelle)") übergeben habe. Und Variablen, die im Aufruf des benutzerdefinierten Ereignisses übergeben werden, können wohl nicht überschrieben werden. ich werde mich daher auf das Beipiel mit Gleiskontakt 3 konzentrieren. Viele Grüße BahnLand

Hallo zusammen, der nächste Anlagen-Baustein, den ich mir vornehmen möchte, ist der Ablaufberg. Meine bisherige Realisierung beruhte darauf, dass die über den Berg zu schickenden Wagen alle mit Nummern bezeichnet waren, und aufgrund der Abarbeitung der Nummernsdchleife diese auf 100 (und damit auch der Güterwagenpool auf 100) begrenzt war. Mit der Lua-Funktion layout:getVehicleGroup(Triebfahrzeug) , wobei als Argument "Triebfahrzeug" die schiebende Lok des über den Ablaugberg zu drückenden Güterzuges eingesetzt wird, kann man sich nun alle im Zug vorhandenen Wagen in einer Liste ausgeben lassen und diese abarbeiten. Damit kann die Einschränkung auf rein numerische Fahrzeugbezeichnungen und die Begrenzung auf 100 Fahrzeuge aufgehoben werden. Im Vorgriff auf diesen neuen Anlagen-Baustein habe ich ein paar Versuche gemacht und bin dabei auf ein paar Eigenarten gestoßen, die ich so nicht verstehe. Basis für meine Vesuche ist eine kleine Testanlage, die ich auch hier zum Nachvollziehen der von mir beobachteten Effekte hinzufüge: Fahrzeuglisten.mbp Die Züge stehen auf 3 Bahnhofsgleisen und können über die Signale jeweils in beiden Richtungen losgeschickt werden. Beim Ausfahren eines Zuges wird mit dem automatischen Stellen der Ausfahrweiche auch die gegenüberliegende Einfahrweiche entsprechend gestellt, sodass der ausgefahrene Zug immer auf seinem eigenen Gleis wieder einfährt, ohne dass man sich um die Weichenstellungen kümmern muss. Allerdings darf ein weiterer ZUg deshalb immer erst dann ausfahren, wenn der erste Zug bereits wieder eigenfahren ist. Auf der gegenüberliegenden Seite des Gleisovals sind 3 Gleiskontakte positioniert, welche jeweils als Objektvariable eine Liste (Gleiskontakt 1), eine Tabelle (Glleiskontakt 2) und beides (Gleiskontakt 3) besitzen. Diese sollen beim Überfahren durch einen Zug jeweils mit dessen Fahrzeugen bestückt werden. Hierbei möchte ich die Liste/Tabelle des überfahrenen Gleiskontakts bzw. den Gleiskontakt selbst sowie den befahrenden Zug (dessen Triebfahrzeug) als Parameter an ein benutzerdefiniertes Ereignis übergeben, in dem dann mittels der oben angegebenen Lua-Funktion die Fahrzeuge des Zuges in die Liste oder Tabelle übetragen werden, um dann in weiteren über die grafische EV-Schnittstelle definierten Ereignisdefinitionen ausgewertet werden zu können. Die Objektvariablen der Gleiskontakte habe ich dabei wie folgt initialisiert: Die Definitionen für die Gleiskontakte 1 und 2 sind hier absichtlich so gewählt, um später aufzeigen zu können, dass sie nicht aktualisiert werden. Die Objektvariablen des Gleiskontakts 3 werden dagegen tatsächlich korrekt aktualisiert. Die durch die Gleiskontakte ausgelösten Ereignisdefinitionen dienen nur dazu, die als benutzerdefinierte Ereignisse definierten Lua-Scripts mit den am jeweiligen Gleiskontakt als Auslöser identifizierten Objekten als Parameter aufzurufen: Die in den benutzdefinitierten Ereignissen hinterlegten Lua-Scripts basieren auf den Beispielen aus diesem Beitrag von @EASY (vielen Dank dafür!). Ich habe diese wie folgt abgewandelt: Bei den Tests hat sich dann herausgestellt, dass die Beispiele mit den Gleiskontakten 1 und 2 nicht funktionieren. Betrachtet man hier das Ereignisprotokoll, ... ... erkennt man, dass die Listen im jeweiligen Lua-Script selbst zwar korrekt erzeugt werden, die Ergebnisse aber in den Objektvariablen der Gleiskontakte 1 und 2 aber nicht ankommen. Ich vermute, dass das daran liegt, dass anstelle der in den aufrufenden Ereignisdefinitionen hinterlegten Parameter "([Gleiskontakt].Fahrzeugliste)" und "([Gleiskontakt].Fahrzeugtabelle)" in den aufgerufenen Lua-Script-Ereignisdefinitionen "irgendwie" deren Inhalte übergeben wurden (Anzeige "(3 Elemente)" im Ereignisprotokoll). Und das verstehe ich nicht. Nur beim Gleiskontakt 3 wird dieser als Paramter korrekt übergeben, sodass auch hier nach der Bearbeitung das Ergebnis korrekt in den Objektvariablen des Gleiskontakts hinterlegt ist: Unabhängig davon ist mir noch eine weitere "Ungereimtheit" aufgefallen: Wenn ich in der Testanlage die Züge nach rechts ausfahren lasse, sodass sie die 3 Gieskontakte in der Reihenfolge 1+2+3 passieren, werden auch genau die 3 zugehöigen Ereignisprotokolle in der richtigen Reihenfolge angezeigt. Die Reihenfolge stimmt zwar auch in der entgegengesetzten Richtung (hier 3+2+1), doch werden in dieser Richtung im Ereignisprotokoll zufallsgesteuert einige Gleiskontakt-Ereignisse mehrfach aufgelistet: Im obigen Protokoll werden die Ereignisse sowohl für den Gleiskontakt 2 als auch für den Gleiskontakt 1 mehrfach aufgelistet, wobel die Anzahl der Wiederholungen bei unterschiedlchen Durchläufen zufällig ist. Und es tritt ausschließlich bei der Fahrt im Uhrzeigersinn auf. Entgegen dem Uhrzeigersinn triitt jedes der 3 Ereignisse im Protokoll immer korrekt genau einmal auf. Mir ist jetzt allerdings nicht klar, ob die Ereignisdefinitionen nun tatsächlich mehrfach ausgeführt wurden, oder ob es sich nur um einen Ausgabefehler in der Protokolldatei handelt. Denn eine Wiederholung der Ereignisauswertungen führt in der hier vorliegenden Konstallation zu keinem geänderten Ergebnis. Viele Grüße BahnLand