[solved] Timetable Scenario Class - And Issues With Eta

Not so in the UK - we’ve gone the other way and sectional timings are quite padded compared to the actual capability of the train… but this is mainly because the capability of the driver is increasingly constrained by defensive driving techniques, particularly with regards to braking into stations / approaching adverse signal aspects.

 

Have anyone tried to get in touch with AP about this? AFAIK Armstrong Powerhouse always use Timetabled scenarios with their products

 

It is not an issue per se, if the scenarios work all is fine. (Checking some of my AP scenarios, they're all Standard though).

 

Putting timetabled stops into a standard scenario is not the same as using the now defunct timetable category.

 

Pretty certain the AP stuff I've installed have their scenarios listed under "Timetabled" in the editor

 

I just spotted your edit now.
I have never failed a scenario because I was early. It just extends the stop.
There are scenarios with forgiving intermediate objectives, but a strict final one - only doable if you built a leeway. Obviously these have to be Go Via instructions or else you'll be held (by default).

Your theory is fairly easy to test. Just create stopping services and drive them according to the visible clock once, ETA next. Observe the ETA. It is expected to fail when ETA is past arrival / departure (not entirely clear), succeed otherwise. With long scenarios the deviation can grow big enough to suggest you're early and late. Plus of course your pic where the big clock ran ahead.

For the record, the 442 scenarios on München-Garmisch have a very aggressive ETA, expecting nearly 200% but the timetable is attainable. Some other routes guesstimate I'll be late, but I keep gaining time. My own scenarios with the default 75% are all over the place, usually it expects better acceleration but then once I surpass 75% of track speed I gain it back. I did fail my short stopping scenario with the Class 37 on ECMLS due to that. In similar non-timetabled scenarios station stops are cut short, suggesting I'm running late. Donner Pass 1-2a-2b-3a-3b are curious because even when running at track speed, the ETA increases, suggesting you're slow. 4 (winter checkup) is the other way around, however.

My clock deviation is very similar per route, so I don't think the timetable affects it. I simply think that the game uses two clocks in this confusing way. ETA is a sum of the hidden current time and the estimated duration to get to the objective. Once you stop for the objective, the latter is zero, so it exposes the hidden current time. The estimated duration itself is complicated, it certainly uses the provided performance percentage but it also accounts for traffic. I've learned that when ETA doesn't move, I'll be held. When it jumps, I'll get a clear signal soon. I can even hold back until it starts moving. (Technically, holding back and crossing the signal at track speed exactly when it turns clear is the earliest estimated time of arrival. Waiting patiently instead means you'll have to accelerate after, thus it takes longer. Hence the ETA goes up while waiting for the clear.)

 

I have failed being on time on Brennitzer Linienstern School Train, that's the issue I'm associating with 100% performance instruction AND manually adjusted arrival time - a specific case.

 

Do you have a screenie perchance? Expected Arrival (F1), Expected Departure (F1) and Estimated Arrival (HUD) while stopped.
I did delay arrival times to fix overly strict scenarios, to enable completing it successfully. Those were 75% but too strict nevertheless, same story as yours.
Now, let me imitate some work...

 

No screenie, but the ETA went crazy requiring me to be three minutes earlier than F1. Unfortunately this happens at the end of the scenario.

Like I said, most scenarios work fine, and success/failure is based on your actual time arriving.

It's just finding out what makes the few specific scenarios behave weirdly, for "Journey through the Mist" I think what I've stated in the Theory is actually what happens, displaying the booked time the scenario author set but using an internal time due to the error, which you could find by analyzing the scenario.bin. And converting the seconds stored in each instruction to HH:MM:SS.

 

My most recent experience was with the standard scenarios in Victory Works' Manor pack, which I played and wasn't penalised for arriving late at timetabled objectives. They don't seem to have any scripts beyond those for the starting camera...

 

Can you open that in the editor and see if the timetable shows any red instructions?

 

There are no red instructions.

 

AI traffic running before you? Yellows?

 

Don't think so IIRC. How is this relevant to the game failing you for arriving late?

 

Because I am trying to find out why it punishes you on Norfolk Southern e.g., having impossible schedule, but not on London-Faversham, where AI is preventing you from making it in time.

 

Remember that on your screenshot you were on time according to the ETA, six seconds early to be exact.
It's all fine, trying to discover and understand. My theory (of two, independent clocks) sounds so stupid that it's hard to accept.
That's why I asked a screenie from Tom as well.
I have the same in career and free roam, so I'm very convinced. But! If one programmer discovers and fixes it, whatever the reason, that would be the ultimate best.
My theory has no fancy about it. I simply claim that the big clock runs at a slightly different pace from the hidden one, due to unknown conditions but likely related to fps, stutters and such. And for simulation / timetabling purposes, the internal one seems to be the correct one, its behavior following scenario design (signals affecting timings) quote precisely and reliably, e.g. your ETA doesn't change when approaching a wait and it's the same across multiple runs.

 

What the ETA says should have no effect - the code should only compare real arrival time vs scheduled time.

That "inpedendent clock" apparently starts doing its own thing when the conditions I stated before are met. (AI traffic and booked arrival time not matching performance percentage.)

So my first careful conclusion would be:

Create a PickUp instruction. Tick the "Clock" symbol. If you use this time, you won't notice a "second clock".

