simonjackson1964

I have been considering doing exactly this. But I have yet to come up with a layout where it would come into its own.

I'm interested in knowing what others think on this subject. The virtual depots are a great idea as they save space and allow what seems to be an infinite number of vehicles - I loaded one with almost every variation of every road vehicle in the catalogue without blowing the limit. For road vehicles they are ideal and can send random cars and trucks out giving a nice feel to the road traffic without the need to loop vehicles around and turn them invisible and visible again... But for trains, for me there is something satisfying about seeing all the rolling stock lined up on parallel tracks, coding the event to randomly select a train, and see the points all change, see the signal clear and the train start to move... Using routes makes this a lot easier and takes away the headache of interlocking the points and signals. The down-side is the space required for the storage tracks, and the fact that you can only run a certain number of trains. But the thing about the virtual depots is that you still need a fiddle-yard. Placing the virtual depot on the end of the visible track means that the train appears and disappears quite suddenly and unrealistically. I've found the best thing is to put a length of track long enough to take my longest train on a level below the baseboard and link it to the end of the visible track with virtual portals (wonderful things!), with a carriage length of the visible track hidden under a bridge or something. And of course, adding a new train to the layout means a length of empty track is needed to construct the train on, and a contact/event to send it to the depot when it's ready. As much as I love the virtual depots, I think there will always be a place in my heart for the fiddle-yard. ============================================================ Mich interessiert, was andere zu diesem Thema denken. Die virtuellen Depots sind eine großartige Idee, da sie Platz sparen und scheinbar unendlich viele Fahrzeuge zulassen – ich habe eines mit fast jeder Variante jedes Straßenfahrzeugs im Katalog beladen, ohne das Limit zu sprengen. Für Straßenfahrzeuge sind sie ideal und können beliebige Autos und Lastwagen losschicken, um dem Straßenverkehr ein schönes Gefühl zu verleihen, ohne dass Fahrzeuge umrundet und unsichtbar und wieder sichtbar gemacht werden müssen ... Aber für Züge ist es für mich etwas Befriedigendes, das gesamte rollende Material auf parallelen Gleisen aufgereiht zu sehen, das Ereignis so zu programmieren, dass ein Zug nach dem Zufallsprinzip ausgewählt wird, und zu sehen, wie sich alle Weichen ändern, das Signal frei wird und der Zug sich in Bewegung setzt. Die Verwendung von Routen erleichtert dies erheblich und erspart Ihnen die Mühe, die Weichen und Signale zu verknüpfen. Der Nachteil ist der Platzbedarf für die Lagergleise und die Tatsache, dass man nur eine bestimmte Anzahl von Zügen fahren kann. Aber die Sache mit den virtuellen Depots ist, dass man immer noch einen Schattenplatz braucht. Durch die Platzierung des virtuellen Depots am Ende des sichtbaren Gleises erscheint und verschwindet der Zug ganz plötzlich und unrealistisch. Ich habe herausgefunden, dass es am besten ist, ein Gleisstück zu platzieren, das lang genug ist, um meinen längsten Zug auf eine Ebene unter der Fußleiste zu bringen, und ihn mit virtuellen Portalen (wunderbare Dinge!) mit dem Ende des sichtbaren Gleises zu verbinden, und zwar mit einer Wagenlänge der sichtbaren Spur, die unter einer Brücke oder so etwas versteckt ist. Und natürlich bedeutet das Hinzufügen eines neuen Zuges zur Anlage, dass ein Stück leeres Gleis benötigt wird, um den Zug aufzubauen, und ein Kontakt/Ereignis erforderlich ist, um ihn zum Depot zu schicken, wenn er fertig ist. So sehr ich die virtuellen Depots auch liebe, ich denke, dass der Schattenplatz immer einen Platz in meinem Herzen haben wird.

.... Was about to say, "What if I don't have a 'Strg-key'?" ... My computer says "Press any key to continue", but I can't find the "Any" key...! (Very old IT joke!)

