Problem with Alternatives Rule and non-unique UIDs

There's also a related problem in that there is no guarantee that the trains will enter in the correct order: If the first instance of the timetable is running late and/or the second one early, the second instance can actually enter the sim first, with the "Must appear X minutes after Y leaves the area" rule being applied the wrong way round (see Mantis 14574).

Jan in post 87206 said:

There's also a related problem in that there is no guarantee that the trains will enter in the correct order: If the first instance of the timetable is running late and/or the second one early, the second instance can actually enter the sim first, with the "Must appear X minutes after Y leaves the area" rule being applied the wrong way round (see Mantis 14574).

I don't have access to Mantis, unfortunately, but I'm not surprised at the behaviour. I've always wondered how the Rules code decides what to do when the two trains in a Rule have the same TD/UID pair. How does it decide which train is which in these circumstances?

One solution might be to allocate an additional unique internal UID to each train in the timetable and use this internal UID for all Rules decisions. This would allow the original (or external) UID to remain unchanged so that chaining will not be affected, but I'm sure the coding gurus will come up with a much simpler solution.

Lyn-Greenwood in post 87207 said:

Jan in post 87206 said:

There's also a related problem in that there is no guarantee that the trains will enter in the correct order: If the first instance of the timetable is running late and/or the second one early, the second instance can actually enter the sim first, with the "Must appear X minutes after Y leaves the area" rule being applied the wrong way round (see Mantis 14574).

I don't have access to Mantis, unfortunately, but I'm not surprised at the behaviour. I've always wondered how the Rules code decides what to do when the two trains in a Rule have the same TD/UID pair. How does it decide which train is which in these circumstances?

One solution might be to allocate an additional unique internal UID to each train in the timetable and use this internal UID for all Rules decisions. This would allow the original (or external) UID to remain unchanged so that chaining will not be affected, but I'm sure the coding gurus will come up with a much simpler solution.

Some kind of suffix that is not transmitted to a chained simulation sounds a good idea. Thanks.

Rather than using a suffix, can't you just use the UID and sort by simulation entry time?

Rather than using a suffix, can't you just use the UID and sort by simulation entry time?

Sacro in post 87215 said:

Rather than using a suffix, can't you just use the UID and sort by simulation entry time?

I thought about that as well, but in the case where a train leaves and reenters the same sim more than once, this means that you have to have more than one "Must appear X minutes after Y leaves the area" rule, which means there's no way of unambiguously matching the correct rule to the correct instances of the same UID. Even if rules could be directly attached to a train's timetable data (which I seem to remember was the long-term intention at some point), it would still be difficult to work out which of the multiple trains sharing a UID is supposed to be "Train Y" within the context of the rule.

Having said that, I guess that just two trains and one rule is still the most common case and your idea (trains sharing the same UID have to enter in booked order) has the charm of fixing that case without requiring any existing timetables to be modified.

By the way, while checking out the Rules behaviour I discovered that if a train is to depart a Yard late owing to a Rule enforcement, then the shunter rings for 'Permission to leave Yard' at the original scheduled departure time, not the modified time. I've even had a shunter ringing for permission before the original train had arrived at the Yard. If this hasn't already been reported, please add the issue to the Mantis system.

Sorry to jump on this late. This issue with the same UID has a simple but long-winded, albeit short-term, solution.

What I found is how the UID is allocated when the rule is set up.

Basically the 2nd train is being allocated the 1st train's UID code. When you scroll through the listings of a train, BOTH UID are in the list BUT the one assigned to the Rule is taking the wrong UID.
When you click the dropdown, they both show the 1st iteration of the UID in both separate boxes, when the 1st dropdown should be referencing the 2nd UID, as the Rules start with the 2nd train's entry , followed by the train it's entering after (train Y)

I hope this helps all.

When you are setting up the rule, you either manually enter the TD or UID for a train (in which case the first train fitting that description in the TT is selected unless you manually intervene) or you pick from a drop-down list. If there are two (or more) trains with the same TD/UID combination, they will show as 2 separate but adjacent entries in the drop-down.

I think Guts is telling us that you need to take care about which train you select from the drop-down. As far as I am aware, the drop-down sorts things in the same order as the listing by TD in F4. So if you have 1A00/$XXXX going off sim and re-entering giving you two instances of 1A00/$XXXX in the TT you need to be careful which of the two is selected when writing the rule.