Now if you want to have the player arrive later, don't just manually enter a later arrival time, instead lower the percentage until the time matches, making only small adjustments to seconds.

Same goes for earlier - make sure the percentage is set accordingly.

-> If the game calculates your stop being much earlier/later than by the TIME set, but due to the PERCENTAGE - the clocks start to deviate. You can see this difference if you untick the clock symbol in scenario editor and reclick it again. Now the editor puts in the time it calculates.

Easier said:

ADJUST PERFORMANCE NOT TIME MANUALLY!

But as this "bug" allows being late in the case of the "Journey through the Mist", it's probably OK but confusing nevertheless.

I will now create a simple demo scenario to test this.

 

It doesn't.
What I'm saying is that it shows the internal clock that has effect.
ETA is simply the (only) way to see its value (when stopping for an objective). I explained above, ETA equals Current Time plus Delta (time to reach objective), when stopping Delta is zero, therefore ETA equals Current Time. Pure logic and a simple one.

I really don't need to argue about it, it merely showcases the confusion well for the devs. It would be equally bad if it would be the other way around: stupid game thinks I will be here in 3 minutes, but I'm here already! Doh! (Basically, all you say.) Plus, it would be really hard to stay on time when it runs 30% faster In this sense my 57 minutes per hour is helpful.
Just hoping to see it fixed. In current terminology, the game needs only one ICurrentTime implementation and instance, and likely one that is incremented / updated by the simulation.

 

Testing. First using calculated arrival by only clicking the clock symbol. No adjustments to time.



Stopping on time, all well.

 

Next test: Adjust Performance to 100% - not updating the times by un- and reticking the clock)



Aiming to be exactly on time:

FAILED!

 

So there you go. That's the issue solved. If the time set in the arrival field deviates from the time based on the performance, you'll experience the "second clock" phenomenon.

We can reveal the time the game expects you if we untick the clock symbol, and tick it again - magic resolved!




A full minute earlier! That explains why I failed. What's in the "time" field is of no matter for the player - ironically it is what gets displayed as scheduled time. The more you change it, the more the ETA deviates, as the player is always expected at the initially calculated performance based time (which is not being displayed to him - only the value in the arrival and departure fields)

(The case when you're late but successful, is the opposite way: Display time is earlier than performance time)

atomicdanny This might be of interest for you.

Final conclusion: Make sure that the arrival time you've set matches the performance percentage. Adjust performance before making changes to arrival time, and adjust these in small values only to have the player being able to rely on the clock.

Case closed for me

 

In your first set, the big clock shows 17:05:54 but the departure is at 17:06, so the big clock was late, it should be 17:06:23 plus the 9mph.

In your second set, your stop shows at 17:06:17 which is late as the objective was 17:05:48 and it's valid until the end of the minute.
Given you are just about stationary at 17:05:50 you were likely a bit later than during the first run.
Basically it replicates what I did during Chop and Change. I stuck to the big clock but it was actually slow and I was about a minute late with the internal clock. If you drive a bit faster, making sure ETA doesn't slide past 17:05:59 you should be good.
Given the deviation on my PC, if I stick to the big clock I'm always late.

But really, just tag some dev. And stick to the ETA. However much you don't like the idea

 

Have you seen that I've explained why it works like that? The only clock that the game is using is based on the performance percentage. Thanks for telling me how to drive - the point of this thread is not managing to succeed in a scenario, but showing why the game thinks you are late or early when you are on time. I have deliberately slowed down on the second run, to be exactly on time (17:05:48) to pinpoint the issue. On the first shot I arrived a bit to early, yeah, but it works when arriving at booked time also. It seems only in Career Mode you're being held (correctly) until departure time.

So it's really all about adjusting percentage to get the wanted arrival times. And I think many scenarios authors know this that manually adjusting times leads to this effect - that's why most timings seem to be "unrealistic", not being rounded to the full minute or 30 seconds.

This might be interesting to know for scenario authors. I saw many complaints on Steam forums, being penalized whilst being on time. Here's why

 

Will setting the arrival time to a time after the expected time based on performance cause issues?

 

Yes - if the difference is great enough, the player sticking to his timetable in good faith will fail, because he's expected by the game to be on the earlier calculated time, no matter what you set in the Arrival Time field, which is just what will appear in F1 / Scheduled Arrival Time in the HUD. That's what I've shown on the second run of my test scenario.

If you'd set the performance to 25% but keep the 17:05:48 time, you'd be allowed to arrive 9 minutes later, without knowing why when you play it. But you'd then be held at the station for a long long time, as these clock differences are adding up, so keep your adjusted times close to the ones the editor is giving to you.

Note: Career can act differently (and probably more realistic than a Standard scenario), not fully explored using test scenarios as of now.

 

It would hold you past the set departure time?

 

That's what happens on "Journey through the Mist" exactly.

 

Yes, I have also noticed that I have been held past a set departure time. Once by a couple of minutes, which was mysterious.

Are you saying that the problem is when a performance indicator is set AFTER a time is adjusted? As in, always set the arrival time manually AFTER setting performance?

 

No, I'm saying you should use the performance to get the desired arrival time, then only adjust that time slightly (e.g. setting a percentage of 85 will result in the dispatched time of 10:58:53, you would then adjust the time manually to 10:59:00 for example, as the game will expect the player at exactly 10:58:53 no matter what time you put into the field. It's just a visual number, and not being processed.)

 

Oh, that's a nuisance.