Hi Ern I have to agree with you... Containers sat sideways on flat-bed wagons, massive gaps between ground and track or the track disappearing underground, bridges that are too low, tunnels that are too tight.... But then not everyone is a perfectionist like me. I think I've only published one of my layouts (at V5 or 6, I don't remember exactly which) and even then I was forced to state that there is no road traffic - because road vehicles were simply not working for me...! I think the thing to remember here is that this is something we do for fun! If it ceases to be that, and becomes a chore, why do it? If, like me, you get a kick out of getting everything just so, then that is part of the fun, but for me that means I'm hardly ever going to publish anything. For other people the pleasure lies in showing off what they've built, and so they publish stuff that might be unfinished or has errors they haven't spotted... I think that if we were talking about the real world, I would be extremely concerned about the quality of the engineering in some of the railways. If we were talking about physical model railways, I would probably be concerned that some of the models would not physically work. But this is a virtual world with it's own "laws of physics", where a train can pass straight through a road vehicle on a level crossing without killing several hundred people, and two trains can pass through a diamond crossing in opposite directions at the same time without a massive explosion... (although there is a simple fix for that one). I think my advice here would be not to get too hung up on the details in other people's layouts. Take inspiration from them, fix the issues if you like, but accept that different people have different standards. It's not like the layout is hurting anyone by being incomplete. Cheers Simon

Hi Herman. I tried to build a layout that unloaded trucks at one end and loaded them at the other, and had two trains that passed in a loop in the middle, and when a train arrived the truck loading/ unloading halted while the train was loaded/unloaded. Stacking the containers was the thing that never worked properly, and sometimes a container would get put inside another, or the container floor would get lifted. Plus, the swich-over routine didn't always work properly. I think my biggest point of confusion though was determining if a crane was loaded or unloaded, as the boolean always seemed to have the wrong value!

I've only had it happen once...!

I just had this exact same error... Having worked in IT debugging code, I know hat as much info as possible is always useful. In my case the vehicle camera was riding with an Uerdinger railbus driving trailer at the rear of a train (8EAE538A-BC34-41F6-A7B8-F22657F063EF), and was turned to look backwards through the cab windows. I doubt if that last bit is significant, I suspect the error occurs when a cab camera is active on a non motorised vehicle? Anyway, you already know about it, this is just corroborative evidence, if you like...

594B3EC2-7A0F-4549-B947-186D6897860D Hee hee!

Absolutely, thanks. As already noted UK semaphore signals are totally different. In fact it's only the KS multiblock signals that are even remotely similar to UK signalling. It has been bothering me whether the actual practice is correctly emulated by the model - obviously the signals would not change simultaneously on a manual signal box (they may well do on an electronic one!) because the signalman can't physically pull two levers at once - especially if one of them is a 1000m long wire, that's a heck of a weight! But to have them change at the same on the model is definitely easier than trying to build in a 2-second delay. (It would be possible, but again, not worth the effort!) Once again, @Goetz your insight has been invaluable. Thank you.

