So I did some analysis of the build version of all the assets I have...

[RobWed]

Thanks for taking the time and effort to put your response together, John.

As a new Trainzer, having bought the latest (non-subscription) product on offer, and using a route that is marketed as 2022, I find it frustrating to be blocked at so many turns by assets that don't work. I assume it's my lack of experience when something doesn't work as expected so it's exasperating to invest further time only to find out it was never going to work. That everything I have learned from Trainz so far as had to be learned empirically doesn't help either.

I understand that the config file gets compiled. It is, however, stored as a text file. So it can be parsed. And some of these error correction tasks can be automated. One thing in your list that piqued my interest was "-The user used the tab-key to move the cursor into position instead of the space key causing columns to break and other errors." which suggests to me that there is a rule to define how the key and value are seperated. How many spaces? Or is is just any number of spaces? I was looking for a template for config.txt. Found an exposition on the keys and their value data types which is a start.

 

[RobWed]

The "bigly" advantage of Trainz over many other simulators is the user involvement in the creation of assets. It is one reason why the sim/game is approaching its silver anniversary and is still going strong. It is both a benefit and, as John has pointed out above, a curse.

The focus in this thread on the "minimum build number (3.7)" is misleading. As I pointed out in a post above, this limit is for uploads to the DLS only. As John mentioned there are creators who have departed because their work can no longer be uploaded to the DLS. Another current, prolific and well known creator has stated that he will not do the extra work needed to add LOD data to his creations. His assets work in the latest TRS22PE SP5 but if/when N3V makes LOD mandatory then he will probably stop creating.

The focus of this thread is why assets built into TRS22 or available in DLC for TRS22 do not comply with the "minimum standard" for TRS22 - build number 3.7 which is TRS12 SP1, a standard that is now about 13 years old. In reality TRS22 has its asset build number at 5.1 and SP5 increased this to 5.6. My installed copy of TRS22PE SP5 has about 4800 built-in and base assets, only 55 of which are at TRS22 standard (build 5.1 and above). Interestingly, one of those is named "XBox Loading Screen". Only 14 of those 55 assets meet the TRS22PE SP5 asset build number. I do not have any DLC installed on my copy of TRS22PE so I can use it as a test bed to ensure that my routes and sessions only contain built-in and DLS assets.

If a built-in asset with a lower build number (below the 13 year old 3.7 standard or the new SP5 5.6 standard) still works then why not allow it to be included in TRS22? And as new versions and SPs of Trainz are released should the minimum standard for built-in and DLC assets also be increased?

What I'm actually looking for is something that works as intended. As a new Trainzer I'm looking for an exemplar route. One that is fully functional and showcases the features of TRS2022 in a way that allows me to see how the various components work so I can go off and start my own routes confidently.

For better or worse I chose the Schwaninger Land route to get started on. It's an Auran product marketed as TRS2022 content. It's extensive. It looks great and implies a lot of potential. However, things are unfinished. Stations are not properly configured. There's not enough sessions to effectively guide a newbie. Some assets are broken. Not all of this is bad as the configuration work can be a learning experience. But investing time in a broken asset because you don't know enough to know it'll never work. That's just wasted time.

I did say that I'm a subscriber to the 'if it ain't broke...' philosophy. So maybe my position should be less about build numbers and more about functionality. It doesn't upset me that I have build 1.3 assets that 'work'. It does upset me that I have assets (of any build number) that don't function properly yet are packaged in what is marketed as a contemporary offering. When those broken assets are build 2.9... it suggests indifference.

You've spoken about older assets still working but you yourself have stated that there is no guarantee that older build number assets will continue to work. I did that analysis piece because I was hoping to see that the distribution of assets used in retail products made by N3V was weighted towards more recent builds. I can see there was some effort made around 4.6 but overall there's not a significant weighting. I was looking for some assurance. Focussing on build numbers was perhaps not the way to find it.

I understand that some of the assets used in the creation of the route are the work of non-N3V content creators who may no longer be active. N3V has a different relationship with its customers than its customers have with each other. I have no right to expect anything more from a content creator than that which they are prepared to give. With thanks in exchange. The relationship with N3V games is transactional so when they sell me something I expect them to take responsibility for the entirety of that product. I know they can because the Dowload Station cleanup page outlines a time limit for creators to fix faulty assets.

 

[pware]

How many spaces? Or is is just any number of spaces?

In my experience it is any number (1 or more) of spaces.

 

[pcas1986]

