Timba

Moin Matt, Soweit ich das aus deinem Screenshot erkennen kann, ist deine Platte 200 m x 110 m. Darüber hinaus habe ich eben meine alte V5-Version nochmal gestartet, das ist die, mit der du gerade arbeitest, und habe festgestellt, dass auch die Gleise in Spur H0 aus dem Katalog korrekt umgerechnet und angezeigt werden. Ein Märklin C-Gleis in der Länge 171,7 mm wird mit ~14,9 m dargestellt. Es liegt kein Fehler vor. Ich kann dein Problem nicht nachvollziehen. Wenn du bis an den Rand bauen willst, füge einfach mehr Gleise an. Gruß Timba

Oh, ich bitte um Verzeihung, dass ich mich ohne Expertenwissen in diese Simulation eingemischt habe. Ich werde künftig meine unqualifizierten Fragen in einem Kaninchenforum stellen.

Moin, beim Ks Vorsignal (Content-ID 15EC520B-E45D-4DE2-8E5B-DD481408A0EB) vermisse ich bei den Variationen die Option "für Mastmontage". Beim H/V Vorsignal (Content-ID 3743D15B-FA43-4BCD-BCEB-4418C40169E1) oder beim H/V Blockvorsignal (Content-ID 55DFBEBA-4FF1-4CA9-B8A8-D58427607B0D) gibt es diese. Ist diese Möglichkeit beim Typ Ks absichtlich nicht vorgesehen? @Roter Brummer Gruß Timba

Ja, das ist wohl so. Aber was ungeordnet ist, kann man versuchen zu ordnen. Solange es noch keine Weiterentwicklung der Fahrstraßen gibt, damit meine ich, solange das Studio hier nicht ordnend eingreift, muss der Nutzer halt selbst durch entsprechende EV-Programmierung für eine von ihm gewünschte Ordnung sorgen. Du sagtest es ja selbst: Letztendlich ist das ja sogar Teil des Spaßes. Wie langweilig wäre es, wenn man nichts mehr selbst austüfteln dürfte. Wünsche den Frieden der Nacht. Timba

Ja richtig, übrigens ein anschauliches Beispiel, dass FIFO auch nicht unbedingt das Gelbe vom Ei ist. Bis gerade hatte ich das noch favorisiert. Davon abgesehen hat Neo selbst es aber kürzlich so erklärt, dass bei mehreren konkurrierenden und auch aktivierbaren Anforderungen nach dem Zufallsprinzip ausgewählt wird, welche zuerst Berücksichtigung findet. Und das ist irgendwie noch weniger Gelbes vom Ei. Ob das in der Praxis Relevanz hat, sei dahingestellt. Es ist eher unwahrscheinlich, dass es so oft vorkommt, dass so viele Züge zur gleichen Zeit eine bestimmte Stelle passieren müssen, dass einer davon überhaupt nicht vom Fleck kommt.

Gelesen. Ok, aber muss denn nicht auch beim Selbstblockverfahren bei Verzweigungen die Signale auf Halt stehen und eine Freigabe angefordert werden? Irgendwo habe ich mal was darüber gelesen, wenn ich nicht ganz schief liege, sogar von dir.

Das verstehe ich grad nicht, aber muss ich ja auch nicht.

Klar funktioniert die. Ich forderte auch in der Blockstrecke die Aktivierung jeder Fahrstraße an. Das mag vielleicht nicht exakt den Regeln der Deutschen Bahn entsprechen, aber funktionieren tut es. Etwa zu zwei Dritteln enden/beginnen meine Blöcke in Abzweigungen, die anders als Blöcke behandelt werden müssen. Den übrigen Blöcken habe ich dann halt auch noch einen Gleiskontakt spendiert. Allerdings, bei dem Konflikt, den du geschildert hast, wo eine Nebenstrecke auf eine Hauptstrecke mündet, da ist auch bei dir keine normale Blockbehandlung mehr richtig, so weit ich weiß.

Sorry, gerade fehlt mir die Zeit dazu. Im Moment mache ich mehrere Dinge gleichzeitig und gucke nur mit einem Auge aufs Forum. Was du schreibst hört sich allerdings für mich nach einem anderen Problem an, das mich ebenfalls etwas stört. Das ist, dass mehrere gleichzeitig angeforderte Fahrstraßen nicht in der Reihenfolge ihrer Anforderung abgearbeitet werden, sondern irgendwie nach dem Zufallsprinzip. Ich hatte mir diese Woche auch einen Test mit vier Loks gebastelt, die stets überlappende Fahrstraßen anforderten, und ganz oft standen zwei Loks ewig vorm Signal rum, während die anderen eine Runde nach der anderen drehten. Das ist tatsächlich unschön und ich hoffe, dass da noch eine Änderung folgt. Als Lerneffekt aus meinem Test habe ich bei meiner Anlage bei der Bahnhofseinfahrt eine Routine programmiert, die zuvor testet, welches Bahnhofsgleis zur Verfügung steht und erst dann die entsprechende Fahrstraße anfordert. Wenn keine zur Verfügung steht, ruft die Routine sich solange selbst auf, bis eine gefunden wurde. Auf diese Weise kann der Zug in das Gleis einfahren, das zuerst frei wird. Ohne diese Routine würde der Zug irgendeine Fahrstraße wählen und ist die einmal gewählt, muss er warten bis die frei wird, obwohl andere längst frei sind.