Sorry for the cryptic title but I'm having a bit of a dilemma. Prior to the advent of routes, I would always control my advance signals by connecting them to the main signal they were giving advance warning of. I'm sure most people did the same as it means the advance signal always shows the same aspect as the main signal and saves a lot of extra coding. But with routes, it becomes possible to have the advance signal work independently, so that it changes to Vr0 "Expect stop" as the train passes. with no effort at all, and I'm pretty sure that in a manual signal box this would be the case - the signalman would not leave the signal at Vr1 "expect proceed" until the train was out of the block, just in case it got forgotten, surely? Especially as the block exit signal would be a kilometre further down the line and might even be under the control of a different signal box... The issue of course is that by using the route to control the signal, it no longer shows the same aspect as the main signal all the time. Not really a problem if it shows "expect stop" when the exit signal shows "expect proceed" as long as the train has passed the advance signal. But the block exit signal would most likely be the block entry signal for the next block, and thus the start of the next route, and so it won't change until that route is activated. But you can't have both. If the signal is connected to the main signal then changes go both ways and if the advance signal changes to Vr0 as the train passes, the main signal will also change, preventing the train from exiting the route. Frankly, the easiest think to do is to keep using the connection and set the advance signals to "Do Nothing" on the route controls. But I was wondering whether to disconnect and reconnect the advance signal so it shows what seems to me to be a more realistic aspect without interfering with the main signal - NB This would probably not use the route to set it but a simple "Track Contact is activated on leaving" event on the advance signal to disconnect it and change to Vr0, then a "signal is changed" event on the main signal to reconnect when the signal goes to Hp0. Pretty sure I could make it work, but I'm wondering if it would be worth the effort? What do people think? (translation courtesy of Firefox) Entschuldigung für den kryptischen Titel, aber ich stecke in einem kleinen Dilemma. Bevor es Routen gab, kontrollierte ich meine Vorsignale immer, indem ich sie mit dem Hauptsignal verband, vor dem sie Vorwarnung gaben. Ich bin mir sicher, dass die meisten Leute das Gleiche getan haben, denn das bedeutet, dass das Vorsignal immer das gleiche Aspekt wie das Hauptsignal zeigt und eine Menge zusätzlicher Codierung eingespart wird. Bei Strecken ist es jedoch möglich, das Vorsignal unabhängig arbeiten zu lassen, sodass es beim Vorbeifahren des Zuges auf Vr0 „Halt erwarten“ wechselt. und ich bin mir ziemlich sicher, dass dies bei einem manuellen Stellwerk der Fall wäre – der Stellwerkswärter würde das Signal für alle Fälle nicht auf Vr1 „Fahrt erwarten“ belassen, bis der Zug den Block verlassen hat wurde doch sicher vergessen? Zumal das Blockausgangssignal einen Kilometer weiter unten auf der Strecke wäre und möglicherweise sogar von einem anderen Stellwerk gesteuert würde ... Das Problem besteht natürlich darin, dass durch die Verwendung der Trasse zur Steuerung des Signals dieses nicht mehr immer das gleiche Aussehen wie das Hauptsignal aufweist. Es ist kein wirkliches Problem, wenn „Halt erwarten“ angezeigt wird, während das Ausfahrsignal „Fahrt erwarten“ zeigt, solange der Zug das Vorsignal passiert hat. Aber das Blockausgangssignal wäre höchstwahrscheinlich das Blockeingangssignal für den nächsten Block und damit der Beginn der nächsten Route und wird sich daher nicht ändern, bis diese Route aktiviert wird. Aber man kann nicht beides haben. Wenn das Signal mit dem Hauptsignal verbunden ist, erfolgt der Wechsel in beide Richtungen. Wenn das Vorsignal beim Vorbeifahren des Zuges auf Vr0 wechselt, ändert sich auch das Hauptsignal, wodurch verhindert wird, dass der Zug die Strecke verlässt. Ehrlich gesagt ist es am einfachsten, die Verbindung weiter zu nutzen und die Vorsignale an der Streckensteuerung auf „Nichts tun“ zu stellen. Aber ich habe mich gefragt, ob ich das Vorsignal trennen und wieder anschließen sollte, damit es einen meiner Meinung nach realistischeren Aspekt zeigt, ohne das Hauptsignal zu beeinträchtigen – NB: Dies würde wahrscheinlich nicht die Route zum Einstellen verwenden, sondern einen einfachen „Gleiskontakt“. „Aktiviert beim Verlassen“-Ereignis am Vorsignal, um es zu trennen und auf Vr0 zu wechseln, dann ein „Signal wird geändert“-Ereignis am Hauptsignal, um die Verbindung wiederherzustellen, wenn das Signal auf Hp0 wechselt. Ich bin mir ziemlich sicher, dass ich es zum Laufen bringen könnte, aber ich frage mich, ob sich der Aufwand lohnen würde? Was denken die Leute? (Übersetzung mit freundlicher Genehmigung von Google)

