The DLC-system lets me fall into despair

I agree as well.

When the DLC program was introduced, that's when everything got messy because this broke the fluidity that we have with the DLS as a whole by causing unwanted version differences and thus missing dependencies.
 
Right, the DLS has been always kind of a safe harbour for content (with few exceptions I know). Its broken now.
 
At the risk of preaching to "the wrong crowd", I will repost one of Malc's comments.

N3V are still in the process of ensuring that DLS assets up-versioned and bundled in packages are also updated to the same version on the DLS, it mostly works, occasionally something gets missed, in which case help desk or bug report should fix it or if still around the original creator can update it to match. I've done about 5 of my assets that got missed and caused missing assets and one got sorted by Zec who picked it from a thread on here.

N3V have stated for the reasons I have posted earlier in this thread that they will not be going back to the old system of simply referencing DLS content in DLC packages. DLS assets will continue to be included in the DLC packages.

To those of you who have posted about problems with this new system, have you reported them via the bug reporting system at https://n3vgames.typeform.com/to/xRdryu or the Help Desk?

My opinions.
 
Hi All
Just to confirm.

Where ever possible, if we (N3V) do need to update an asset to fix errors/issues ourselves, we try to ensure that the update is uploaded to the DLS as soon as we can. In the past, especially if large numbers of assets were involved, some assets were missed, where these are reported to us we will generally be able to get the update onto the DLS within a couple of days.

In the past DLC packs were packaged manually by N3V, and so sometimes we would fix DLS assets on the go, and then being human sometimes it was forgotten to upload those fixed DLS assets to the DLS. This method is no longer used, and we won't be returning to it at all.

With the introduction of the TCCP system, and more specifically TCCP2.0, the packaging is essentially in the hands of the creator of the DLC pack. The N3V team don't actually have a hand in packaging the DLC pack, which means that we also don't update assets when the DLC pack is packaged to fix errors.

For DLS content, the latest revision of the asset is used from the DLS.

The exception will be if the person submitting the package has a newer revision to a DLS asset from another source (some creators are unfortunately releasing updates to their own content elsewhere, when an earlier version is on the DLS). In this case, the newer revision will be included in the package, but may not be available from the DLS. But this would be no different to obtaining the newer revision from the source it was released through...

Regards
 
As said, i used the bug tracker more than one time.

So if I provide you a KUID list, you are able to update the DLS-versions?

In my case, it affects mostly the two Niddertalbahn DLCs and the additional T:ANE assets

