In-game clock running fast

[filberttrains]

Morning all,

I've been working on some High Speed scenarios for Danny's Victoria & St Pancras to Faversham 2016 route and I've come across a strange problem. The in-game clock seems to run fast until it's about 30 seconds ahead. The ETA display is accurate and I get a green tick at stations which, according to the clock, I've arrived at late. So it's definitely the clock that's wrong and not the ETA display.

I'm sure I've experienced the opposite (the clock running slow) in the past when I've had poor performance on certain routes, but I've never seen it this way round before.

Any suggestions as to what's going on and how/if I might be able fix it? And would anyone like to test the scenarios to see if it's just my computer it happens on?

Thanks in advance,
Filbert

[filberttrains]

PS: I realise the obvious place for this would be the scenario creation forum, but I wanted a broad audience and figured this might have been experienced by people who don't write scenarios too.

[smarty2]

Isn't TS world time faster anyway? Pretty sure I read that somewhere a long time ago?

[gptech]

Filbert, what are basing the conclusion that the clock is running fast on?

[filberttrains]

Filbert, what are basing the conclusion that the clock is running fast on?

I'll give you an example. I set off from, say, Faversham at 09:26:00. I'm due to arrive at Sittingbourne at 09:34:00. As I stop at the platform at Sittingbourne, the game clock shows 09:34:35, but the ETA shows as 09:34:05 and stays there once I'm stationary. This, and the fact that I don't get a 'red cross' for arriving late, even when the game clock says I have, leads me to believe that the 'actual' time is 09:34:05. The difference between the ETA as I arrive and what the game clock shows gets longer and longer until it settles at between 30 and 40 seconds.

[karma99]

Could this be the difference between the listed arrival time which only shows hours and minutes and the actual time set in the scenario which also included seconds?
For example, if you set the arrival as 10:30:59 I think it will show in the HUD as 10:30.
To add to the confusion the guess'timated arrival time does include seconds

[gptech]

Right, so you don't actually know whether a second of in game time is equal to a second of real time--you're going just by a discrepancy between the two timings on the screen.
Remember what the E in ETA stands for, it isn't a 'carved in stone' time. You can be late at stops without incurring a penalty; what the latitude is and where it's determined I couldn't say for sure, it could be route related or scenario related.

Is it in any way stopping you playing and enjoying the scenario?---I'd run it myself but don't have the merged route.

[rfletcher72]

This is something I have been seeing for some time in the game, ever since the release of Riviera.

Early morning and evening scenarios seems particularly susceptible to this, though I have seen it also in daytime scenarios on CML. For example I was running a home brew career scenario on Wherry lines the other night, and despite arriving at stations bang on schedule - as the scenario progressed, I was increasingly penalised points wise for lateness. When I compared my log against the timings the game reported, the game clock was ahead by a few seconds as I left Norwich and more than three minutes ahead by the time I got to Lowestoft. Early appearance of AI is also a feature.

My thoughts are that this is linked in some way to the feature that was introduced that allows route builders to specify the density of people on platforms depending on what time of day it is. I tested this out on a clone of Riveria, by swapping these platforms lofts out for some older ones (IoW I think). I didn't generate any platforms loadings on these, and on running a scenario the fast clock had vanished.

I did flag this up with Support and their advice was to use career scenarios. Sadly in my experience, these are affected also.

[gptech]

I didn't generate any platforms loadings on these, and on running a scenario the fast clock had vanished.

That brings in the possibility of it being related to loading instructions rather than being platform asset related. A quick test would be to try a new scenario with fewer stops, time it as it's being played and see if there's a definite point where/if (still unproven) the game speeds up.

[ttjph]

I first thought this was going to be a 14 fps 'collar' issue, but that's clearly not the case now I've read the thread!

I too have experienced odd behaviour with target times vs actual: specifically, as rfletcher72 has found, I've been penalised for late arrival even though I'm on time, or slightly early, comparing the displayed clock to the HUD target arrival time (including seconds).

I had also wondered about the ETA being generally a very poor E; but I'd just put that down to poor choice of the 'effort' parameter in the scenario instruction, and poor prediction of player braking, and hadn't paid much attention.

