TrainzUtil asset status flag "Y" - what does it mean?

[deneban]

TRS19 added a new "Y" flag to the TANE version of the TrainzUtil asset status argument, but I can't seem to find out what it means.

TANE asset status flags : EIABDPLMFOUXC
TRS19 asset status flags: EIABDPLMFOUXCY

TrainzUtil has been recompiled / resigned 3 times for TRS19, but the programmer never added the "Y" definition flag to the TrainzUtil Help output.

Anybody know what a "Y" or "y" flag indicates for an asset status?

 

[JCitron]

What do the other status flags mean?

 

[clam1952]

Wiki doesn't help re Y either as you can see from this extract! however.

• Aa - The asset is archived.
• Bb - The asset is builtin or packaged content.
• Cc - The asset is in the base content set.
• Dd - The asset is on the download station.
• Ee - The asset is open for edit.
• Ff - The asset is faulty.
• Ii - The asset is installed locally.
• Ll - The asset is locally modified.
• Mm - The asset has missing dependencies.
• Oo - The asset is obsolete.
• Pp - The asset is listed in the DLS index as payware DLC.
• Uu - The asset has an update available.
• Xx - The asset is authorised for use in this Trainz installation.
• Yy - Unfortunately the TrainzUtil Help command does not indicate what a "Y" flag means

 

[pware]

Could it be Y = "Yuletide"?

EDIT: On a more serious note, perhaps put in a bug report?

 

[deneban]

Wiki doesn't help re Y either as you can see from this extract! however.

Correct, I essentially wrote that Wiki page :hehe:

Could it be Y = "Yuletide"?

Exactly, as in "You'll Tidy" me up with the answer guys. Need to know for my RMAN asset renaming utility, it makes renaming decisions based on an asset's status flags, so its best if I know it the "Y" flag affects the re-namability / re-commitability of an asset.

EDIT: On a more serious note, perhaps put in a bug report?

I was thinking that also - I might have to get someone to tap a programmer on the shoulder and interrupt them to look at the source code (which has potential for creating a future bug), but asking the community is a good first step.

 

[pcas1986]

I did try a few combinations tonight and the "Y" always came in uppercase (true) so I was none the wiser. If I can think of more test cases I'll try again tomorrow.

 

[JCitron]

I think it means Yup.

 

[deneban]

I did try a few combinations tonight and the "Y" always came in uppercase (true) so I was none the wiser. If I can think of more test cases I'll try again tomorrow.

Thanks for your efforts Paul.

I think it means Yup.

By the way, it is unlikely the thing it represents begins with a Y because over half the alphabet was already used in TANE.

 

[JCitron]

...By the way, it is unlikely the thing it represents begins with a Y because over half the alphabet was already used in TANE.

Or better yet, it represents something that doesn't even begin with the letter Y. I've run into that with other programs and operating systems with the least intuitive switches.

 

[pcas1986]

I tried a number of different assets and the result was always true. About the only thing I can think of is some status regarding MPS but AFAIK all that information is on the cloud and nothing local.

 

[BummerDude]

Maybe setting up for a future feature?

 

[deneban]

I tried a number of different assets and the result was always true. About the only thing I can think of is some status regarding MPS but AFAIK all that information is on the cloud and nothing local.

Thanks Paul -- Multiplayer is certainly a possibility (it has a Y in it while M and P are already used), also the in-game content store, things that TANE didn't have would be where to speculate. TrainzUtil does have a number of arguments that invoke network communications, so it would be nothing new for it to query the cloud to give us an asset's status string. So far your MPS theory sounds the most plausible.

I am going to wait a few more days on this thread for a positive confirmation before submitting a ticket. (Also I will request a revision to recompile the command so the Help argument output does not neglect "Y"). Last resort is to write a program or TrainzUtil batch file that queries the cloud for a lowercase "y" status, RMAN has some pertinent routines that could be modified to do that.

 

[deneban]

The following bug report is being tracked under task number TSR 617892203:

This report is from: deneban

1. Bug Summary

TrainzUtil.exe bugs​

2. Build Number

105100 Trainz Plus (PC)​

3. Bug appears in previous version?

all TRS19 releases​

4. Where does the issue occur?

Other_ Windows command line interface​

5. Detailed Description

TrainzUtil.exe has the following bugs that need correction:​

1. All TrainzUtil compilations for TRS19 introduce reporting a 14th asset status flag, designated letter "Y", when an asset "status" argument is used (was not present in TANE). However, the "Help" argument, does not state the nature of this 14th flag as it does the prior 13.​

2. If TrainzUtil requires TRS19 running to execute an argument, it erroneously reports "TANE .exe" is not running, rather than "TRS19.exe" is not running.​

3. TrainzUtil offers the "category" of an asset as output from a "status" argument. There is also a "searchbycategory" argument. However, nowhere does TrainzUtil define the complete list of asset "category" designations. The Help argument output hints what some of the categories are: "CMP;MESH|BD;-ACTV|VE|SCEN", but does not define them, nor list all in use.​

6. KUID List

The 3 bugs occur with all asset versions​

7. Reproduce on demand?

Yes​

8. What you expect to happen.

1. The TrainzUtil Help output, in keeping with its established precedents, should define what the "Y" asset status flag designates, and should list all asset "category" designations in use and define them.​

2. The error message for the absence of the required resource, "TRS19.exe", should state "TRS19.exe" and not "TANE.exe".​

Lack_of_Y_flag_definition.PNG
TANE_is_not_running.PNG
Demonstrates_Y_flag_and_category_output.PNG

 

[deneban]

Partial Success...

TrainzUtil.exe has been revised to add the meaning of the "Yy" asset status flag as "The asset is compatible with this Trainz installation". TrainzUtil was recompiled for TSR 617892203, and given to QA, who and ran for me (at my continued behest) then reported back. I believe what is meant by the QA response is "Y" means the assert is incompatible and "y" means the asset is compatible. I've revised the Wiki accordingly.

The recompiled TrainzUtil.exe of course will not be released independently, it will be released en masse with some as yet unidentified next release. When it does get released, it will be a little difficult to identify because TrainzUtil.exe does not seem to have version numbers, as it is does not output them with the "help" argument. The "version" argument only tells the console your Trainz build number. One has to go by the .exe signing dates to distinguish TrainzUtil versions.

That's the good news. The not so good news is that the other two bugs on my ticket are not accounted for (as seen below the "TANE.exe" bug and absence of fully disclosed TrainzUtil asset category designations). It looks like they will need separate tickets to be addressed. I just realized a fourth bug is that the "help" argument says the "version" argument spits out the TrainzUtil version number whereas in reality it gives your Trainz program build number.

I realize developer's time is at a premium so its ok to get this resolved in baby steps.

More to come....

 

[deneban]

Update on TrainzUtil versioning:

I am told by N3V QA that TrainzUtil.exe is not versioned because it is always always recompiled in parallel with Trainz.exe (now TRS19.exe) as a pair. That is why when you use the TrainzUtil "version" argument, it merely asks the main executable what it's build version is. TrainzUtil will respond "TANE.exe is not running" if you call the "version" argument with no companion main executable running. In any event TrainzUtil compilations can be differentiated by their digital signing date.