There are *at least* the following assets affected:
Code:
<kuid2:60238:26108:1>  shown as unknown, its "Ferrymodern" by vulcan (DLS-version)
<kuid2:143205:10001:1> Prellbock DB
<kuid2:42778:33105:1> gittermast AGD860 N ci
<kuid2:489332:34129:2> Dm-Bf-Deko Bank B
<kuid2:489332:34143:3> Dm-Bf-Sch GleisNr-s 2
<kuid2:489332:34103:3> Dm-Bf-Sch GleisNr-s
<kuid2:489332:34127:2> Dm-Bf-Deko Fahrkartenautomat
<kuid2:489332:34123:2> Dm-Bf-Deko Fahrplan 1
<kuid2:489332:34101:4> Dm-Bf-Sch Stationsschild-s-L
<kuid2:42778:33101:1> gittermast AGD860 N i
<kuid2:489332:34125:2> Dm-Bf-Deko Fahrplan 1+2
<kuid2:42778:33372:2> fahrdraht Ax6060 co
<kuid2:42778:30300:4> fahrdraht Ax6050 cc
<kuid2:42778:30301:4> fahrdraht Ax6050 ci
<kuid2:42778:33374:2> fahrdraht Ax6060 ic
<kuid2:42778:30302:4> fahrdraht Ax6050 co
<kuid2:42778:30305:4> fahrdraht Ax6050 ii
<kuid2:42778:33378:2> fahrdraht Ax6060 oc
<kuid2:42778:30306:4> fahrdraht Ax6050 io
<kuid2:42778:30307:4> fahrdraht Ax6050 iu
<kuid2:42778:30308:4> fahrdraht Ax6050 oc
<kuid2:42778:30309:4> fahrdraht Ax6050 oi
<kuid2:164988:37030:1> tenement Nr30
<kuid2:42778:30310:4> fahrdraht Ax6050 oo
<kuid2:42778:30313:4> fahrdraht Ax6050 ui
<kuid2:42778:33370:2> fahrdraht Ax6060 cc
<kuid2:42778:33371:2> fahrdraht Ax6060 ci
<kuid2:42778:3002:3> flachmast A860 c
<kuid2:42778:3001:3> flachmast A860 i
<kuid2:42778:3003:3> flachmast A860 o
<kuid2:164988:369875:1> tenement Nr6
<kuid2:42778:33107:1> gittermast AGD860 N cu
<kuid2:42778:3027:1> gittermast A860 ic
<kuid2:42778:33100:1> gittermast AGD860 N c
<kuid2:143205:10002:1> Prellbock DB
<kuid2:42778:33106:1> gittermast AGD860 N co
<kuid2:42778:33108:1> gittermast AGD860 N ic
<kuid2:42778:33102:1> gittermast AGD860 N o
<kuid2:35848:32002:1> Pilzlampe
<kuid2:121021:40901:1> station sign old L
<kuid2:74744:28012:1> Streckentelefon
<kuid2:164988:369880:1> tenement Nr7
<kuid2:164988:369965:1> tenement Nr19
<kuid2:164988:37105:1> tenement Nr36
<kuid2:343955:29001:5> VSM Hv-Vsig(1969)
<kuid2:343955:29000:5> VSM Hv-Vsig(1969-L)

Further assets seem to be part of the T:ANE DLC (or maybe other DLCs I cannot identify right now), those I have to replace if they cannot also find their way to DLS:
Code:
<kuid:523:19723447>
<kuid:565830:100222> Rock Single
<kuid:-25:1212> Flowers_Lavender2
<kuid2:661281:85197:1> PBR Cobble Stones 2 - Seasonal
<kuid2:82412:49891001:1> TUME-Street-101
<kuid2:82412:49891006:1> TUME-Street-106
 
Last edited:
Hi All
Just to confirm.

With the introduction of the TCCP system, and more specifically TCCP2.0, the packaging is essentially in the hands of the creator of the DLC pack. The N3V team don't actually have a hand in packaging the DLC pack, which means that we also don't update assets when the DLC pack is packaged to fix errors.

For DLS content, the latest revision of the asset is used from the DLS.

The exception will be if the person submitting the package has a newer revision to a DLS asset from another source (some creators are unfortunately releasing updates to their own content elsewhere, when an earlier version is on the DLS). In this case, the newer revision will be included in the package, but may not be available from the DLS. But this would be no different to obtaining the newer revision from the source it was released through...

Hi Zec,

Your explanation seems to be trying to oversimplify the process as it sounds sounds as if you are allowing DLC content creators to modify DLS assets that they don't own and:

1. Bypass the requirement to make sure that the original author agrees to the change.
2. That these changes will never make it to the DLS because n3v will no longer ensure that it is put onto the DLS or alternatively that the DLC Content creator decides that it shouldn't be updated to the DLS.

How do you establish where an up-versioned DLS asset came from? Is it just a hope that the DLC creator either owned it or had permission to update it?

For example: What happens if someone modifies an asset for their own personal use (this could be because it contained errors or warnings, or possibly a minor change to a texture). They then decide to create a route for the DLC and include such an updated asset, having long since forgotten that they ever modified it. Will this just simply be accepted?

Given that the majority of us do not create content for the DLC, but most do download items from the DLS, is there anything that explains the process in detail. In particular when and how decisions are made with regard to assets that have a different version to that on the DLS.