Penalties when you appear to have arrived on time, however, are very annoying!

I think I can specifically point to The Up Boat Train Part 3 on WCMLoS for this: I was recently playing this for 1000 points (liberal use of sanders on departure required!), and recall noting that I actually needed to be somewhat early at the final stop to avoid a penalty. Riviera 50s (my other current favourite route) is definitely another culprit, though I can't name a specific scenario.

And these are career scenarios, so the advice given to rfletcher by Support is clearly as much use as ever.

[gptech]

recall noting that I actually needed to be somewhat early at the final stop to avoid a penalty

Would/could that be the cumulative effect of having to be early at intermediate stops? Whilst there's definitely a consensus that there's an issue with how the ETA and displayed time correspond to each other nobody posting in here has compared elapsed time in the game against real world time.

[gptech]

Just ran a career scenario on Chatham; "Going back in time" from the BR Blue pack--class 421 as driven stock, using the most advanced time recording equipment I have...

the kitchen clock, with a new battery fitted.

I loaded the scenario, and immediately pressed the "Pause" key on the keyboard to freeze it at 12:11:00. Once the kitchen clock got round to 17:11:00 the "pause" key was once again pressed to start *properly*.

First stop was Swanley, booked at 12:16:20. Actual time of arrival was 12:16:11 in game, ETA in game had settled at 12:16:13 but 17:16:15 by the kitchen clock, indicating that in this instance the game was actually running slow (OK, we could ignore that---the measuring system ain't accurate)

Next stop, St. Mary Cray, booked at 12:20:20, actual in game 12:20:55, ETA in game 12:20:47, kitchen clock 12:21:05

Once again, indicating the game is slower than real time---now by 10 seconds, so is that too much to simply ignore as "observational error"?

If nothing else it indicates that going by the ETA displayed is not reliable---it's a guess at any given moment by the game going on the speed at the time of measurement, possibly factoring in braking time (% of line speed as defined in the scenario?)-- and that the in game clock isn't a Swiss watch.

Granted, that's only one scenario (or part of) on one particular route so if anybody else has a kitchen clock they can purloin/borrow (and a new battery) would they care to test something else?

[filberttrains]

Right, so you don't actually know whether a second of in game time is equal to a second of real time

I do now - I've used a stopwatch to compare the two, and the in-game time is definitely running faster than real world time.

This is something I have been seeing for some time in the game, ever since the release of Riviera.

Early morning and evening scenarios seems particularly susceptible to this

Firstly, I'm very glad I'm not alone! Secondly, my scenarios are both set in the evening, which is interesting.

Is it in any way stopping you playing and enjoying the scenario?

Yes, I'm afraid it is. I find the clock being fast totally detracts from the realism and spoils my enjoyment of a scenario that, if I do say so myself, is otherwise pretty bloomin' good! It makes it a lot harder to work out whether you're running early, late, or on time. And arriving at every station late, according to the in-game clock, even though you're actually on time or early, is irritating and spoils the realism massively.

A quick test would be to try a new scenario with fewer stops, time it as it's being played and see if there's a definite point where/if (still unproven) the game speeds up.

It begins to happen immediately on setting off, according to my tests.

I'm glad you're flagged it to support, Richard. I'll do the same, not that I hold out much hope for a resolution. In the meantime, do any of you technically-minded sorts (Gary...) have any ideas of things to try?

Cheers,
Filbert

[filberttrains]

if anybody else has a kitchen clock they can purloin/borrow (and a new battery) would they care to test something else?

I started typing my reply above before you posted yours. Yes, I'll give one of my scenarios another go and take down accurate times from a stopwatch.

[gptech]

I'll give one of my scenarios another go

It would be useful if you measured one set in the evening or morning---no need to be all that accurate, for now all we need to know is if there's a trend, but as the one I had a quick test with is set around midday we can call it 'the middle ground' so as well as needing more testing around that time we need tests at other times. The more information we could pass on to DTG the more likely it is that theyll do anything about it---as unpalatable as it is to some, the users have to play their part in smoothing out the rough bits of the game.