Weird bug in TRS19

I gave up on trying to resurrect the most recent versions of the BC&SJ. I went back to version 303 and started to redo the work that got lost.

So far, so good. Surveyor and Driver have been working OK (except for Surveyor abruptly disappearing on me one time - but the recovery got back nearly all my unsaved changes since the most recent save).

I hope there are no hidden gotchas in version 303 (now up to version 320 - I've been making a lot of saves in new files just in case)

HF

And I think to myself, what a wonderful world...

With apologies to Louis Armstrong....

Good news:

I worked diligently for a couple of days and got the older version of the route updated to where it was before. Life was wonderful.

Bad news:

Then I installed a few new trains on the route, saved it under a new name and clicked for Quick Drive.

Sigh... You guessed it. I'm back to the Driver screen being entire white except for the sky.

Strangely Quick Drive worked on the route before I added the new trains.

One of the trains was a Piper Cub (aeroplane). I removed that from the route, saved under yet another route name, and tried Quick Drive.

No dice, so I tried double clicking the Default route. Still nothing. But upon exiting out of the program my little background task friend was running.

Instead of ending this background task I'm letting it run...

None of the new trains I added were anything I've not run before.

Given the size of the route, 99 miles of mainline, a couple of branch lines and almost as many trees and other vegetations as the prototype Oregon has in real life, could I be knocking on the door of too much stuff for TRS19 to handle? The Task Manager sez it's using 2.4GB of ram, but all tasks running ATM are using only 18% of system memory (64GB). Cpu usage is also pretty low.

Ya know, a feller dealing with this might find hisself getting kind of irate...

Horace (still with ruffled) Fithers

Here it is 12:56 AM the next day and the TRS19 background process is still grinding away doing heaven knows what using 11% to 12% of a 16 core Threadripper 2950x.

If it's doing database repair as was suggested previously it must be one doozy of a repair job. Of course, it might just be doing Anitra's dance.

Judging by some other comments in the TRS 2019 forum area, I'm not the only person experiencing the joys of recovering from major data corruption, either.

It's beginning to remind me of a girl I once knew. Really, really pretty, but after a while it became apparent she came with some big problems.

HF

horacefithers said:

Here it is 12:56 AM the next day and the TRS19 background process is still grinding away doing heaven knows what using 11% to 12% of a 16 core Threadripper 2950x.

If it's doing database repair as was suggested previously it must be one doozy of a repair job. Of course, it might just be doing Anitra's dance.

Judging by some other comments in the TRS 2019 forum area, I'm not the only person experiencing the joys of recovering from major data corruption, either.

It's beginning to remind me of a girl I once knew. Really, really pretty, but after a while it became apparent she came with some big problems.

HF

Click to expand...

This is one of the reasons i've stayed with TANE, its been around longer, and generally SP3 seems quite stable ( now i've said this it no doubt will crash and i'll lose everything) . it may be you have a corruption as it should not take this long to repair, even big database installs of 100 gigs or so will generally sort themselves out after an hour or so. Did other routes run ok ?

horacefithers said:

... really pretty, but after a while it became apparent she came with some big problems ...

Click to expand...

:hehe: ... so recognizable ...

I listed dependencies recursively for the version of the BC&SJ that I had fun with tonight (er, last night as it's now tomorrow morning...)

I notched a strange coincidence:

There were a bunch of dependencies with an install date of 16-AUG-2019 or earlier (on the 16th I installed a bunch of 2-bay open hoppers). These are now marked "modified" with a modification date of 22-AUG-2019.

Does that imply that a third party tweaked some of those assets? Or did the DB repairs I attempted reset the modification dates? They're listed below. I really doubt that they all were updated on Aug 22 by human hands, but I don't know for sure.

Also, for what its worth, I used the content manager filter described by John in the "strange effect" TRS19 topic to search for out-of-date items in my DB and it found none.

When I searched my installed stuff for "obsolete and not built-in" I got a number of hits. I searched for more up-to-date versions assets marked "Open for edit, Obsolete" and installed them. Most of those seem to be JR freeware which got installed in the DLS.

With the newer version installed, will the route automagically update to the newer versions or do I need to crawl around in a contents file and manually update them. I looked for a way to determine the actual KUID of an installed object in my route but didn't find a way to do so.

HF

Installed assets tagged "modified" and with 22-AUG-2019 modified date:

<kuid:68926:300004> Steve Lerro Engineer
<kuid:648132:101540> SP ALCo PA-1
<kuid:421503:15012> 2bay hopper A.T.S.F.
<kuid:648132:101542> SP ALCo PB Rebuilt
<kuid:421503:15014> 2bay hopper ATSF
<kuid:648132:89819> AAR Type B bogey
<kuid:421503:15011> 2bay hopper UP
<kuid:438995:1170> SP Baldwin #3299 2-8-2 Vanderbuilt Tender
<kuid:103021:100050> Coupler Bogey Back 4-10-2
<kuid2:103021:100114:1> 40ft Boxcar CN Late Leaf
<kuid:68926:300002> Bill Klene Fireman
<kuid:421503:15010> 2bay hopper UP Billboard
<kuid:438995:1169> SP Baldwin #3299 2-8-2
<kuid2:103021:100113:1> 40ft Boxcar CN Late Leaf Textures
<kuid2:103021:100105:1> 40ft Boxcar CN
<kuid2:103021:100104:1> 40ft Boxcar CN Textures
<kuid:648132:89779> AAR Type B bogey - SP
<kuid:278716:100976> Alco 244 V16
<kuid2:648132:89734:2> Alco PA PB bogey black
<kuid2:103021:10103:2> Red Corona
<kuid:648132:89783> ALCo RS-11 SP
<kuid2:103021:10102:2> Green Corona
<kuid:648132:89782> ALCo RS-11 SP BW
<kuid:156765:1509> Bettendorf truck high detail red
<kuid:475197:100714> CNW Airchime M3 #1 - 3 Part
<kuid:648132:101543> SP Train Indicator Numbers
<kuid:68926:819047> SP GS-8 Whistle (3 Part)
<kuid:103021:100903> Commonwealth Tender Truck Black
<kuid:648132:89851> SP Depot CS-22
<kuid:68926:819003> Cotton Belt L1 Drivers
<kuid:103021:100990> SP 4-10-2 SP-2 Late
<kuid:68926:819006> Cotton Belt L1 Engine Spec
<kuid:103021:100993> SP 4-10-2 Drivers Disc
<kuid:68926:819009> Cotton Belt L1 Enginesound
<kuid:68926:819004> Cotton Belt L1 Pilot Wheels
<kuid:103021:100992> SP 4-10-2 Pilot Truck
<kuid:68926:819008> Cotton Belt L1 Tender Truck
<kuid:68926:819005> Cotton Belt L1 Trailing Truck
<kuid:103021:100051> Coupler Bogey Front 4-10-2
<kuid:103021:100994> SP 4-10-2 Engine Spec
<kuid2:38408:10050:1> CS Water 01
<kuid:884720:9100001> hf_bcsj Custom 40' Boxcar - #1
<kuid2:200687:120032:1> JR Generic House 1 Story w/Porch 05
<kuid:884720:900000> hf_bcsj Custom 40' Boxcar Lib
<kuid2:103021:10101:2> Incandescent Corona
<kuid:200687:120094> JR Flag US 30ft 5x8ft
<kuid:68926:81901100> SP GS-8 Tender
<kuid2:200687:120044:1> JR Generic 1 Story House Simple 01
<kuid2:200687:120045:1> JR Generic 1 Story House Simple 02
<kuid2:200687:120046:1> JR Generic 1 Story House Simple 03
<kuid2:200687:120028:1> JR Generic House 1 Story w/Porch 01
<kuid2:200687:120031:1> JR Generic House 1 Story w/Porch 04
<kuid:175455:100885> JR Small Tank Loading Platform
<kuid:103021:100991> SP 4-10-2 Trailing Truck
<kuid2:348207:100223:1> JR US Phonebooth 1a
<kuid2:69593:49007:1> mesh library distanziatore
<kuid:103021:100904> SP 4-10-2 Tender
<kuid:467590:100841> SP 2472 6 Chime Whistle with Air Actuated Bell
<kuid2:103021:10100:1> White Corona
<kuid:68926:8190004> SP GS-8 Engine
<kuid:103021:100039> SP Number Board Textures
<kuid:103021:100052> US 6 Axle Tender 70 PSI

I found an error in my DB

I was updating an asset USA SP Class GS-4 Steam Engine kuid2_59906_4449_1.cdp

There was an error loading dependency: USA SP Class GS-4 Engine Rear Bogey <kuid:59906:50011>

Failed to load child images for texture file: 'sp_classgs-4_4_8_4_body.texture.txt'

Could this be causing the troubles I was seeing?

I took the version of the route that I had not installed three trains and a piper cub airplane and could open that in Driver. One of those trains had a GS-4 in it.

I was then able to Edit Trains and add the three trains and Piper Cub and run them all without experiencing the white out.

Question: Should all my locomotives and other rolling stock be installed in the session-layer? Could this be causing problems?

HF

horacefithers said:

I was updating an asset USA SP Class GS-4 Steam Engine kuid2_59906_4449_1.cdp

There was an error loading dependency: USA SP Class GS-4 Engine Rear Bogey <kuid:59906:50011>

Failed to load child images for texture file: 'sp_classgs-4_4_8_4_body.texture.txt'

Could this be causing the troubles I was seeing?

I took the version of the route that I had not installed three trains and a piper cub airplane and could open that in Driver. One of those trains had a GS-4 in it.

I was then able to Edit Trains and add the three trains and Piper Cub and run them all without experiencing the white out.

Question: Should all my locomotives and other rolling stock be installed in the session-layer? Could this be causing problems?

HF

Click to expand...

Definitely put all rolling stock on your session layer. There have been reports of issues with putting rolling stock on the route layer, but I have never experienced that. Sessions are things that are dynamic such as rolling stock, therefore, put the trains there. I believe in KISS and I've done it this way for years with zero confusion.

If this content has been installed from CDPs, and it has been, it'll appear as modified in Content Manager rather than Built-in, Payware, or Installed from Download Station.

It's possibility that this asset is corrupted, but that should not stop the program from working, or your route from loading, it may however, break a driving session by being missing. Delete this dependency and reinstall from your CDP. That will repair the asset since this should not have this error.

Sometimes errors will appear in content after running an EDR. Viewing the errors and warnings generally will make them disappear. Why this happens, I don't remember as it was explained once to us ages ago.

With my 1.5 TB of content, an EDR will take about 4 hours on my regular hard drive, therefore, your 100GB database shouldn't take as long to repair as it did. Hopefully your hardware is okay. There are things I can think of that can cause that off the top of my head: A full disk, a highly fragmented older-type disk, a failing disk, malware scanning, background processes other than TRS19 running - watching videos, listening to music, browsing, malware infections, etc.

Are you opening route for edit when you place the trains? If this is the case you also have a blank session attached and no allocated drivers. Quick drive takes you to the first driver allocated which is held in the session, not the route. Select your route and select a session that was used when life was wonderful and select edit session. Now add your trains and then go to quick drive. save all under the new name.

John,

The drives in question are ultra fast m.2 pcie/x4 drives.

I don't think there's malware - I keep eset up to date.

When things are working I periodically see hiccups in Driver playback (a slight hesitation).

I'll move the rolling stock into there own layers.

I manually ran a DB repair which took under 1/2 minute.
Then I ran an extended DB repair which took around 5 to 10 minutes (iirc) and after which the no textures, track, or splines became the vast white fog with sky above.

A while back, I ran into a problem when doing lots of large cut and paste operations (F5) the resulted in the program hanging. I recently (2 or 3 weeks ago) experienced this again. Because all this madness started when using the "move asset(s) into selected layer" when within selected rectangle I wondered if there was a relationship. I was able to create a test case that locks up the program on the third paste operation (copy, paste, paste, paste - locks up). I submitted a ticket on Friday and am waiting for N3V to come off their weekend and see if they can reproduce the problem on their end. However, it only seemed to happen with large routes and large copy rectangles. I couldn't get it to fail with a simple test case so I ended up including the entire BCSJ (earlier, working version) in the bug report.

Question: What other things can result in a "modified" asset state?

HF

Stagecoach,

In the most recent version of the route that failed Driver, I set the trains of interest in Surveyor. I saved the route with trains in place then clicked the quick drive icon in the upper left region of the Surveyor screen. Result was an all white display topped by sky.

Last night I made another copy of the most recent version of the route that had NOT had the trains installed. This version did run Driver when entered from the Surveyor window. I used "Edit Trains" in Driver to set the same trains as were present in the situation that had failed Driver. I saved the game as a scenario and then drove around for a while (the setup is a lunatic in a Piper Cub overflying the newest area of the route with three trains running in it. This was successful (I grabbed video off the screen and will be posting a YouTube video shortly).

Just now I tried firing up a new TRS19. I double-clicked the route version with the "session" (from the previous paragraph), then double-clicked the session I'd set up with the 3 trains and the Piper Cub. To my relief (and surprise) it loaded in Driver and appears to be able to run.

I'm very curious as to why I could Quick Drive (from Surveyor) the route prior to installation of the three trains plus Piper Cub,
but could not Quick Drive after adding the 3 trains + cub in Surveyor (there are already zillions of trains littering the rail scape in the route including some with the GS-4 locomotive that should have had the textures.txt issue, so why did adding a few more make trouble?),
but could run the route with the exact same trains if I'd installed them using Edit Trains in Driver?

FWIW I have a LOT of versions of my BCSJ route present in content manager (I usually try to keep at least the previous 50 versions because I'm paranoid that I may need to go back and look for something that gets deleted - or corrupted...). But I'd deleted a lot of Default sessions to try to clean up the content-manager listing.

Could those deletes have caused this problem?

HF

horacefithers said:

John,

The drives in question are ultra fast m.2 pcie/x4 drives.

I don't think there's malware - I keep eset up to date.

When things are working I periodically see hiccups in Driver playback (a slight hesitation).

I'll move the rolling stock into there own layers.

I manually ran a DB repair which took under 1/2 minute.
Then I ran an extended DB repair which took around 5 to 10 minutes (iirc) and after which the no textures, track, or splines became the vast white fog with sky above.

A while back, I ran into a problem when doing lots of large cut and paste operations (F5) the resulted in the program hanging. I recently (2 or 3 weeks ago) experienced this again. Because all this madness started when using the "move asset(s) into selected layer" when within selected rectangle I wondered if there was a relationship. I was able to create a test case that locks up the program on the third paste operation (copy, paste, paste, paste - locks up). I submitted a ticket on Friday and am waiting for N3V to come off their weekend and see if they can reproduce the problem on their end. However, it only seemed to happen with large routes and large copy rectangles. I couldn't get it to fail with a simple test case so I ended up including the entire BCSJ (earlier, working version) in the bug report.

Question: What other things can result in a "modified" asset state?

HF

Click to expand...

Little hiccups are normal, unfortunately. There are many factors that cause this including lack of LOD (Level of Detail) on an asset causing it to appear suddenly. The solution is to check assets first because they're the biggest culprit by removing one at a time. Doing an ALT+Y to walk on the ground while in Surveyor will help because you can move around easily in the area in question and hit ESC to exit out when you find something that isn't right. The front out view is like being in driver. If things work well here, they'll work better in driver. I did this recently on my Gloucester route because there's an area where an older bridge spline was causing problems. It took a bit of time and trial and error to find the problem asset.

Any asset that's been "touched", meaning opened up and modified or installed from third-party will have this tag. I wouldn't worry about it too much unless it's a payware from N3V (DLC), or built-in. If these assets are marked modified, highlight them, right-click and choose revert to original.

Reporting the issue is a good thing. Be prepared to send off the route and session to the QA team so that the problem can be confirmed. Once the ticket is placed, you'll receive an email directly from the guy that does that (I can't remember his username!).

Regarding your backup versions. That's an excellent idea and is smart working. Keep one or two installed, but back up the rest, individually, to CDPs. This is done in Content Manager - right-click and choose Export to CDP. Once backed up, you can delete these from within Content Manager along with any related default sessions you may have. Speaking of default sessions, these can be deleted with no harm since they are a separate entity and only connected to the route but not part of it.

Default sessions are created because you open edit route. This causes a blank new session to be attached to the route. Quick start from that session without a driver being allocated will go to a blank screen. As you said you added the trains and saved with a different name, you actually saved a blank session. You need to edit session and allocate at least one driver to a train.

stagecoach said:

Default sessions are created because you open edit route. This causes a blank new session to be attached to the route. Quick start from that session without a driver being allocated will go to a blank screen. As you said you added the trains and saved with a different name, you actually saved a blank session. You need to edit session and allocate at least one driver to a train.

Click to expand...

This is interesting as since January when I first started using Trainz I have always gotten to Driver by starting with Surveyor and using the Quick Drive menu item (upper left corner). Yet it is only recently that I started experiencing the missing textures, splines, and track or white with sky problems.

HF

You keep mentioning surveyor, but which one, the route or the session? Do you open route for edit or open session for edit? It makes it a lot clearer if we know which one.

I have traditionally opened route for edit. Then jumped to Quick Drive from the route edit.

As far as sessions go, I have yet to set up and official "session" with trains having list of stuff for them to do.

HF

You can not go via edit route to quick drive as the session is the blank default one. It has nothing on it.
You must go via edit session which has some trains on it with allocated drivers. If you only open route you must place a train and allocate a driver to it. No drivers means no quick drive. You don't have to set up driver instructions, just have a driver and always open this session for edit.

I could because I was putting the trains in the route-layer not knowing anything about sessions....

HF