Timetable Analyser...

I have used your most recent Peterborough 1977 TT to have a look and from what I am able to see there is no real error with the Timetable Analyser, the errors that come up are quite simple fixes.

Take 5S30FO you get 10 errors for this train and looking at them it’s clear from the analyser that is it looking for its joining train on the other days of the week ie: MON, TUE, WED, THU, SAT, a very simple fix for this is to put the DOTW decision on 5S30FO (D: DOTW, C: FRI) you would also need to do the same for the other 5S30's doing this you remove 50 of the errors straight away.

Also look at NNSH-6SX you have one for each 1B19 which has a choice of loco, it simply becomes a matter of putting the decision on NNSH-6SX. So for NNSH-6SX/ZDC482CL31 if you put the decision of 1B19SX and the choice of 31. Then it’s just a matter of doing the same for the other NNSH-6SX obviously with the relevant choice

Platform shares are slightly different but the same principle applies take 2B69SX you have currently only put 1B12 as a platform share but in the TT you have four you need to put in each of the 1B12's using their own UID's but importantly on the trip activity editor put in the decision 1B12SX and then the choice for that 1B12, for example the first entry for platform share on 2B69SX could be 1B12SX/ZGG345CL40 using the decision box on the right put in 1B12SX and under choice put 40, you just need to do the same for the other 1B12's with the relevant choice.

So is the issue actually the documentation rather than the tool itself?

MarkC in post 134515 said:

I have used your most recent Peterborough 1977 TT to have a look and from what I am able to see there is no real error with the Timetable Analyser, the errors that come up are quite simple fixes.

Take 5S30FO you get 10 errors for this train and looking at them it’s clear from the analyser that is it looking for its joining train on the other days of the week ie: MON, TUE, WED, THU, SAT, a very simple fix for this is to put the DOTW decision on 5S30FO (D: DOTW, C: FRI) you would also need to do the same for the other 5S30's doing this you remove 50 of the errors straight away.

Also look at NNSH-6SX you have one for each 1B19 which has a choice of loco, it simply becomes a matter of putting the decision on NNSH-6SX. So for NNSH-6SX/ZDC482CL31 if you put the decision of 1B19SX and the choice of 31. Then it’s just a matter of doing the same for the other NNSH-6SX obviously with the relevant choice

Platform shares are slightly different but the same principle applies take 2B69SX you have currently only put 1B12 as a platform share but in the TT you have four you need to put in each of the 1B12's using their own UID's but importantly on the trip activity editor put in the decision 1B12SX and then the choice for that 1B12, for example the first entry for platform share on 2B69SX could be 1B12SX/ZGG345CL40 using the decision box on the right put in 1B12SX and under choice put 40, you just need to do the same for the other 1B12's with the relevant choice.

Mark

Thank you, but you are missing the point. You are putting the cart before the horse....

Before recent changes, the timetable you quote was error and warning free.

Now it isn't.

Nothing has changed on the timetable.

Why should I have to change the timetable to satisfy the analyser when there is nothing wrong with the timetable?

Everything works as it should, it's the analyser that's the problem, not the timetable.

Vince

VInce in post 134519 said:

MarkC in post 134515 said:

I have used your most recent Peterborough 1977 TT to have a look and from what I am able to see there is no real error with the Timetable Analyser, the errors that come up are quite simple fixes.

Take 5S30FO you get 10 errors for this train and looking at them it’s clear from the analyser that is it looking for its joining train on the other days of the week ie: MON, TUE, WED, THU, SAT, a very simple fix for this is to put the DOTW decision on 5S30FO (D: DOTW, C: FRI) you would also need to do the same for the other 5S30's doing this you remove 50 of the errors straight away.

Also look at NNSH-6SX you have one for each 1B19 which has a choice of loco, it simply becomes a matter of putting the decision on NNSH-6SX. So for NNSH-6SX/ZDC482CL31 if you put the decision of 1B19SX and the choice of 31. Then it’s just a matter of doing the same for the other NNSH-6SX obviously with the relevant choice