Furthermore why is it that simply having a higher version number, makes the asset itself suddenly become a totally unknown asset. This seems to defeat the whole purpose of retaining asset numbers and tagging them with a version number. My own experience of right clicking on an asset listed as unknown, has been that it is still reported as an unknown asset, other versions are not listed. Only by closing CM and then re-opening it and doing a search for the asset without version number allows you to get a list of the asset versions. why can't these assets be reported as being an unknown version?

Regards

Mike
 
Hi All
Just to confirm.

The exception will be if the person submitting the package has a newer revision to a DLS asset from another source (some creators are unfortunately releasing updates to their own content elsewhere, when an earlier version is on the DLS). In this case, the newer revision will be included in the package, but may not be available from the DLS. But this would be no different to obtaining the newer revision from the source it was released through...

Regards

How does anyone know where the source was? This means if you later delete that package you are left with an asset that is missing because the DLS version is classed as out of date obsolete. Why could you not create all DLC content as a kuid3 so that the kuid2 on the DLS wont get replaced.
 
How does anyone know where the source was?

That, unfortunately, is no different to the current situation found in a number of DLS routes where the creator has thrown in assets from 3rd party web sites and you are left to play the game of "Hunt the asset source". I think that it should be a rule that any asset in a DLC package that is to be labelled as "packaged" must also be uploaded to the DLS, if that exact version is not already there.

My opinions.
 
That, unfortunately, is no different to the current situation found in a number of DLS routes where the creator has thrown in assets from 3rd party web sites and you are left to play the game of "Hunt the asset source". I think that it should be a rule that any asset in a DLC package that is to be labelled as "packaged" must also be uploaded to the DLS, if that exact version is not already there.


EXACTLY!!!!! I agree with this. Play with DLS or don't, but if you do... please go *all in*.
 
Thanks Basti, I'll look into those in the next couple of days (I've already added myself a task with the assets so I can look into it :) ). If all goes well I'll put a reply here to confirm which assets are uploaded/etc (in theory all, but I just need to verify their DLS status first :) ).

In regards to non DLS updates to assets; unfortunately there are creators who actively release updates to their assets through their own website, and not the DLS.

When this happens, and a route builder ends up with that updated asset installed, then the route will require that asset. If they wish to release it through TCCP, then it'd need to include that asset; if the creator gives the ok for the asset to be included then the TCCP system will process it as a non DLS asset (as it would with any other non DLS assets). Unfortunately we cannot force creators to upload their updates to the DLS; and because there is no simple way to 'revert' an asset in a route to a previous version it becomes problematic to simply block routes that use non DLS updates to DLS assets as well.

TBH there is no simple solution to this, from our point of view. In reality, the best solution is for the creator of the asset to upload the update to the DLS...

As to any asset to be labelled as 'packaged', as a creator I can't agree here. I have included non encrypted assets in my DLC packs of either my own creation, or the creation of friends who assist on some of my projects. They aren't intended to be 'payware' encrypted assets, but rather are simply dependencies of that DLC pack. But they're also not assets either the original creator or myself intended to be on the DLS, they were made primarily for those DLC packs.

An example of this is a few of the scenery assets I made for the Healesville route. They're intended specifically for that route, and weren't intended for DLS release, but they're also not assets I specifically see needing payware encryption. So they become 'packaged' instead.

Regards
 
An example of this is a few of the scenery assets I made for the Healesville route. They're intended specifically for that route, and weren't intended for DLS release, but they're also not assets I specifically see needing payware encryption. So they become 'packaged' instead.

OK. As someone who has the Healesville route that mean I cannot use any of those assets in any route I create and upload to the DLS. If they are labelled as "Packaged" then how do I tell that they are not on the DLS and therefore cannot be downloaded by anyone who installs my route?

If I select one of those packaged but not-on-the-DLS assets and view its asset versions in CM all I will see is the packaged asset, not the fact that it is also on the DLS. I tried this on an asset I created that is on the DLS (because I put it there) and has since been added to a DLC pack - so it now appears as packaged with no indication that it is also on the DLS. So how would I know if it is safe to add it into a DLS route?
 
