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

[RobWed]

I got curious about the trainz-build numbers of the various assets I have...

I have

• the base game (TRS22),
• the DLC it came bundled with because I bought PE,
• the free stuff on the store, and
• a few routes I downloaded hoping that I might not smack into the missing asset wall.

Here's the results:


I think the conclusions are fairly obvious but just in case, here's a couple of interesting ones;

• N3V continue to use unsupported assets in new products
• The currency of built in and packaged assets is not noticeably different from the DLS. Which is interesting as the DLS must have a significant number of assets on it that the original creator has walked away from.

I now have so many questions.

• If 3.7 is the minimum supported Trainz build, why are N3V selling me stuff that is unsupported?
• If 3.7 is the minimum supported Trainz build, why are updates breaking content with a minimum build number of 3.7?
• If N3V decide to package user made content into the base game or DLC how does that change the relationship between the creator and N3V?
• If N3V decide to package user made content into the base game or DLC, what responsibilities do they have to ensure all content is supported?

Now to be clear, I am not a supporter of extended backwards compatibility. So I have no problem with a minimum build number. However when I buy the latest product, it doesn't seem unreasonable to expect that the content I'm buying would all be of the minimum supported version.

I'm also a fan of "If it ain't broke, don't fix it". I expect some of you will be reaching for that as an explanation. 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. That would be the real determinant of 'broke'!

But let's be honest, at least some of the stuff packaged with TRS2022PE is most definitely broke. And not all of the broken stuff is 3.6 or earlier.

 

[RobWed]

Don't know why that image failed to embed...

 

[2995Valliant]

I have a number of hobbies I've pursued for many years, and it always makes me smile when someone new comes along and tells us all how it should be done

IMHO backward compatibilty is one of Trainz greatest strengths. I have been building/rebuilding and using some of my routes for over 20 years. I woud not want to start over every few years when a new version came out!

What benefit would come from your supposedly trivial excercise in updating pre build 3.7 assets and have you seen how many there are on the DLS? What benefit would changing the build number bring on your opinion? It wouldn't change the performance or appearance of the asset, but would in many cases break it as it would not pass the error checking requirements for higher build versions, so ultimately you'd end potentially doing a lot of work to each single asset for no gain.

I haven't got anything I'm aware of that's packaged with TRS22 that's broken - any examples please?

 

[pware]

• N3V continue to use unsupported assets in new products
• The currency of built in and packaged assets is not noticeably different from the DLS. Which is interesting as the DLS must have a significant number of assets on it that the original creator has walked away from.
• If 3.7 is the minimum supported Trainz build, why are N3V selling me stuff that is unsupported?
• If 3.7 is the minimum supported Trainz build, why are updates breaking content with a minimum build number of 3.7?

By "unsupported" I am guessing that you mean below the build 3.7 cutoff? Any assets that are built-in and below that cut-off (I have nearly 2000 of them in Trainz Plus) have been "modified", mostly compressing their texture files and a few other tweaks, so that they work efficiently and correctly in Trainz Plus/TRS22. So being below the "support level" is not an issue.

Assets below the 3.7 cutoff (TRS12 SP1) are still supplied as built-in because many users still use older routes created before TRS12 in TRS12, TANE, TRS19 and probably even earlier. They are still on the DLS because many users still use older routes and versions of Trainz for which these assets are crucial and still work.

The minimum supported build of 3.7 actually refers to the minimum build that the DLS will accept as new uploads. N3V have stated, on at least one occasion, that the older builds are still on the DLS for those users who need them BUT they do not give any guarantees that these assets will always work with the newer Trainz releases - many (or even most) of them probably will work but some will not.

But let's be honest, at least some of the stuff packaged with TRS2022PE is most definitely broke. And not all of the broken stuff is 3.6 or earlier.

I have TRS22PE installed and not a single asset, built-in or from the DLS, is "broke".

 

[stagecoach]

Unsupported.
3.7 is the minimum, does not refer to the assets, just the Trainz version.
Some assets have been updated but still show the older build versions.

 

[RobWed]

