Public Beta Build 77.1a

I think the logmate 'command' should be -LogMate -SetLogFilters=all

 

Try to add lua-debug-messages.

Code:

-LogMate -SetLogFilters="All" -lua-debug-messages

 

-SetLogFilters="All" is the correct syntax as a string is passed as a parameter, usually requiring quotation marks.

 

I've got what I posted in the launch options and that works but I wasn't aware of what you posted but that works as well.

 

Oh dear - senior moment - thanks to Oystein for reminding me of something basic like "-lua-debug-messages" and to Spike and Andy for your thoughts too.

 

It does need the ""
There is a complete (at least I think it is pretty complete) list of all parameters over at:
https://forums.dovetailgames.com/threads/all-119-command-line-launch-options-which-ones-are-current-obsolete-incorrect-or-missing.74961/

PS: Do let me know if you have any additional info / additions / corrections / remarks for that list.

 

Hi, will the next core update fix the issue of the system giving an error when you press control/alt/delete to exit the game. Thanks Fred

 

Not on my system it doesn't but I'll let it rest at that.

 

Can confirm quotation marks are not always needed, mine works as per below

-LogMate -SetLogFilters=all -ShowControlStateDialog --enable-backups

 

Were there any changes on how far the light flares are rendered? I have been noticing that they are not rendered after a certain distance.

 

Just tested and yes, something has changed. I would call it broken.

 

Does this happen at night or only during the day?

 

Any example for repro?

The <FadeDistance> is set in the HeadlightBlueprint, it shouldn't be a thing the game decides. It's individual for each loco.

 

It happens both day and night. Earlier I could see the light flares far away (>1000m) from the loco, now it disappears like ~30m from the loco.
There is only "Fade Start Distance" and "Fade End Distance" in the blueprint.
Fade End Distance should be where the size of the flare stops changing, but it should not disappear.

 

Please give an example loco, I can compare on different builds. (Not "any" please )

 

I haven't released this project. But if I roll back to 75.8a there isn't any problems with the light flares.

 

So far I noticed it on most freeware Czech routes and K-Trains' Traxx, for example. It would require to do some digging if there's anything official from DTG suffering the same issue.

 

The BR 232 from RSC cannot be driven, the engine can be started but it does not move

 

Given so little detail, can I ask if you are aware of how to operate the 232? Have you flipped the "Drive" switch and released the handbrakes?

 

I've done everything, but the RSC BR 232 locomotive just doesn't want to run. I tried the VR BR 232 locomotive and there are no problems

 

Is it this loco DB BR232? I just tested it in the public beta version and it works. I tested with a single loco in Quick Drive.
If you roll back to version 75.8a, does it work?

 

Thank you for your answer, yes that is the DB BR 232 from RSC, in version 75.8a everything works, except in the beta version 77.1a the locomotive does not work for me. I am not a professional in programming. Actually, I'm only building a route in the beta version, I've been building the route since 2021

 

Strange. Do you have any mods for it?
Just tested it in a scenario I made and it works. Just release brakes and set reverser to forward, then everything is ready.

 