So there's no interlock between the two then? I see.... And now I have a weird image in my head of Gandalf as a pointy hatted signal saying "YOU SHALL NOT PASS!" to a smoke and steam belching locomotive Balrog... Incidentally, Gandalf would make a terrible driving instructor!

Supplementary question: If the shunt signal goes to SH1 the main signal stays ah HP0, but if the main signal goes to HP1, are you saying that the shunt signal has to change as well? From what i remember that certainly isn't UK practice with Semaphore signals on preserved lines where they are still in use. Of course German practice could well be different, but the interlocking would mean that the shunt signal would need to be pulled first which could potentially confuse a driver who might set off down the line before the min signal is pulled without the token and then stop at the shunt limit. It makes more sense that if either signal is cleared the other can be ignored...?

Ich kenne die Tutorials nicht, aber ich habe festgestellt, dass die Verwendung von Routen mit einer 1: 1-Korrelation zwischen Route und Block mit Blocksignalen am Anfang jeder Route eine realistische Steuerung ergibt. Die Fahrstraßen steuern auch automatisch die Weichen, und das Stellwerk ist ebenfalls automatisch, mit Ausnahme von Kreuzungen, bei denen Weicheneinstellungen hinzugefügt werden müssen. Ich hoffe das hilft? I'm not familiar with the tutorials, but I've found that using routes with a 1:1 correlation between route and block with block signals at the beginning of each route gives realistic control. The routes also automatically control the switches and the interlocking is also automatic, except for crossings where switch settings need to be added. I hope it helps?

Sorry I thought Mr Clay was trying to pass a keyword out of a user defined event. I miss-read. My apologies! While Goetz's solution is definitely more efficient, if you already have a number of keywords set on a number of vehicles and it would be a lot of trouble to change them, you could feasibly use a nested (or repeated) condition to check for the existence of each keyword in turn and set a variable to the name of the keyword before passing it down...! The choice between nested or repeated would depend upon whether a given vehicle could have more than one of the keywords being tested for, and if it has more than one which should take precedence.

I think actually there is a way to do this. First, let me check what you are actually trying to achieve: You have a user defined event that presumably is called when a vehicle hits a track contact, and you want to set a condition based upon a keyword on that vehicle? In fact @Goetz is not entirely correct. A keyword is either present or absent. This is a binary condition, 1 or 0, that equates exactly to a boolean variable. I frequently use the "Property/Variable Exists" condition to check for the existence of a keyword on an object, and as with all conditions this returns a boolean result, true or false. What I think you need to do is create a Module boolean variable. Then within your UDE, you set that variable to true (1) or false (0) depending on the condition "If Variable "keyword" exists." Be warned though: This will only work correctly if it is only possible for it to happen once at a time. If you have the UDE called whenever a vehicle hits one particular track contact, it should be fine. If it is called when a vehicle hits a track contact with keyword, you may get unpredictable results. I that case it might be better to put the boolean variable on the track contact and pass the Object ID of the contact to the ODE as a parameter. The effect should be pretty much the same.

Some of the time it doesn't matter if something is at 0° or at 180°, at 90° or at -90°. The tracks themselves, for example. The catenary doesn't matter until you want to run two wires side by side, end a wire, or enter a tunnel. Then it does. Freight wagons, again, not normally an issue, unless you want to line the oil tanks up with the oil loading terminal, or you want to split a train in the middle - you need to know which coupler to disable! Passenger cars with animated doors, it matters! And of course anything defined as having an engine has a front and a back.

