Public Beta Build 76.3a

If you want help then please run again with logmate switched on and put the logmate logfile here. With luck it will identify the blueprint causing the issue. (a lot of luck...)

 

Eventhough i am on the latest public version i think this belongs here: The SDB seems to be easily corrupted in the latest versions. I have to erase it regularly to get all routes to show up in qd. 11 pages pf routes shrink to three or five every other day. Literally.

It seems to be the creation of a new qd scenario that causes it, but this could be unrelated, and just because that’s what i do a lot in TSC.

 

Report:

RailWorks64.exe as well as RailWorks.exe (Window mode, Win 10)
Several Scenarios on different routes are affcted

I received a tip from another user and can now confirm after my own tests that the script call "ScenarioManager:PlayVideoMessage" does not work in the current beta version - no videos are played.

This applies in particular to scenarios in which the feature worked without any problems in the past. Unfortunately, the last version I know of in which the call worked reliably is TS2020, although I assume that the problem occurred during one of the more recent updates.

There is no output about the problem via Logmate, .Net 6.025 is installed.

Best, Benjamin

 

They took away the video playback functionality some time ago, that's known. (It was only used in four official scenarios afaik, Canadian Mountain Passes and Story of Forest Rail, but could cause memory leaks as I understood it).

As for scenarios crashing, please always give their exact name to reproduce the issue.
We've found multiple causes so far, sometimes a bad blueprint (collision box touched the ground, which was not checked for in earlier versions, US Centerbeam wagon).

"Serveral routes / several scenarios" is not something to work with. Be specific. The most likely cause still are corrupt assets / badly setup blueprints. TSC is pickier now.

 

I got an OOM error when I wanted to drive a route in TSC beta 76.3a. the route was a CZ route

 

Thank you! I think it will be better with this.

 

As usual - not very clear if this adds anything or not. One oddity does strike me - when logmate cites blueprints it gives an .xml extension for items - the last listed thing in here uses .bin: Rollmaterial\DB-Dostos\DBpbzfa766\wagon\TTB_DBpbzfa766_VBB_RegioDB_wag.bin

Worth you having a look at the file and also at any consist definitions that may be citing it. I have seen cases where a binary is referenced in another binary but uses .bin instead of .xml. This used to fail 'safe' ie didn't cause a crash - perhaps it does so now.
BTW .xml is almost always used inside blueprint files even though the file it is referencing is actually a .bin.

 

Exciting news somebody! A not-seen-before error message in the log (after an OOM):

Code:

2024/01/13 16:57:07.106 - [Engine] - Trace D:\RGBuild\CoreRelease\Code\Libs\Heracles\Engine\Base\cHcStreamingObject.cpp : 206 = cHcStreamingDeltaObject::load: Opened stream from file @os:c/Program Files (x86)/Steam/steamapps/common/railworks/Assets/DT/DT_GNR_6WheeledCarriagePack/RailVehicles/Passenger/CompCoach/LNER/DT_GNR_CompCoach_LNER.GeoPcDx
2024/01/13 16:57:07.106 - [Streaming] - Trace D:\RGBuild\CoreRelease\Code\Libs\Heracles\Engine\Hc1Draw\cShapeAnimationController.cpp : 1286 = FATAL: Failed to allocate 65 ParentRelativeNodeMatrices in AllocateWorkingMatrixArrays, with freebytes = 1358, freecount = 196142
2024/01/13 16:57:07.106 - [Streaming] - Trace D:\RGBuild\CoreRelease\Code\Libs\Heracles\Engine\Hc1Draw\cShapeAnimationController.cpp : 1293 = FATAL: Failed to allocate 65 WorldSpaceNodeMatrixAdjusters in AllocateWorkingMatrixArrays, with freebytes = 1358, freecount = 196142
2024/01/13 16:57:07.106 - [Streaming] - Trace D:\RGBuild\CoreRelease\Code\Libs\Heracles\Engine\Hc1Draw\cShapeAnimationController.cpp : 1301 = FATAL: Failed to allocate 65 WorldSpaceNodeMatrixAdjusters in AllocateWorkingMatrixArrays, with freebytes = 1358, freecount = 196142

No idea what it means but probably resource/memory related?

Anyone had this?

Anyone have any idea what to do about it?

 

Or an error in the model.

TSC is now very strict on asset structure.