I've tested on stable v75.8a. Indeed sometimes it doesn't take power (I turned off Dynamic Braking while stationary (because the brakes already are too strong) - the loco wouldn't move. Restarting the scenario (Munich-Augsburg - "Hot under the Collar") it worked, and I turned of the DynBrakes when already running. It might be a script issue with that one - it is actually a vR loco provided to DTG without PZB functionality).

So that bug has existed before this beta.

 

Finally had the chance / time to test the new beta and came across some quite strange behavior: CPU usage (of the one core utilized by TSC, not overall CPU usage of course) is not 100% anymore, but something around 50%. CPU frequency, thus, is not boosted, but stays at the idle frequency. Also, the PCs fans stay quiet - so far so good However, I don't get past 1 or 2 FPS..
Opting out of the beta, reversing to the latest stable brings back the old behavior: 100% single core usage, max CPU boost frequency, loud fans, 20FPS.
Am I missing something?

 

Not experiencing this issue in Beta. CPU Usage 30-40% @4.6GHz fps fixed at 30. Please read signature for system specs.

 

Would it be possible to pack these FPS Limiter options into the Game settings or command line argument?

I'd like to keep to my preferred method of letting the Gfx driver impose FPS limits for active and minimized games.... (I keep TSC running at 20 FPS max when tabbed out and editing blueprints )

 

You can limit FPS from the command line.

More info over at :
All 119 Command Line / Launch Options - Which Ones Are Current/obsolete/incorrect Or Missing ?
https://forums.dovetailgames.com/th...-current-obsolete-incorrect-or-missing.74961/

 

That works on a global scale, but the beta has introduced separate hardcoded game / menu limits now.

 

Hello,
I have noticed since a few days a drop in my FPS when I resume a scenario after saving it. It took a few minutes before I could recover my "normal" FPS (which I have limited at 35). I did a test today by leaving the public Beta option, and the problem did no longer occur. I thus guess the Beta option is responsible for this drop ?

Did anyone have the same problem as me and what do you think about it ?


Thank you for your response.

 

Hi all!
I've also been testing around with the new beta and I've also come across a problem, I've already done a complete fresh reinstall of my TS but to no avail.

I'm trying to load a QD on a Dutch freeware route which used to work fine. After updating to the new build (using the 64 bits version), the QD seems to load normally but after the 'tick' indicating that loading has finished my TS loads to a black screen and crashes. Trying to build my own QD leads to the same result. When doing the exact same in the 32 bit version, things are working fine.

Does anyone of you have any idea what might be going on? I'm slowly running out of options what to do...

 

Have you run it using logmate to see if anything coes up there?

Obvious question - does this happen on all routes or just this specific one? If it is just this one then try removing the scenery folder (just change the name to 'sceneryX') and retry. If it works then there is a scenery asset that doesn't play nicely and you can try checking individual asset folders to see what it is (or just let the route developer know).

If it happens on all routes then there is something amiss/unusual with your setup since the beta works ok for many others. Try dropping all rourtes except one ( a nice, safe kuju one perhaps) and see if that works. If it does then re-introduce the other routes one at a time (or in groups if you add in all the DTG ones first as they should work regardless).

Good luck.

 

As QuickDrive randomly loads assets from all over your installation, you must use LogMate to find out which asset crashes the game.

Use Freeroam to check if the route and used stock is ok, as it will only load assets you have specified.

 

Thanks for your replies, here's a little more background:
On all other routes I have experienced no issues (so far). The QD I'm trying to load only crashes when starting from certain locations. Starting from some locations in the QD work, and some don't. In 32 bit, all locations work fine. I am using the latest build of RWEnhancer 2 with Vulkan. Free roam and 'normal' scenarios all load up fine on all locations. I ran a LogMate before and couldn't find the potentially guilty asset, hence that I tried a full reinstall of my TS. I've attached a LogMate of opening the problematic QD, maybe you see something that I don't?

 

Can't study that all, but two things: Your Just Trains Voyager preload blueprints are corrupt, and you are missing hundreds of files.

Apparently, everything comes to a halt when TS loads stuff from Assets\Coha - it seems there's damaged or bad files in there.

 

Sorry, I saw that too and reinstalled some of the Coha assets. Here is a new file:

 

Remove the files that are marked as containing invalid data. You must reinstall them from where you got them.

 

Thanks for your advice. I proceeded as you said and I still have the same issue, log attached. The only thing that I can still see that I wouldn't expect is this entry:
2024-05-06 10:22:24.086 - [Content] - Trace D:\RGBuild\CoreRelease\Code\DLLs\DataManagement\cBlueprintLibrary.cpp : 270 = Blueprint set not found : DanielSyntus, VluchtdeurAlmelo
I asked the route builder and he told me that this object will be part of a future update and 'got stuck on the tile' while deleting. Can that be the cause of the issue?

The other thing I can imagine is that there might be an issue with the latest build of RWEnhancer2?

 

You could try removing that particular tile to see if the problem clears up?

 

I would advise creating a thread in the Technical Reports section, as this is a content (data) problem with a specific freeware route and corrupt assets, and not a TS beta (code) issue.

 

Thats only if the preload is configure properly to begin with. Maybe the Developer needs to check it.

 

I've seen freeware addons adding preloads - doesn't mean it's JT's files yeah.

 

These ones I had are not JT's original ones.
And they were incorrectly configured on top of that.

 

Allright, if you all think it's not beta-related then I'll head over to Technical Reports. Thanks for the help everyone!