Page 1 of 1
| Train entry problem 09/04/2018 at 15:06 #107427 | |
postal
5197 posts |
I've got a problem which I can't find a way to solve. Any help/advice would be more than appreciated. I am working on a TT using the 2009 Groundhog Day data so I don't want to change anything that might affect a train crossing the boundary to another sim/TT. There are 4 relevant trains in the TT and 3 rules, the upshot of which is that the initial train does not enter. The TTs are: 4M78/$H71714: enters the sim at 18:52H and drops off sim at 19:55 to enter depot. 0M78/$Z71714A: LD off train for fuelling point; enters sim at 20:00, drops off sim at 20:04 0M78/$Z71714B: LD from depot to work train forward; enters sim at 20:20, drops off sim at 20:24 4M78/$H71714: enters sim from depot at 20:52 and drops off sim at 21:22H Rules are: 1) $Z71714A must appear 5 minutes after $H71714 leaves the area. 2) $Z71714B must appear 5 minutes after $Z71714A leaves the area 3) $H71714 must appear 15 minutes affter $Z71714B leaves the area The problem is that rule 3 is stopping the entry of the original train at 18:52H. Remove the rule and the original train enters to time. The obvious way to do it would be to create $H71714A/$H71714B but I don't want to change the UID $H71714 as this could affect either the sim handing the train over of the sim to which the train passes next. Has anyone any ideas how I might make things work? “In life, there is always someone out there, who won’t like you, for whatever reason, don’t let the insecurities in their lives affect yours.” – Rashida Rowe Last edited: 09/04/2018 at 15:08 by postal Reason: None given Log in to reply |
| Train entry problem 09/04/2018 at 16:41 #107428 | |
Meld
1098 posts |
I'm pretty sure that using $H71714B wont affect any transfer to an adjacent sim, I've done it a few times on the Welsh set with no major dramas
Passed the age to be doing 'Spoon Feeding' !!! Log in to reply The following user said thank you: postal |
| Train entry problem 09/04/2018 at 19:42 #107429 | |
Jan
892 posts |
I did a little experiment and I think this only works because when the receiving sim cannot find a timetable with the same UID, it falls back to matching by the Train ID only, which sort of defeats the reason why UIDs were introduced in the first place. If the receiving sim then has multiple trains running around with the same ID during the course of the day, it'll try applying some logic to hopefully pick the right timetable for the train that has just entered via the chaining link, but it might not always get it right - and if there are multiple copies of a train which all enter at the same location and time, but have diverging paths somewhere downstream, it's literally impossible for the receiving sim to pick the correct timetable if it cannot refer back to the UID. The proper solution would be something like Geoff proposed in #16068: Allow for UID suffixes which remain purely internal to a sim and are stripped off when the train transfers to a neighbouring signal box. Two million people attempt to use Birmingham's magnificent rail network every year, with just over a million of them managing to get further than Smethwick. Log in to reply The following user said thank you: postal |
| Train entry problem 10/04/2018 at 11:38 #107438 | |
|
Danny252
1461 posts |
Jan in post 107429 said:I did a little experiment and I think this only works because when the receiving sim cannot find a timetable with the same UID, it falls back to matching by the Train ID only, which sort of defeats the reason why UIDs were introduced in the first place. What happens if the next sim were to have a $H71714B entry as well, which comes from a different entry point (because of similar activities/rules in that sim)? I would have thought Simsig would be smart enough to take into account the different entry point, though maybe the rules are more lax in multiplayer given the possibility of a train entering through a different entry point (e.g. slow vs. fast lines, or a Bath train diverted via Badminton between Swindon and Bristol). Last edited: 10/04/2018 at 11:38 by Danny252 Reason: None given Log in to reply |
| Train entry problem 10/04/2018 at 12:58 #107441 | |
|
Jan
892 posts |
That reminds of a scenario that might require some more thinking even with non-transmitted UID suffixes: What should happen for timetables where a train leaves a sim not towards a non-simulated off-screen area that will never have a sim in its own right, but rather towards another sim and then later re-enters the original sim, e.g. freight trains running via Lewisham on Victoria South Eastern? In the Up direction, those leave the sim at St. Mary Cray Jn and then later re-enter from Lewisham towards Nunhead. For the timetable to work properly when not chained to London Bridge and with UID suffixes implemented, the first part of the timetable from say the Maidstone fringe to St. Mary Cray Jn will run as $H12345 and the second part from the Lewisham fringe towards the WLL as $H12345-1, with a rule that "$H12345-1 must appear x minutes after $H12345 leaves the area" linking the two together. However when running chained to both Maidstone and a hypothetical London Bridge sim, the train would enter as $H12345 each time. That scenario would seem to mean that when a train enters from a chained simulation, the receiving sim needs to ignore UID suffixes and consider all timetable with the same front part of the UID as potentially valid candidates when attempting to decide which timetable is the best match for an entering train, i.e. similar to what happens today where a timetable might contain multiple "partial" timetables with completely the same UID. Two million people attempt to use Birmingham's magnificent rail network every year, with just over a million of them managing to get further than Smethwick. Last edited: 10/04/2018 at 20:42 by Jan Reason: None given Log in to reply |