Cloaked Ghost crossing errors

[rwk]

I'm having a problem that I don't know how to fix. Two of Cloaked Ghost's crossings, US Level Crossing 2 Tracks and US Level Crossing Tower have errors like this VE146: An asset must be specified for tag 'texture-kuid'. and VE194: Tag 'texture-kuid' does not contain a valid kuid: null that I don't know how to fix. Is there something simple like adding or deleting something in the config that will fix it? Is there a method for replacing the two faulty assets with other similar crossing signals?

 

[JCitron]

In Content Manager, right-click on one of the faulty assets and choose Open... and choose Edit Config file text.

Delete that line texture-kuid " " line.

Save the config.txt and close Notepad or whatever you use to edit text files.

Back in Content Manager, right-click on the asset and choose submit.

Check faulty content for this asset you just edited. If everything is okay, repeat the process with your other faulty asset. If not, check your work on the first one you edited and submit again.

 

[rwk]

I think what the issue is here is that these are 2004 era assets and Trainz 19 is much stricter with validation checks and certain tags and meshes that were acceptable in Trainz 2004 Trainz 19 doesn't like. I got a few more errors after committing one of the crossing signals but I'm going to see if I can fix them in the config if not I'm going to need an expert to help me. A route is calling for those two signals and I don't want to have to find every one and replace them. If they are missing in the route due to the errors, how do you find where they are? I just got one of the signals to show up. I'm going to work on the other one.

 

[JCitron]

If there are more of the same crossing signal, then fixing one will fix them all. I agree, replacing road crossings is painful. The assets are referred to in the route by its KUID and the asset isn't included anywhere in route. This is why replacing a KUID with something else will change the asset. In the olden days, prior to KUID2 format, a content creator could obsolete an asset by adding an KUID to the obsolete-table found in a new asset. This worked okay until things got confused and a mill got replaced by a canal lock, or some houses got turned into trees.

You are spot on here regarding the stricter error reporting. TRS2004 was kind and not so kind to us users. We could stuff all kinds of working and not working well assets into that version and the program would clunk and chucg along, literally not figuratively. TRS2004 would chug and stutter and then crash to the desktop without warning, or usually would error when exiting. Sometimes doing a save would crash, so a Save-as and overwrote the same route or session was your safe bet before quitting. If you did a save, you'd see the desktop or blue screen instead.

The reason? Bad scripts, or bad content that wasn't error-checked the way TRS19 does today, or even what TRS2006 started doing when that version came out.

If you need help, feel free to PM me and I'll take a look at those assets for you. Please provide the KUIDs so I can download them from the DLS or provide links to them for me to download.

 

[wreeder]

TRS2004 actually did error checking but other than making an entry in the error log, it did nothing to let the user know an asset was faulty until the game crashed as John says. If you had a third party addon called TrainzObjectz, you could click open the error log and the KUID of the faulty asset could be clicked on and opened to edit and fix the error. The big problem was that there was little if any error checking done when assets were uploaded to the DLS in the TRS2004 days. So the standard for content creation was pretty low. Basically, if it showed up in game and kind of did what it was meant to do then most creators were content to upload it.

 

[rwk]

Lazy creators. And some creators never fixed their content to work in newer versions, leaving users stuck and having to try to fix them themselves or ask for help. I got the crossing signals to work now.

 

[JCitron]

I'm glad you got the crossing working.

When I did a bunch of repairs after bringing in old content into TS2009, I came across some of the most absurd errors. These were mostly typographical errors that the modern error checking would catch but even TRS2006 let slip by.

catigory instead of Category with other variations in between
desicription instead of description
Non-conforming numbers.
Splines mis-configured and acting weird,

and many more including the incorrect type of quotes, single instead of the double, causing the config.txt file to totally mess up and required me to fix that.

I don't blame the content-creators for this. Typos do happen and this is why the program needs to catch them when the asset is compiled. I put the blame squarely on Auran because many errors were caused initially by the early assets that content-creators copied. For many early assets, content-creators copied config.txt files and changed the names and information to protect the innocent, I mean to suit their similar asset. This is well and good if the base asset is correct in the first place. What this did was cause the same errors to occur over multiple content-creators using the same base asset for their own. Other errors occurred if content-creators used an asset as a base and didn't update the information properly, and finally other errors were simple typographical errors, missing textures, dependencies, or bad scripts.

There are really four kinds of errors.

Semantical errors, meaning those that allow code to work but are not with the intended outcome, won't be caught by the compiler or error checker because there is no way for the program to know the intent.

Syntactical errors, meaning typos, can be caught if the error is included in the list for the checker to find.

Missing dependencies and textures.

Faulty scripts.

Who's to blame here?

I put the onus on Auran because they didn't implement better error-checking right at the beginning instead of horsing assets through with a lick and promise and some prayers while hoping the assets would work and not cause a crash.

Due to the huge number of user complaints, error checking started in earnest with TRS2006, it was announced that stricter error checking would be implemented. This was the very early beginning of what we have today. Most assets, meaning those that complied with the rules, loaded fine but many, many more needed repairs. As time has gone on, the error-checking has become stricter. To allow for backwards compatibility, the error-checker has some filters such as build-version. Again, as long as an asset plays by the rules based on that version, it'll load up fine. The reason for this is to allow the older assets to load up in newer versions without triggering errors. We can see this if we take an older asset from TRS2004 and change the build number to 5.2. If there are any obsolete tags, meaning those no longer directly supported in build 5.2, then the asset will fail to load. This is the same with the reverse. In addition to some file changes for some assets, many newer assets can't be down versioned due to having different tags, scripts, and even texture changes that were non-existent when TRS2009 or TS2010 came out so that these newer features cause the asset to fail.