...
I understand that the config file gets compiled. It is, however, stored as a text file. So it can be parsed. And some of these error correction tasks can be automated. One thing in your list that piqued my interest was "-The user used the tab-key to move the cursor into position instead of the space key causing columns to break and other errors." which suggests to me that there is a rule to define how the key and value are seperated. How many spaces? Or is is just any number of spaces? I was looking for a template for config.txt. Found an exposition on the keys and their value data types which is a start.

I think it is a single space minimum but that is something I've never thought about. The parser should treat tabs and spaces equally as "white space" when creating whatever it needs internally. Trainz does create a "config.chump" file that users shouldn't really see but can often appear if an asset has not been opened/closed correctly.

John W's excellent post addressed your comments about simply updating the Trainz Build to 3.7 using some tool. AssetX has macros to update assets to various builds and I created an AssetX macro to take assets to 3.7. I also wrote a Pascal program to parse and update about 700 assets that all had the same issues. But that was unusual.

Only N3V can answer why some "built-in" assets remain at TB 1.n levels. My speculation is that they never saw the need to update them.

 

[RobWed]

In my experience it is any number (1 or more) of spaces.

Thanks, I was just off doing some research and that's what I discovered.

 

[RobWed]

Thanks Paul,

The parser should treat tabs and spaces equally as "white space" when creating whatever it needs internally.

-The user used the tab-key to move the cursor into position instead of the space key causing columns to break and other errors.

Can you clarify how both of these statements are true?

AssetX has macros to update assets to various builds and I created an AssetX macro to take assets to 3.7. I also wrote a Pascal program to parse and update about 700 assets that all had the same issues.

That's the stuff I'm talking about! If for no other reason than to plan out a program of work. Find commonalities, identify the low hanging fruit, &c

 

[JCitron]

Thanks for taking the time and effort to put your response together, John.

As a new Trainzer, having bought the latest (non-subscription) product on offer, and using a route that is marketed as 2022, I find it frustrating to be blocked at so many turns by assets that don't work. I assume it's my lack of experience when something doesn't work as expected so it's exasperating to invest further time only to find out it was never going to work. That everything I have learned from Trainz so far as had to be learned empirically doesn't help either.

I understand that the config file gets compiled. It is, however, stored as a text file. So it can be parsed. And some of these error correction tasks can be automated. One thing in your list that piqued my interest was "-The user used the tab-key to move the cursor into position instead of the space key causing columns to break and other errors." which suggests to me that there is a rule to define how the key and value are seperated. How many spaces? Or is is just any number of spaces? I was looking for a template for config.txt. Found an exposition on the keys and their value data types which is a start.

Your faulty assets need to be looked into. That's something that we're not experiencing. In my current install, I only have the known faulty DLC

We always thought that the config.txt file was just a text file as the name implies but we were recently informed by the lead programmer that this is actually a compiled file that gets decompiled to text for us to see.

The text is spaced apart by a number of spaces we've never counted. There are templates available I think for ConText or Cute Editor and Notepad++ for Trainz config.txt files. I had difficulties getting the one to work for Notepad++ due to my version of NotePad++ being higher than what the template could handle.

In the past, I've used Oracle's NetBeans IDE. This was helpful because the IDE keeps track of the curly brackets making troubleshooting a broken mesh-table easier.

As Paul mentioned, AssetX does some auto-repairs using macros. What I have done is use Search and Replace Master to fix multiple assets with the same error in the config.txt files.

 

[pcas1986]

...
Can you clarify how both of these statements are true?

We do know that use of editors other than a plain text editors will leave unwanted ASCII characters in the config. This tends to break the parsing and throw up errors.

...

We always thought that the config.txt file was just a text file as the name implies but we were recently informed by the lead programmer that this is actually a compiled file that gets decompiled to text for us to see.
...

As John says, the config gets rebuilt as a new config.txt when an asset is opened for edit. The easiest place to spot some changes is in the kuid-table container. When a creator makes the original kuid-table, they only need to include kuids that have a label for identification in a script. Assets that are included for, say, a bogey container, or referenced mesh in the mesh-table container, do not need to be included in the original config. However, when the asset is opened for editing, Trainz will include all referenced kuids (assets) in the kuid-table.

As mentioned in an earlier post, some asset modifiers just include the original kuid-table in their version and that can invoke a dependency that isn't needed. That can be a bad thing as that unnecessary dependency could be faulty.

..

That's the stuff I'm talking about! If for no other reason than to plan out a program of work. Find commonalities, identify the low hanging fruit, &c