I have a number of hobbies I've pursued for many years, and it always makes me smile when someone new comes along and tells us all how it should be done

You don't do yourself any favours by trying to trivialise my approach. New eyes see things old eyes have grown accustomed to.

IMHO backward compatibilty is one of Trainz greatest strengths. I have been building/rebuilding and using some of my routes for over 20 years. I woud not want to start over every few years when a new version came out!

Just so we're clear, I'm not saying no backwards compatibility. By all means have historical assets in the DLS for those who use earlier editions. I don't expect anyone to have to keep buying the latest version. What I am saying is that I understand why N3V would want to limit ongoing support for earlier versions. No-one expects a modern rail company to keep a maintenance workshop for steam locomotives.

What benefit would come from your supposedly trivial excercise in updating pre build 3.7 assets and have you seen how many there are on the DLS?

Some of these tasks could absolutely be automated. Hence trivial.

What benefit would changing the build number bring on your opinion?

You've answered your own question in your next sentence.

It ... would in many cases break it as it would not pass the error checking requirements for higher build versions.

So if it's not broken how could it fail the error checking tests?

I'm not talking here about legacy assets for legacy games. I'm talking about TRS22PE. Why shouldn't I expect all the built in assets for this version to meet the current game standards? Same for the DLCs which are sold as Trainz22 DLC. As far as I can tell the packages all have the same number regardless as to whether they are promoted as T:ANE, TRS19, or TRS22.

 

[RobWed]

By "unsupported" I am guessing that you mean below the build 3.7 cutoff? Any assets that are built-in and below that cut-off (I have nearly 2000 of them in Trainz Plus) have been "modified", mostly compressing their texture files and a few other tweaks, so that they work efficiently and correctly in Trainz Plus/TRS22. So being below the "support level" is not an issue.

So they modified the files within the assets but didn't update the build number? How does that fit into the principle of version control? What do these updates do for the people who use these files in their legacy games? I'm going with forward compatibility wasn't built into any of the legacy editions.

Assets below the 3.7 cutoff (TRS12 SP1) are still supplied as built-in because many users still use older routes created before TRS12 in TRS12, TANE, TRS19 and probably even earlier. They are still on the DLS because many users still use older routes and versions of Trainz for which these assets are crucial and still work.

I'm not objecting to that. I'm objecting to the idea that assets that have the potential to fail contemporary tests are being sold as part of Trainz22, specifically when it's DLC marketed as for Trainz22

I have TRS22PE installed and not a single asset, built-in or from the DLS, is "broke".

• xBUe railway crossings found in Schwaninger Land. Pretty confident that one's broken given the comments I read whilst scouring Trainz.de site trying to learn how to make it work.
• DBSig. That one even pops a window to say it is u/s
• Possibly VSM signalling and Enhanced Interlocking Towers in concert, although that could be my lack of experience. I can get VSM working fine using AutoDrive and CJ3 and I can get EIT working fine with American signals but when I try to get EIT to be Signalman for me in Schwaninger Land all the points get switched but all the VSM signals controlled by the tower are red and the trains just bomb straight through, no emergency braking.

 

[pware]

I'm objecting to the idea that assets that have the potential to fail contemporary tests are being sold as part of Trainz22, specifically when it's DLC marketed as for Trainz22

But they do not fail the compliance tests for TRS22 so they are still useful. The alternative would be to have every built-in, DLC and DLS asset that works in TRS22 despite having a build number below 3.7 renovated/rebuilt/upgraded to 3.7 standard or to 5.1 standard for TRS22. This would be an issue since TRS22 SP5 is now at asset build number 5.6 so the renovation/rebuilding/upgrading of all assets would have to occur after every SP release.

A problem will eventually come if/when N3V start to insist that all visible assets have built in LODs. At that time a large number of very popular and useful older assets will be rejected. Who is going to undertake the task of adding LODs to every one of them or do we carry on with a much smaller set of available assets?

I don't agree with your premise that all assets released in TRS22 DLC must be at a minimum build number, be it 3.7 or (worse) one that matches the current release SP level. My opinion.

 

[pcas1986]

...
Some of these tasks could absolutely be automated. Hence trivial.

