Train Simulator Classic – Core Update & Route Refresh

https://dovetailgames.freshdesk.com/support/tickets/60354

 

Just wanted to say thanks again, TrainSim-Steve .

The update works perfectly - so we're just waiting for the virtualRailroads fix that I know is in the works (according to Maik - supporting his old company - and Ulf posting on Rail-Sim.de).

Edit: Not having checked yet, but there's reports of the Searchlight SD40-2 and WM Retro Pack having brake script issues - Smokebox said there's already a new core update in the pipeline which fixes this (source: Steam TSC General Discussions)

Only exception still is the Consist Editor crashing when too many assets (probably corrupt) are installed. I don't use it, so it's not important to me.

Have you tested this (Create custom consist) on a computer having all of your DLC installed?

I have now transferred everything (260 routes, 670GB total - 28.000 folders and 370.000 files) to the new core installation, having left a small v72.3b installation only for playing AHS Ashford-Lille and the complex 373 Eurostar - which is the only thing that will probably not work with the update as the author is not replying to any requests even from yourself offering to fix it. Which is a bit sad, as it's a nice long High Speed route and fun to drive. Glad we can have multiple installations

Keep it up!

 

Patch Size = 475MB
I just got 335 KB from Steam for TS.... is that it? Seems a bit small.

 

Guess it depends on what content, routes precisely, you own... I, too, got only 335KB.

 

Jamie, if I may ask, what exactly was the problem with LUA compiler / interpreter? I see from your post it was all about floating point. But that´s too brief. And what version of LUA is present now in game engine?

 

No it won't.

It's only core files that everyone has that were updated, completely irrelevant what DLC content you own.

 

Bit of research shows no updates for the routes and I also got the tiny one, despite owning Soldier Summit and North London.
However the routes were functional before, so adjusting the core can fix these issues.
In which case, of course, there is no reason for them to be updated.
Of course the updated files are much larger so the install size may vary depending on the starting version.

 

Pardon me - but that's not logical. The only depot changed was 24009 which is the core that everybody has - so the patch must be the same size for everyone.

The way I see it, the 300KB delta patch inflated to a sum of 300MB files (exes and dlls that got replaced).

Anyway - good work and thanks to the team! Have a nice midsummer

 

Update: As reported on the technical subforums, there is huge issues with VNHRR routes Springfield Line and Montana HiLine - both cause the game to lock up and RailWorks64.exe to stop responding.

Springfield workaround: use 32bit exe

Montana workaround: checking 32bit... seems to do the trick.

 

It continues with the same version, maybe in 20 years they will change versions. Because using a version from 20 years ago must still be a good version.

https://forums.dovetailgames.com/th...update-route-refresh.69230/page-6#post-661967
https://forums.dovetailgames.com/th...update-route-refresh.69230/page-6#post-662186

 

As Lua is mainly needed to do maths and manipulate ControlValues and particle emitters in TS, it would probably not benefit from an update - rather introduce compatibility issues.

 

Okay, I won't disagree with the incompatibility, make a recursive function with the Lua 5.0.2 version and then do it in the current version, every millisecond is precious and this directly impacts fraps, there are even Lua variants on GitHub with more improvements than in original compiler too.

 

Ok, I've got a question. Are you free to use any version when you compile your script to binary .out, as opposed to a TSC processed .lua or .luac ?

 

According to LUA versions - it depends. Newer versions has much better table and array handling, better garbage collection, etc. Personally I´m using tables very often, also string manipulation, because for example I do via settexts even display icons, thus saving ControlValues for better and later use (buttons or switches...). And if this process can be significantly faster, then why not use it, right??

 

Montana HiLine only works in 32bit now - after testing I found the reason is the signal scripts.

rwaday filed a ticket, I've posted my find on the RWA forums.

https://forums.dovetailgames.com/threads/vnhrr-montana-hi-line-does-not-work-anymore.70987/

 

So scripts are still not fully solved...

 

