Goetz

Das ist ein Ereignis, dass nicht durch Aktivitäten in der Anlage ("Signal schaltet", "Zug verlässt Gleis" etc.) ausgelöst wird, sondern durch eine Aktion in einem anderen Ereignis. Diese Aktion heißt Der Auslöser kommt also vom Benutzer. Das unterscheidet dieses Ereignis von den Übrigen. Im Ereignis passieren dann dieselben Dinge wie in anderen Ereignissen auch. Vielleicht hilft es, wenn du dir ganz generell die folgende Denkweise angewöhnst: Die Ereignisse sind die Auslöser für die EV. Also Signal schaltet, Variable ändert sich, Timer läuft ab und so weiter. All diese Dinge ereignen sich während des Betriebs. Egal, ob du damit etwas anstellst oder nicht. In der Ereignisverwaltung legst du dann fest, welche Aktionen als Reaktion auf solch ein Ereignis ausgeführt werden sollen. Und in diesem Sinne geht es beim benutzerdefinierten Ereignis um einen vom Benutzer initiierten Auslöser.

Du (doch) nicht. Aber andere Menschen tun das. Und war es nicht erst vor ein paar Tagen, dass jemand sich für das MBS interessierte und vorab hier ein oder zwei Fragen dazu gestellt hatte?

Das wäre eine ziemlich sichere Methode, Neuzugänge zu verhindern. Kaum einer möchte Mitglied in einem Club werden, den er von außen nicht einsehen kann.

Hallo Timba, alternativ kann man das Monstergleis, welches ja seinen Bestimmungsort schon gefunden hat, auch mittels Heftzwecke anpinnen. Dann ist es nur noch per Doppelklick oder Modellliste auswählbar, lässt sich in diesem Fall aber bequem "am Stück" handhaben. Gruß Götz

Oh, tut mir leid Michael. Ich kann ehrlich nicht sagen, warum ich deinen Namen verwechselt habe.

Die Befehle selbst erzeugen keine neuen Kopien. Bei Bahnland ist die Tabelle, die er als Ziel für table.insert angegeben hat, eine Kopie. Ob das bei dir ebenso der Fall ist muss ich mir anschauen. Und synchronisiert wird per se gar nichts. Weder in Lua, noch in anderen Sprachen. Entweder verbirgt sich hinter zwei Namen dieselbe Adresse oder nicht. Die Sache ist deshalb ein wenig "tricky", weil man genau hinschauen muss, wo was übergeben wird. In Lua läuft es so ab: Liste_1 = {"John", "Paul", "George", "Ringo"} Liste_2 = Liste_1 -- Kopie oder Weitergabe der Adresse? s = table.concat(Liste_2, "\n") -- alle Texte der Tabelle in einen String print("Liste 2\n"..s.."\n") -- sieht aus wie Liste_1 table.insert(Liste_1, 1, "Stewart") s = table.concat(Liste_1, "\n") -- alle Texte der Tabelle in einen String print("Liste 1:\n"..s.."\n") -- Liste 1 hat einen neuen Namen dazu bekommen s = table.concat(Liste_2, "\n") -- alle Texte der Tabelle in einen String print("Liste 2:\n"..s.."\n") -- Liste 2 ebenfalls, weil nur die Adresse übergeben wurde. Es ist dieselbe Tabelle! -- Das heißt: umgekehrt wirkt sich eine Änderung in Liste_2 auch auf Liste_1 aus. table.insert(Liste_2, 1, "The Beatles") s = table.concat(Liste_1, "\n") -- alle Texte der Tabelle in einen String print("Liste 1:\n"..s.."\n") -- Liste 1 hat einen neuen Namen dazu bekommen Selbst dann, wenn man eine globale Tabelle als Funktionsargument übergibt, bleibt es dieselbe Adresse: Liste_1 = {"John", "Paul", "George", "Ringo"} function Test(Liste_2) table.insert(Liste_2, 1, "The Beatles") local s = table.concat(Liste_2, "\n") print("Liste 2:\n"..s.."\n") end Test(Liste_1) s = table.concat(Liste_1, "\n") print("Liste 1:\n"..s.."\n") In diesem Punkt ist Lua wirklich eigenartig. Eine Variable wäre als Funktionsargument lokal definiert. Sie könnte sogar den selben Namen haben, wie die globale Variable und würde dennoch nichts mit ihr zu tun haben. Eine lokale Änderung hätte keine globale Auswirkung. Aber bei der Tabelle wird nur die Adresse an den lokalen Träger übergeben. Und die weist auf dieselbe Tabelle. Aber in der EV von MBS passiert mehr als nur Lua. Die Übergabe von einem Ort (Objekt, Modul etc.) zum anderen wird nicht von Lua erledigt. Sonst gäbe es keine adressierbaren Objekte. Die kennt Lua nämlich so nicht. Dahinter steckt Neos Cleverness! Und bei der Übergabe einer Tabelle in der EV wird diese Tabelle kopiert. Deshalb ist es ratsam, nur das Objekt zu übergeben, welches die Tabelle beherbergt. Denn wenn ich das Objekt (und die darin enthaltene Tabelle) anspreche, dann ist es das Original.