...

Wow! I wish I could have asked you to join the CRG back in 2016 as you would have saved me and the other members many thousands of hours repairing several thousand assets. Yes, some of those "repairs" were trivialised to some extent by the PEV and Andi Smith tools in AssetX but there was a lot of testing and validation by other members. We were only repairing non Auran assets.

Despite repairing all those assets, the CRG still has some 26,047 broken assets to repair. We look forward to seeing your CV, references and other recommendations when you apply to help us out. We did get the figure down to around 5000 in the early days but N3V keep upping the validation.

BTW, if you think repairing assets is easy I have spent the last 15 months repairing just 50 of Andi Smith's assets, most of which were TB 2.4, and I worked on them most days.

I thought your original post was rather interesting. Not so sure about your comments since then.

 

[RobWed]

Unsupported.
3.7 is the minimum, does not refer to the assets, just the Trainz version.
Some assets have been updated but still show the older build versions.

I'm intrigued by this. An effort was made to bring some assets up to current standards but the build version was left untouched? What is the problem with using the versioning system as built? The legacy people might get a message that a newer version is available but the newer version could have "For TS12 SP1 and later" appended to the name so they know not to download it.

Also, if this is the case, is there an actual difference between the contents of, say, T:ANE Trainz Route: Settle and Carlisle and Trainz 2022 DLC - Settle and Carlisle? Because as far as I can work out the route only has one package number and packages seem to contain an single asset, the rest presumably downloaded through the DLS.

 

[RobWed]

But they do not fail the compliance tests for TRS22 so they are still useful.

How do they test for compliance if they don't update the build number? I recall reading on N3V's site that updating a build number in config.txt will not necessarily make something fit for that build version but will expose it to more sophisticated error checking. It sounded very much like the first step in upgrading an asset was to update the build number and see what errors and warnings that threw up. There's your upgrade workflow right there. I just did it with Bulk Load, which had no build version at all but was showing as 1.3. Added the build tag 3.7, put it's kuid in an obsolete table and gave it my own kuid. That just threw the warning about 'asset-filename' being an obsolete tag.

The alternative would be to have every built-in, DLC and DLS asset that works in TRS22 despite having a build number below 3.7 renovated/rebuilt/upgraded to 3.7 standard or to 5.1 standard for TRS22. This would be an issue since TRS22 SP5 is now at asset build number 5.6 so the renovation/rebuilding/upgrading of all assets would have to occur after every SP release.

I didn't suggest all DLS assets need to be updated. Nor did I say that ALL DLC assets needs to be built to 5.1. I did say that I'm a supporter of the principle of 'if it ain't broke..' I just think that N3V should apply the same expections on itself as it does on content creators.

A problem will eventually come if/when N3V start to insist that all visible assets have built in LODs. At that time a large number of very popular and useful older assets will be rejected. Who is going to undertake the task of adding LODs to every one of them

A little tangent here before I come back to the point. I've spent the last 40 days in Schwaninger Land. I chose this route for my learning development as it's a great looking route with lots of opportunities to complete it and to extend it. I downloaded a German DMU from the DLC to test the work I'd done on a non-electrified branch line. It's build 2.3. It throws warnings about the lack of LODs. I've grown kinda fond of it and so I looked at the license and it's freeware. I found the VE error table and what each error number means. What I couldn't find was info on how to go about resolving the errors.

or do we carry on with a much smaller set of available assets?

We're already carrying on with a smaller (or, at best, a shifting) set of assets. Code gets updated. Things break. OG creator may not be around any more.

I don't agree with your premise that all assets released in TRS22 DLC must be at a minimum build number, be it 3.7 or (worse) one that matches the current release SP level. My opinion.

That's cool. This is only my opinion, too!

 

[johnwhelan]

I got curious about the trainz-build numbers of the various assets I have...

I have

• the base game (TRS22),
• the DLC it came bundled with because I bought PE,
• the free stuff on the store, and
• a few routes I downloaded hoping that I might not smack into the missing asset wall.

Here's the results:


I think the conclusions are fairly obvious but just in case, here's a couple of interesting ones;

