Train Simulator Classic – Core Update & Route Refresh

Are you sure that you saw what you saw?

 

Yes, it's beyond obvious. I didn't do any loading since the patch, though.
Typical loaded weight is around 5x of empty, so it's quite hard not to notice, actually.
It's not impossible they broke it. Would be funny to pull 30 loaded coal wagons uphill with a single GP9.
Time to score 1000 on Monumental Part 1 if so! (The one with so many gondolas that it crawls at 10.5 mph.)
That said I'm talking about Kuju stock. The statement of "loaded weight doesn't exist" sounds a bit generic, responding to a more specific report.

 

It was more of fun response than actually a "real" question...

 

Tests of RRS team show that wagons with ticked load do have impact on physics, but it is no close to physics when you put loaded wagon weight into wagon's mass field.
Maybe mass of load was half implemented in some patch as some king of crutch?

And I have to mention interesting fact. There is no consist self movement if you use full mass wagons.

 

Self movement has nothing with mass. Somebody mentioned here it is due to AI / Player train recognition. I think something else, but better will save it for myself.

 

Playing some MGR scenarios at MML's Ratcliffe PS, I definitely notice the train getting heavier with each wagon being filled. This has always been working for me in TS. IF the blueprints have the payload section set up correctly.

And the wagon blueprints do have a cargo/fuel section defining center of mass and load weight for payload.

Some developers supply separate loaded and empty blueprints, probably for QD Custom consists (these ALWAYS have the preload flag set to TRUE. So to have an empty wagon for QD, the "unloaded" version can be used. You can recognize them by the suffix _LD or _MT for example on some G-TraX/GN assets)

 

It can be pretty easy to find out if consist mass has changed after cargo load or not... Here´s the code:



Put it into a loco script. Function ConsistMassChange() should be called in Update function (at the beginning of that it), and that global variable can be declared anywhere at the beginning of the script. I have written this very fast, so of course, it can be optimised much more.

 

TrainSim-Steve

Could you give us a simple short example of non working 64bit lua code and the fixed version? Or is the aim to regain full compatibility again (fix the code not the script) - which would then allow the Eurostar 373 to work again?

 

I second that. It would be nice to know what code pitfalls are incompatible so far...

 

why is it ever since the huge core update the game lags way more then it used it its so dam bad idk how to get around fixing it and im on a high end pc

 

It performs equally or even better than v72.3b on my system, due to redundant code removal and using a newer VisualC++ compiler creating a better optimized x64 build. Only the experimental DX12 version stutters, but that's optional anyway and in a very early development stage.

 

Not getting any additional lag on the new version. If anything it’s slightly improved. Running set to the highest detail rendering at 4k outputting to 1440p and getting just as good framerates as before and a lot less OOM errors.

DX12 version is not so good but as Torfmeister said, that’s still experimental.

 

Well I presume if they knew the problem they could fix it...
And in any case fixing the code rather than the script should definitely be the goal.

 

Although I'm not optimistic about Train Simulator Classic, a friend contacted me with a problem with the Stevens Pass Route Add-On, where it does't load in build v74.8a (X64), so I decided to apply my debugger to analyze, in a matter of 5 minutes found the problem and i fixed, it's already working again.

 

Please share the fix, I'm sure other users would appreciate it.

 

Yes, I just submitted it to the Train Sim Community, please wait for approval.

 

https://forums.dovetailgames.com/th...line-does-not-work-anymore.70987/#post-671437

 

There's a lot of crazy people out there, take your car to get the brakes fixed, yes the mechanic fixed the brakes, but he broke the accelerator and the clutch, a lot of crazy people out there.

But I'm going to flip like crazy, Future of Train Simulator Classic is fantastic, everything works.

 

Feel better for that? Good good, now hush and let the grown ups talk there's a good luv.

 

#60783,just logged a ticket about broken class 170 TrainSim-Steve ,has anyone else had same problem?

 

Which 170 AP or standard and what went wrong? I was driving the AP one earlier on a quick drive and didn’t have any issues.

 

both variants,when it loads, eitheir the engine stops,or train simply won't move. But controls work,bar headlights looking like there broken.

 