Keine Variable, sondern die ganze Tabelle. Mit bekommst du: Aber diese Tabelle ist eine Kopie. Und alles, was du hier in "FzListe" speicherst, landet in dieser Kopie und nicht in der ursprünglichen Tabelle. Zu deinen neuen Fragen muss ich erst einmal schauen, was da im Einzelnen passiert ...

Hallo BahnLand, die Argumente FzListe bzw. FzTabelle enthalten in den Ereignissen für die Kontakte 1 und 2 eine Kopie deiner Tabellen aus den Kontaktpunkten. Diese Kopie wird mit dem Inhalt der temporären Liste "namen" befüllt, aber nicht das Original. Damit versickert FzListe bzw. FzTabelle im Lua Code und wird an niemanden im MBS weitergereicht. Du erkennst das daran, dass das Ereignis "Objekt Variable wird gesetzt" nicht getriggert wird. Im Kontakt 3 übergibst du nur den Kontakt selbst als Argument und sprichst dann im Code direkt die Tabelle in diesem Objekt an. Damit erreichen die Daten das gewünschte Ziel. Viele Grüße Götz

Hallo Axel, du hast zwar schon viele Vorschläge zur Verbesserung bekommen, aber noch keine vollständige Antwort auf diese Frage. Du hast mehrere Ereignisse mit dem selben Auslöser "Ein Zug/Fahrzeug betritt Gleis/Straße Block 16" Wenn also ein Auto dieses Gleisstück betritt, dann werden alle Aktionslisten ausgeführt, die diesen Auslöser haben. Und weil die sowieso alle ausgeführt werden, kannst du auch sämtliche Befehle in ein einziges Ereignis schreiben statt sie auf mehrere zu verteilen. Das reduziert die Rechenlast. Das nur zum besseren Verständnis der Zusammenhänge. Lösungsvorschläge für deine konkrete Anwendung hast du ja schon Götz.

Hallo Martin, hinter deinen folgenden beiden Aussagen verbirgt sich ein grundsätzliches Missverständnis. Das würde ich gerne aufklären, weil das in sehr vielen Fällen zu falschen Denkansätzen führen kann. Außerdem ist dieses Missverständnis ein Klassiker und passiert vielen. Es ist nicht zu langsam, sondern im Gegenteil zu schnell. Nein, so ist es eben nicht. In deinem Beispiel mit der Lackdose führst du den dritten Schritt erst dann aus, wenn die zweite Aktion abgeschlossen ist. Aber in der EV passiert etwas anderes. Die EV gibt dem Zug nur den Befehl "Beschleunige" und führt dann sofort den nächsten Schritt aus. Sie wartet nicht ab, bis der Zug beschleunigt hat. Du würdest mit der EV keine Farbe auf die Wand kriegen, weil du gleich nach dem Befehl "Verstreich die Farbe" den Deckel wieder schließen würdest. Es bliebe nicht einmal die Zeit, den Pinsel in die Dose einzutauchen. Noch etwas präziser: Wenn der Maler den Befehl wahrgenommen hat, dann sieht er schon wieder eine geschlossene Dose. Ich hoffe, das hilft dir weiter Götz

kann niemand hier einbringen, weil sie gegen solche Maßnahmen geschützt sind. Einzige Ausnahme wäre der Konstrukteur des EEP-Modells selbst. Der hat die Konstruktionsdaten und könnte sie somit auch anderweitig einsetzen.

Da ich das Bild gerade fertig habe (und es vielleicht anderen hilft, Bedingungen besser zu verstehen) ...: Ich wüsste übrigens kein Ereignis, in dem deine Vorgehensweise funktionieren würde. Das Einzige, was eine wiederholte Prüfung der Bedingung zur Folge hätte, wäre das Ereignis "Timer ist abgelaufen". Und in solch einem Ereignis wäre deine Bedingung nie erfüllt.