There are two solutions to this that I can see.. A simple one and a complex one. Simple solution: Manually check the orientation of the cargo pads attached to the wagons (ot the wagons themselves if you aren't using cargo pads on them) and make sure they are all pointing the same way as the cargo pads on the trucks when they pull alongside. This solution will only work if you have a loco run-around at both ends of the layout or you use a return loop at one end and either a return loop or a virtual depot with the train reversed on release at the other (unless you are happy to have the train pushed in rather than pulled...) Complex solution: use Lua to set the wagon or cargo pad to the correct orientation as the train stops.

I've noticed this behaviour too, I think that the best way to avoid it is to rotate the logs (or other cargo) yourself by 180° manually, before the crane picks it up. (And save the layout with that change made!) I have just checked, and this works. Make sure that the logs have the same z rotation as the container floor (or other target) they are being lowered onto, before they are picked up.

I'm not sure if this would work, as I've not tried it but there might be a way to store the name of the keyword on the triggering point/turnout and then reference it in the iteration meaning you only need one event. To be honest a lot of building a working layout in MBS is about deciding whether you want to do a lot of fiddling about with variables and keywords, and have a simple and streamlined event module, or whether you want to save time and effort at the build stage and put that time and effort into a more complex and repetitive collection of events. There is no correct or wrong answer, and it's really just personal preference. Personally I go for streamlining the EV as it always seems wasteful to me to have a whole load of events that are doing the same job. But to have one event for each occurrence of the "event" might make sense in a given scenario...

Is there a reason you're using road traffic lights rather than railway signals? The railway signals have a track contact built in (from version 6 onwards) and from V7 on the route system basically handles the signalling and interlocking for you. I have to say, it's almost certainly something in your code that is causing the contact properties to change.

@hmclay Just reading this, and I have a feeling it might solve your problem of positioning things at different heights: The text was automatically translated from German by Firefox so the word choices are a bit off, but the message is that if you create a layer with a height limit equal to the height of the platform and set it as the default, all objects you add to the layer will go at that height.

Train routes are the flip side of road targets, You create your routes in advance by assigning a start and end way-point. A good rule of thumb is parity between routes and signalling blocks - As train signals have a track contact on them they can be used as waypoints, as can anything else with a track contact. When you select the route (either manually or using an event), it automatically sets all the points and signals. If there is a conflict with another train movement the routes automatically interlock to prevent a collision. (With one exception - diamond crossings need to have a switch added to them to prevent trains crossing from both directions at once!) This is seriously good as it means you no longer have to do all the signal and point interlocking in the EV.

What Goetz said. Basically when a contact is triggered you assign the triggering vehicle a new target contact. You can also use the same event to control the vehicle's indicators if you feel flashy. (Pun intended!)

If a KS multi-section signal is showing KS2, and there is an approach signal and/or a distant repeater signal in advance of the multi-section signal, what should those two be showing? My thought is that the next main signal, the multi-section, is showing "Proceed, expect stop", therefore the approach signal should be showing "Expect Proceed" - KS1. and so should the repeater. The multi-section signal's "Expect stop" applies to the main signal after this one, which will be HP0. Wenn ein KS-Multi-Section-Signal KS2 anzeigt und es ein Annäherungssignal und/oder ein entferntes Repeater-Signal vor dem Multi-Section-Signal gibt, was sollten diese beiden zeigen? Mein Gedanke ist, dass das nächste Hauptsignal, der Mehrfachabschnitt, "Fortfahren, Halt erwarten" anzeigt, daher sollte das Anflugsignal "Fortfahren erwarten" - KS1 anzeigen. und so sollte der Repeater. Das Signal "Erwarteter Halt" des Mehrabschnittssignals gilt für das Hauptsignal nach diesem Signal, das HP0 sein wird.

I am assuming that you are using V7 or V8? In either case I would suggest, rather than using an Event to change the switch in the road, use vehicle targetting. It's much more efficient and doesn't change the route too early. That said there are some vehicles that the auto acceleration and auto deceleration doesn't seem to work properly on...