Passengers <kuid-3:11061> in TRS19

owsleyiii

New member
What is the best way to handle Passengers <kuid-3:11061> (obsolete, modified) in TRS19?


I located and installed Passengers <kuid-3:11061> asset (modified, obsolete) into TRS19 and this seems to have taken care of the problem; everything seems fine after installing Passengers <kuid-3:11061> in the TRS19 install where its absence resulted in many faulty assets due to missing Passengers dependencies that should have been alleviated by obsolete tables for Passengers but was not for some reason (?).


TRS19 CM lists over 200 dependents for modified, obsolete Passengers <kuid-3:11061> that are built-in, payware, modified and dls.

The common connection appears to be Base asset Prod Passengers 2012 <kuid-25:1235> as all of these
Passengers <kuid-3:11061> dependents list Prod Passengers 2012 <kuid-25:1235> in dependencies but not Passengers <kuid-3:11061> itself; Passengers <kuid-3:11061> is identified as an asset version of Prod Passengers 2012 <kuid-25:1235>.

As it is a Base asset it has not been modified (that I am aware of) and numerous DBRs and several EDBRs have been performed since the beginning of June when this install was setup.


I have read a few threads attempting to find as much about this here in the forums but would like to ask the question for clarification: what is the best way to deal with Passengers <kuid-3:11061> in TRS19?


I have a backup .cdp of <kuid-3:11061> as it is almost certain that at some point while TRS19 CM database pruning and deleting non-essential obsolete assets that I will accidentally delete this as well.

Thank you very much for any help with this.



Owen
 
Just curious as to where you even found <kuid-3:11061>. I have TRS2019 and TANE-SP3 installed but both list <kuid-3:11061> as "unknown", so it's not installed in either version or on the DLS.
 
I located <kuid-3:11061> using trainzkuidindex but subsequently realized it is built-in in TS2 Mac and would imagine it is built-in in TS12.
 
I located <kuid-3:11061> using trainzkuidindex but subsequently realized it is built-in in TS2 Mac and would imagine it is built-in in TS12.

That explains why it's not in any of the Trainz editions I have. Why don't N3V put all these basic dependencies on the DLS to preclude missing dependency issues? It seems to be the most common complaint about this program.
 
Why don't N3V put all these basic dependencies on the DLS to preclude missing dependency issues?
<kuid-3:11061> should not be a missing dependency because it is obsoleted by <kuid-25:1235> which is a base asset in TRS2019. For some reason the obsoleting is being ignored. This is something that can happen as assets are added and removed, but it usually sorts itself out quickly. For some reason it is becoming more common, and is persisting.
 
I ran into this passenger issue back in May 2019 while upgrading my CC&LE route to TRS19 standards. See this thread conversation on the subject and how I had to solve it:

https://forums.auran.com/trainz/sho...oduct-problems-in-TRS19-and-a-fix-you-can-use

Basically the TRS19 obsoleting system wasn't working correctly and I finally had to come up with my own solution and product below to solve it once and for all. At the same time I brought that passenger product up to build 4.6 standards. I am now using this new passenger product in all my new route upgrades.

kuid_439337_103987.jpg


Passengers-SAP
KUID:439337:103987
Description: SAP Visible passenger product. An updated and corrected version of <kuid:-25:1235>. This product will load and unload visible passengers from any passenger rolling stock item or structure configured to accept this product. While I have made some corrections in order resolve some issues in TRS19 with the old passenger product, so I can use this on my own routes and sessions, I am not the author of the original meshes or the textures. I don't know who was the original author, since it didn't say in the <kuid:-25:1235>, but whoever it is still retains all copyrights for this great visible product. I thank that original author for his great product!

Additional items that that I created to work with this new product:

<kuid:439337:103990> SAP_Platform_Passenger_Low_Wooden_100m
<kuid:439337:103995> SAP_Platform_Passenger_Low_Wooden_60m
<kuid:439337:103996> SAP_Invisible_Station_50m
<kuid:439337:103997> SAP Gunnison Station-Ver1

Bob
 
Last edited:
In that case they should fix the obsoleting system since it's one of the foundation stones of the game. Only N3V can do it.

