As I haven't posted this issue here yet, I think I should. So, in-game there are two clocks. Timers, if you like. One of them is visible on the HUD, counting each second. The same value is displayed by in-world clocks. The other is only visible implicitly, showing the ETA. It's exact when you are just stopping for a destination. I don't know which one the AI is following, but based on some sillies, I guess it's the first. Sometimes they are fairly together, other times they deviate a lot. Sherman Hill, Midnight Magnet. Scenario starts at 22:30. I think these are enough. Steady 60 fps. 1) Here you can see that I've stopped at 00:21:40 but I will arrive at 00:26:57. No, just 5% off. 2) The scenario completely finished at 00:21:59, overall 1:51:59 duration, but... 3) ... it took me 1:57:21 to do it. The point is obvious, I'd prefer if this would be fixed.
if you look at the first one it shows you stopped at 00.21 as you said but the game expects you to stop at a fixed point 0.07 miles from where you actually stopped. If you had kept going until the stopping point was 0.00 it would have been 00.27
I appreciate the bump I'm sure you noticed that when you stop on the objective, once you stop it changes to the moment you stopped. So it usually goes back a few seconds, but it can also go up if you slipped forward. (It doesn't take 5 minutes to move 0.07 miles, and also wouldn't explain why the score screen shows more time. It is ETA + stopping time.) By the way, just finished Thunderheads with a 2 minute discrepancy (in 91/93 minutes), and on the score it correlated with the ETA as usual.
The ETA is an estimate based on your current distance to the END of the prescribed stopping place based on your current speed and accelleration So if you stop 100m closer than the end of the destination point the dispatcher will estimate your approach at 1mph, thus it seeming longer than you may think (because you would probably accellerate to 5mph, thus reducing the time) Don't forget the dispatcher is very literal
No, no, no and no. I explained in my previous post. Yes, it calculates to the end, but as soon as you stop, it resets. Do I really need to make a two hour long video of this? Just glare at the ETA as you stop early literally anywhere. Goes up, then jumps back. Just go and watch any random stopping service video on Youtube, or do it yourself. The last two pictures are literal proof. How could I drive 117 minutes in 112 minutes? The denial is real hard.
Just had a look at the remainder, only thing I can think of is that although you get dropped in the cab at 22:30 the start time for the dispatcher may be different (often a few minutes behind) so I would look at that also
I have noticed, only recently, a few times now that the clock and the ETA clock are not always in synch. It seems prevalent on the North Wales Coast line on my set-up, I did read somewhere that it might be a memory/frame rate issue. It will often say I have arrived at a station on time or thereabouts but the clock is showing a time a few minutes ahead of that.
I haven't experienced that, it would be level 2 confusing This whole thing is fairly easy to test with a stopping service. Also. I didn't mean to lash out too hard on you. In the past 6 years I have noted a number of issues, usually there is someone coming back with "can't be true, isn't true, you are lying, you are wrong". So I create a video explicitly proving them wrong, the only possible reaction being "umm". (Say, Sherman Hill.) Then a couple weeks later someone reports the same problem, and the same person responds with "can't be true, isn't true, you are lying, you are wrong". There was a veteran UK driver who said you never push consists. I mean... shunting? HST? Class 91? Hello? Also, in other news, the Earth is flat, I know. So it's nothing personal, I just find it hard to deal with legit scepticism and trying to be helpful. :hug: Sounds like the same, except for me it's never forward in time. I mean, could be. I was free roaming the GWML when I noticed that looking at the sun, the clock would go way faster than looking away from the sun. Or the other way around. 3 years ago, long time forgotten.
Simple enough to check. Go into Build from the home screen, then into scenario tab at the top, then scroll down to the route and find the right scenario, click Edit (bottom right) When it opens, use top right pop-out and find the one which looks like a clock (red and white), click this. From the service list find the player train (will end in (P)) and click it. The top instruction will be the start time of the SERVICE which may be opposed to the start time of the SCENARIO, and that's what I was referring to in my second comment You don't know me, I don't know you so such comment bounces off. As in I don't know you well enough to care overmuch
triznya.andras I raised this on the forums in around 2014 as I noticed a similar discrepancy to that reported by you. There was no solution at that time, but apparently the algorithm to set the ETA (if set in the scenario that way) was based on the theoretical line speeds you were to encounter in the scenario. So if you travelled slower or faster that was expected then the ETA was different and maybe not always updated. From the scenario database on Google A timetabled instruction lists both arrival and departure times. These times will remain fixed and not update. Non-timetabled instructions will periodically update the arrival and departure times based on current performance. I have also noted when playing some scenarios the ETA does not update as you would expect it to – I put that down to the scenario creator. You get a similar issue in some long scenarios where the mileage to home is displayed incorrectly in the F4 HUD and doesn't change until you get quite close to the destination.
I think I know about the very last one. It's possible to add instructions but opt to hide them from the screen. I don't know specifics, but the few times I encountered what you described was when I got a popup message or a hidden stop instruction. Koblenz-Trier has one such scenario, having to stop in a siding, but I was always slow enough to have a clear aspect. Figured I should stop anyway. Then again, I could be wrong.
This is normally a hidden go via. The dispatcher glitches and doesn't show you the "true distance" to the next active point, but the distance from the go via to the active point. Doesn't seem to do the same with waypoints though
Just want to close / reflect this topic with having the less usual scenario recorded, running GWD320, starting at 8:00. In this first shot you can see that ETA is roughly one minute behind (usually it's ahead). Traveling forward at 45mph makes it pretty clear. 2021-02-14 21-04-58 By the next objective the discrepancy has lessened, but still there. 2021-02-14 21-18-56 Note the actual difference between the screenshots reflected in the filenames, 0:13:58. (I didn't pause.) The ETA has increased by 0:14:12, a couple seconds split between me going slower (takes longer to traverse objective, 0.13 miles both) and the clock running faster. The world clock has only increased by 0:13:35.
I know I said "close" but I just came across a situation which is fairly obvious to investigate. I created a Free Roam for simonmd's BR's ECML, albeit the intention is more of a Timetabled scenario. 43 to 55 to 37. I noticed that the clocks divert about 2.5 minutes every hour, the big / world clock being slower. You could argue it's just a silly mishap, but it's also restored from the save. So it is very much in the design. I am attaching the save around 3.5 hours. Full extract path: ...\Routes\a0143040-1ef1-4131-95bf-22ba607e430d\Scenarios\86a0d03d-8b76-405f-a93e-449fa50461d8
There was a small reference earlier to system time - I would expect that, if you have a system which is either GPU or CPU challenged by this sim, then you may be running at less than 30 fps. If that is the case, especially if significantly less, then clock time, depending on programming, will be retarded.
