Why hasn't the thumbnail image path separator validation fault be fixed!

SailorDan

New member
"No thumbnail image found for the asset"

Just because I use a "\" as the separator in the thumbnail image file path instead of "/". This insistence on a non-standard separator serves no purpose and should be removed. It is inconsistent with stated policy to support both forms of separator. It has hung around for too long and needs to be dealt with.

We are coming up to 6 months since it was first reported, and still no action.

This insistence on the wrong form of separator also stuffs up the display of traincar icons in surveyor consist mode.
 
Since support for your last listed version has been dropped a year ago, that will not be fixed.

The solution is easy though: put those images in the root file of the asset (so next to the config file).
 
Since support for your last listed version has been dropped a year ago, that will not be fixed.

It's got nothing to do with the version I am using. Everyone who tries to upload is affected.

The solution is easy though: put those images in the root file of the asset (so next to the config file).

I know what the solution is. But CM (any version) won't report it as an error, so why does it get rejected in the upload?

If it isn't fixed now then the use of "\" will gradually become illegal, affecting all sort of file references. If the file is in a third party mesh library, for instance, how is that going to be allowed for? This is just an attempt to convert everything to MAC standards, and Windows users should be objecting NOW.
 
This is just an attempt to convert everything to MAC standards, and Windows users should be objecting NOW.

No, the "\" has been traditionally used by Windows but the "/" is the standard for the Web and is device and OS independent, and this probably makes it the more sensible choice.

The "/" was in use on Unix systems long before the Mac came along.
 
And to add the "/" (forward slash) also works on the PC now too as of Windows 8.x I think; it definitely works in Windows 10.
 
And anyway can't Windows users have a problem with something being supported for once?

It is... now.

The back slash "\" came about way back when directories were first created on disks. IBM wrote most of the utilities and commands which used the "/" or forwards slash character as a way to add arguments to the commands. You see people needed a way to navigate the directory structure and since the / was already used, the other slash was used. This all took place around 1982 or so, which is a long time ago and long before Apple OSx.

Here's a nice link you might like:

http://blogs.msdn.com/b/larryosterman/archive/2005/06/24/432386.aspx

Today this is still handled internally and redundantly, but it works fine with either slash. The problem with older versions of Trainz is this function may have been hard coded which is why there are errors today with the content because newer versions do not have this issue.
 
Today this is still handled internally and redundantly, but it works fine with either slash.

No it doesn't. No warning from CM, just a rejected upload. No updates to the documentation, no comments, no response to tickets.

Assetx defaults to the wrong format.

It started with the thumbnail image path, but it is now appearing in the other icons, affecting the consist display in T:ANE. How long before it works its way into every path in config or texture.txt files, requiring multiple fixes to thousands of assets. It's a pointless additional requirement that must be stopped now.
 
Are you certain that the "/" "\" "confusion" is the cause of the problem? Has anyone else been reporting this issue?
 
It's a pointless additional requirement that must be stopped now.

Since you claim that this is adapting everything to Mac standards, it is not pointless. Are you suggesting that ease of use for Mac users be stopped so you can solve a simple problem? It's time for Windows users to have to deal with something not working as well.
 
Last edited:
Since you claim that this is adapting everything to Mac standards, it is not pointless. Are you suggesting that ease of use for Mac users be stopped so you can solve a simple problem? It's time for Windows users to have to deal with something not working.

Didn't you see my post?

It does work on the PC now, but for older versions of Trainz like TS2010, where the interface may be hardcoded, it's not going to change because that product is long out of support and patches, besides when that was written it wasn't an issue.

The other thing too is this issue may not all be related to the /-thing. Some users hardcoded implicit paths to directories (folders) on their own computers then uploaded the asset to the DLS. When the asset is up on the DLS, the asset is now considered faulty because this isn't a logical path like it's supposed to be, it also has a path pointing now to a non-existent folder.

Here's an example. There were some assets that I have come across in my travels that had thumbnails pointed to in content-creator's My Documents folder. The creator used the following notation which is correct for a local install because it's an implicit path to this specific location.

Similar to this:

"..\..\..\users\My Documents\pictures\thumbnail.jpg"

What the ..\..\.. is going is backing up the directory tree to the root of the drive. Yes, the top level in Unix/Linux, and DOS/Windows is called the root. The rest of the path is self-explanatory as it then points to the users\My Documents\pictures\thumbnail.jpg

The problem now is when this asset is moved to another computer, it will fail because the new owner of this asset does not have a thumbnail image in their \users\My Documents\pictures folder, or may not even have this setup at all.

Going forward, It think with TS12 and up, placing thumbnails outside of the top-level folder for the asset causes an error, and rightly so. This prevents this situation, and prevents images from getting lost.
 
Going forward, It think with TS12 and up, placing thumbnails outside of the top-level folder for the asset causes an error, and rightly so.

ONLY if the Windows separator is used and ONLY in DLS upload. If this is the new standard it should be documented and it should be part of CM validation. There are many reports, some dating back to last May.

This asset: PON P70 Coach 3,<kuid2:522774:100288:2> has the following in the thumbnails container.

Code:
  1
  {
    image                               "cn_p70_coach_art\cn_p70_coach_art_icon.texture"
    width                               128
    height                              64
  }

In T:ANE HF1 create a consist that uses this asset. Note how it looks in the consist display in surveyor and driver. Now adjust the "\" for the icon to "/". Look at it in the consist view again. This sort of undocumented creeping change is what frustrates developers. For the icon it is a display detail. If it migrates to other paths it will affect the functionality.
 
ONLY if the Windows separator is used and ONLY in DLS upload. If this is the new standard it should be documented and it should be part of CM validation. There are many reports, some dating back to last May.

This asset: PON P70 Coach 3,<kuid2:522774:100288:2> has the following in the thumbnails container.

Code:
  1
  {
    image                               "cn_p70_coach_art\cn_p70_coach_art_icon.texture"
    width                               128
    height                              64
  }

In T:ANE HF1 create a consist that uses this asset. Note how it looks in the consist display in surveyor and driver. Now adjust the "\" for the icon to "/". Look at it in the consist view again. This sort of undocumented creeping change is what frustrates developers. For the icon it is a display detail. If it migrates to other paths it will affect the functionality.

You are right here...

Report it using the bug reporting link for the help desk. The same issue for T:ANE HF2.
 
What I am thinking happened is the forward slash as well as backslash support was updated in other data locations but not the one for the small art-icon used for consists. The issue in this example, though is for an asset which dates back to the TS2006 days. I think, and I'm not sure about this, but the whole art-folder setup was removed after that maybe during the TS2009, or maybe TS2010, I can't remember. The problem is we still have assets floating around from UTC days where the older data structure was the norm, therefore, code should still support that path as well, and perhaps throw up a warning in CM if it is encountered.

Perhaps something like this:

"The use of the art folder is no longer supported in Trainz Build 4.x." Please update the asset to remove this... Loading defaults..." etc.
 
"No thumbnail image found for the asset"

Just because I use a "\" as the separator in the thumbnail image file path instead of "/". This insistence on a non-standard separator serves no purpose and should be removed. It is inconsistent with stated policy to support both forms of separator. It has hung around for too long and needs to be dealt with.

Already reported and ignored:
http://forums.auran.com/trainz/showthread.php?123045-Internal-test-build-78602&p=1444445#post1444445
 
Back
Top