Never-ending crew change?

The solution is not to edit the timetables, but to wait for a core code fix.

#18602 applies.

I don't basically disagree but if the problem goes on and on uncorrected then work arounds will be found and people will us them.

So just what are the timetable writers supposed to do?

Its no good producing timetables using the present crew change system, since it doesn't work properly as evidenced by this whole thread.

Do we just abandon writing and releasing timetables until the matter is fixed which may be this week, next week next year or whenever - we don't know? I don't think that would be good for Simsig, do you?

....or do we continue to write timetables using a work around that works.

Perhaps the poor relations that are the timetable writers could have some guidance please on what we should be doing rather than criticise us for making it work.

Vince.

VInce in post 103462 said:

I don't basically disagree but if the problem goes on and on uncorrected then work arounds will be found and people will us them.

So just what are the timetable writers supposed to do?

Its no good producing timetables using the present crew change system, since it doesn't work properly as evidenced by this whole thread.

Do we just abandon writing and releasing timetables until the matter is fixed which may be this week, next week next year or whenever - we don't know? I don't think that would be good for Simsig, do you?

....or do we continue to write timetables using a work around that works.

Perhaps the poor relations that are the timetable writers could have some guidance please on what we should be doing rather than criticise us for making it work.

Vince.

I don't mean to criticise, I work very closely with the timetable writers for my simulations, and I don't think either of them consider them poor relations!

My point is creating extra work doing, then undoing, and issues with version control is not worth it in the long run.

From what I can tell the feature was broken between 4.6.4 and 4.6.5, given that I'd expect it can be sorted ahead of the other changes to crew changes. Sometimes it's best to wait a couple of weeks and see if a fix is forthcoming.

I don't agree. it didn't work properly in 4.6.4 - we could never get it to work if trains were early or late and if they were on time we couldn't get them to leave on time. I used it when Lyn Greenwood and I first updated Peter's 1977 Peterborough Friday timetable and we spent weeks and weeks testing various scenarios trying to make it work. Somewhere in the archives there are threads we put out at the time.

Still, we've thrashed this one to death - again. I certainly won't be doing any more work on the two timetables I'm dealing with at the moment and whether I can raise the enthusiasm to finish them will depend on how long it takes for this issue to be fixed.

I won't be holding my breath.

Vince

Thanks Albert. I was using the 1978TT.

Andy174 in post 103450 said:

Thanks Albert. I was using the 1978TT.

Given it takes some time to fix the issue - and so far I haven't found a 4.6.4 loader for download - I have made a temporary fix to the timetable which I attach here with permission of the TT's author.

It's good to know this is going to be fixed in core code, but since it takes a while I also think it would be nice to have a few working TT's to play Oxford meanwhile.

I am working on this issue - in fact started last night. So please just give me a few days to work out what happened, to fix it, and get it tested before release.

Version 4.6.5.3 of the Loader seems to have fixed the long-standing problems with Crew Changes. Trains that have a Train-type crew-change dwell time now behave themselves and depart on time following the change of crew, whereas they always used to depart at 'scheduled departure time + crew-change dwell time' before v4.6.5 of the Loader was released, which caused them to never depart at all!

However, the F2 list shows the scheduled departure time for the expected crew-change time, which suggests the dwell time has been ignored. Also the message window shows 'XXXX starting the crew change' as soon as the train has arrived, which in my tests is before the new crew arrive. Maybe this is correct, but I'm a bit dubious about that.

I've attached a .zip file with the message log and several F2 lists for the tests that I did. 0Z01 & 0Z02 have a 2 minute Train-type crew-change dwell time and 0Z03 has a 2 minute Location dwell time with no crew-change dwell time.

I hope the attachments are useful, Geoff.

Geoff,

Now you are working on an interim fix to the Crew-change Dwell-time issue, do you also intend to fix the long-standing problem with the Train-type Station Dwell-time (both of them) so that the Dwell-time is measured from the Actual Arrival time of the train rather than from the time its last Activity completes?

I'm sure there would be some very happy users if it could be done now rather than when the mega-changes to the Dwell-time logic are agreed and implemented.