TRS19 SP5 Beta (115546)

Downloaded the cab and if I look in viewer i see this

opened it for edit, and I think the alpha tag is missing in window.texture.txt
will report if can be fixed

this is how it looks with the Alpha tag added


@weevil ty for testing, hope we can find what causes the crash, Have you tried turning PhysX off?
 
Last edited:
OK. I'm done with this. I'd love to help beta test and help the team improve the product but I can't test jack through endless database rebuilds. These have literally hijacked my PC for a total of 6 hours today. Total real testing time has probably been less than an hour in total.

You surely have a bad asset or something causing your crashes. I have used every version of '19 now since early release including SP4, SP5, and now TS22 beta and I just don't see what you describe. It's been months since I've had a crash.
 
OK. I'm done with this. I'd love to help beta test and help the team improve the product but I can't test jack through endless database rebuilds. These have literally hijacked my PC for a total of 6 hours today. Total real testing time has probably been less than an hour in total.

i was having lots of problems with one of my beta builds. It turned out my build got corrupted along the way. The corruption caused countless problems. I downloaded a fresh copy of TRAINZ and the problems went away.
 
Sure you are not talking about TRS22 Beta John? this is 2019 Beta which doesn't have the new surveyor.
 
Quick download and patch to 115546, but the initial database repair took a little longer than usual.
TrainzUtil.exe 'prebuild' command stalled at one point but eventually completed.
All my settings preferences were preserved and home-built routes and sessions appear to function properly.
Like the new icons displayed in Content Manager.
Disappointed that we don't get to see Surveyor 2.0 in this build, but I guess that's something to look forward to when I upgrade to 2022.
 
well i'm still going through the process of the database rebuild, just about to hit the 20 hour mark on the rebuild and its showing " checking faulty assets (592235/592235) " with the bar 3/4 complete; this is a fecking joke..... should not take a full day to do a database rebuild.

nzld
 
My suggestion is your anti-virus must be interfering with things. (Or something is). I have a 1TB database and it takes about an hour for full db rebuild.

The easiest thing to do is to create a fresh local data folder and it takes a few minutes, especially for a beta build where you don't really want to be using your main local data folder anyway.
 
OK. Let's assume I have a bad asset. The only assets I have used in the SP5 beta are ones I was already using in SP4. It didn't cause any problems there. I would also suggest that if this were the case then CM needs to handle "bad" assets in a more robust manner, because there are plenty of them out there.

Same applies in the case of Tony's suggestion. If AV programs don't upset SP4, why would it cause a problem with SP5? Let's be honest, if you're using SP4 without stability problems, but using the same assets and doing the same things in SP5 and it crashes a lot, there is only one reasonable conclusion . . . .
 
Last edited:
OK. Let's assume I have a bad asset. The only assets I have used in the SP5 beta are ones I was already using in SP4. It didn't cause any problems there. I would also suggest that if this were the case then CM needs to handle "bad" assets in a more robust manner, because there are plenty of them out there.

Same applies in the case of Tony's suggestion. If AV programs don't upset SP4, why would it cause a problem with SP5? Let's be honest, if you're using SP4 without stability problems, but using the same assets and doing the same things in SP5 and it crashes a lot, there is only one reasonable conclusion . . . .

If you have installed the SP5 in a new folder, then the antivirus is going to scan the new path and treat that data as a new install regardless of whether the same-named exe is installed in another folder, or whether the data is named the same.

The assets being copied from one disk to another, or perhaps a glitch when downloading that caused them to become corrupted. I recently had a hard disk issue that caused some of my content to become corrupted. The only recourse was to download the assets again from the DLS which solved the problem, and I tried that as a last resort. The issue caused all kinds of weirdness including outright crashes to the desktop, assets not loading, CM reporting faults with the assets, and other things such as weird spikes on the assets when they were used.
 
Possible repair list SP5 Beta report


Crucial Fixes:
-Texture replacement scripts are not working
-Content Manager is [much] slower to list items in some cases (check if new icons cause this)
-Some headlight coronas not working (script issue)
-Several content issues not yet updated (e.g. Tidewater)
DLC's should work good, but can be done over time and not hold back the base release
-Many and long Dbase repairs (maybe because AV software and .tzarc format)


Recommended Fixes/checks:
-Remove (now obsolete)consist data handler rule from the standard new session list
-Main menu the top main buttons, Type: LOCOMOTIVE is truncated (at 1920x1080) same for ROLLING STOCK
use a smaller font? (or wider buttons)
-freedom (and easy way) to use any grid in any region
-Driver Setup rule Properties, shows a 0 (zero) in the upper right corner
-Junction Arrows, cleaner without the red blob (circle)
-Clean up of Installer files after a patch is done
-scripted embedded object minimap, options to set what is visible and direction arrows working
-Check if the Cabin (kind interior) tag opacity has changed in SP5, 4gy4tl4n
use Auran cab <kuid:-25:1168> gen 1044, in SP5 to test
-LLCR <kuid2:87589:90002:7> Loco Lighting Control Rule, back in built-in content
-<kuid2:523:19723276:5> USRA Light Pacific, DCC mode, Internal view, check the injector switch
-New water needs further development, more user friendly, color, transparency, easy removing, good manual
-Clean up of unused Surveyor2 files in TRS19
-Edit Environment, green dot at default session time (10.00h) (for easier setup) euromodeller
-lower brightness of trackspline circles, euromodeller