What happens if you put only that coach in a new freeroam scenario? (I'm using Academy for testing stock, as I can rule out any other asset conflicts)

 

Sadly it is a QD and I'm not convinced I can find the (possibly) guilty party ;-) I'll keep an eye out. Thanks

 

The guilty party is named in the report you posted.

Assets/DT/DT_GNR_6WheeledCarriagePack/RailVehicles/Passenger/CompCoach/LNER/DT_GNR_CompCoach_LNER.GeoPcDx

 

DLC scenarios incompatibility

Unfortunately, there's more official stuff appearing that reproducibly crashes on "LOAD_SCENARIO".

Canadian Mountain Passes Eldon Extra
Munich - Garmisch [ICE-T] Ice on a Summers Day

discovered today, adding to the issues with Penninsula Corridor, Saluda Grade and Longhai

TrainSim-Steve It seems we need to check the stability fixes again before moving on to phase 2? The list grows, I find new incompatibilities daily.

 

Thanks for pointing that bit out Spike. I'll take a look (cos why not) but when I checked before that looked like a reference to the previous asset - not the failing one. I'll shuot if I find anything useful...

 

And another thing: the old 'occasional floating' decals problem is still happening. This is where, on starting a scenario, all decals are hovering 20-30m in the air. This can really kill any sense of immersion. The effect seems to be random - it is not related to specific scenarios or scenario-types.

 

I've seen it... I think on the old Glasgow Airport link I saw a GoogleEarth overlay floating around. I think restarting the scenario solved this. Probably content not core related though...

 

Slightly OT. I wonder how the google overlay was visible in the first place, outside the route editor? If it’s possible to have it visible, imagine what it could add to mountains outside the 4km ground texture rendering radius.

 

Google images imported as decals, if I'm not wrong.

 

Yep, Brendan has left these in on his Dublin-Cork-Limerick-Tralee route. It saves on terrain painting, and is ok for distant terrain actually. But I've also noted it floating high up in the air at times, after restart it was where it should be. It probably shouldn't be saved as scenery decals but baked into the terrain mixmaps, but I'm no expert on that. It probably has to do with a decal crossing tile borders.

Likely to be dismissed by Steve & core dev team as being Content-related issues. Not sticking to guidelines That's what we are seeing, now, there's way more blueprint validity checking and assertions like the collision height than before. Which makes sense to be future proof. Most of the OOMs ingame were caused by bad assets. Now these scenarios are locked out completely from loading.

And probably the editor crashing on selecting destinations on some routes might be related to little flaws, micro spaces between ribbons, in the route itself.

 

I use both custom (mine cloned from kuju ones) and default Kuju decals (allotments and car parks) so the problem lies somewhere in the core engine I suspect. I know that a restart can (sometimes) fix it - but when your scenario loads are taking 2+ minutes a restart is a painful thing.

 

2+minutes ? Wow, yes I remember these loading times when running TS from a magnetical harddisk, but not from an NVMe SSD...

On my old HDD, I always instantly packed the new route folder contents into a MainContent.ap, improving loading times and protecting it from accidental changes.

 

Thanks Spike - the route is big and so are some of the scenarios so even with an SSD it can be tedious.
Just tried ap-ing it - hasn't made any noticeable difference in load speed so far - I will play around a bit.

 

Out of curiosity, how do you AP a file and what makes it run instead of using the individual files?

 

Zero compression (store) zip it and change .zip to .ap
You must then remove the other files or thegame will read them not the .ap

 

Of course the assets will take a lot of time to load. Freeware assets and some by SAD, virtualRailroads etc cannot be packed because they contain filenames with special characters (which you just should never do for any game file. Always treat your game files like you're working on UNIX and keep to 7bit ASCII), which don't work when packed. The more dependencies the route has, the higher the loading times (and blueprints.pak creation if you have previously cleared the cache, this will also extend loading times. It's when you see the white loading bar at the bottom freezing for some time, that's when the cache file blueprints.pak for each product folder is being built).

(As route files have standardised filenames (tracks.bin, ScenarioProperties.xml), it's safe to pack them. Previously you couldn't pack scenarios containing .ogv movies, because the player plugin couldn't access these then, but that obsolete (and hardly ever used feature) got removed now.)

When you pack, like mentioned before, make sure to not use compression, which will counter the fast loading zlib routine as additional time will be needed for decompression. Also, while it may work using compression, nobody gives you a guarantee it will work in future builds.

Demo:

 

And this has what to do with the beta?

 

It is a useful digression arising from my report of the continuation of the floating decals issue in the beta. Spike response is usefulto those of us who never got around to doing the .ap thang.

 

More than your forum gatekeeping has that's for sure.

 

Just spent most of the day creating a railfan scenario at Kings Cross (1954). Running pretty well, added in some of the final loco/train movements and bang. OOM - load scenario in dispatcher message (ie unhelpful). I'm trying to remove the most recent additions one-by-one in RWTools - no joy so far. Sick of it at the moment - will try to grab some logs tomorrow.

 

These issues do not appear in v75.8a. Those dispatcher bugs have been reported and DTG are aware.

Opt out of the beta if you want to play/create normally - it's mainly for testing.

 

Fair point - I had got used to it being pretty stable and got suckered in ;-)

 

Cheers Spikee - using the 75.8a version still gave the same error but once I'd cleared the consist with the 'pathing failed' error in the log the rest of the scenario loaded into the editor (with a handful of minor errors) and I could carry on without loss. That saved me a load of re-work - and also explains why some people using my route could run a different scenario that was failing for me under 76.3.

On a related note - did stopping points get deprecated at some point - one of my re-edits was to remove one that had worked some releases ago but caused an edit fail now?

 

If i remember correctly, all that data is stored in the scenariotracks.bin (if it’s markers applied in the scenario editor) and the tracks.bin if it’s markers applied in the world editor.

Both files can be “fragile” at times. I’ve experienced that a few markers were missing both when importing a backup installation and when cloning a scenario.

 

Scenario placed Markers are in "ScenarioNetworkProperties.bin", Route based markers in "tracks.bin".

 

Thanks for the correct. Then we can add the Scenar…….bin file to the list of files where info can “go missing”. Are QD AI spawnpoints stored in the same file?

 

Just create a QD. ScenarioProperties.xml hosts the spawn point information, and ScenarioNetworkProperties.bin the marker positions iirc.