Platform shares are slightly different but the same principle applies take 2B69SX you have currently only put 1B12 as a platform share but in the TT you have four you need to put in each of the 1B12's using their own UID's but importantly on the trip activity editor put in the decision 1B12SX and then the choice for that 1B12, for example the first entry for platform share on 2B69SX could be 1B12SX/ZGG345CL40 using the decision box on the right put in 1B12SX and under choice put 40, you just need to do the same for the other 1B12's with the relevant choice.

Mark

Thank you, but you are missing the point. You are putting the cart before the horse....

Before recent changes, the timetable you quote was error and warning free.

Now it isn't.

Nothing has changed on the timetable.

Why should I have to change the timetable to satisfy the analyser when there is nothing wrong with the timetable?

Everything works as it should, it's the analyser that's the problem, not the timetable.

Vince

I am not missing the point here the release of V5 introduced Decision checks within the analyser, the trains pick up in the V5 analyser by rights should have the decisions added to them, take 5S30FO the train runs friday only but there is no decision to tell the analyser that it runs friday only, so the analyser is saying that under the other choices for DOTW there is a problem, you may turn around and say that there is a rule to prevent its entry if 5L30FO does not run, but that rules does not tell the analyser what day it is running.

Was it meant to be a secret to discourage those that write historic timetables? A conspiracy theorist would have a field day.

Okay, the Timetable Analyser is my code, so I ought to step in here.

If a timetable doesn't use decisions, the new analyser should produce the same results as the old one.

If a timetable uses decisions, the old analyser would get things wrong because it didn't know about them. The new one does a separate analysis for each branch of the decision, producing more accurate results.

One thing I hadn't realized when I was rewriting it was that many people were using rules to apply the effects of decisions. The analyser doesn't currently look at rules at all. The next rewrite will apply rules to all analysis (not just their relationship with decisions). But that's some time away because it will be another big job (and I have other things on my plate).

As part-maintainer of a TT which now shows well over 200 error messages, to be told that I can put them right if I edit all the offending trains is a little less than sensitive but to be fair the error messages have all been there since we started using decisions in the TTs.

postal in post 134532 said:

As part-maintainer of a TT which now shows well over 200 error messages, to be told that I can put them right if I edit all the offending trains is a little less than sensitive but to be fair the error messages have all been there since we started using decisions in the TTs.

For pedant clarification, there are no 'error' messages which prevent trains running, they are 'warning' messages of things that might not be right.
For a couple of 'DAYOF WEEK' I'd probably grumble and fix them, otherwise if I get stuck with these I simply put a note in the timetable text field -

If anyone analyses with Loader v x.xx this timetable is known to generate xxx warnings. These are understood and can be ignored as they are due to (trains spanning long platforms / actions at non-key locations / interaction of decisions and rules) where the analyser tool is (being over cautious / confused / not yet able to analyse rules). They do not affect train running unless mentioned in the notes.

More of an issue to me is the 300 newly invalidated trains I am now fixing in Motherwell 84. That is 4 days of not making any nice new timetables for folks to play with.

Bill

Remember, this (and many others like it) isn't a CIF download, "boil in the bag" timetable. I know people who create CIF timetables and in their (understandable) hurry to get them released can't be bothered even to run them through once. A lot of the correspondence you see regarding errors in newly released modern timetables could have been avoided if only the timetable concerned had been tested properly.

Vince in post 134539 said:

Remember, this (and many others like it) isn't a CIF download, "boil in the bag" timetable. I know people who create CIF timetables and in their (understandable) hurry to get them released can't be bothered even to run them through once. A lot of the correspondence you see regarding errors in newly released modern timetables could have been avoided if only the timetable concerned had been tested properly.

I find this comment to be quite discourteous toward people who write modern timetables, there is absolutely nothing "boil in the bag" about the work that has gone into a large number timetables derived from CIF data. In fact it's literally hundreds of hours of work.