Confirmed Fixed:
-Various derailments on loading
-Switches in cabins are in the wrong position when entering the cab
-On steep track slopes train vehicles can have incorrect pitch at start
-Drivers are not automatically added in some cases
-Reverse rotated vehicles
-Steam loco water is not handled by the Automatic Fireman feature
-Testtrack (but needs 1 extra click on drivertab to bring up interface)
-Jump behavior in viewmode 3 fixed


Keep up the good work
beta test time 10 hours+, but enjoyed it
greetings GM
 
Last edited:
If you have installed the SP5 in a new folder, then the antivirus is going to scan the new path and treat that data as a new install regardless of whether the same-named exe is installed in another folder, or whether the data is named the same.

I appreciate the suggestion John, but Trainz had been crashing and rebuilding the DB all day yesterday. I'm certain it doesn't take my AV program all day to scan 600Mb of files. ;)

Your other suggestion of a copying error seemed plausible, so switched my SP4 build of Trainz to use the beta build local folder this morning. No problems all morning.
 
Last edited:
I managed 2 x 2 hours testing last night (I had a 2 hour break inbetween), my only niggle now (apart from what J.M. has already posted) is that the track spline circles are way too bright, but the original problems that I had have now gone, so well done to all involved. :Y:
I tested in surveyor, Trainz basic, (no Subs).
I recommend also for users to edit the environmental settings to default and then make your adjustments....

Environment.jpg


You add the extra green dot because that is the default time setting, maybe there should be a default green dot already there.

Cheers,
Graham
 
I appreciate the suggestion John, but Trainz had been crashing and rebuilding the DB all day yesterday. I'm certain it doesn't take my AV program all day to scan 600Mb of files. ;)

Your other suggestion of a copying error seemed plausible, so switched my SP4 build of Trainz to use the beta build local folder this morning. No problems all morning.

Yay, I'm glad to hear that, it wasn't the antivirus stomping on the files, which can also cause similar problems as I noted. With an antivirus program, it'll go after the files as they are decompressed by the program for access. Our data today is no longer kept in the old file structure and the assets now are contained in .tzarc files. There are components that are still compressed in the old way, but the assets themselves are all compressed into .tzarc files. You can see this if you open up your data-folder/local and then a hash folder. As these files are decompressed at runtime, the antivirus has a field day and prevents the files from loading either by blocking them in memory, or by quarantining them. This activity not only causes piss poor performance, it can also cause data corruption as well.

What happens is once a major crash has occurred, the program will run a check on the database for errors and go through the repair process, and this can become a repetitious cycle. If you have more than one crash in the future, the best bet is to end that repeating mess by running an EDR. To do this press CTRL at the same time when clicking on Repair Database.
 
Last edited:
We downloaded the beta, but there is a problem that the database recovery stops at error checking 582895/582895. After that, it hangs for 4 hours and only after 4 hours it ended. This is true for everyone. We tested several people.

unknown.png
 
Yay, I'm glad to hear that, it wasn't the antivirus stomping on the files, which can also cause similar problems as I noted. With an antivirus program, it'll go after the files as they are decompressed by the program for access. Our data today is no longer kept in the old file structure and the assets now are contained in .tzarc files. There are components that are still compressed in the old way, but the assets themselves are all compressed into .tzarc files. You can see this if you open up your data-folder/local and then a hash folder. As these files are decompressed at runtime, the antivirus has a field day and prevents the files from loading either by blocking them in memory, or by quarantining them. This activity not only causes piss poor performance, it can also cause data corruption as well.

What happens is once a major crash has occurred, the program will run a check on the database for errors and go through the repair process, and this can become a repetitious cycle. If you have more than one crash in the future, the best bet is to end that repeating mess by running an EDR. To do this press CTRL at the same time when clicking on Repair Database.

Hmm. I'm not sure you understood me John. I said I switched my SP4 build to use the beta "local" folder and have had no problems, meaning it isn't a problem with the local folder or assets therein. It's an SP5 problem. No celebrating here.
 
We downloaded the beta, but there is a problem that the database recovery stops at error checking 582895/582895. After that, it hangs for 4 hours and only after 4 hours it ended. This is true for everyone. We tested several people.

unknown.png

Yes. It's pretty insane. I wouldn't even mind so much if it could do this quietly in the background but it hijacks my whole computer making doing virtually anything else impossible.
 
The incorrect numbers above the progress bar are a known error. To see what's really going on, click on the small triangle to the left of the progress bar, to expand the window.

Peter
 
In order to check if an asset is faulty, it is run through a validation process. This includes loading scripts, precaching, checking mesh attachment and texture naming etc. 582895 is the total number of items on the DLS. Only the items installed are validated.

The bug here is that it counted to the end and appeared to hang your db repair, while in fact it was still validating (which you can check in the logs).

Anyway, that bug is fixed, and we're still looking at other db issues.
 
Back
Top