Atomic Systems

Hi folks,

Has anyone found how to override the annoying 35 sec dwell time? Reason I am asking is that there are now several routes atleast which only have 10 seconds so there must be some way of overriding this. The routes I know of atleast are the Exeter-Barnstaple and the revamped Liverpool-Manchester. There are I am sure others but these two spring to mind immediately

Any help on this will be greatfully appreciated, I am ok with editing files - just need to know which file and where it is that controls it!

Thanks in advance.....

The only way I know is to make the stops timetabled and specify the duration of the stops that way.

You still get the minimum dwell time though, with the routes mentioned it's set to 10 secs not the 35 so there must be something within one of the route files that sets this, otherwise if it was a ts default it would alleys be the same, no matter what route you drive....

The only thing I've ever done to increase the dwell time as stated above is when you are making the scenario click on the alarm clock symbol and set the dep time to what is req

If 35 seconds is too long to wait, just don't stop at those stations...

Wouldn't a lot depend on the minimum time the animation for the rolling stock's doors to open/close needs though?

35 secs isn't prototypical on a lot of timetables, particularly on suburban lines its down to as little as 20 in some. By the time the doors have closed and interlock obtained, it can be as much as 45 to one minute depending on the stock which makes keeping to a real timetable difficult, if not impossible. The minimum is set by the route at the time, no matter weather it's a scenario or quick drive and doesn't matter what stock you use. This has to be something which is set by the route when it loads locally otherwise all routes would be the same. I've also noticed the with the original Liverpool Manchester route that this is 35 and not 10 so this was changed with the revamped version in some way.

For aslong as I know, since Rail Simulator, the default Passenger stop time has always been a minimum 35secs. I have noticed no difference in the scenario editor. When you create a passenger stop, it says 35 secs, try to change it to under 35secs and it reverts back to 35secs.

There are times when you add an untimetabled passenger stop, and that may only last 10 - 20secs when the scenario is being run but you cannot govern this from within the scenario editor. This again, has been going on since Rail Simulator.

I agree with everything JasVick has said. Also wondering what controls this seemingly core value for a route.

gptech wrote:If 35 seconds is too long to wait, just don't stop at those stations...

Wouldn't a lot depend on the minimum time the animation for the rolling stock's doors to open/close needs though?

Useful bit of information on the animation side of things: The animation for the doors is usually just 30 frames where at frame 0 the doors are closed, and frame 30 the doors are open. This is a 'one way' animation, in that the closing animation is just a reversed version of the opening. The time the animation takes to play, regardless of amount of frames used in 3dsMax, is controlled in the blueprints. The only way I can think to make it work as OP requires, is to define an invisible dummy object/animation for the doors, and then use scripting to call for the 'visible' doors to open/close as and when required. I'm not 100% sure on how scenarios work, but I imagine it'd be possible to replace a 'pick up passengers' with a 'stop at Doleham Platform 12' and have the user operate the doors within the required time.

Ho-hum. The whole scenario station routine really needs a makeover from where it is now.

I started seeing the 10 second stop when the modern Riviera line was introduced. I have no problem with this as such (except when 12 coach trains get such a call at a mainline station perhaps), but for me what was/is more annoying is the propensity for the Dispatcher to start doing as they please in terms of the timetable, ie. disregarding timings entered in the editor and scoring against you when the player has clearly adhered to the timetable - especially on evening and night time scenarios. This issue appeared at the same time as the 10 second stop.

In an on/off route project of mine, I cured this by using older platform overlays - the lofts you apply to make them function and display passengers (the yellow balls). If I used a more modern loft then I saw these problems. If I used older ones (IoW from memory), then all was hunky-dory.

I recall talk of a feature being introduced whereby a route builder could specify the passenger density at a platform as they saw fit (to avoid loads of passengers appearing at 0300 for example). Therefore my money is on summat to do with this and/or these more recent lofts.

So reading what Sir Richard and Sir Richard have said, depending on the route, can I specify in the timetable view of the scenario editor that a stop will last less than 35 secs?

I was running a test scenario on a new route of mine last night and the stops were lasting no more than 10 secs but they were un-timetabled passenger stops (you didn't have a set time to adhere to) although in the timetable view in the scenario editor the time for each stop was 35secs. The platforms I'm using are from the Academy assets

The density setting on the platforms does work. I've used it on my Morecambe route but I can't recall if it makes a difference to none timetabled instructions.

It's the opposite effect that drives me mad. One of my favourite scenario concepts is to force the player to fall behind schedule early on in a long run, and then try to make up time en-route. However if you arrive at a station late, even specifying a dwell time (say 2 mins for an HST) is ignored by the dispatcher which will give the right away after either 10 or 35 seconds depending on the route. Which kind of removes the challenge and seems stupid.

passedcleaner wrote:It's the opposite effect that drives me mad. One of my favourite scenario concepts is to force the player to fall behind schedule early on in a long run, and then try to make up time en-route. However if you arrive at a station late, even specifying a dwell time (say 2 mins for an HST) is ignored by the dispatcher which will give the right away after either 10 or 35 seconds depending on the route. Which kind of removes the challenge and seems stupid.

The issue I allude to above, the dispatcher seems to do as they please ,

I found a way to override the times, took me long enough to work out though.

In the platform bin files (like platform_uk01_90m_left.bin for example) there is a value at the bottom like this stating loading times

<LoadingTimeSeconds d:type="sFloat32" d:alt_encoding="0000000000002440" d:precision="string">0</LoadingTimeSeconds>

0 defaults to 35 so I changed the value to 10 and it works way nicer for suburban and DOO stops, 10 is also the value Manchester - Liverpool and a few other routes uses.

passedcleaner wrote:It's the opposite effect that drives me mad. One of my favourite scenario concepts is to force the player to fall behind schedule early on in a long run, and then try to make up time en-route. However if you arrive at a station late, even specifying a dwell time (say 2 mins for an HST) is ignored by the dispatcher which will give the right away after either 10 or 35 seconds depending on the route. Which kind of removes the challenge and seems stupid.

I was playing a scenario on the South London Network which was a 455 West Croydon to London Bridge via Stretham and Tulse Hill.
But you cannot keep time and get penalised - I don't have the points scoring thing - but it says you were late due to no fault of yours.

So I went it to the editor and the times were in Red which I think means it's wrong.
I removed the 'timed stop' tick and let it recalculate. Ran the modified scenario and completed it without problems - even with a 442

Peter