Now I'm sure you didn't mean to tar all timetables derived from CIF data with the same brush, but there are good "older" timetables (Such as the ones yourself have written or worked on), there are also bad ones that have appeared over the years that have exactly the same problems with not having been tested properly. In the same way there are good and bad modern timetables.

There's definitely some constructive and good points you raise there Vince, perhaps as this thread relates to the Timetable Analyser you could split some ideas off into a separate thread about how better testing of user contributed timetables might work?

OK, if I accept that, then why doesn't someone explain what has been done in V5. As far as I know, when the changes were made nothing documented what was changed, which would have prepared timetable writers to expect results like the ones I get. The ones who are "in the know" knew about it, but no-one else apparently.

I wrote a number of timetables for Huddersfield which, when V5 came out were rendered useless since one of the exit/entrance points was changed. Where was that communicated?

Again, its not the timetable that's at fault, its the analyser which can't deal with all scenarios available to the timetable writer.

Where here https://www.SimSig.co.uk/Wiki/Show?page=usertrack:ssrun:func:f4:tools1 does it tell me anything useful in interpreting what this means....

NNSH-6SXSX/$ZDC482CL46[1117.15]{DOTW=THU}(1B19SX=31):Terminates at Peterborough with no onward working

When I look at the train concerned I see absolutely nothing wrong. Why? Because there is nothing wrong. The timetable analyser doesn't like the way the timetable is constructed so it throws up misleading statements... and yes I do know warnings do not affect anything in the actual running of the timetable.

Its a very good job I've finished writing timetables - anybody that attempts to write an historic timetable from scratch is going to find it a very daunting prospect.

Maybe unrelated: Do decisions affect whether trains that are not going to run are marked as entered in the F4 window?

What we need to remember is that SimSig was written to give a simulation of an existing operation as it would look if running at an IECC so it was designed with only the "modern-day" era in mind (although some of the simulated areas have seen radical changes since their first "modern-day" appearance in SimSig).

To that extent both the ability to show different eras and run TTs to a different specification than that for which the sim was designed are effectively subversions of the original SimSig ethos. Many users are grateful for the widening of the scope but it is a distraction for the developers of the core code and simulations.

The manually written TTs (often from heritage eras) are similarly beyond the scope of the core SimSig TTs which are now produced with a large automatic input before manual work to add in the associations and non-timetabled moves like light engines and shunts.

The things like the 5-day timetables and the implementation of those (originally through a dummy seed train and rules and then through decisions) are just examples of TT writers pushing the boundaries and taking the SimSig capabilities far beyond what the writers and developers expected.

As part-maintainer of a TT which now shows well over 200 Edit: error warning messages, to be told that I can put them right if I edit all the offending trains is a little less than sensitive but to be fair the Edit: error warning messages have all been there since we started using decisions in the TTs.

That is all leading us to the point where we need to understand what the future direction of travel will be. If the direction is towards a situation where heritage TTs (and eras) are a distraction and the end game is to get rid of them there will be a lot of disappointed users but so be it. On the other hand, if SimSig wishes to maintain a broad church then some thought does need to be given to the way that forthcoming proposals are publicised and even for some sort of feedback process involving more than those in the centre both to help those who care deeply for SimSig but are working at the boundaries of the capabilities and more importantly to avoid the dangers of group-think when only a small number of people working from the same background are involved in decision making.

Albert in post 134528 said:

Maybe unrelated: Do decisions affect whether trains that are not going to run are marked as entered in the F4 window?

If a decision goes the wrong way, the train will be greyed out just as if it's cancelled for any other reason (e.g. there's an alternative rule or it's a run-when-required working that didn't win the random number choice).

Different eras and different styles of timetable are not subversions of the SimSig ethos, they're showing that SimSig is far more extensible than just modern eras. I don't know whether Geoff would authorize building one, but there's no reason why we couldn't do (say) Liverpool Street in Great Eastern days (see https://www.davros.org/rail/diagrams/old_liverpool_street.gif), though the signalling would probably behave as if it was all track-circuited.