Public Beta Build 75.6a

This is a debugger of the simulator itself that was programmed to find these types of errors easily, as the project unit is in D:\, so when compiled it comes out with this path... I don't know why it is difficult to find the error, some d3dDevice ->CreateVertexBuffer is hanging and not returning correct.

The error happens the second time you switch between tabs with game in fullscreen.

 

If you are still wondering about the iMaxParticles *6* error I've encountered it using Caledonian Works loco's as the way particles are set up there is a file in the Particles folder usually called SN dummy.bin which is set to 0 particles which generates the error.

There is a way to get rid of the error, let me know if you still need it.​

 

Thanks Niall. I would be interested in the fix (which I guess is around making the setting>0?). I have been fixing a slew of minor niggles with various locos that have arisen since the big updates so I shall add this one to the list!

 

You're right about setting the number of particles to above 6, there is also a setting further down the particle file which controls the size of the particles which I change to a smaller value since the SN Dummy.bin file does not have a associated texture so you will see the yellow missing texture square smoke coming out of the emitter now.

The next stop I do is a bit more time consuming since it needs to be done with all the loco.bin files individually. I've been editing the loco.bin file and moving the emitter (SN Dummy.xml) position up inside the loco so that the missing texture smoke is concealed within it. It's a bit of a rough workaround but I try and eliminate any errors I find in logmate if I can, with your better knowledge of the files you may come up with a more elegant soloution than me.

 

I like the lateral thinking involved there I'll take a look. My first thought is to provide a basic texture with a transparent output so it doesn't error or throw a missing texture spat but also doesn't give errors in logmate.
And yes, the long (endless?) task of tracking and fixing (possibly unimportant but who knows) errors in logmate is part of the cycle of TS life. The 'missing bogies' error still niggles me after 14 years....

 

If you mean the error about missing wheel or bogey blueprint that showed up on the Thompson B1 for example it is due to a mismatch between the bogie and wheel setup in the wheel.bin files and what is listed in the loco GeoPcDx. Sorry I can't be more specific but when I tried to use logmate to get an example of the error both the new and the older logmate programmes don't display anything at all, I don't know what is going on.

 

Yup. Unfortunately it is trickier to fix once built then I first thought. It is annoying because a build rule was obviously set way back when and then massively ignored by pretty much all loco builders without any bad effect on the loco. So the 'rule' is nugatory and might be better dropped from the error checking.

 

A lot of the time it doesn't seem to cause any issue although I remember making scenarios that would consistantly crash after exiting the editor and reloading and after removing a loco with a bogie blueprint error the scenario would load, but then again TSC worked or didn't in mysterious ways when using the editor.

I have just opted in and out of the public beta twice and the logmate program both the new one and the old one do not seem to record anything while I'm opted into the beta version, I have no idea why this is but it seems to be consistant, hopefully this isn't intentional.

 

So I have been experiencing out of memory errors while doing some route modifications, so I did a little bit of diagnostics and had my task manager up with the performance tab open. (Running an AMD Ryzen 7 5800x, B550, Vega 64, 32 gb DDR4 3600)

Usually when I have an issue its from switching between scenario editor and world editor, for example I was building an engine shed, and would put the locomotive on the track to make sure the buildings height is set correctly, then go back to world editor, adjust the height, then I want to replace the track that runs through it, go back to scenario editor, move the locomotive, go back to world editor, replace the track, go back to scenario editor and place the locomotive, then go to drive mode and usually going back to drive mode crashes the game, not always, but more or less is a normal thing.

Watching the performance tab, I noticed that every time I go between scenario editor and world editor, it commits the same amount of ram each time, almost like if the game isn't dumping the old temp files in the ram, and just compounds it on top of itself every time I switch back and forth.

I can also get OOM errors if I am in the world editor, and making a ton of edits, and them move to another part of the map, (Which commits more ram) but then when I go back to where I previously was, instead of it clearing the ram from the last time I was there, It adds more, and just keeps building on itself until it crashes.

What I am noticing is this pattern of it not clearing what was previously committed to the ram, and it will hold on to this even if I go to a completely different route, it never clears out.

I dont know if this is something DTG has noticed, But I figured I would point it out in case they have been looking for an answer to whats going on. Now similarly, If I am in Trainz and doing the same thing, each time I move to a different point on the route, I see the ram increase or decrease depending on what is there, it never compounds itself like TS:C does.

 

No more OOM error flying in bird mode over higly populated areas.
Much appreciated.
Unfortunately, crashes remain in 64bit mode when launching some selfmade routes. In 32bit mode everything is ok.

 

Anyone having an issue with the beta now not uploading and sticking..

EDIT - Seems to have worked whilst I wasn't looking - maybe i didn't opt out.. I think I got caught out by the V upping tp 75.8a

 

Fixed! The cause of crashes was the presence under C:\Program Files (x86)\Steam\steamapps\common\RailWorks\Assets\DTG\Academy of the file "BR189Academyrepaintpack.ap" (from Rail-sim.de). It was sufficient to unpack the file and now it's all OK.
No idea why.

 

Because having TWO .ap files in any asset folder that may overlap in content will cause blueprints.pak generation to crash - leaving you with a zero byte blueprints.pak (which is a perfect indicator where to start troubleshooting.)

(In route folders, which are not being cached, it's no problem, that's why you can add ScenarioPacks in their own .ap files.)

If anyone remembers, this was the cause for the japanese Union Workshop routes to crash, because they renamed an asset pack so you'd have two versions of the same asset .ap's in your folder.

JT Benedict This is also the cause for some JustTrains routes crashing. Check their asset folders - I think based on what routes you have installed, you might end up with two .ap files in the "GreatWestern" or "ChilternMainline" folders. Solution is to unpack them. (I've unpacked both, merged them, and repacked them.)

Benedict, I've just tagged you because it is sad to see your sales being affected by bad reviews which are just down to these issues of the shared .ap assets in your Steam releases.

 

Any update on the BETA update that was mentioned for December?

 

My build seems to be doing okay so far Steve, not getting any of the mentions up above, was very much expecting the game to run like pants out of Kings Cross on APC91EP: 1D39 15:35 London Kings Cross - Leeds, but smooth 30/45FPS and only seen it dip down to 25. These 'Updates' are very much helping with performance, simulator seems to be using close to 3GB of RAM, haven't seen it peak above that, and is ultilising about 50% of my GPU.

 

Maybe close this for further comments then?