Es gibt ein Ereignis, dass jedesmal, wenn es eintritt, deine Aktionsliste einmal triggert. In dem Augenblick, wenn ein Zug deinen Kontakt betritt, wird die zugeordnete Aktionsliste genau einmal abgearbeitet. Bedingungen in dieser Liste sind dann jeweils "entweder/oder" Entscheidungen. Aber der Ablauf nimmt nur einen Weg. Entweder diesen oder jenen. Wird der Kontakt erneut betreten, dann wird die Aktionsliste ein weiteres Mal abgespult. Das Bedingungen ein entweder/oder bedeuten ist keine Besonderheit der EV. Das findest du genau so in jeder Programmiersprache.

Nein, das ist nicht unlogisch. Jede Bedingung wird nur einmal geprüft. Bedingungen sind kein "Dauerbrenner", der bei jeder Änderung erneut reagiert. Du musst lernen, Bedingungen und Ereignisse zu unterscheiden.

In Anlehnung an den Text in der Titelsequenz: "... ein Modell zu bauen, dass nie ein Mensch zuvor gebraucht hat"

Das ist einfacher als dein Konstrukt

Die Bedingung "Timer läuft nicht" wird nicht ausgewertet, weil die Bedingung "Timer läuft" erfüllt ist. Das Ereignis wird insgesamt nur einmal ausgeführt, wenn der Kontakt betreten wird. Und bei diesem ersten Mal ist die Bedingung erfüllt. Schmeiß den Timer raus. Der ist die falsche Wahl. Nutz stattdessen mehrere Verzögerungen.

Variablen, die keine Objektreferenzen enthalten, werden alle mit kopiert: Wenn die Variable eine Objektreferenz enthält, dann gibt es die folgende nützliche Eigenschaft: Kopiert man Kontakt und referenziertes Objekt gemeinsam, dann steht im neuen Gleiskontakt eine Referenz zum neuen Signal. (Das gilt natürlich für alle denkbaren Objektkombinationen, nicht nur für Kontakte und Signale.) Kopiert man nur das Objekt mit der Referenz, aber nicht das referenzierte Objekt, dann ist dieses Ziel in der Kopie leer.

Ja, man kann die Software auch dafür nutzen. Aber man muss die Modelle ein zweites Mal bauen, weil sie komplett anders angelegt werden müssen.

Du hast recht. Es gibt zwar Brücken, die sich wie Fahrwege biegen lassen. Aber sie sind dennoch keine Fahrwege und der Gleiskontakt bekommt keinen Link zu solch einem Element.

Hallo Crassus, Sketchup ist einfacher zu erlernen, wenn 3D-Modelling per Software für dich neu ist. Blender ist ein mächtigeres Werkzeug und eröffnet dir mehr Möglichkeiten. Für den 3D-Druck nutzt dir das aber beides nichts. Ein 3D-Modell für grafische Darstellungen in einem PC-Programm ist vollkommen anders aufgebaut als ein Modell für den 3D-Druck. Beispiel: Ein virtuelles Haus hat Wände ohne Dicke. Für den 3D-Druck muss aber jede Wand Volumen haben und das Innere des Hauses ein Hohlraum sein. Du wirst also Modelle für den 3D-Druck noch einmal neu entwerfen und dabei ganz andere Faktoren berücksichtigen müssen.

Es müssen nicht unbedingt zwei identische Gleise sein. Denkbar sind auch Gleis und Tunnelröhre oder Gleis und Brücke. Zwei Elemente, die wie Gleise verlegt werden und deckungsgleich aufeinander liegen.

Du übersiehst eine Kleinigkeit. An einem Ort können zwei Gleise exakt aufeinander liegen. Trotzdem wird der Kontakt auch an solch einer Stelle nur einem der beiden Gleise zugeordnet. Bei einer Weiche ist der Ort beider Spuren zwar meist nicht identisch. Aber doch am Ansatz der Weiche so ähnlich, dass man die Situation wie "zwei Gleise am selben Ort" betrachten kann. Die Zuordnung ist hier allerdings einfacher, weil stets nur eine der beiden Spuren aktiv ist und somit der Gleiskontakt eindeutig zugeordnet werden kann.

Ein Gleiskontakt kann nur auf einem Geisstück sitzen. Denn er hat einen Link zu diesem Element. Und Links können nur ein Ziel haben. Gibt es an einer Stelle mehr als ein Gleisstück, dann muss ein Fahrzeug über das Gleis fahren, dem dieser Kontakt logisch zugeordnet ist.

Alternativ könntest du deinen Kreisverkehr in zwei Hälften oder - besser noch - vier Viertel unterteilen. Er besteht ja aus vier identischen Segmenten. Das brauchst du eigentlich nur einmal bauen und kannst dann vier davon zusammenstecken.