[solved] Timetable Scenario Class - And Issues With Eta

Years ago DTG Matt stated on his Youtube channel that it is only there for compatibility with old scenarios and should not be used for creating new ones. (If I manage to find the video, I'll post the link. Saw it many moons ago but that was sticking in my head - must of been one of the scenario editor tutorials of his.)

In fact in can behave weirdly, I've just managed to finish the "1. School Train" timetabled scenario on Brennitzer Linienstern after failing at the penultimate stop many times, though being exactly on time or even earlier - much to my distress and anger, because I couldn't figure out what I was doing wrong.

What happens is that the ETA clock must be in sync with the actual arrival time - for example if a stop requires you to be at the station at 15:00, and you are there at 14:49:50 but the ETA shows 15:02 - you'll fail. The ETA clock gets out of sync after a penalty brake for example.

There is no need ever to use this scenario class - use Standard or Career instead.

The behavior of the ETA clock in this mode explains many reports of scenarios failing, getting an X at stops for no apparent reason. Timetabled scenarios appear under the "Standard" tab, going to Build>Scenario route reveals the Timetabled class type.

Edit: Found it.

 

Will they work ok if you change them in TSTools to Standards?

 

Change them to Standard either with Notepad++ or TSTools as Matt explained. They'll work

If you don't see changes after editing them and they still appear under Build>Scenario>Timetabled, deleting Content\SDBCache.bin will update them.

 

Good advice in general.

Changing - It depends on how the scenario works.
In case you wait at a station and pick a train, standard will be dysfunctional. Free fly scenario. Same about changing.
In many others, like Koblenz-Trier, simply editing the appropriate tag in ScenarioProperties.xml was sufficient.

The ETA clock issue is something I noticed across all game modes. I was ignored or called a delusional liar.
Some scenarios include hidden stop at instructions. I was caught by one on Koblenz-Trier, I was routed through a siding and failed, so figured I should have been more aggressive and then held back. Stopped, success. Those are also exposed by the distance counter not moving (and showing something inappropriate) until passing the stopping point. (Not your issue but it could result in the same puzzle.)

 

Changing type is referring only to eTimetableScenarioClass to eStandardScenarioClass here, not FreeRoam. You can then ignore the ETA, stop will be ok if you arrive on time.

 

I think I have to clarify.

Search for this (E18) scenario. 44f7be1f-559a-48e8-91f7-bf10d521fcba (Hagen Siegen, route #4)
Title: Zugübernahme = Train Takeover

There is no player train at the beginning. You wait at a platform for your train, then click on it to take over. AI continues if you don't.
If you convert that to a standard scenario, I suppose the only thing you can do is fly around.
There is a similar Class 47 scenario with TEA wagons on GWML.
The workaround is to set these trains as player trains. Or starting from the editor.
There are many more, pasting a table below - the bullet points. Some of them even say pick any train you fancy - yard work I recall.

The only problem I experienced with timetabled scenarios specifically is that they don't have the hand cursor like free roam. There is also a chance to click on a train that is supposed to be AI instead (I did, out of curiosity, works fine).

The ETA issue is absolutely there in Standard and Career scenarios. I have never added timed objectives in Free Roams, but I see no reason why would it work differently. Objectives are measured against the ETA - if it diverges, you have to pay attention.

• Sunset Shift Western Lines of Scotland / Black 5
• Last Train to Gallitzin Horseshoe Curve / Centipede
• Your Birthday, Your Choice Horseshoe Curve / Centipede
• Loading in Oro Grande Cajon Pass / GE 44
• Unload Auxiliary Cajon Pass / GE 44
• Tasks in San Bernardino Cajon Pass / GE 44
• [37+TEA] Repairs required Hedborough North
• [37+TEA] Tea or Fuel? Hedborough North
• [47+MJA] All scattered Hedborough North
• Thorn Delivery Cajon Pass / GE 44
• 1 - S6 Morning rush hour Köln-Düsseldorf
• 2 - S6 Evening Köln-Düsseldorf
• vR 03 Pack - SC02 - RE5 Köln-Düsseldorf Köln-Düsseldorf
• vR 03 Pack - SC03 - Nach Köln mit Umleitung Köln-Düsseldorf
• vR 03 Pack - SC04 - Ersatzleistung in Düsseldorf Köln-Düsseldorf
• vR 03 Pack - SC05 - Die Helfende Hand Köln-Düsseldorf
• vT 0.1 Streckeneinweisung Berlin-Wittenberg
• vT 0.2 Homerun Berlin-Wittenberg
• vT 0.3 Frühberufsverkehr Berlin-Wittenberg
• vT 0.4 Fluggäste befördern Berlin-Wittenberg
• vT 0.4b Fluggäste zurück befördern Berlin-Wittenberg
• vT 0.5 Eissturm Berlin-Wittenberg
• vT 0.8 Reise mit Hindernissen Berlin-Wittenberg
• vT 0.9 Nachtzug Berlin-Wittenberg

 

Of course you should only change to Standard if it isn't of that freeroaming type (which I've not seen yet ).

The ETA works like this normally. It is based on your deviation from the given performance of the instruction (default 75%). If you're slower, ETA rises, if you're speeding, it falls. If a signal is red ahead, it will stay the same and only begin updating once the signal is clear (That's a good indicator of what's ahead in Career scenarios btw. - if the time won't change no matter what speed you're at, be sure to hit a red. So begin slowing down early - when ETA starts counting up, the route is clear).

Nothing wrong with all this, the ETA is just an indicator for you if you're on time. But in Timetabled mode, even if you're early - but ETA shows late - you'll fail. This has not occured to me in a standard scenario.

Btw, S6 Morning Rush Hour - this was one of the first scenarios I ever played (one of the first DLC I purchased was Cologne-Dusseldorf). Slam the throttle - slam the brakes - drive like Red Five Mansell .... I really prefer Career scenarios with scoring disabled as you get a checkmark even when late. Standard is unforgiving

Anyway, my thread was mainly about not creating new scenarios of this relic type (Workshop won't accept them anyway). In Brennitzer Linienstern, they're all like that, so I quickly adjusted all ScenarioProperties.xmls.

Andras, can you name me a specific Career or Standard scenario that would show this bug - stopping on time, still failing the task? (Not those with hidden GoVias and a minimum speed to succeed, that's another thing and mostly a testing leftover - forgetting to set GoVia Speed to 1mph for player service.)

 

Your thread is completely valid, I only wanted to dissect the why. I can also try to be early, although typically difficult.
The old PDL was my first such experience.
I can try to record a video. Now that I have Win10, it comes with Win-G
DTG could simply remove the option from new scenario creation.

 

Why - as Matt explained it was planned by Kuju to be like the TSW timetable, but the code never made into to the game.

I mean they made sure that you can't upload them to Workshop because of the issues they bring. Removing the option, well, the RelayScenario is also available. I think they went for full Kuju RS compatibility.

Its taken them already three years and we still have the obsolete TS 2019 setup_audio.bat that irreversibly replaces OpenAL dlls, and even TrainSim-Steve warned not to use it since the 64bit dll is supplied in the main folder already (and gets overwritten with older dlls by running the .bat)

And yeah, I could record videos now too that I'm on 10. Considered making small modding tutorials on YT... but my voice sucks. Too much smokes

 

Just be aware that many of the AP scenarios were run in 'timetable mode' and even if you convert them to Standard with TS Tools they will revert back after any update from AP. Personally, I haven't had any issues running AP scenarios in either timetable mode or standard mode.

 

I am aware

Just forwarding Matt's message. And if you have a scenario you can't complete due to the TT ETA issue having an effect on the outcome, use this method. But if it works, leave it.

 

Did the recording. Here are two screenshots.
The recording is fairly boring, but I can upload it as an unlisted video if you wish (e.g. you can force someone's hands with it, I mean it's valuable, convincing proof).
This is how I drove originally, this being one of my early routes (have screenshots from 2016-01-29). This scenario starts with a bunch of yellows, and I noticed the leeway in the timetable, so I drove slow (about half track speed, averages out at 40-42 mph).

1) Made sure to arrive and open doors at this objective precisely "on time". According to ETA I'm 40 (41) seconds past departure, though.

2) Here you can see that loading finished by 14:00:01 and yet the objective is failed.

 

Just name the scenario, it's hard to make out anything on these shots. I can see it is Chop and Change, that's PDL right? Yes it is.

I think the issue with this is that all performance fields are set to 100% (I always choose default 75% for the player, unless it needs adjusting to have a train pass you.)

I see I have played that one successfully, but will eventually do a rerun.

 

Yes, it's that one. Perfectly doable, if you make sure you meet the ETA.
The whole exercise was to show that once the two clocks deviate enough for you to fail the ETA, you fail, regardless of what the other clock shows. That other clock is just decoration. For some reason they deviate a lot on my PC on most routes. 2-3 minutes per hour.
It does the same in Career, it's just timeliness penalty instead.
Case in point, it's universal behavior, both the clock and the binary behavior of timed objectives in non-career.

 

I'll verify that on the Brennitzer Linienstern scenario once changed to Standard.

In both cases, the performance value for the instruction influences how strong the ETA will react to speed changes. 100% means you won't ever make up lost time. I never had that "failed" stop effect when values were below that (they are for most at 75%)

And another thing - if you're early in timetable mode, you can leave after passengers have boarded even if that means you'll leave before dispatched departure time. Normally a timed passenger stop will hold you at the station at least till departure time (a normal StopAt won't, that's realistic and called "Betriebshalt" in Germany, leave as soon as signals allow) - that seems to be different in timetabled scenarios.

Will look further into that.

 

As far as I discovered, it's literally just what it says - Estimated Time of Arrival.
Based on current (invisible) time, your current position & speed, calculated path, specified performance, timetable events.
Just shows the result. It's very indicative when you arrive at your destination. Slowing down it guesstimates how long it takes for you to reach the platform / siding / marker end, but when you stop, it jumps to current time.

Timeliness penalty and post-game timers are also derived from the same clock. Easiest to see when you arrive just a wee bit late at stations and compare penalty values to the ETA.

There are some complicated things in TSC but this is a really straightforward one, just a bit tricky to notice at first.

 

So basically the fundamental problem is that timetabled scenarios fail the player for arriving late.

 

That's what we're investigating. Matt just stated you should not use them when creating scenarios.

 

I also have this exact problem with clock deviation, roughly 3 mins per hour of game time. The dispatch times seem to follow ‘real time’ so I think it’s the display time in the game running slow for some reason, As I tend to build scenarios based on working timetables and always have the ‘hold to time’ box ticked for station stops, it’s extremely irritating. I don’t know if it was a particular version update of the sim or acquiring my latest PC that started this,

 

I thought it was fairly well known (at least by anyone who knew about the existence of timetabled scenarios) that they failed the player for arriving late.

 

Does not seem so, and I stumbled over the issue on the Brennitzer Linienstern. And the issue is not actually arriving late but still being punished. I still need to check the scenario after changing type.

But it's such a sunny day here, think I'll go to the lake (you're passing it on Karlsruhe-Strasbourg, the southern one between Ettlingen and Malsch) now.

Have a nice sunday everyone!

 

Well is the issue is twofold; the game will sometimes decide you have arrived late when you've haven't, and timetabled scenarios fail you for arriving late.

 

Ever since I realized that only ETA matters for objectives I haven't been ever surprised.
Some scenarios have a leeway, maybe until departure.
Many old scenarios require full aggression and some even impossible. Those will fail. (Like many Class 166 scenarios. Or Bristol-Exeter that requires you to do 125 in a 100.) Since the big clock is usually behind ETA, there is a window thus you may think you were on time. But as soon as you stop it shows the time, compare it to the objective and you know, on time or late.

Timetabled just allows the player to pick and jump trains. Shunting big yards, or playing through a morning schedule.
You can do the exact same with free roams right now. The only difference is that every single train creates a popup.
Either way, objectives for multiple trains in parallel, with the ability to pick and switch. I've done such free roams.
In every other aspect, a timetabled scenario is just the same as standard (and free roam). They all fail late objectives.

Every single confusion mentioned thus far is a simple consequence of the clock problem.
No need to acknowledge, just believe me and remember to glue your eyes to the ETA and make sure you're on time. It is usually predictable, even if using terribly off configuration (expecting 150-200% track speed). If you don't know better, just drive bold, use power and brakes. Observe. Eventually you'll be in the know.

I hope you had a good one!

 

That's why I prefer Career mode without scoring. You have the most freedom, and if you're late, you'll still get your checkmark. Of course Standard with reasonable timetables are also fine - but Standard requiring you to speed are not.

 

Regular scenarios also fail you if you're late on one stop. But there the ETA apparently works as it should.

 

This is absolutely incorrect - regular scenarios do not fail you for being late.

 

Yes they do. It's the very reason I put a scripthook in my standard scenarios to always complete the scenario successfully. If you are late to any stop and get a x on a standard scenario without that script hook, you will never get a green tick.

 

Well-modelled routes and scenarios constructed from real world WTTs (NOT public tables!) should be achievable. In reality schedules have padding time compared to 100% (or more) of the capability of the train, particularly nowadays with defensive driving techniques etc. Getting all of this right in a scenario is a large part of the realism for me personally. Not interested in tearing around like an idiot chasing what the simulator ‘thinks’ should be possible.

 

Does this script hook prevent getting Xs on objectives?

 

Sorry meant to say without that script hook My bad. Some scenarios you want the palyer to be running alte so they will get an x or at least I've seen some devs do this. Unfortunately if they haven't used the force success script you'll never get a tick for the scenario.

The hook doesn't prevent x's but it will reward a tick if you reach the end!

 

On one of my screenshots from TS2013, I noticed this in the summary screen: AI trains late



Now I'm wondering if there's a leftover still in the code which is affecting eTimetableScenarioClass scenarios - the reason you fail even when on time, because you've held up some AI trains that did not make it on time to their destinations? Is this why Matt said using these scenarios should be avoided?

I still need to test Brennitzer Linienstern "School Train" in Standard mode, as of now (timetable class) you need to be at the penultimate stop some minutes before dispatched time to succeed.

Also double check that you are not released from the passenger pickup stop before departure time (which does happen in Timetable class - come early, leave early. This must only apply to StopAt instructions - never to Passenger Pickups.)

To avoid confusion: This thread is not about timetabled stops in general, but about the (legacy) Timetable scenario type which seems to behave differently than Standard/Career types.

 

Are you absolutely sure you are talking about Standard scenarios? I've played Standard scenarios and got an objective tick even when I arrived late.

 

I've been writing scenarios for TSC for 8 years I would like to think that I know what I am talking about thank you.

 

I'm just saying that what you're saying doesn't match up with my experience.

 

Now this is confusing me - I am not sure I have experienced such a "mess" before, or maybe I just did not notice.

London - Faversham, "Journey through the Mist" (Standard)

Arriving late (realtime) - but ETA is below booked time. It keeps me at the station too long - adding the time difference between booked arrival and my ETA - and still succeed being 3 minutes late. It seems the realtime clock is of absolutely no relevance anymore ???





Will replay that in the same driving style (slowly through the yellows) on v72.3b....

 

If you look at the eta at the bottom - it suggests that you are actually early (the strood one shows 19:55 - but eta at 19:53 - so that suggests that the "clock" you see is at least 5 minutes fast? (so showing the wrong time) - but that is of course me guessing?

 

That means you solely have to adjust your driving to the keep the calculated ETA "happy" and not the actual world time? And when being late, being held much longer at the station? This just can't be right, it looks more to me that a variable in the code has been accidentally swapped, probably just one tiny instance of it?

What I can say now - it has nothing to do with Timetable or Standard class. This happens all over the place.

 

I'm not saying I agree with that, it was more what i was seeing (which I agree with you on that seems a bit off, I have heard of the time not matching before though - in my case i wouldn't even know where to look or fix that )

 

It feels I've lost trust in the whole system, not knowing how to drive correctly.

Strengthens my point that Career mode with Scoring disabled is the best way to enjoy scenarios, as timings are only taken into account for point deductions and not task failure/success.

So right now I'm replaying on 72.3b, after that on TS2014 and see if it was always like that...
We can rule out a scenario script issue because this one hasn't got one, what I'm noticing is the editor is flagging three stops having impossible timings - so maybe again it could just be a scenario issue other than core code... which I would prefer to relax again...


I'm coming to believe that scenarios that show these errors can cause those issues.

Confused but carrying on testing... Code or Scenario issue?

Cyclone All your fault mate, been watching your channel - now spending the whole day on this one....

 

The red numbers thing is a red herring, I've put that to 150 % in some scenarios - driven normally and gotten there 5 minutes early , equally i've had the opposite too - where i've put timings in and they've said 5 minutes later or something like that and still have struggled. (most scenarios i've done have been with actual timetables though - I think most of mine you can tell because i label AI as 01, 02, 03 (then a few of 00, or 01a 01b because i've missed some! )

Anyway though I agree it's all Cyclones fault

 

Real world clock is running too fast. 20 seconds ingame are 17 seconds IRL on my system (capped at 75FPS).

Maybe this is related to FPS and game tics? Need to take a break now....

triznya.andras please take over

 

The timing plausibility check is based on the engine's simulation.bin blueprint performance data. So if real world timetables don't match this means the TS engines are too weak / AI services preventing you from reaching destination on time.

And if the game clock is not synchronized to the gameplay (a deviation from real time would not matter then if it were) - this could be a reason.

 

I have just played this on TS2014 and the behaviour is exactly the same. You cannot reach Strood in time because of a red signal that clears too late (that's why the instruction is flagged red in the editor), but the game is not punishing you even for being +2 minutes late here. Very interesting. It seems you're being forgiven if the AI held you up . Note the bigger font size in the HUD and the lack of the lonely unpaired opening bracket before ETA




There's not much more to say on this for me. Case closed

 

I don't know if it's because I'm a real life driver (lorries not trains) but I always go off the ETA I do it irl and I naturally do it in-game too, maybe that's why I've not noticed the issues you all seem to be having?

and also...

I used to respect you torf..

 

Not sure I have that scenario,
What you discovered is 100% in line with my experience: the clock behind ETA matters. Its silly nature aside it didn't disappoint me, quite the contrary, now I know what I need to do in order to succeed. No more random fails. Like in this last shot, you arrived at 19:55:24 (ETA while stationary), objective is 19:55:30, you were on time. You are also correct that this is old behavior, I encountered this in January 2016.
Very rarely I do get a faster running clock, I noticed a bit of a change depending on which way I look with the camera (sunlight, shadow, anything). The Steam overlay is a pretty good comparison. Yesterday it was precise to the second. It's rather reproducible on my end, so I guess frame rate, stuttering or something similar behind it.

The AI trains late is an interesting finding. I started after that version, however I have never been able to finish Donner Pass 3a/3b, despite those are standard with non-timetabled steps. Obviously I must be late as in all other versions, and I recall the last objective failing, no matter what. Case in point, that might be related.

I think what eldomtom2 is confusing is the following.

• Every objective has an estimated time (in the editor) for informational and dispatching purposes, however the author needs to tick the timetabled checkbox per objective to enforce (and optionally refine) the time constraint.
• Some people call scenarios with (many) such objectives "timetabled".
  Considering this, it adds clarity to equate standard with single-train whereas timetabled with multi-train scenario (concept).
• The idea behind each scenario class suggested the habit that career and timetabled are timetabled, while standard and free roam are not. Ever since the addition of career it simply makes sense to stick to it, so that it's less binary..
  (Except for delaying AI so much that it ends up crashing.)

Bit of a side story, back when playing early routes I noticed how much of the network is programmed. GWML (OP) in particular. So what you mentioned about implementing the entire timetable may have been the idea. It's just a bit risky, unless you always pick stationary trains and then meet the timetable. Otherwise, just like in real life, you mess things up big time.

 

Comes with the Class 465 pack.

Yeah. We'll have to live with that quirk, that it does not matter what time it is when you arrive but what the virtual ETA shows. So I'm preferring Career mode scenarios and driving after the game world clock so the passengers can rely on me

Estimated Time of Arrival should be only an informal display that adapts to my speed and tells me if I'm running behind the clock or not - for task completion the Actual Time of Arrival (game clock) should have been used and compared to the booked timetable.

It seems there has been a terminology confusion between Estimated and Expected (dispatched) time of Arrival here that got into the code long time ago. As a fix could break even more, this will stay in the code and authors like KTL_Rob Powell have found clever workarounds to prevent player frustration.

As a side note, Not.Silent has managed to keep his well choreographed scenarios almost free from timetabled stops, instead he's telling you when to leave a station via message box to make sure the scenario plays as intended.

 

I'm not entirely sure on what you're saying I'm confused on. When I refer to Standard scenarios that don't penalise the player for arriving late, I'm talking about scenarios that are listed as Standard in the editor (as opposed to Timetabled) and list times for the objectives in-game.

 

Well then.
There might be some like that, though my standard experience is that timed objectives do penalize. See Chop and Change above. Quoted to click the pictures. A bit hard to see, it was designed as a video.
View attachment 120335
View attachment 120336

 

No red herring - red signal before Strood. Editor is correct in complaining. And a loco can't go faster than 100% or linespeed

Anyhow - this particular scenario is very very interesting. First stop at Higham is scheduled standard 35 seconds, yet notice how the red bar will stay on for almost three minutes even though you're arriving slightly late. At Rochester you're 5 minutes behind schedule and still won't fail.

I really think it's related to the editor red errors because it somehow messes up the dispatcher, and overall I have not noticed this effect often.

And for using real timetables, you must be sure the stock is really accurately designed and performs equal or better as real world stock, never weaker. Because real world timetables are super tight nowadays - at least in Germany that is.

triznya.andras I've changed my mind, and I am interested in the technical background, attacking the issue by just stating a theory and trying to prove or refute it.

THEORY

Unachievable timings reported in Scenario Editor are the cause for ETA mismatches and timetable +- deviation. In this case the dispatcher will display the time set by the scenario author in the left hand corner as usual, but will internally use the earliest POSSIBLE arrival time the player is able to achieve - scoring is based on that internal calculation.

If timings are deemed achievable (editor giving no errors), success or failure will depend normally on meeting your scheduled time. (+59 seconds, not sure though)

That could be the answer to this mystery. Still the influence of the performance set for the instruction is something I will look at, especially changing the time manually after the editor calculates the arrival time based on the percentage.

(Example: What happens when you set the percentage to 100%, then adjust the editor's calculated arrival time to a few minutes later - will this lead to the failure when being on time as in PDL's "Chop and Change" because it expects you to be earlier (=100%)? This would be exactly the opposite case as "Journey through the Mist" (Late=success vs On Time=Failure)

Please report other scenarios you find, failing when being on time or succeeding even being +1 minute late, and then we can check what they have in common.

Take your time, no rush. I think you can follow my stream of thoughts

 

I didn't say that scenario - I just said i've experienced it where the red numbers haven't been accurate , I think i said it "can be a red herring" .Equally, i should have worded that a bit better - but equally I have heard that west-to-east routes seem to be more affected by the timetable issue.

(I've seen it but not recently. (the last scenarios that i wrote for the 700 / Chatham Main Line (Ramsgate one), didn't have that issue when tested for example - even though part of the route is largely the same track as the Faversham route (at least Gravesend to Faversham)