It seems the last update which reintroduced AP/vR script compatibility broke these - I know HiLine has worked before that update.
For this to work, the devs need to work together with DTG, as they need the source scripts (can't debug an .out file).

Edit: Just tested Stevens Pass - also broken now! (same scripts)

TrainSim-Steve
Short summary of issues since last patch: (confirmed to be working before Jun 20th update)

- Springfield Line (crashes at certain locations, reproducible)
- Montana HiLine (any scenario due to signal script now broken)
- Stevens Pass (see HiLine)
... and probably all routes using G-TraX signals.

32bit is not affected, so use this as a temporary workaround. I hope DTG and G-TraX can fix this together.

 

Perfect, you understand the subject of programming and I see that you also like to get performance.

 

Who wouldn't like that, right? Even with pseudo OOP simulated via arrays, localised functions, stored functions, etc. that game engine is still too slow. Because it still uses only one processor core, it is pretty limited in final fraps...

 

I received the usual 12 step membership program message. No confirmation that anyone ran it on their "vanilla" computer. but with torfmeister's sleuthing there is enough to send them in the right direction.

 

Typical DTG practice, fix one bug on the third attempt, introduce a dozen new ones ....

The obfuscated .lua scripts worked before and now are broken, or broken in a new fashion. SSI has already stopped development and patching of their products until DTG sorts out their self-created mess. No doubt, AP, vR and others offering advanced rolling stock feel very much the same, being left out in the cold, being not included in the inner circle testing pool, being made to chase a moving target while trying to keep their business afloat.

Where is the much needed focus Focus should have given DTG by now? With TSW in the doldrums, TSC should haven been the stable foundation that now has crumbled?

The strange thing is some scrips appear to work in 32 bits GameManager.dll and not in 64 bits? While .lua scripts should be independent?
One supposes the .lua interpreters are the same since both .dll's got patched by the same 512 bytes?
One can also assume some DLC creators try to be smarter than DTG themselves, violate the DevDocs' .lua version rules and have more clever/and or efficient scripts?
And DTG needs to keep backwards compatibility in case someone still wants to play a RW2012 scenario using commercial DLC from that era?

G-Trax signal scripts have DEBUG set to TRUE, so the LogMate.exe output is flooded with useless messages IIRC.

 

21c164fightercommand you hammered some point with those 'clever' scripts... Personally I know at least 2 guys that could hide dtg scripters into a pocket...

 

Developers are receiving alpha updates for testing on their products.

One would think that DTG has copies of everything their developers have sold through Steam or directly through DTG on their "Vanilla" computers. Again the question, why was this not caught. I would guess that Stevens Pass and Montana Hi-Line were should have been. There were alpha versions accessible for developers for them to test their products. Most of the testing would have been to simply to be able to open a route in 32 or 64 bit. Am I missing something?

 

Because there were no script-related issues with these routes with the core update - until June 20th - you can't just test 200+ routes and 1000 locos again - this is a hell of a complex game, and it gives developers much freedom on how to accomplish things. They were focussing on AP and vR stuff - following the bug reports. Why the FloatingPoint lua patch broke Rick Grout's signal scripts is to be investigated.

Remember, they dared to touch Kuju code to ensure TSC will run in the future and continue DX12 implementation, and I'm sure none of the original coders are aboard DTG. It's always difficult to work on someone else's code. Adding functions is a bit easier than reworking, cleaning and recompiling.

I'm very sure they will fix this quickly once they get the uncompiled scripts from the fellas at RWA. (I've just seen that AP often leave their scripts in plain .lua format - can only support this.)

 

The truth is that I haven't seen any improvement since I stopped with Train Simulator in 2017, for me this simulator is the same, but many fans go crazy with each release of a banner that turns into chaos. All being fooled with DX12 and now with a new Core Update, which is actually all the same.

So I hope the same doesn't happen with Train Sim World, because it's in the Unreal Engine 4.26 version, but have the Unreal Engine 5.2 version, developers from other games are migrating and getting better performance results and even more incredible graphics.

 

It is not the same just because it looks the same. Stability - that's what this phase 1 update was about, and getting away from VC2010 code - has definitely improved. If you've worked with the editor, you'd notice. Moving a 100-car consist over some distance would surely crash the game before the core update, now that thing is very stable. No DTG scenario crashes anymore.

And nobody's going crazy. We're just working together here.

