simonjackson1964

I have learned that SH0 overrides HP1 or HP2, and that SH1 overrides HP0. This for semaphore signals presumably also applies to the Type 69 light signals? (But not the KS signals that work on a different system). My question is twofold: First, is HP00 (two red lights) the equivalent of SH0 - where the type 69 Lock Signals also show two horizontal red lights, and the Man 69 blocking signal will show SH1 with two diagonal white lights and a single red light. Second, I read somewhere that SH1 permits a train to drive "until the end of the shunting movement". Does this mean that a single SH1 will override all following HP0 signals? But will presumably end at the next SH0 or HP00? (Our system here in the UK is a lot simpler!) Ich habe gelernt, dass SH0 Vorrang vor HP1 oder HP2 hat, und dass SH1 Vorrang vor HP0 hat. Dies gilt für Semaphor-Signale und vermutlich auch für Lichtsignale des Typs 69? (Aber nicht für KS-Signale, die nach einem anderen System arbeiten). Meine Frage ist eine doppelte: Erstens, ist HP00 (zwei rote Lichter) das Äquivalent zu SH0 - wobei Typ 69-Sperrsignale ebenfalls zwei waagerechte rote Lichter zeigen, und das Haupttyp 69-Sperrsignal zeigt SH1 mit zwei diagonalen weißen Lichtern und einem einzelnen roten Licht. Zweitens habe ich irgendwo gelesen, dass SH1 einem Zug erlaubt, "bis zum Ende der Rangierbewegung" zu fahren. Bedeutet das, dass ein einzelnes SH1 alle nachfolgenden HP0-Signale außer Kraft setzt? Endet die Bewegung dann aber vermutlich am nächsten SH0 oder HP00? (Unser System hier in Großbritannien ist viel einfacher!)

I've noticed that most containers are loaded onto wagons from above, dry powder goods are also usually dropped into the top of the hopper. Liquids, likewise are often poured into the tanker from the top. This causes a problem for electric trains that take power via a pantograph from overhead cables, obviously. And equally obviously the solution is to either use a diesel shunting loco to move the freight consist, or to reverse the train into the loading area so that the loco stays on the catenary, but the wagons are out from under it. Hhowever, I was doing some research and came across this article in "Railengineer" https://www.railengineer.co.uk/electrification-of-freight-terminals/ It looks like a cleaver idea and it would be interesting to have something similar on MBS.

Never mind, I have found a work-around.

851A9ACC-644E-43F0-8C5D-C6BA59E1D7A5 - draft upload. Please will the usual folks who are good at this stuff have a look at the code and the variables and see if you can figure it out? Many thanks Simon

By the way, I have also tried it this way: And this way: With the exact same result!

On the same subject, I have a row of seven stacks of three pallets. The virtual track the stacks are lined up on (so a fork-lift can place them) has the following variables: I am trying to do the very first step in moving the pallets from the stacks to a railway wagon, setting the two indexes to the values to select the first pallet as the target for a crane. Values 1 and 3 respectively. But no matter which way I try and code the event, I always get this message: I've tried it every way I can think of, I know I've done this before, but I can't get it to set the sub-index. Please can someone have a quick look at the above code and tell me what I've done wrong? I cannot see it to save my life, but I know it' something so obvious I'll kick myself!

@Klartexter Thank you for that, I may just use that in future. @Roter Brummer <Facepalm> For some reason I thought those were fork extensions... I mean the workshop equipment tab has everything else you could possibly imagine, so it's an understandable error! Thanks <Facepalm> Aus irgendeinem Grund dachte ich, das wären Gabelverlängerungen... Ich meine, die Registerkarte Werkstattausrüstung hat alles, was man sich vorstellen kann, also ist es ein verständlicher Fehler! Danke

It seems that the only way to move pallets around with any degree of realism is to construct an artificial floor out of empty pallets, in any location that you want to stack them. This includes the wagons you want to load them in, unless you want to have them standing on the roof or floating mysteriously above the wagon bed. This is pretty much the same for containers, except with containers there are pre-made container floors in different sizes that even have the option of being invisible built in, just leaving the corner markers visible. This means that the container floor can be placed carefully on a flatbed wagon, linked and grouped and left with just the marks showing, and then the wagon group copied as many times as needed. And of course a nice big container storage area ca be constructed by laying the floors contiguously on the baseboard. It would be nice to have something similar for pallets. I realise that having something the size of a container floor that could hold (say) 21 pallets and have a built in array to control where the next pallet went would be asking a lot, but a Europallet sized version of the container floor would be a start? (By the way I tried to translate this to German but Google was playing silly-buggers so I gave up!) A wagon ready to be stacked with pallets.

I've given this a try, and I honestly cannot figure out what the values held in (Object).transformation.rotation represent... They are not consistent - it's as if the values are stored as text but held as real numbers (or vice versa), so when you retrieve the value you only get part of it. Try setting X, Y and Z rotations to 0, 90 and 180, and print the three different values, then change them to 90, 180 and 0 respectively and do it again. The values are totally inconsistent. Especially odd is the one that should be zero is in fact not zero!

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.