If you want a rule that the train must not re-enter until Z minutes after it leaves the sim (Train B must not enter until Z minutes after Train A leaves the area), you need to make sure by reference to the TT which in the list of two entries is Train A and which is Train B. Then you have to pick the correct item from the Rules drop-down for each of Train A and Train B rather than just clicking on the first item in the list each time.

Apologies to Guts and Lyn if I've got that wrong, but it is something I've had to be careful about at some stage in the distant past when the situation arose in a TT with which I was tinkering.

As an alternative, could the creation of a new entry in the TT automatically grant a serial number so that no operator input would be required. It would probably need things like the Rules set-up screen to allow for selection by TD, UID or serial and I've no idea how complex that would be. However, you would have to do something similar if using a suffixed UID.

Presumably the generation of a serial number could be coded to happen automatically for a manual TT entry. I've no idea how complex it would be from a CIF download but if it could be done it would de-risk things by removing the opportunity for operator error when inputting a new suffixed UID.

My idea was to let the suffixed UID default to the normal UID (as supplied in CIF downloads), but give the user/tt-writer the ability to change it on the tt Edit Screen if this was found to be necessary.

FWIW I would not expect to need to alter any existing timetables, only if the author wishes to fix some scenario.

GeoffM in post 87313 said:

FWIW I would not expect to need to alter any existing timetables, only if the author wishes to fix some scenario.

Certainly - I didn't mean for any changes that would actually break existing timetables. I was just trying to say that some solutions might become effective immediately after being implemented in the core code, while others would only be effective after the timetable has been updated in order to take advantage of some new feature (and if the timetable isn't updated, it continues to work just as before).

GeoffM in post 87313 said:

One thing this doesn't address is where you have sims A and B feeding into sim C, where a train will only ever run A-C or B-C, but never both on the same day (actual instance dictated by day-to-day demand, such as coal traffic). Sim A doesn't know that sim B is sending its version of the train, and vice versa. Their timings through C are the same, ie they share the same timetable path for part of their journey. There was talk some time ago of a master timetable server that would decide on things like this but it's a big task.

That is fairly easy to sort out. Assuming that sims A & B use a decision to decide if they are going to run the train or not then that decision could be forced if A, B and C are chained.

One thing this doesn't address is where you have sims A and B feeding into sim C, where a train will only ever run A-C or B-C, but never both on the same day (actual instance dictated by day-to-day demand, such as coal traffic). Sim A doesn't know that sim B is sending its version of the train, and vice versa. Their timings through C are the same, ie they share the same timetable path for part of their journey. There was talk some time ago of a master timetable server that would decide on things like this but it's a big task.

Lyn-Greenwood in post 87310 said:

My idea was to let the suffixed UID default to the normal UID (as supplied in CIF downloads), but give the user/tt-writer the ability to change it on the tt Edit Screen if this was found to be necessary.

Would that cause a problem if sims were chained and the TT writers for the two sims had used different suffixes for the same train - or does the chaining allow for a bit of fuzzy logic to pick a best fit?

KymriskaDraken in post 88339 said:

GeoffM in post 87313 said:

One thing this doesn't address is where you have sims A and B feeding into sim C, where a train will only ever run A-C or B-C, but never both on the same day (actual instance dictated by day-to-day demand, such as coal traffic). Sim A doesn't know that sim B is sending its version of the train, and vice versa. Their timings through C are the same, ie they share the same timetable path for part of their journey. There was talk some time ago of a master timetable server that would decide on things like this but it's a big task.

That is fairly easy to sort out. Assuming that sims A & B use a decision to decide if they are going to run the train or not then that decision could be forced if A, B and C are chained.

How does A know via C that B has sent its version, or not, and vice versa?

GeoffM in post 88341 said:

KymriskaDraken in post 88339 said:

GeoffM in post 87313 said:

One thing this doesn't address is where you have sims A and B feeding into sim C, where a train will only ever run A-C or B-C, but never both on the same day (actual instance dictated by day-to-day demand, such as coal traffic). Sim A doesn't know that sim B is sending its version of the train, and vice versa. Their timings through C are the same, ie they share the same timetable path for part of their journey. There was talk some time ago of a master timetable server that would decide on things like this but it's a big task.

That is fairly easy to sort out. Assuming that sims A & B use a decision to decide if they are going to run the train or not then that decision could be forced if A, B and C are chained.

How does A know via C that B has sent its version, or not, and vice versa?

I would have thought that the hosts of the sims involved would speak to each other about such things.


Kev