Unfortunately, AssetX is no longer supported but is usable by those who know its issues and can work with them. It's out of date for config tags, FBX files and cannot render PBR materials.

 

[ek.skirl]

The "bigly" advantage of Trainz over many other simulators is the user involvement in the creation of assets.

I'm fully hearted with you.

His assets work in the latest TRS22PE SP5 but if/when N3V makes LOD mandatory then he will probably stop creating.

I don't know yet if there is the need of more than one LOD but 1 LOD (the former one texture/mesh group should be not a graet deal. The only following to that is for me to to invent a kind of performance classes for assets, depending on mesh complexity, real world dimensions, and copunt of lods. So N3V is able to formulate a warranty to performance by using assets onwards a performance class. This lets creators create assets in low Lod level as well as in high lod levels.

If a built-in asset with a lower build number (below the 13 year old 3.7 standard or the new SP5 5.6 standard) still works then why not allow it to be included in TRS22?

What if in newer versions the assets get a newer identical asset with a higher (or special?) version number and after fullfilling its task in the newer Trainz version get the higher base version? This could be dane by the proof process and the creators will be informed at the newer version number if not a special version nummber (may be starting with 1000 or bigger if needed) will be used.

 

[JCitron]

What if in newer versions the assets get a newer identical asset with a higher (or special?) version number and after fullfilling its task in the newer Trainz version get the higher base version? This could be dane by the proof process and the creators will be informed at the newer version number if not a special version nummber (may be starting with 1000 or bigger if needed) will be used.

These assets would replace, meaning obsolete, the older versions. The only way around this would be to create a new asset by using a new kuid number for the new version of the same asset in order to preserve the old one.

The problem is there's a possibility that users will grab the older version of the asset if both are installed when creating a route or session instead of checking the kuid number first to tell which version to use. As you can see, this can lead to confusion and can become really messy to manage.

 

[RobWed]

These assets would replace, meaning obsolete, the older versions. The only way around this would be to create a new asset by using a new kuid number for the new version of the same asset in order to preserve the old one.

The problem is there's a possibility that users will grab the older version of the asset if both are installed when creating a route or session instead of checking the kuid number first to tell which version to use. As you can see, this can lead to confusion and can become really messy to manage.

Is this about not being able to obsolete someone else's asset? I did have a go at updating a 1.3 build asset of N3V's and put the original kuid in the obsolete table but the OG asset didn't come up as obsolete in CM.

 

[HiBaller]

... Well, if it ain't broke then it would be a trivial exercise to update the build number to 3.7 in every config.txt file. ...

As someone who has been programming since 1962, I cringe when someone says this. It brings on severe anxiety as soon as I hear it -- and I've heard it many times. Just to specify HOW one would go about searching out the content to apply your change to would be daunting. Database operations are not trivial, and you'd have to access each one, in turn, and make sure it gets put back into the DB properly -- but only AFTER you've run it through the current error checker to see if you've broken anything (and I can practically guarantee you will have errors). If you have, then another can of worms gets opened. You have to fix them first before re-storing just the one piece of content.

I wouldn't attempt it.

Bill

 

[JCitron]

Is this about not being able to obsolete someone else's asset? I did have a go at updating a 1.3 build asset of N3V's and put the original kuid in the obsolete table but the OG asset didn't come up as obsolete in CM.

No. There's a block in there to prevent others from obsoleting other people's content.

What the obsolete-table was for was to replace an existing asset with a new version by the same author. This was the standard practice before the kuid2 numbers were developed. With kuid2 numbers, the obsolete-table is obsolete and has been deprecated except for anything that can still use that, meaning old assets.

One of the issues with the obsolete-table was a simple typo in the kuid number would upset the applecart very quickly. Back in TRS2004, I had some mill buildings on a route that suddenly became navigational canal locks. A simple transposition between a 6 and an 8 turned the mill buildings into canal locks. It took another couple of days before this was rectified by the author uploading the corrected version.

With kuid2 numbers, version updates are done by changing the version number suffix found on the far right of the asset kuid.

This might help explain what I was saying here regarding the kuid numbers and how they are formatted.

KUID - TrainzOnline

online.ts2009.com

 

[RobWed]

No. There's a block in there to prevent others from obsoleting other people's content.

What the obsolete-table was for was to replace an existing asset with a new version by the same author. This was the standard practice before the kuid2 numbers were developed. With kuid2 numbers, the obsolete-table is obsolete and has been deprecated except for anything that can still use that, meaning old assets.