Das ist aber ein gefährlicher Kram. Auf der Hauptstrecke könnte ein Zug Bruchteile von Sekunden vor der Einfahrt in die Fahrstraße der Hauptstrecke sein, dann ist die Fahrstraße der Hauptstrecke zwar noch nicht belegt, aber du bekommst den Zug auch nicht mehr zum stehen, wenn du ihm direkt vor der Nase das Signal auf Stop knallst. Eine Fahrstrecke, die freigegeben ist, sollte man besser nicht mehr deaktivieren. Das führt meist zu Schrott, wenn auch in diesem Fall nur virtueller Schrott. Gruß Timba Nachtrag: Dass die Fahrstraße der Hauptstrecke aktiviert wurde ist ja eigentlich bereits ein Beweis, dass ein Zug herannaht, sonst wäre sie ja nicht aktiviert. Also ich finde deine Idee äußerst fragwürdig.

Hallo Wolfgang, Wenn ich für mich dieses Problem zu lösen hätte würde ich folgendermaßen vorgehen. Irgendwann muss Zs3 ja geschaltet werden und die bei Freigabe zulässige Geschwindigkeit anzeigen, sonst macht das alles ja keinen Sinn. Dieses Ereignis (Zs3 schaltet) würde ich als Auslöser nehmen und den von Zs3 angezeigten Wert in das betreffende Hauptsignal als "Beschleunigung bei Stellung 'Fahrt'" eintragen. Dazu ist wichtig, dass während des Eintragens das Signal auf 'Fahrt' steht, sonst funktioniert das nicht. Also eine Befehlsfolge Signal Fahrt / Beschleunigungswert eintragen / Signal zurück auf Halt. Hab's nicht ausprobiert, sollte aber kein Problem darstellen, das geht so rasend schnell, dass man es nicht sieht und so weit ich die Funktion vom MBS verstanden habe, wird ein vor dem Signal stehender Zug auch nicht in Gang gesetzt. Wichtig ist nur, dass die Befehle direkt hintereinander stehen und alle im selben Ereignis, damit keine andere Aktion dazwischenfunken kann. Wenn dann das Hauptsignal auf Fahrt schaltet, wird die gewünschte Geschwindigkeit gefahren. Wie gesagt, ausprobiert habe ich das noch nicht, aber ich glaube, das müsste so gehen. Gruß Timba

Moin, Das kann man schon. Nur müssen die Wegpunkte einmal neu definiert werden, damit das Programm die Strecke findet. Alles andere bleibt dabei erhalten, also Bezeichnung, Kategorie, etc. Ein großer Aufwand ist es jedenfalls nicht. Gruß Timba

Hm ... aber nur, wenn ein remove-Befehl vorangeht. Ich habe nun den Zug einige Runden drehen lassen und dabei das Protokoll beobachtet, es funktioniert zuverlässig, wenn erst insert und dann remove kommt. Für die Funktion ist die Reihenfolge ja egal. Warum es funktioniert, weiß ich nicht, so wie ich Neo verstanden habe, kann das eigentlich nicht funktionieren, tut es aber. Keine Ahnung. Egal, was funktioniert, darüber meckere ich nicht. Gruß Timba

Genau so ist es! Im Protokoll findest du in schicker grüner Schrift die Ausgabe des Print-Befehls. Die einzige Möglichkeit, Funktionen innerhalb eines Lua-Scripts zu überprüfen. So weit es das MBS betrifft, meine ich.

@Goetz So, jetzt habe ich das Problem eingegrenzt. Wenn ich die Zeilen vertausche table.insert(vehicle.variables["Fahrplan"],satz) table.remove(vehicle.variables["Fahrplan"],1) also zuerst insert und danach remove, dann funktioniert es. Aber das ist doch totaler Quatsch, oder? Bin gespannt, wie @Neo das erklären kann. Widerspricht jeglicher Logik.

Ich hatte zwischenzeitlich eigene Versuche angestellt. Mit einem Schalter starte ich ein benutzerdefiniertes Ereignis mit dem Skript satz = $("BR 103").variables["Fahrplan"][1] print(satz.Dauer,satz.Ziel,satz.Halt) table.insert($("BR 103").variables["Fahrplan"],satz) Im Prinzip dasselbe wie oben, nur nicht mit Auslöser, sondern das Objekt wird explizit bezeichnet. Das funktioniert tadellos. Liegt's daran, dass "Auslöser" (vehicle) in Lua nicht mehr verstanden wird? Gruß Timba