If you want to ensure that your route uses ONLY DLC assets, and not builtin assets (since builtin may become part of a 'package' in future releases, rather than being placed onto the DLS itself), then you can add the 'on Download Station' = true filter to the filters list. This will then show only assets that are available from the DLS.

Regards
 
Download Station' = true filter to the filters list. This will then show only assets that are available from the DLS.

Thank you for that. I was able to conduct a test of that solution.

I have two installs of Trainz Plus (117092 and 117540) on the same computer.

  • Install 1 (117092)
    • I ran the recommended filter plus Obsolete = False to eliminate obsolete packaged assets just to make the display simpler.
    • Selected all the "Packaged" assets, 7076 of them.
    • Right mouse clicked and selected the List Assets in New Window command
    • Copied to the clipboard the contents of the Asset KUID filter line which contains the KUID codes of all 7076 assets
  • Install 2 (117540)
    • Pasted the clipboard list into the Asset KUID filter line
    • Deleted the Installed = True filter line

Both lists displayed the same number of assets (7076). In the list for Install 2 all 7076 assets were listed as "Available for download" or "Installed from DLS".

So for the 7076 assets tested, case proven.

My observations.
 
Thank you for that. I was able to conduct a test of that solution.

I have two installs of Trainz Plus (117092 and 117540) on the same computer.

  • Install 1 (117092)
    • I ran the recommended filter plus Obsolete = False to eliminate obsolete packaged assets just to make the display simpler.
    • Selected all the "Packaged" assets, 7076 of them.
    • Right mouse clicked and selected the List Assets in New Window command
    • Copied to the clipboard the contents of the Asset KUID filter line which contains the KUID codes of all 7076 assets
  • Install 2 (117540)
    • Pasted the clipboard list into the Asset KUID filter line
    • Deleted the Installed = True filter line

Both lists displayed the same number of assets (7076). In the list for Install 2 all 7076 assets were listed as "Available for download" or "Installed from DLS".

So for the 7076 assets tested, case proven.

My observations.
Very good, the thing is though, we now know about this , but what if we don't read this thread? There are far too many instances of obscure fixes to problems that cause endless hassles to route creators that only a few know about ,and the solutions to which are not widely known because there is insufficient explanations by NV3 , there has to be an easier way to make this more obvious to the route creator without having to post pleas on the forum to end our suffering .
 
Yeah, i'd wish to see more filters included, also one to simply see outdated assets and update them - but that's OT :)
 
As a step towards providing the information, I have amended the Trainz Wiki Page on Understanding the CM Status Labels to include a search for filtering packaged assets that are, or are not, on the DLS.

Great information!

Problems can arise if the asset included in a DLC package has a higher version number (the :digit> at the end of a kuid2 number) than the "identical" copy on the DLS. This usually occurs when the DLS copy has not been updated to match the DLC copy. See How to Check the DLS Status of Packaged Assets below. If you encounter this problem in a Packaged asset, report it by the Bug Reporting Web Page or the Trainz Help Desk

I usually find that there was some change in the broken ones that need a bug report, ie file size difference, so "identical" may not apply, just my thoughts, otherwise I think your spot on.
 
Problems can arise if the asset included in a DLC package has a higher version number (the :digit> at the end of a kuid2 number) than the "identical" copy on the DLS. This usually occurs when the DLS copy has not been updated to match the DLC copy. See How to Check the DLS Status of Packaged Assets below. If you encounter this problem in a Packaged asset, report it by the Bug Reporting Web Page or the Trainz Help Desk

The simple solution is to have a system in place to automatically upload the up-versioned asset to the DLS rather than relying on human intervention. The problem is things to go simply and easily as we plan, so the alternative could be when a route or asset is uploaded to the TCCP, there is an asset version check done against those on the DLS. If any asset included in the route is newer than the one on the DLS, then an email is sent, or message posted on the screen, indicating that the conflict needs to be resolved before the assets can be uploaded. This enforced response will require the content-creator to uploaded the newer version to the DLS.
 
Back
Top