One of the issues with the obsolete-table was a simple typo in the kuid number would upset the applecart very quickly. Back in TRS2004, I had some mill buildings on a route that suddenly became navigational canal locks. A simple transposition between a 6 and an 8 turned the mill buildings into canal locks. It took another couple of days before this was rectified by the author uploading the corrected version.

With kuid2 numbers, version updates are done by changing the version number suffix found on the far right of the asset kuid.

This might help explain what I was saying here regarding the kuid numbers and how they are formatted.

KUID - TrainzOnline

online.ts2009.com

Thanks, John. The KUID format and its components is fairly straightforward. I do see obsolete tables in use by N3V where, presumably, one staff member is updating the work of another. Makes sense and you can see that in action repeatedly when you List Asset Versions. I'm unsurprised it's a privilege not bestowed on us mere mortals. Can't be having us turning someone's sword into a ploughshare. Or in your case, a mill building into a canal lock! Not that there's anything wrong with a canal. I quite like canals.

 

[johnwhelan]

Thanks, John. The KUID format and its components is fairly straightforward. I do see obsolete tables in use by N3V where, presumably, one staff member is updating the work of another. Makes sense and you can see that in action repeatedly when you List Asset Versions. I'm unsurprised it's a privilege not bestowed on us mere mortals. Can't be having us turning someone's sword into a ploughshare. Or in your case, a mill building into a canal lock! Not that there's anything wrong with a canal. I quite like canals.

Middleton with canal has a couple of the available locks and UK narrow boats.

Cheerio John

 

[JCitron]

Thanks, John. The KUID format and its components is fairly straightforward. I do see obsolete tables in use by N3V where, presumably, one staff member is updating the work of another. Makes sense and you can see that in action repeatedly when you List Asset Versions. I'm unsurprised it's a privilege not bestowed on us mere mortals. Can't be having us turning someone's sword into a ploughshare. Or in your case, a mill building into a canal lock! Not that there's anything wrong with a canal. I quite like canals.

I wouldn't doubt that N3V has the ability to do that for obvious reasons, however, any minus numbered asset is an Auran or N3V asset to start with and so are kuid:523 assets.

That was quite upsetting when it occurred and I posted up on the early forums about it. It was then I learned what the problem was that caused that issue.

 

[ek.skirl]

What if in newer versions ...

First I want to tell, that this post part should be a handling idea for newer future trainz versions, not a workaround for current. On the first fly I don't see that it breaks back wards compatibility.

The problem is there's a possibility that users will grab the older version of the asset if both are installed

This of course could be solved by adding a settings checkbox to allow older (obsolete) installed assets to be shown in the asset lists,

As you can see, this can lead to confusion and can become really messy to manage.

and than it lies in the hand of the users who need older asset versions. And there are additionally picklists possible for convenience.

These assets would replace, meaning obsolete, the older versions.

Hm. Realy? An existing objects in an existing session will automaticaly replaced with the newer object version without any permission? That i didn't notice yet, may of course by having no much routes/sessions created and imported from older Trainz versions yet.

 

[JCitron]

Hm. Realy? An existing objects in an existing session will automaticaly replaced with the newer object version without any permission? That i didn't notice yet, may of course by having no much routes/sessions created and imported from older Trainz versions yet.

Yes, this is what happens and this has always been the way the program works. A newer asset version will automatically obsolete the old one installed when the new asset is downloaded. The only way to prevent that is to not update assets. If there's a problem with the newer versions, we rarely run into that problem, by the way, and when it does, the old version can be downloaded from the DLS if needed.

It is recommended to keep assets up to date. Not doing so can lead to issues later on when a new Trainz service pack or version is released. Since TRS19 and up, many assets are updated to reflect the changes in the program. Not all assets, mind you, because updates are not always necessary but scripted assets especially need to be updated. With stricter error checking, this is most important as bug fixes in content are released.

Having a checkbox to select or not select a new version is yet another level for the user to think about. As complex as Trainz is, it's still relatively easy to manage content.

 

[Forester1]

John, do you know the mechanism whereby some assets automatically update (hence obsoletes show up in CM with no action), whereas other assets change to "Newer version available", and we need to manually download those? Just curious what causes it one way or the other.

 

[JCitron]

John, do you know the mechanism whereby some assets automatically update (hence obsoletes show up in CM with no action), whereas other assets change to "Newer version available", and we need to manually download those? Just curious what causes it one way or the other.

I have no idea either. I noticed that packaged and built-in require the extra step though. I wonder if this is the reason.