In fact TSW updates cause way more chaos - and I'm done with buying content for TSW for some time now. Apart from that TSW is just too "dead" and quickly gets boring for me. The forums over there are mainly floods of bug reports, speculations and wishlists. All that's left here is the script compatibility of one developer. It's not "chaos".

 

I have the suspicion you're only here to stir up the heat, but again. This is a multi step upgrade. DX12 will come. Code needed cleanup before and recompilation with new VC version.

 

I'm going to try to improve Train Simulator, I forgot it was DX9 (version 9.0c).

HAHAHAHAHA, Lua 5.0.2 (released in March 2004) and DX9 - 9.0c (released in July 2004), excellent evolution.

When it gets to phase 2 or phase 3, I hope it's not in 2030 or 2040, because we'll all be shriveled up or maybe not even present on earth anymore.

 

As you have nothing to contribute here, why post, delete, edit and repost messages that are completely devoid of useful content? Put you on my ignore list. Good bye.

 

Okay, I wish you a good dream for your ultra new generation Train Simulator. Bye.

 

Guys, guys, are you both playing kids or what. Both of you have your own truth in some way. The fact is that TS hasn´t been changed for years, if I do not count cosmetical changes. But on the other hand major changes to core cannot be done in one step, they must be continually tested if they´re implemented correctly. Let´s behave.

 

Please don't try to moderate in that "you're both right kids" way, because it misses the point - though I see you're doing that in good will.

It is absolutely not the topic of this thread for mocking TSC for being a game from 2007 (subtract development time) basically, or how much it got updated. That's no news, we are all aware.

The point is the current update, and this thread is for discussing issues and finding solutions, not for useless and not even funny "sarcasm".

 

torfmeister don´t worry, will never happen again.

 

No worries, and no need to bow down that far kiski

 

I´m not bowing at all. I just respect what you wrote and that´s all, I don´t even know what I tried to achieve. Silly me. Will take care of scripting, that is something I understand much better.

 

"Moving a 100-car consist over some distance would surely crash the game before the core update, now that thing is very stable." This was my biggest issue while using the editor. This improvement was certainly a big plus.

 

Sometimes I look at these issues with a simplistic common sense view not understanding how complex and time consuming this process is. From your postings you seem to have quite a knowledgeable background in coding and the inner workings on how it is applied to TSC. I defer to that. I think that in the foreseeable future it will be a fix and repair cycle. At least their team is on top of it and making progress. I am moving from frustration to hope.

 

If the G-Trax signal patch does not break anything else, we're pretty much clean I'd say. If not, see my thread on how to install multiple older TS versions using one simple Steam console command line.

 

A bit of an off-topic from me. But since many major developers are here. Yet my topic is about core logic.
Has the bug with wagons weight been reported?
When you put mass of load into basic wagon mass (not into capacity field, which said to be gallons and pounds but its actually tons according to GetConsistTotalMass and wagons behavior) and compared to normal way wagons act different.
First way gives more realistic results but GetConsistTotalMass returns same value for both variants.
So I assume, it's a some bug in consist physics formulae.

 

hellishfire that wagon bug is still there. Game engine is not counting with changed weight of a wagon, when you put a cargo in during the scenario/QD/freeroam... it still thinks the wagon is empty. This also works vice versa - unloading loaded wagon realtime and the game still thinks it´s loaded...

You must have two wagon blueprint setups - one empty and another one with cargo loaded from the beginning (in blueprint). In that case everything is counted properly from the beginning.

 

That's what was done with recent RRS freight wagons update. It doubled the list of the wagons. And I began to wonder if this core problem is known to DTG.

 

Any news on the US signal scripts being broken?

 

Glad to hear that, Steve. Good to have you aboard.

 

I'll second that!

 

Funny, and pity in the same time this was never mentioned anywhere. It was always considered as a bug by many and also many tried to solve it. Now I know why it never worked

 

I'm sorry?
I've been playing tons of coal loading scenarios, pun intended. On the ECML near Durham, during vR scenarios with the BR 294 near Hagen and Seebergbahn. Norfolk Southern Coal District.
Container trains as well - Cajon, GWML are definitely early examples.
It's absolutely easy to notice how I need gradually more power to move as I load my train. Also consist dynamics change as the power to weight ratio shifts.