@Goetz, irgendwas ist noch falsch. satz = vehicle.variables["Fahrplan"][1] print(satz.Dauer,satz.Ziel,satz.Halt) table.remove(vehicle.variables["Fahrplan"],1) table.insert(vehicle.variables["Fahrplan"],satz) Der Datensatz wird korrekt in die Hilfsvariable eingelesen (mittels "print" überprüft). Der erste Datensatz wird korrekt gelöscht. Aber der zwischengespeicherte Datensatz wird nicht angefügt. Warum nicht? Ist doch alles richtig ... oder?

Nochmal danke.

@Goetz, super, vielen Dank. Das hilft mir schon sehr weiter. Ich würde nur noch gerne die Datensätze rotieren lassen, also bei jedem Durchlauf den jeweils ersten Satz ans Ende stellen und dann immer nur auf den jeweils ersten Satz zugreifen. Allerdings könnte ich auch einen Zähler mitlaufen lassen und dessen Inhalt als Index nehmen. Rotieren der Datensätze wäre aber eleganter, finde ich. Geht das mit der grafischen EV überhaupt? Wenn ich mich recht entsinne hatte ich das mit Lua mal über eine Zwischenvariable realisiert, aber ist schon ne Weile her. Weiß gar nicht, ob die Dateien noch auf meinem Rechner sind. Gruß Timba

Moin, irgendwie bin ich aus der Übung und brauche mal etwas Nachhilfe. Problem: Eine Objektvariable beinhaltet eine Tabelle. Darin sind zwei oder mehr Sätze, die jeweils aus zwei Zahlen und einem Booleschen Wert besteht. Wie werte ich die Einträge mittels grafischer EV aus? Mit Lua habe ich das vor zwei Jahren mal gemacht, aber mit grafischer EV muss das doch auch irgendwie gehen. Dann soll noch der erste Satz ans Ende gestellt werden. Gruß Timba

Ups ... ist das peinlich. Hatte ich nicht gesehen. Na dann, nächste Lokalrunde auf mich und wir vergessen das Ganze.

Moin, jetzt muss ich mal rumnörgeln. Also alle Harmoniesüchtigen weghören und Augen zuhalten. Gerade richte ich Fahrstraßen ein und bei jeder neuen Fahrstraße, also sobald ich auf das Pluszeichen klicke, kommt dieser Text: Fahrstraße fertig - Text weg - nächste Fahrstraße - Text wieder da - fertig - weg - neu - wieder da ... usw. Ich hab's jetzt kapiert, wie das geht. Warum muss der Text mir auch noch den Gleiskontakt oder das Signal verdecken, das ich gerade auswählen will? Ja, ich weiß, ich kann die Anlage verschieben, um an das Element dranzukommen, und ja, ich weiß auch, dass ich den Text wegklicken kann, aber warum ist der überhaupt erst da? Natürlich ist er hilfreich für Neulinge. Mir selbst hat es auch geholfen, nachdem ich das Update auf V7 durchgeführt habe. Aber sobald man kapiert hat, wie etwas geht, ist das überflüssig! Und nicht bloß überflüssig, sondern es stört regelrecht. Mich wenigstens. Beim Geländebau dasselbe. Da taucht auch so ein ähnlicher Text auf, den ich inzwischen auswendig aufsagen kann, zur Not auch noch bei drei Promille. Hilfe ist ja schön und gut und nützlich, aber nur solange sie gebraucht wird. Wer sich ein Bein gebrochen hat, schmeißt die Krücken doch auch wieder weg, sobald er wieder ohne sie laufen kann. Ich wünsche mir einen Schalter, mit dem man "Hilfe an / Hilfe aus" wählen kann. Von mir aus standardmäßig auf "Hilfe an", um Neulingen den Einstieg zu erleichtern. Ist ja ne gute Sache. Aber wenn man das MBS im Schlaf beherrscht, ist der Text einfach nur noch nervig. Vielen Dank, dass ich meinem Ärger hier Luft machen durfte. Und allen einen schönen Feiertag. Gruß Timba

Nimm die Lineale aus dem Katalog, die für H0 bestimmt sind, und trage bei "Skalierung" (unten rechts im Eigenschaftsfenster) den Faktor 1,379 ein. Dann hast du ein Lineal passend für TT. Gruß Timba

Gerade wollte ich sie per PN schicken, aber Dateianhänge in PN sind offenbar disabled worden. Veröffentlichen möchte ich sie momentan nicht, falls überhaupt. Gruß Timba

Moin, diesen Hinweis vom 8. Oktober hatte ich noch im Hinterkopf, als ich mich vorhin abmühte, das Gelände an gewisse Bauten anzugleichen und es nicht so klappte, wie ich das gerne hätte. So änderte ich kurzerhand die Rastergröße von 4 cm auf 1 cm, habe aber sicherheitshalber vorher abgespeichert. Die FPS-Rate sackte von 60 auf 17 ab. Zugegeben, es handelt sich um eine recht große Platte, aber trotzdem, "keinen so starken Einfluss auf die Performance" ist aus meiner Sicht etwas übertrieben. Gruß Timba