• N3V continue to use unsupported assets in new products
• The currency of built in and packaged assets is not noticeably different from the DLS. Which is interesting as the DLS must have a significant number of assets on it that the original creator has walked away from.

I now have so many questions.

• If 3.7 is the minimum supported Trainz build, why are N3V selling me stuff that is unsupported?
• If 3.7 is the minimum supported Trainz build, why are updates breaking content with a minimum build number of 3.7?
• If N3V decide to package user made content into the base game or DLC how does that change the relationship between the creator and N3V?
• If N3V decide to package user made content into the base game or DLC, what responsibilities do they have to ensure all content is supported?

Now to be clear, I am not a supporter of extended backwards compatibility. So I have no problem with a minimum build number. However when I buy the latest product, it doesn't seem unreasonable to expect that the content I'm buying would all be of the minimum supported version.

I'm also a fan of "If it ain't broke, don't fix it". I expect some of you will be reaching for that as an explanation. 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. That would be the real determinant of 'broke'!

But let's be honest, at least some of the stuff packaged with TRS2022PE is most definitely broke. And not all of the broken stuff is 3.6 or earlier.

Some scenery assets with a build number of 2.4 work fine all the way up to TS22 SP5. The major problem comes in assets that use scripts and other complicated assets. Also reskins are a major problem. There are more than 500 assets on the DLS which need updating in the config.txt file or mesh. I can't update them as they are reskins of my work. The reskinner probably doesn't understand enough to be able to make the changes.

Scripting seems to change on every version of Trainz and let's face it with 2,000 assets on the DLS I'd probably spend all my time updating them which might not be my favourite thing to do. The work fine with the version of trainz they were designed to work with.

Cheerio John

Cheerio John

 

[stagecoach]

You seem to have got a little confused. 3.7 is the build number that the asset was originally created and uploaded with. The version number is the last set in the kuid number. The package contains all the required dependencies for the route or asset as of the time it was created. Some of those assets may have been updated on the DLS or are also on the DLS. Some of those assets dependencies may have been updated. The package is only correct at the time it was created.
Older builds of Trainz often allowed things through the process that newer builds won't, so correcting them to the latest version may even work better in the older builds.

 

[RobWed]

Wow! I wish I could have asked you to join the CRG back in 2016 as you would have saved me and the other members many thousands of hours repairing several thousand assets. Yes, some of those "repairs" were trivialised to some extent by the PEV and Andi Smith tools in AssetX but there was a lot of testing and validation by other members. We were only repairing non Auran assets.

Despite repairing all those assets, the CRG still has some 26,047 broken assets to repair. We look forward to seeing your CV, references and other recommendations when you apply to help us out. We did get the figure down to around 5000 in the early days but N3V keep upping the validation.

BTW, if you think repairing assets is easy I have spent the last 15 months repairing just 50 of Andi Smith's assets, most of which were TB 2.4, and I worked on them most days.

I thought your original post was rather interesting. Not so sure about your comments since then.

Please don't take my comment out of context. What I said was "it would be a trivial exercise to update the build number to 3.7 in every config.txt file" Update the build number because, from either the online.ts2009 site or the wiki, I read that it is the first step in upgrading an asset: Update the build number and see what errors or warnings it throws. Trivial because the config file is a text file and a batch file can be written to move through directories, open the file, find the tag, and replace the number. In no way am I suggesting that that is the only work required to update an asset. Perhaps trivial was a poor choice of word.

At no point was I suggesting the work you and the CRG are doing is trivial. I understand full well the benefit I get from you doing the work you do. Same goes for all the content creators. In fact I'm pleased you are still doing it. I was on Download Station Cleanup page the other day and saw "Further information about this process, including the public repair list, is available from the Download Station Cleanup Index Page". I thought I could at least take a look and see what needs doing and what I might apply my meagre talents to but the link took me to the Auran splash page so I assumed the Cleanup was washed up. Apparently I was mistaken!

 

[RobWed]

