Assets version

[peeet2005]

I would like to ask honorable specialists about the matter of assets numbering. Specifically, the question is, where was the need to introduce the number 4.7 for version SP3 TRS19. In SP1 it was the number 4.6 and what was the reason for the increase of the number for SP3? Was it to force the developers to use SP3, although it is in some respects less convenient than SP1?
I will show on my example that I started a certain route under SP3, but for some reasons I prefer to use it under SP1. Unfortunately, some additions were in version 4.7 and were not visible under SP1 There is a maximum of version 4.6 there. Interestingly, the game under SP1 did not signal that something was missing, it just assumed that it was not there and it was OK. I made more changes to the route I noticed there are some traction poles missing, no portal gates or jib overhangs and it took a while before I figured out the reason for the disappearance.
There is a good proverb - do not move a good one because it turns out that the worse was better.

 

[HPL]

SP3 is 4.8.

 

[1611mac]

If you plan on running in SP1 you need to build in SP1. SP1 routes will work in SP1, SP2, and SP3. But SP2 and SP3 will not work in SP1. N3V makes things backward compatible but not "future" compatible.

 

[Forester1]

I think it is a great question he is asking. Is it truly necessary to bump the version number with every service pack? Is there something about the assets that makes them so greatly different every time? Yes, you can't make SP1 use versions from SP2 and SP3, but what is it in SP2 and SP3 that makes new versions necessary every time. I wonder especially in the case of .fbx files, which as far as I can see breaks everything in SP3 that has them. Every faulty I have come across in SP3 has been because of .fbx files, and often deleting the .fbx files makes them OK.

 

[Alikiwi]

Build 4.7 is in fact SP2. I have already said, that 3 build versions in ONE version of the game ie TRS19 is crazy. Given the issues of not being backwards compatible, I'm sticking to building routes etc in SP1 so they are useable in every version/build of TRS19. As to why they do this, I presume it's because of significant changes to the coding to try and fix problems, don't get me started on that one

 

[grazlash]

3 build versions of TRS19 is driving you nuts? I didn't hear any complaints about the 6 build versions of TANE, 7 if you count TMR17
Graeme

 

[JCitron]

The version change was due to internal file changes that took place after the introduction of MPS. This is not unusual with Trainz as Graeme has pointed out. TRS2004 had multiple build numbers. TB 2.0-2.4, for example.

Backward compatibility is not always guaranteed due to internal code changes. This is not unusual and is not inherent to N3V.

 

[pware]

I wonder if anyone who is still using Word for DOS (v1 to 6) would expect to be able to load and edit documents created in Word 2019. An extreme example I know, but the principle is the same.

Many SP updates in Trainz have made significant changes to file formats which makes the new files unusable in earlier releases. There are users here for whatever reasons prefer to not upgrade when a new SP is released. That is perfectly fine as long as they realise that they will be restricted to using routes created in their current SP version and earlier. Personally I have always updated to the latest SP whenever it is released and only once have I been "burnt" by the experience (T:ANE SP1 was the culprit if I recall correctly).

As for the suggestion that faulty assets can be repaired by deleting files from the asset, that is "crazy talk". It reminded me of a scam that went around the Internet a few years ago that you could make Windows work "better" by deleting a particular file from the system folder - it was claimed that the file was actually a virus. Those who fell for it discovered that they could no longer use files that had filenames longer than 8 characters.

 

[Forester1]

It may be crazy talk, but I have had multiple faulties that "magically" quit showing as faulty when the .fbx files were deleted. I even have a folder on my hard drive for the .fbx files that were copied out before deleting in case I had to put them back. So I guess my question is, if this is "crazy talk" why is it working, and why is having a .fbx file in SP3 making assets faulty?

butoir.fbx
cab.fbx
ejectorhandle.fbx
indbrake.fbx
regulator.fbx
reverser.fbx
water.fbx
wheel.fbx

All removed from assets that now no longer show as faulty.

 

[pware]

Like removing the battery from your smoke detector stops it going off and annoying you but it doesn't stop the fire from breaking out. It could very well be that removing the .fbx files simply stops the normal fault detection process but the faults are still there.

 

[ZecMurphy]

Hi All
The trainz-build number changes when an update/patch/new release introduces changes to Trainz formats. This may be a change or addition to tags in config.txt files (ie adding a new tag), or when an internal file format changes (ie the formats for route files). Why this happens can be a lot of things, it could be that we've fixed a bug that affects routes, or added a new feature for creators to use, or it may be for other reasons.

For routes, and similar, we do not guarantee that a route built in a particular version of Trainz will work in an earlier one (ie a route built in TRS19 SP3 is not guaranteed to work in TRS19 SP2, and no support is provided for this), since even minor changes to route formats for bug fixing can be problematic if you try to use them in an earlier version.

In regards to the FBX files, we have found that a large number of creators were ignoring errors being shown during submitting of their assets in earlier TRS19 releases. These are errors that affect the conversion of the FBX file to the .trainzmesh file (ie may cause part of the mesh to be invisible, or other issues), and so can only be detected during the submit process. With the latest updates, these errors will now cause the asset to not submit.

If a trainzmesh file is present, then deleting the FBX files will allow the asset to be submitted (as it will not try to convert the FBX to a trainzmesh now). However of course any mesh issues would remain present in the trainzmesh files.

Regards
Zec

 

[Forester1]

Thanks for the clarifications Zec. And yes, this will probably come around to haunt me, which is why I kept the .fbx files, but it sounds like the creators will have to provide updates, as restoring the .fbx files will still result in faulty. Good to know it is not SP3 itself.