<kuid-3:11061> should not be a missing dependency because it is obsoleted by <kuid-25:1235> which is a base asset in TRS2019. For some reason the obsoleting is being ignored. This is something that can happen as assets are added and removed, but it usually sorts itself out quickly. For some reason it is becoming more common, and is persisting.

There appears to be a bug with the obsoleting system in general. If a route is installed from the DLS or from DLC, the assets are sorted out, but installing from a CDP causes issues with missing dependencies due to version. The route installed from the CDP still calls for some asset at the lower version, which was replaced with a higher version.

All is well and good while the route is installed in that copy of TRS2019 or T:ANE it came from, but if the route is exported and installed into another version of the program, let's say on another computer, then there's a problem even if the updated version of the asset is installed in that Trainz version. Instead of the newer asset obsoleting the reference in the route installed from CDP, Content Manager indicates there's a missing dependency. I believe I reported this as an error, but for some reason this fell through the cracks.
 
There appears to be a bug with the obsoleting system in general. If a route is installed from the DLS or from DLC, the assets are sorted out, but installing from a CDP causes issues with missing dependencies due to version. The route installed from the CDP still calls for some asset at the lower version, which was replaced with a higher version.

All is well and good while the route is installed in that copy of TRS2019 or T:ANE it came from, but if the route is exported and installed into another version of the program, let's say on another computer, then there's a problem even if the updated version of the asset is installed in that Trainz version. Instead of the newer asset obsoleting the reference in the route installed from CDP, Content Manager indicates there's a missing dependency. I believe I reported this as an error, but for some reason this fell through the cracks.

It sounds like you have a good understanding of the problem John. Could you raise it with N3V again, possibly via a formal Helpdesk ticket with some hard evidence to back up the case? It seems to be quite a major design flaw, and a long-running one at that. You would think that N3V would want to be all over it, assuming some reproducible examples could be provided.
 
It sounds like you have a good understanding of the problem John. Could you raise it with N3V again, possibly via a formal Helpdesk ticket with some hard evidence to back up the case? It seems to be quite a major design flaw, and a long-running one at that. You would think that N3V would want to be all over it, assuming some reproducible examples could be provided.

I remember this being an issue with one of the many betas we went through. I'll check my notes and see if I still have them. I tend to save stuff in text files and what not. I do have evidence such as when sharing routes with N3V for testing and going through the multiple missing assets.

I'll do a formal bug report when I get some time.
 
Thank you all for considering and replying.
Thank you for sharing your experiences and knowledge; I really appreciate your time, input and help.

It would seem a Help Desk ticket -- or perhaps an additional one -- concerning <kuid-3:11061> is in order.

John has completely nailed the situation: DLS, DLC and .cpd installs.
The route installed from the CDP still calls for some asset at the lower version, which was replaced with a higher version.

Added: Thank you John for doing a formal bug report!

Although my small TRS19 install does have a small amount of content from .cdp and does not have the obsolete bug for <kuid-3:11061> the large one has had everything including a few kitchen sinks thrown at it.

I will make a new fresh install and be more careful and methodical and slow in adding older TS2/TS12 and even T:ANE content when importing from .cdp.

I will also consider how best to communicate the nature of the <kuid-3:11061> bug in a Help Desk ticket.
Brevity, concision, linearity are not peronal strong suits.

Owen

Given that installing .cdps of older content can trigger this Passengers dependency bug, the problems with Cab mode operations in the other thread I started (i.e. with the really long opening) concerning a small number of Cab mode issues in sessions are probably also due to my...exuberance in loading TRS19 with lots of old content via .cdp
 
Last edited:
Owen,

By the sounds of it, your issue with the engine-spec is related to the assets themselves. These are the trials and tribulations of dealing with 100s and 100s of thousands of assets.

There was a time when some people 'fixed' things and in the process broke things as well. I have come across some Alco RS3s that wouldn't run at all. They couldn't pull a wagon load of fly eggs if they tried. Eventually updates were done, and the assets worked okay from that point on.

This issue with the missing dependencies definitely, however, needs to be reported via the helpdesk.
 
Back
Top