Some scenery assets with a build number of 2.4 work fine all the way up to TS22 SP5. The major problem comes in assets that use scripts and other complicated assets. Also reskins are a major problem. There are more than 500 assets on the DLS which need updating in the config.txt file or mesh. I can't update them as they are reskins of my work. The reskinner probably doesn't understand enough to be able to make the changes.

Scripting seems to change on every version of Trainz and let's face it with 2,000 assets on the DLS I'd probably spend all my time updating them which might not be my favourite thing to do. The work fine with the version of trainz they were designed to work with.

Cheerio John

Cheerio John

Cheers John.
I wasn't talking about content creators. I'm absolutely fine with you leaving your assets at the version of Trainz they were designed to work with. Or updating them. The choice is yours. It's a win for me either way.

I was talking about N3V.

 

[RobWed]

You seem to have got a little confused. 3.7 is the build number that the asset was originally created and uploaded with. The version number is the last set in the kuid number. The package contains all the required dependencies for the route or asset as of the time it was created. Some of those assets may have been updated on the DLS or are also on the DLS. Some of those assets dependencies may have been updated. The package is only correct at the time it was created.
Older builds of Trainz often allowed things through the process that newer builds won't, so correcting them to the latest version may even work better in the older builds.

Not confused. At least I don't think so...
I think I didn't phrase my questions clearly. It's late here. It was actually two questions

You said some assets were updated for TRS22 but the build number was not updated. I was wondering why something would be updated for TRS22 but the build number wasn't changed to reflect that. Because it would be possible to make those changes to the asset contents, update the build number and publish it with a new version number. Asset still exists for legacy users alongside an updated version to carry forward with.

The second question was about the packages and your answer is precisely what I wanted to know! I have some DLC on my wishlist and was given some advice (might have been by you) on how to best obtain them. I was concerned because each of them is marketed on Steam as Trainz2022 DLC and I was concerned I might be doing myself a disservice if I bought them bundled in an earlier edition of Trainz.

 

[johnwhelan]

Please don't take my comment out of context. What I said was "it would be a trivial exercise to update the build number to 3.7 in every config.txt file" Update the build number because, from either the online.ts2009 site or the wiki, I read that it is the first step in upgrading an asset: Update the build number and see what errors or warnings it throws. Trivial because the config file is a text file and a batch file can be written to move through directories, open the file, find the tag, and replace the number. In no way am I suggesting that that is the only work required to update an asset. Perhaps trivial was a poor choice of word.

At no point was I suggesting the work you and the CRG are doing is trivial. I understand full well the benefit I get from you doing the work you do. Same goes for all the content creators. In fact I'm pleased you are still doing it. I was on Download Station Cleanup page the other day and saw "Further information about this process, including the public repair list, is available from the Download Station Cleanup Index Page". I thought I could at least take a look and see what needs doing and what I might apply my meagre talents to but the link took me to the Auran splash page so I assumed the Cleanup was washed up. Apparently I was mistaken!

It is not a trivial exercise "to update the build number to 3.7 in every config.txt file." Different build numbers have different error checking. The way dependencies are referenced is different.

John

 

[JCitron]

Rob,

Many people have made the same comments you have. Hopefully, I can explain how this came about.

Back in the early days of Trainz, little or no error checking took place. Assets were created by the developers and content-creators replicated them. This is why we have so many box cars, passenger cars, buildings and so on with early version numbers, plus any dependencies needed.

The program would take these assets, and many more that were created once N3V licensed G-MAX with Trainz to allow users to create more assets along with providing the infamous but famous PaintShed to allow easy reskinning, and process them without checking for errors. Some assets would load up okay, albeit, with a lot of performance hits, while others would outright crash the program to the desktop. Many of us remember using Save-As instead of Save because there would be a program error and a possible CTD. While the undo-function was available, don't use it too many times otherwise you'd have a bowl of spaghetti with all the splines going haywire. This latter issue has made many of us leery about pressing CTRL+Z too many times even today. These errors, in addition to causing random CTDs and other weird bugs, will hurt the program performance overall due to the program needing to horse-through and ignore any errors as it attempts to load the assets.