Ok, I just tried both (all 3 that show up in fact. AP, 170 and 170 Turbostar are 3 different options on my loco selection) on a Quickdrive and was able to drive them all fine. My headlights don’t look broken either.

Was there any particular scenario you are trying. If I’ve got it it, I’m happy to try it.

 

was testing just on free roam,do you have discord or can i pm you here? Tigert1966

 

Don’t have discord, but you can PM me.

 

my experience of the new 'improved' updates are not good. I find that the simulator is no more stable. I think that we all want to believe it is.....but it isnt. More importantly, when it crashes it still, more often than not, displays 'out of memory' errors when memory is clearly not the cause! the only thing I think might have improved is stuttering. Framerates are half TSW3 but at least stable. No more announcements have been made by DTG on further updates. My feeling is that DTG are currently in a very bad place. I am blocking all updates at the moment in both TS classic and TW3 because each update seems to bring more problems. It is fair to say that I am a very dissatisfied customer.

 

Well, DTG was never fast with updates to begin with. It's already something what they did this year.
It is also the holiday season, so they'd rather keep stable for now.
Justified or not (many of us have no problems whatsoever, most issues are content related, including official), the negative feedback triggers the obvious reaction that releases must be even more scrutinized. Which in itself slows down the pace.

In the end of the day, if not for these updates, we would be still running 32 bit limited to decade old assets at half the current fps - unless rolling back all the way to v2013. Like in psychology, if people always just complain, the kid learns never to do anything to avoid conflict - even if their doing is actually quite good.

One more thing. Revenue comes from the published content, not the core which is free. With fewer releases, it's tough to justify the costs of working a lot on TSC.

 

I have no idea why "well it only broke some content" is meant to be a defense.

 

I play a very large route with a combination of scenery, track gear and locos that span fourteen years of output from more than 50 content providers. The early stuff is almost certainly not technically compatible with the game engine - but most of the time it all manages to work.

I still get OOM errors where I used to get them - my one disappointment is in the lack of useful error messages. I suspect that many of my crashes come down to just a handful of rogue elements - but finding them by trial and error (instead of error messages pointing them out) is a task of extraordinary magnitude!
I applaud the team's aim of getting to a technically stable base before trying to fix the nice stuff - just hope that usable error logging is next on their list.

 

The reason DTG are updating is simple: its profitable or by their own admission there would come a time when the software effectively failed to function. Its a business, and as they are game developers it is reasonable to expect them to do it well and resolve problems. Its what they do!

 

The the wiper of Class 365 do not wipe the middle of the windscreen, when will it fix?

What is the meaning of “broken”? But I found the red light and the yellow light of NJ Transit seems same colour when see it far away.

 

As someone involved with development, it's simple. It's both defense and admission.

Interlaced PNG is the best example to describe the scenario.
It was never officially supported, but apparently people used it. Upon removing the capability, this content broke.
The lack of exception handling is a plain error, but in other instances it's less obvious to compensate (missing textures, scripts).
DTG was technically correct to remove it, it's the fault of content creators to use this format.
Yet, it was relatively easy to fix so DTG added the capability and ideally documented it.

There are similar incidents with broken (workshop) XML files, or otherwise corrupt assets (All Aboard routes, old VNHRR).
In order to ensure continued functionality, DTG would have to test every single content ever created. 1000+ DLC and all 3rd party free and payware.
You have to draw the line somewhere.

Yes, beta version would have been nice but the file structure isn't compatible, although a new version could fix that (organizing all executables in their own binaries folder instead of RailWorks root).

In the meanwhile, the code still uses the old LUA version and people complain about not updating it. Despite any similar issues it could cause.

Customers are entitled to be unhappy and complain, but overall we all have to understand the big picture.

 

"All content sold by DTG through Steam should still work" is a fairly logical line to draw...
And I don't think you can blame every issue that's happened on the content creators...

 

That's good to hear. I'm happy ploughing through logmate to nail errors down (and fix them sometimes) but there is a tsunami of misinformation which could also be usefully removed as it tends to obscure any actual errors. My personal favourite is this one:

2023/07/08 18:18:10.163 - [Content] - Trace D:\build\CoreRelease\Code\DLLs\RailVehicleManager\cBogey.cpp : 619 = Rail vehicle "DT\DT_GNR_N2\RailVehicles\Passenger\QuadArts\DT_QuadArtShort.xml" missing node "bo01wh01"

This seems to apply to pretty much every steam loco and most carriages. I guess that it is an old 'error' that is no longer an actual error. I tried to fix it (retro-edit of bin files) - wasn't a success...
There are several others ;-)

Good luck with the improvements.

 

cunningn#3154 You can also take a look on model without an access to source file. Open the 3D shape file (GeoPcDx specific for that vehicle) in TSTools, and it spill out something like xml structure on you. Scroll down and you´ll find a list of nodes. I bet you´ll be able to identify the nod that cause this. It will be a bogie´s axle, probably with different name, not the one game engine expects according to blueprint reference (in this case the first axle of the first bogie). Just rename it in blueprint to what you find and you´re good to go.

That´s what I would do.

 

Thanks Steve (and Kiski). Yup, I'm aware of where the problem is - the issue is that it obviously ISN'T a problem as it affects pretty near every loco from every provider doing Uk steam (old freeware, old payware, new payware) and they all run just fine. Which suggests that either they are all doing it wrong or a false issue is being reported (which is what I believe to be the case). As Steve mentioned - it should be some sort of warning rather than an error - and we should be able to filter them out of the results.

Thanks for your replies anyway - roll on a refined error reporting system ;-)

 

I keep coming back to my basic points about OOM crashes. I am willing to bet 99.9% of the time they are not due to the sim itself but are caused by either routing issues in scenarios or duplicated things like ConsistEntry ID's when multiple assets are loaded from a number of authors & products at the point a route loads. At this point the way the sim handles these conflicting ID's seems to cause some sort of problem. Since being very careful about these ( and doing a lot or replacing thsee codes ) I am running almost OOM free except when I build a scenario that forces the pathing of stock into an impossible position either by virtue of the train length or position. Routes that used to cause almost continual OOM's simply run perfectly well. BUT its very time consuming and fiddly work. The truth of it is that ( like the lau code issue ) we developers of assets "got by" in the sim and all sorts of things whose impact were masked by other faults have only now come to fore as the sim has been improved, stablised, and therefore more rigerous.

 

I'm not saying for a second it's possible but a live console like they have in ETS2 would be a welcome addition, just press the tilde key in-game (after editing the .ini file to dev = 1 first) and you get live log mate type info, you can also add parameters and also warnings are yellow and errors are red.

 

Hi Richard,

Can you go into a little more detail about what you have done? I assume you are referrig to the ConsistEntry ids in QD consists?

 

The dispatcher code certainly is a little…..fragile…..for lack of better word.

 

The thread where I explain it is called
A Source ( & Solution) Of Some Crash To Desktops
rather than repeat it its probably better to do a search ( only 'cos I am not sure how to link to a topic here )

 

I think 99.9% of the time is an exaggeration. If that was the case then the crashes would always happen every time.

 

I have experienced OOMs and have now managed to stop them from happening. The root cause for me was conflicting software which made TSC hang up and flood the memory with infinite of the same error message. When I checked Event Viewer I found out which app was really causing my problems and have since stopped running parallel processes. At this point in time I appear to have an OOM free environment. When I was using the conflicting app this would be pretty consistent. TSC seemed to be the software causing the issue as it was the one complaining with the error messages. The culprit for me was NOT TSC. It now behaves very well!

Respectfully

 

Can you say what the conflicting software was - that might prove useful for some of us?

 

Thanks Richard. I have applied the last bit of your advice (about fragments) and have already seen an improvement in QD stability. I won't say any more than that at this stage as it requires a lot more testing - but it is looking good. I will probably write a little utility to do the main consistId renumbering bit as I have a fair few to go through. Many thanks for the advice.

 

you press on the time or on the #number on one of the posts then copy and paste it like this for example https://forums.dovetailgames.com/th...update-route-refresh.69230/page-8#post-679086