Upcoming Games

(UTC times)


Full list
Add a game

Upcoming Events

No events to display

Timetable requirements

You are here: Home > Forum > General > Timetabling > Timetable requirements

Page 1 of 2

Timetable requirements 02/09/2018 at 20:09 #111796
clive
Avatar
2789 posts
[This is the first of three proposals I have for improving SimSig timetabling. I'm throwing them out here for people to think about and, hopefully, come up with further suggestions or point out issues with the idea. I don't have time to work on them at the moment and I don't know when I will, so please don't ask when they'll be available.

Please don't hijack this thread for other ideas.]

This feature would allow a timetable writer to specify what run-time options are required for their timetable to run.

There would be a new "requirements" tab on the main timetable editor panel. This contains a list of requirements, each of the form "+NXXX" or "-NXXX" where NXXX is a code, specified in the sim manual, that relates to a scenario or option. [These codes can already be used with decisions - see https://www.SimSig.co.uk/Forum/ThreadView/47142 - so should be in the manuals. If not, ask the sim developer to add them. The "NSC!" prefix won't be needed.] Note that only scenario or user-selected options are available, not any others in the manual.

Normally this panel will affect the scenario and option tabs in the loader if the timetable is chosen. There will be a tick box to allow this feature to be disabled (for example if there's a bug in the timetable). It won't have any effect once the simulation is running.

NXXX means that option NXXX is required. If this is a scenario or a value in a choice box, that scenario or choice is selected and all others are greyed out. If it's a tick box, that box is ticked and greyed out (so can't be altered).

-NXXX means that option NXXX is forbidden. If this is a scenario or a value in a choice box, that scenario or choice is greyed out and so can't be selected. If it's a tick box, that box is unticked and greyed out (so can't be altered).

All other choices are unaffected.

For example, in Peterborough, "+NBIDI -NFG" means that the Spalding Bi-Di era is required and flashing greens are forbidden. Any scenario can be used.

Log in to reply
Timetable requirements 02/09/2018 at 21:55 #111805
GeoffM
Avatar
6376 posts
Rather than making the user type in obscure text codes, it would be far better to just select from options. Pretty sure I wrote that in a Mantis ticket somewhere.
SimSig Boss
Log in to reply
Timetable requirements 02/09/2018 at 22:27 #111806
JamesN
Avatar
1607 posts
GeoffM in post 111805 said:
Rather than making the user type in obscure text codes, it would be far better to just select from options. Pretty sure I wrote that in a Mantis ticket somewhere.
Have the devs put something (extra) in the NSC file to generate the list of human readable packages? Kinda like the existing choice box one can use for eras but it appears in the TT editor not the Sim startup?

Log in to reply
Timetable requirements 07/09/2018 at 10:04 #111959
clive
Avatar
2789 posts
GeoffM in post 111805 said:
Rather than making the user type in obscure text codes, it would be far better to just select from options.
That's a UI issue. For example, the editor for the requirements tab could display the options that appear in the loader plus an extra drop-down for scenario. Each tick-box would become one of those three-way tick boxes: a tick or empty forces that choice, while grey means the timetable doesn't care and the end-user gets to pick. For choices, there are two extra options of "any allowed" and "some allowed". Choosing a specific value forces it. Choosing "any allowed" does what it says. Choosing "some allowed" produces a secondary pane of tick boxes, one for each choice.

UIs are important, but they are a wrapper on the basic mechanism, which is what I'm exploring here.

Log in to reply
Timetable requirements 07/09/2018 at 10:17 #111960
clive
Avatar
2789 posts
JamesN in post 111806 said:

Have the devs put something (extra) in the NSC file to generate the list of human readable packages?
That would limit it to what the devs offered and could also lead to a large number of choices.

For example, in Peterborough you usually don't care if flashing greens are allowed, but a timetable might need it because it has 140 mph trains in it.

Log in to reply
Timetable requirements 07/09/2018 at 20:32 #111980
GeoffM
Avatar
6376 posts
clive in post 111960 said:
JamesN in post 111806 said:

Have the devs put something (extra) in the NSC file to generate the list of human readable packages?
That would limit it to what the devs offered and could also lead to a large number of choices.

For example, in Peterborough you usually don't care if flashing greens are allowed, but a timetable might need it because it has 140 mph trains in it.
It should be up to the developer, not the user. The user may not know that a particular option makes no sense - ven more so if you use obscure IDs instead of the UI that's staring you in the face.

SimSig Boss
Last edited: 07/09/2018 at 20:40 by GeoffM
Reason: None given

Log in to reply
Timetable requirements 07/09/2018 at 21:37 #111981
postal
Avatar
5264 posts
GeoffM in post 111980 said:
It should be up to the developer, not the user. The user may not know that a particular option makes no sense - ven more so if you use obscure IDs instead of the UI that's staring you in the face.
Very similar ground is covered in Mantis 21503 about ensuring that the correct era is picked when a user selects a TT (only in that case I would argue that it is up to the TT writer rather than the developer but not the user).

Granted the UI is only the wrapper for the underlying code; but if the interface the end used has is though that UI then we are not asking the user to interact directly with the core code, we are asking her/him to make some selections from the UI which are then passed on to the core code. If the UI could be pre-populated with the selections made by the developer or TT writer, then it would give the user the opportunity to amend any of the settings if they had a reason to do so, but would give a default setting for the user who just wants to get on and play. Perhaps this could be done through the TT header? The TT would have been written for a specific set of options, so any pre-set options from the developer would carry through into the TT header along with the options selected by the TT writer.

Probably all too simplistic but is it pointing to something feasible?

“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
Log in to reply
Timetable requirements 10/09/2018 at 22:04 #112053
clive
Avatar
2789 posts
GeoffM in post 111980 said:
clive in post 111960 said:
JamesN in post 111806 said:

Have the devs put something (extra) in the NSC file to generate the list of human readable packages?
That would limit it to what the devs offered and could also lead to a large number of choices.

For example, in Peterborough you usually don't care if flashing greens are allowed, but a timetable might need it because it has 140 mph trains in it.
It should be up to the developer, not the user. The user may not know that a particular option makes no sense - ven more so if you use obscure IDs instead of the UI that's staring you in the face.
I think there's some confusion here.

If two things don't make sense together ever, the developer should ensure that the NSC file won't allow it. (It may be we need to add some new facilities to help with this; if so, the devs should ask.) But I'm talking about the case where features might make sense together in some situations, but NOT with a particular timetable. So it needs to be driven by the timetable auther, not the developer.

Log in to reply
Timetable requirements 10/09/2018 at 22:06 #112055
clive
Avatar
2789 posts
postal in post 111981 said:

Very similar ground is covered in Mantis 21503 about ensuring that the correct era is picked when a user selects a TT (only in that case I would argue that it is up to the TT writer rather than the developer but not the user).

Granted the UI is only the wrapper for the underlying code; but if the interface the end used has is though that UI then we are not asking the user to interact directly with the core code, we are asking her/him to make some selections from the UI which are then passed on to the core code. If the UI could be pre-populated with the selections made by the developer or TT writer, then it would give the user the opportunity to amend any of the settings if they had a reason to do so, but would give a default setting for the user who just wants to get on and play. Perhaps this could be done through the TT header? The TT would have been written for a specific set of options, so any pre-set options from the developer would carry through into the TT header along with the options selected by the TT writer.
Um, that's the whole point of this proposal!

Log in to reply
Timetable requirements 10/09/2018 at 23:29 #112063
GeoffM
Avatar
6376 posts
I think we're all confused at each other! Admittedly I may have confused things by referring to a user rather than a timetable author (timetabler? scheduler? Let's try the latter).

The interested parties:
- Player
- Scheduler
- Developer
Player just needs to know how to set up a simulation to run a particular timetable, hopefully guided by (or forcibly given) whatever timetable they select. Oh, and we ought to be able to do multi-select for timetables really, eg for timetables with special add-ons that fit into another schedule.

Scheduler needs to know the options available but should not need to enter IDs in a text box - they should be able to click and choose.

Developer either needs a way to be able to specify to the scheduler that these options are available, or they need to be in a manual. I'd prefer the former.

So what start-up options exist in the general case?
- ARS enabled or not
- TORR enabled or not
- Era of simulation (timeframe generally)
- Difficulty/failures
...any other types of option?

ARS may or may not be something that is relevant to the timetable. TORR is unlikely to be relevant. Era almost certainly, but see below. Difficulty: unlikely.

Eras have been done in different ways, I've noticed. I tend to do mine by year, so ERA2001, ERA2015, and one era selection maps to one VIS class. But others do it by feature, such as FLYOVERADDED, TURNBACK, with the era selection referring to multiple VIS classes. It would not make sense for the scheduler to choose one and not the other here. I'm not sure it's an issue but worth remembering.

SimSig Boss
Last edited: 10/09/2018 at 23:29 by GeoffM
Reason: None given

Log in to reply
Timetable requirements 11/09/2018 at 00:16 #112067
pedroathome
Avatar
915 posts
As a thought here.

How would it work if there was a tab on the F4 TT editor window showing the startup options presented to the user on sim startup. This could allow the TT writer to select the era (As presented to the user, ignoring vis classes,and other backend stuff), and have it saved with the timetable.

James

Log in to reply
Timetable requirements 11/09/2018 at 00:30 #112068
postal
Avatar
5264 posts
clive in post 112055 said:
Um, that's the whole point of this proposal!
I was driven by your comment on Mantis ("I won't close this, but I can't right now think of an easy way of doing it that will work in general"). While there may well be lots of different combinations of parameters available, I was just trying to ask why we need to consider all the combinations when most are presumably conflicting or irrelevant.

“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
Log in to reply
Timetable requirements 12/09/2018 at 18:36 #112118
KymriskaDraken
Avatar
963 posts
I think the player should be able to override some of the options specified by the timetable writer. For instance a 1980s timetable could be written to say No ARS, but with some sims it's helpful to have ARS running unstaffed panels. Obviously era choices shouldn't be overridable (is that a word?) if things would break. Maybe calling some choices "critical" (can't be overridden) would help the various parties decide if something is critical or not. For example an era choice would be critical and ARS wouldn't be.


Kev

Log in to reply
Timetable requirements 12/09/2018 at 21:13 #112124
postal
Avatar
5264 posts
KymriskaDraken in post 112118 said:
I think the player should be able to override some of the options specified by the timetable writer. For instance a 1980s timetable could be written to say No ARS, but with some sims it's helpful to have ARS running unstaffed panels. Obviously era choices shouldn't be overridable (is that a word?) if things would break. Maybe calling some choices "critical" (can't be overridden) would help the various parties decide if something is critical or not. For example an era choice would be critical and ARS wouldn't be.


Kev
I don't see why the player shouldn't be able to override any of the options; it's their game, not the TT writers. However, for many users it would be good if the options used by the TT writer were loaded by default into the UI screens so that they would know that they would be running the TT in a fully compatible mode.

“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
Log in to reply
Timetable requirements 12/09/2018 at 21:19 #112126
GeoffM
Avatar
6376 posts
postal in post 112124 said:
KymriskaDraken in post 112118 said:
I think the player should be able to override some of the options specified by the timetable writer. For instance a 1980s timetable could be written to say No ARS, but with some sims it's helpful to have ARS running unstaffed panels. Obviously era choices shouldn't be overridable (is that a word?) if things would break. Maybe calling some choices "critical" (can't be overridden) would help the various parties decide if something is critical or not. For example an era choice would be critical and ARS wouldn't be.


Kev
I don't see why the player shouldn't be able to override any of the options; it's their game, not the TT writers. However, for many users it would be good if the options used by the TT writer were loaded by default into the UI screens so that they would know that they would be running the TT in a fully compatible mode.
That's how I envisage it. In other words, when you click Next from the timetable selection, the next screen has the scenario options all set up ready, but you can still change them, as per now.

SimSig Boss
Log in to reply
The following user said thank you: postal
Timetable requirements 13/09/2018 at 15:18 #112139
clive
Avatar
2789 posts
GeoffM in post 112063 said:

I think we're all confused at each other! Admittedly I may have confused things by referring to a user rather than a timetable author (timetabler? scheduler? Let's try the latter).

The interested parties:
- Player
- Scheduler
- Developer
Ok, here's what I have been thinking.

Developer has already done what's necessary by providing options at startup. This proposal doesn't require anything new from the developer.

GeoffM in post 112063 said:

Player just needs to know how to set up a simulation to run a particular timetable, hopefully guided by (or forcibly given) whatever timetable they select.
Right. If the timetable has requirements then somewhere, probably on the timetable selection pane, there's a new tick box "override timetable requirements". If they tick that, the following stuff doesn't happen. If they leave it unticked, then the core code looks at the requirements in the timetable and applies them to the scenario and options pane. So the user might see some of the scenarios greyed out, or might see the "Flashing greens" tick box ticked and greyed out. In other words, the core code will ensure that the player can only select options that the timetable works with; if the timetable doesn't care about something (e.g. TORR), the player has a free hand to decide what they want.

If the timetable has no requirements then everything works just like today.

GeoffM in post 112063 said:

Oh, and we ought to be able to do multi-select for timetables really, eg for timetables with special add-ons that fit into another schedule.
Different issue; please start another thread or raise a separate Mantis ticket.

GeoffM in post 112063 said:

Scheduler needs to know the options available but should not need to enter IDs in a text box - they should be able to click and choose.
As far as how this stuff would work internally, it doesn't matter how it's done. The "IDs in a text box" was just a first thing that could be put together relatively quickly. I agree that, in a smooth and polished version of this, they should do it by something similar to the current options page. As I said previously, three-way tick boxes and extra "allow any" and "allow some" choice boxes would probably work.

GeoffM in post 112063 said:

Developer either needs a way to be able to specify to the scheduler that these options are available, or they need to be in a manual. I'd prefer the former.
I don't agree. But not how you probably think. The developer shouldn't need to do anything. They've already specified what the options are and we have a user interface for that. The developer should NOT be saying what the scheduler can or can't require. The scheduler just looks at the existing setup screens and knows what the options are.

(Forget the stuff about codes. First, I was thinking more about how the core code would handle this stuff. Secondly, the codes need to be in the manual for use in Decisions, so I assumed that would be the simplest approach. But as soon as it was pointed out, I can see that making it visual is far better for the scheduler and player.)

GeoffM in post 112063 said:

So what start-up options exist in the general case?
It doesn't matter. Whatever options the developer has provided, the scheduler should be able to use. Let's not try to second-guess.

GeoffM in post 112063 said:

Eras have been done in different ways, I've noticed. I tend to do mine by year, so ERA2001, ERA2015, and one era selection maps to one VIS class. But others do it by feature, such as FLYOVERADDED, TURNBACK, with the era selection referring to multiple VIS classes. It would not make sense for the scheduler to choose one and not the other here. I'm not sure it's an issue but worth remembering.
True. But the scheduler will think in terms of "need to pick the 'recent' era" or "need the extra sidings option" and won't care or know how that's handled internally. If they pick from the stuff on the startup screens, it all just works.

Log in to reply
Timetable requirements 13/09/2018 at 15:23 #112141
clive
Avatar
2789 posts
KymriskaDraken in post 112118 said:
I think the player should be able to override some of the options specified by the timetable writer. For instance a 1980s timetable could be written to say No ARS, but with some sims it's helpful to have ARS running unstaffed panels. Obviously era choices shouldn't be overridable (is that a word?) if things would break. Maybe calling some choices "critical" (can't be overridden) would help the various parties decide if something is critical or not. For example an era choice would be critical and ARS wouldn't be.
In my opinion, the timetable writer shouldn't be forcing the player to use or not use ARS. They should only be enforcing stuff that will break the timetable if got wrong (which is where we started this whole concept). "It's not such fun if you have ARS" is a personal opinion, not one to push on people.

For "ARS" also read other stuff, like the Nene Sidings phone calls in Peterborough. Some things, like flashing greens, might be a user choice for one timetable but essential for another. Even eras might be: a Peterborough timetable written for the main era doesn't need to prevent you using the Spalding bidi era, because a user might want to see what difference using that makes. But a timetable that needs the bidi should be able to force it.

tl;dr: if it's not "critical", the timetable writer shouldn't require it. Which things are critical depend on the specific timetable.

Log in to reply
Timetable requirements 13/09/2018 at 16:44 #112142
postal
Avatar
5264 posts
We gradually seem to be converging towards a common position that the UI will be able to offer guidance and/or compulsion when a TT is selected. It would be an excellent innovation and I would love to see it happen.

Having established the principles, there is obviously lots of detailed work to do. I'm still a little confused about how some of the stuff might work. For example, using the Spalding bidi situation, would the Scheduler tick the box when the TT was being created in order to lock that in to the TT parameters if the bidi was required by the TT or would the core code be expected to compute the requirement from the TT data? If input by the scheduler, would that then show the greyed out check-box while no input from the scheduler would allow input to the check-box by the user? What then happens in the converse case where checking a box is incompatible with the requirements of the TT? Would there be some way for the scheduler to set that box as empty but greyed out or again would the core code be expected to compute and grey out?

Looking a little further, there are a multitude of older timetables which have been written before this came over the horizon. Presumably the new capability wouldn't be backwards compatible, not in the sense that it might break older TTs but rather that the options/proscriptions wouldn't be offered as the data is not held in the TT. Would you then envisage a simple update process for those TTs of the Scheduler loading the older TT, making sure the sim settings are as desired then re-saving the TT with the fixed and optional settings locked in to the updated format so the TT can be re-published?

“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
Log in to reply
Timetable requirements 13/09/2018 at 17:14 #112144
GeoffM
Avatar
6376 posts
clive in post 112139 said:
GeoffM in post 112063 said:

Oh, and we ought to be able to do multi-select for timetables really, eg for timetables with special add-ons that fit into another schedule.
Different issue; please start another thread or raise a separate Mantis ticket.
No it's not - it's more important to consider it now than as a separate issue - and if multi-select were done now, you'd definitely have to consider it with these proposals! Let's say there are three eras. Timetable 1 only works in eras A and B. Timetable 2 only works in eras B and C. After selecting those two timetables, the software needs to enforce use of era B (the only option common to both). Similarly, if the combination of timetables results in a conflicting set of requirements then it should say so.

clive in post 112139 said:
GeoffM in post 112063 said:

So what start-up options exist in the general case?
It doesn't matter. Whatever options the developer has provided, the scheduler should be able to use. Let's not try to second-guess.
It's brainstorming, exhausting every possibility in case there is something that needs to be considered.

clive in post 112141 said:
KymriskaDraken in post 112118 said:
I think the player should be able to override some of the options specified by the timetable writer. For instance a 1980s timetable could be written to say No ARS, but with some sims it's helpful to have ARS running unstaffed panels. Obviously era choices shouldn't be overridable (is that a word?) if things would break. Maybe calling some choices "critical" (can't be overridden) would help the various parties decide if something is critical or not. For example an era choice would be critical and ARS wouldn't be.
In my opinion, the timetable writer shouldn't be forcing the player to use or not use ARS. They should only be enforcing stuff that will break the timetable if got wrong (which is where we started this whole concept). "It's not such fun if you have ARS" is a personal opinion, not one to push on people.
That's why ARS (or not) needs to be considered: ARS is more strict on timetables (line/path codes etc). It's quite possible to write a simpler timetable that works in a non-ARS mode but not in ARS (ie your "break the timetable" comment).

SimSig Boss
Log in to reply
Timetable requirements 13/09/2018 at 18:49 #112145
KymriskaDraken
Avatar
963 posts
Not breaking existing timetables is an important consideration so if the sim finds a timetable with no start-up options set it should offer the player the full range of start-up options as now.

Perhaps a new tab could be added to the TT editor for these options. I don't know how straightforward it would be to get it to copy the options from the sim so that the timetable writer can set the default options for that particular timetable. There could be a checkbox to "force" certain options - era for instance which will then show a greyed-out box/menu to the player when they load the timetable.

Kev

Log in to reply
Timetable requirements 14/09/2018 at 12:30 #112150
clive
Avatar
2789 posts
postal in post 112142 said:

Having established the principles, there is obviously lots of detailed work to do. I'm still a little confused about how some of the stuff might work. For example, using the Spalding bidi situation, would the Scheduler tick the box when the TT was being created in order to lock that in to the TT parameters if the bidi was required by the TT or would the core code be expected to compute the requirement from the TT data?
Neither. The Scheduler would open up a new "requirements" tab on the F4 timetable editor. This would show, inter alia, a copy of the tick box but with the tick in grey. Clicking on this runs through three states - grey tick, black tick, empty - in a cycle. If she leaves it on black tick, then when the timetable is used it will force bi-di on. If she leaves it on empty, then when the timetable is used is will force bi-di off. But if she leaves it on grey tick then the timetable won't make any requirements at all.

(Actually, Bi-Di is part of the era, which is a drop down and will use a different visual approach. But the principle is the same.)

postal in post 112142 said:

Looking a little further, there are a multitude of older timetables which have been written before this came over the horizon. Presumably the new capability wouldn't be backwards compatible, not in the sense that it might break older TTs but rather that the options/proscriptions wouldn't be offered as the data is not held in the TT. Would you then envisage a simple update process for those TTs of the Scheduler loading the older TT, making sure the sim settings are as desired then re-saving the TT with the fixed and optional settings locked in to the updated format so the TT can be re-published?
Yes. She would open the timetable editor, go to the new tab, set the requirements, and save, exactly the same as when developing a new timetable. The initial state of this tab will always be to allow the Player all options and the Scheduler can change the settings on this tab at any time.

Last edited: 14/09/2018 at 12:39 by clive
Reason: None given

Log in to reply
The following user said thank you: postal
Timetable requirements 14/09/2018 at 12:37 #112151
clive
Avatar
2789 posts
GeoffM in post 112144 said:
clive in post 112139 said:
GeoffM in post 112063 said:

Oh, and we ought to be able to do multi-select for timetables really, eg for timetables with special add-ons that fit into another schedule.
Different issue; please start another thread or raise a separate Mantis ticket.
No it's not - it's more important to consider it now than as a separate issue - and if multi-select were done now, you'd definitely have to consider it with these proposals! Let's say there are three eras. Timetable 1 only works in eras A and B. Timetable 2 only works in eras B and C. After selecting those two timetables, the software needs to enforce use of era B (the only option common to both). Similarly, if the combination of timetables results in a conflicting set of requirements then it should say so.
Hmm, good points. But the solution you've expressed there would work without any change to this feature, only to the multi-select feature.

GeoffM in post 112144 said:

clive in post 112139 said:
GeoffM in post 112063 said:

So what start-up options exist in the general case?

It doesn't matter. Whatever options the developer has provided, the scheduler should be able to use. Let's not try to second-guess.

It's brainstorming, exhausting every possibility in case there is something that needs to be considered.
Okay, though I'm sceptical that there is.

GeoffM in post 112144 said:

clive in post 112141 said:
KymriskaDraken in post 112118 said:
I think the player should be able to override some of the options specified by the timetable writer. For instance a 1980s timetable could be written to say No ARS, but with some sims it's helpful to have ARS running unstaffed panels. Obviously era choices shouldn't be overridable (is that a word?) if things would break. Maybe calling some choices "critical" (can't be overridden) would help the various parties decide if something is critical or not. For example an era choice would be critical and ARS wouldn't be.
In my opinion, the timetable writer shouldn't be forcing the player to use or not use ARS. They should only be enforcing stuff that will break the timetable if got wrong (which is where we started this whole concept). "It's not such fun if you have ARS" is a personal opinion, not one to push on people.
That's why ARS (or not) needs to be considered: ARS is more strict on timetables (line/path codes etc). It's quite possible to write a simpler timetable that works in a non-ARS mode but not in ARS (ie your "break the timetable" comment).
I don't understand this point.

I agree that timetabling is different on ARS and non-ARS sims. But if the sim has ARS, you can't validate the timetable unless you put all the line and path codes in, EVEN if you then turn ARS off when running it. The PTH validation stage is still the same.

Last edited: 14/09/2018 at 12:38 by clive
Reason: None given

Log in to reply
Timetable requirements 14/09/2018 at 17:09 #112154
GeoffM
Avatar
6376 posts
clive in post 112151 said:
GeoffM in post 112144 said:

That's why ARS (or not) needs to be considered: ARS is more strict on timetables (line/path codes etc). It's quite possible to write a simpler timetable that works in a non-ARS mode but not in ARS (ie your "break the timetable" comment).
I don't understand this point.

I agree that timetabling is different on ARS and non-ARS sims. But if the sim has ARS, you can't validate the timetable unless you put all the line and path codes in, EVEN if you then turn ARS off when running it. The PTH validation stage is still the same.
That depends on how you write the data. If you have a simplified set of segments (literally one segment in each direction between each location) for non-ARS, and a comprehensive set for ARS (multiple segments with line/path codes) then you will have a scenario where non-ARS will tolerate a much less detailed timetable.

Anyway, ultimately it's up to the person who writes the timetable. If they allow a set of options that are not compatible with the timetable then it's down to them.

SimSig Boss
Log in to reply
Timetable requirements 14/09/2018 at 17:44 #112155
58050
Avatar
2659 posts
Online
GeoffM in post 112154 said:
clive in post 112151 said:
GeoffM in post 112144 said:

That's why ARS (or not) needs to be considered: ARS is more strict on timetables (line/path codes etc). It's quite possible to write a simpler timetable that works in a non-ARS mode but not in ARS (ie your "break the timetable" comment).
I don't understand this point.

I agree that timetabling is different on ARS and non-ARS sims. But if the sim has ARS, you can't validate the timetable unless you put all the line and path codes in, EVEN if you then turn ARS off when running it. The PTH validation stage is still the same.
That depends on how you write the data. If you have a simplified set of segments (literally one segment in each direction between each location) for non-ARS, and a comprehensive set for ARS (multiple segments with line/path codes) then you will have a scenario where non-ARS will tolerate a much less detailed timetable.

Anyway, ultimately it's up to the person who writes the timetable. If they allow a set of options that are not compatible with the timetable then it's down to them.
Well you say that Geoff but I really think when developers create sims with eras they need to be alot more specific as to what eras(preferably in a date format0 so the timetable writerknows what he can or can't get any with. For example some months ago I had a discussion with Karl(headshot119) with reagrds to the south Wales sim being able to run a BR era timetable on them. He told me that the Cardiff PSB sim hadn't really changed that much & as a result of him confirming that a BR era timetable could be written I purchased a licence for them. Now to be fair there have only been a few issuesraised on MANTIS so far & to be fair to him he is prepared to amend the sim to cater for what's required for the timetable(1987-1988 for anyone interested). That said not every develop0er is prepared to go to such lengths to change things.
There are a number of users who like me specifically only like running BR era timetables & don't bother with the modern era at all & I dare say there are users on here that go the other way & omnly run modern era tts on sims. Each to their own I know, some users out there have written BR era timetables for sims that as yet still aren't in a state whereby the timetable can be tested & released. I know this has been mentioned before & I appreciate that alot of developers have day jobs & families to deal with, but I find that reporting issues on MANTIS just doesn't get looked at from one month to the next & the net result is that the timetable writer can't progress forward wit6h the project because he's waiting on issues raised being sorted. You get to the point where you feel is there any point in doing any of this. Since the release of Carlisle on Loader there are 5 projects I've started & not yet finished two of them are on hold because the dev is away & the other 3 I've been switching between them. One user who has assisted greatly in one of my timetables has even purchased a licence so he can test another one of my timetables which is close to being completed for testing, but is for the best part on limbo because of a back log on MANTIS. I've said this before & I'll say it again there's not alot of communication between developers & timetable writers & apart from a handful I('ve woprked with creating timketables for their yet to be released sims everyone else don't seem to give 2 hoots about timetable writers. A sim when created is nothing more than a load of lines with sugnals on them, it's the timetable that brings the sim to life. Writing timetables takes me alot of time as I do it the long way & probably for BR era timetables that's really the only wey, but I'd like to see timetable writers treated to the same degree as developers that would be a step in the right firection.

Log in to reply
Timetable requirements 14/09/2018 at 21:53 #112164
clive
Avatar
2789 posts
58050 in post 112155 said:

Well you say that Geoff but I really think when developers create sims with eras they need to be alot more specific as to what eras(preferably in a date format0 so the timetable writerknows what he can or can't get any with.
More specific, yes, but not necessarily in a date format.

I have a sim with five different layouts. Those five represent five snapshots of the layout at five different times. To the best of my knowledge the significant changes between those snapshots all came in "big bangs", so there were no other layouts between them. I could therefore list the middle three as a date range, but the first one would be "I don't know when until <date>" and the last one is "<date> until last time I looked". So prefer to describe them in terms of features: "platform 0 added", "Ayetown flyover closed". I also might not know the exact dates of changes.

So if you say to me "I want to make a 1989 timetable", I can say that I *think* layout number 2 was in use at the time, but I can't be sure. And it may be that a particular siding you're relying on was actually removed half way through the life of layout 2 rather than, as I thought, as part of the change from layout 1 to layout 2. If so, it may be - as with Superior Sidings in Peterborough - I can add it simply to make a sixth layout. But perhaps there's a reason it's not that easy.

But my main point is that I will never guarantee a date. I'll tell you what features are there and which layout I *think* corresponds to the date you're asking about. But I make no promises.

Log in to reply
The following user said thank you: 58050