Starting with TRS2006, an initiative was made to error check content and prevent faulty assets from loading. In some ways, this was the beginning of the DLS cleanup. The error-checking, while pretty tame back then, sent a lot of content creators to the hills never to return. The errors though, were there and some are pretty interesting. If you ever download some older unchecked assets from third-party sites, you'll see some of them firsthand.

The policy set then which is still true today is assets are error-checked at the version level they are created at. This is to allow for backwards compatibility. As long as an asset meets the error-free status of the build it was created at, then it'll load fine in the current version. That doesn't mean that an asset will always work in some future version. The warnings you see regarding the unsupported versions have nothing to do with program support. This is a reminder and note to the asset creator to update their assets and to warn the user that the asset may not work someday in the future whenever that may be.

Taking an asset that is error-free at version 2.4 and upgrading the same asset to version 5.6 can cause many errors due to version 5.6 error-checking halting on obsolete functions. The opposite is true if newer capabilities are added to an older asset while keeping the asset at its lower version number. This is due to newer functions and capabilities not being known to the compiler at the time the asset was created.

Yes, some older assets have been upgraded to the current standards while still keeping them compatible with older versions. These happen to be simple assets such as buildings or other scenery-type assets. Those with scripts will fail due to unknown functions at their build-level. It's interesting to note that such things as LOD were actually available in earlier versions, but users ignored it until they were forced to implement it in T:ANE and up.

As time has gone on, error-checking has become stricter and less forgiving as part of the continued effort to make the program operate reliably and smoother. This is why the German signals don't work and that level crossing doesn't work properly. Since T:ANE, script-errors are now enforced due to performance issues seen in the past. Scripts will now timeout, if they use large tables for instance, or have other compiler errors. Initially, these errors were warnings and as has been stated by N3V warnings can become errors at some point. The issue we have with this is N3V did not provide advance notice that that build was going to be the one where these scripts used by these assets and many, many more than these would no longer work. This is why the CRG now has so many more assets to repair and rather suddenly too.

The config.txt file as much as we think it as just a text file, it is not. It's actually a file that gets compiled by the program when an asset is submitted and decompiled for editing and Content Manager will throw up (a good term) error messages. The text in this file could be laid out in one string but is set up the way it is for our clarity, however, the component blocks, aka containers, and tags - lines, must comply with a specific format. In some ways, this could be thought of as an xml file before xml was developed. I find the formatting to be similar to JCL from when I used to edit the files to run jobs on an IBM mainframe a couple of decades ago.

With that in mind, there were numerous errors, while simple to fix, populated many assets due to typographical errors in the config files. Since the assets were replicated, these same errors could be found across a whole slew of assets created by a single person, or people if they used one of these as a base. I encountered these while updating assets I imported from previous versions into TS12 and up.

- Errors such as catigory instead of category and other spelling errors such as desicription.
-Double sets of quotes causing text to move out of place, causing weird things to happen.
-Full mesh-tables and other information placed in the obsolete-table.
-Missing quotes
- A missing curly bracket or brackets causing weird things to happen.
-The user used the tab-key to move the cursor into position instead of the space key causing columns to break and other errors.
-A full implicit path to textures located somewhere else instead of the local path for an asset.
-Missing file extensions.
-Using whole numbers or real numbers where a binary 1 or 0 for true/false enabling. isfreeway 9 instead of isfreeway 1 was a common one.
-Incorrect references to non-existent meshes. The mesh referenced belongs to the original asset but was never updated to reference the new one.

Due to the assets being cloned these other errors occurred as well.
-Missing textures. Since the program horsed through these, there would be white spots.
-Incorrect dimensions not the power of two.
-Incorrectly referenced textures in the texture.txt file
-The same script errors.

and so many more.

 

[pware]

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?

 

[wreeder]

"minimum build number (3.7)" is misleading. As I pointed out in a post above, this limit is for uploads to the DLS only.

N3V backed off from this policy. Now any build number can be uploaded to the DLS but anything under 3.5 is not visible in Content Manager but will download if it is a dependency of another asset. Any asset that is faulty is bounced to the CRG queue for repair and updating to build 3.5 to make it visible for downloading.