PA & Berwin-missing texture

boleyd

Well-known member
I am missing the texture in the Allegheny East & West yards. I downloaded any JR "stuff" that might have the texture. Photo of one end of yard.

I have totally reinstalled the route but the problem remains. Does anyone know the name of the texture?


Berwin.jpg
 
TUME-Street-101 is NOT on the Content Manager. 102 104 105 106 and 107 are there. Checked using "street" and "101" search factors but no 101 street. Censors must have been upset with it. Will have to visually find each occurrence and manually paint the area. All the N3V tools seem to assume nothing is ever missing. Thanks......
 
Last edited:
Hy-jacking this thread to report another missing texture in the vicinity of Babcock Mine. If someone can help me identify it, I can find it, or fix it. Thanks in advance!!

Edit - Forgot to add that the route does not show any missing or faulty dependencies.


 
Last edited:
I have that as Parking Lot <Kuid2:45324:24850:1> which I think is JC's Kuid.
2019-09-01-164007.jpg


Not sure which route it came with either sorry not much help.
Cheers Mick.
 
Yeah so, apologies to all for starting the other thread over in the other section, but it did get me responses I wasn't initially getting here so thanks to all who responded.

I am closer to a fix with the identity of the parking lot asset, but now I am seeing something similar to others. In CM, the base kuid and version :1 are listed as "unknown", meaning they are not installed or available on the DLS. Norfolksouthern37 is listed at the author, so I am going to search the JR site first. I am using TRS19 so this may be my issue?

Edit: Well, I have an interim solution. I extracted <kuid2:45324:24850:1> Parking lot from my P&B "buildings" download backup file, deleted the :2 version, and now I have asphalt. Maybe someone can take a look at the :2 version as it doesn't show in TRS19. At least not for me.

 
Last edited:
I'm also in TRS19 which the above image was taken in, JR has been putting a ton of content on the DLS of late so maybe this one has been caught up sum where in-between.
Mick.
 
It has to tied to the :2 version. If you updated the asset pushed to the DLS, it does not show. Reverting back to :1, it shows.

Thanks for finding this. I'll make the change as well.

The problem is related to a bug I reported previously to N3V QA Team regarding this very issue. If a route has a certain KUID installed, something at version :1, for example, and the asset is updated to a :2, the route will show no missing dependencies locally.

However... If the route is exported and installed in another Trainz install, even if the :2 asset is installed, the route will still look for the :1 version.

This issue affects other assets that have dependencies and N3V is looking into the matter.
 
Thanks for finding this. I'll make the change as well.

The problem is related to a bug I reported previously to N3V QA Team regarding this very issue. If a route has a certain KUID installed, something at version :1, for example, and the asset is updated to a :2, the route will show no missing dependencies locally.

However... If the route is exported and installed in another Trainz install, even if the :2 asset is installed, the route will still look for the :1 version.

This issue affects other assets that have dependencies and N3V is looking into the matter.

Perhaps if people seeing this problem for themselves would submit more Helpdesk tickets, N3V would put more resources into fixing it. Breakdown of the obsoleting system is a pretty serious issue I would have thought.
 
Perhaps if people seeing this problem for themselves would submit more Helpdesk tickets, N3V would put more resources into fixing it. Breakdown of the obsoleting system is a pretty serious issue I would have thought.

I agree! I'm always reporting the niggles as they show up minor or not.
 
I'm still a bit confused by what's reported to be going on here. In this case, jbaxter 1964 is saying the problem is fixed by somehow getting version :1 and deleting version :2.

In the case of assets that call on mesh libraries, it's the opposite solution. The problem is fixed by deleting version :1 (of the mesh library) thereby forcing the dependent assets to use version :2. It should be looking for and using whatever is the latest version of the library even if older versions are still also present.

Either way, there is something very wrong with the way Trainz is handling the obsoleting system.
 
I'm still a bit confused by what's reported to be going on here. In this case, jbaxter 1964 is saying the problem is fixed by somehow getting version :1 and deleting version :2.

In the case of assets that call on mesh libraries, it's the opposite solution. The problem is fixed by deleting version :1 (of the mesh library) thereby forcing the dependent assets to use version :2. It should be looking for and using whatever is the latest version of the library even if older versions are still also present.

Either way, there is something very wrong with the way Trainz is handling the obsoleting system.

Yes there's a bug with the obsoleting system as you can see.

The problem is the route still has the version :1 in its object file list, and under normal circumstances, how things used to work, installing a version :2 would automatically obsolete the version :1 on the route and things would work. Everything is fine as long as things remain local. However... That's not the case here and things go a bit awry now if the route is exported and imported into another Trainz version. In this case the route is still referring to version :1 and is ignoring the fact that the version :2 may already be installed. Since this is a simple asset, changing the build number to version :1 gets around the unknown asset.

I agree this can get messy with mesh-table assets because things will get out of sync with the versioning.
 
Yes there's a bug with the obsoleting system as you can see.

The problem is the route still has the version :1 in its object file list, and under normal circumstances, how things used to work, installing a version :2 would automatically obsolete the version :1 on the route and things would work. Everything is fine as long as things remain local. However... That's not the case here and things go a bit awry now if the route is exported and imported into another Trainz version. In this case the route is still referring to version :1 and is ignoring the fact that the version :2 may already be installed. Since this is a simple asset, changing the build number to version :1 gets around the unknown asset.

I agree this can get messy with mesh-table assets because things will get out of sync with the versioning.

Yeah, I didn't try updating the route config to point to :2. Probably would have worked, but I am not messing with it now. lol
 
Yeah, I didn't try updating the route config to point to :2. Probably would have worked, but I am not messing with it now. lol

Don't worry... It would have been a waste of time. Updating the route config.txt file will only work temporarily because this is only a list of dependencies used for the search filters and is not only not always accurate, but also running a DBR will reset your change to the config.txt file.

The only way to force a permanent update to a route is to install the asset, or run delete missing assets.
 
Back
Top