TRS19 Content delivery strategy causing major route development problems

The whole nub of this present situation is that freeware uploaded to the DLS must remain freeware forever and ever Amen and does not become ring fenced in anyway by becoming payware. Assets specially and specifically commissioned by N3V for a DLC route should be the only assets that get designated as being payware.

I'm only a fairly minor content creator in the great scheme of things, but I know I would be very annoyed if something I'd made and licensed as being, 'Fair use, - not to be sold as payware', ended up as a payware item on a DLC route.

And

T:ANE SP3 build 94916

<kuid:-12:24002> Signal USA1 02 is listed in the Content Manager as "Installed/Payware" it obsoletes <kuid:-12:21902> Signal USA 02 which was on the DLS. Checking the Download Station now it shows "No Downloads Found".

TRS19 build 100240

<kuid:-25:857> Signal USA 02 is listed as "Built-in" it obsoletes <kuid:-12:21902> Signal USA 02 which is listed in the CM as "Available for download, Obsolete" (if you select "Download this version" it does download)

<kuid:-25:1209> Sig_US1_02R is listed as "Built-in" it obsoletes <kuid:-12:24002> Signal USA1 02 which is listed as "unknown"

What does it all mean? :hehe:

KotangaGirl said:

The whole nub of this present situation is that freeware uploaded to the DLS must remain freeware forever and ever Amen and does not become ring fenced in anyway by becoming payware. Assets specially and specifically commissioned by N3V for a DLC route should be the only assets that get designated as being payware.

I'm only a fairly minor content creator in the great scheme of things, but I know I would be very annoyed if something I'd made and licensed as being, 'Fair use, - not to be sold as payware', ended up as a payware item on a DLC route.

Click to expand...

I believe there is also the issue where freeware assets have been created using textures or possibly even shape files (Sketchup?) which have a strict non-commercial clause applied. Of course that brings us round the circle about the route only referencing the asset(s) but nonetheless it is still being used to enhance another creation and, as per the OP, may have gained a payware tag in the process.

Vern said:

Of course that brings us round the circle about the route only referencing the asset(s) ...

Click to expand...

That doesn't apply to payware, where the freeware assets are included in the payware package that is supplied to the purchaser. N3V gets the right to distribute these assets when the asset is uploaded to the DLS. If the original content creator does not have the right to licence the asset to N3V for this purpose then it should not be uploaded to the DLS.

Not including freeware assets in the payware package is one solution that has been proposed above, but that creates an inconvenience for the purchaser in requiring additional installation steps. It has the advantage that there is no risk of running foul of restrictions in the original source material (eg, images) that use terms like '... as part of a payware package'. It has been suggested that this could be done by an automatic invisible DLS download of missing dependencies as soon as the installation of the payware package is completed. The simpler solution is to include the freeware assets in the payware package, but to ensure that they are the DLS version and are marked 'Installed from DLS' and not 'Payware' when the user installs them. This may create a fuzziness about whether or not material is being distributed '... as part of a payware package', but would be no more than currently exists.

Update: We haven't forgotten this thread. Just letting you know we're working through step by step to cover all bases and work out the best outcome. We expect to have something for you next week.

As I said last week, we expected to make our post this week. We're nearly there, but there are many ways of skinning this cat (can we still say things like that in 2019?) and we want to be sure we make some changes that provide the best outcome long term.

Among the list of items, we're investigating ways of providing source code versions to allow for editing by those who want to do edits, while ensuring the "masses" still have optimised content (and ideally no need to ever edit anything in the first place).

We're also looking at the best ways to ensure route builders can build their routes with confidence that others can access everything they need to, and/or identify what they would need to purchase if the route builder wishes to include payware.

Tony_Hilliam said:

As I said last week, we expected to make our post this week. We're nearly there, but there are many ways of skinning this cat (can we still say things like that in 2019?) and we want to be sure we make some changes that provide the best outcome long term.

Click to expand...

Can you say at this stage whether you will be amending the License Agreement governing upload access to the Download Station to allow N3V to make the changes required to make DLS items built-in (such as adding the privileges container, encrypting meshes and images, adding text translations) or will the items where these changes have been made be reverted to the form in which they were originally uploaded?

Re the DLS Agreement - that's one of the points under discussion, how far to go, how to handle various options etc.

Tony_Hilliam said:

Among the list of items, we're investigating ways of providing source code versions to allow for editing by those who want to do edits, while ensuring the "masses" still have optimised content (and ideally no need to ever edit anything in the first place).

Click to expand...

Tony:

One of the things I would highly recommend would be to allow .BLEND (ie; from Blender) files to be included in the CDPs, for those authors desiring to do that, such as myself. It can be done now, but only if you rename the file extension to .txt or .jpg or something similar to get past the Trainz file screening process.

It is a hard fact that people come and go in this hobby for a variety of reasons, but whatever content they make often remains on the DLS forever. In time this can be a problem if the original author does not continue to upgrade the item to keep pace with new major versions of Trainz. We are seeing that now with older content that has not been updated since it was first submitted. By allowing authors to include their source code .BLEND files you provide a way for others to keep the item current and also to allow for many variations of that item. This can only be a win-win for Trainz and everyone else. After all it is the availability of all that free content on the DLS that makes Trainz the popular success it is today.

Bob

Here Here!

I've raised a task about that request, although it does have some downsides:
- it increases the size of the download for everyone, with only a small % requiring the file
- it's likely to also mean that people could include other "unwanted" attachments (such as some virus/executable)

So there may be a better way to achieve the desired result (such as some sort of source file repository).

Anyway, to update you further on our progress, we've been working through the various build processes to identify any contributing factors to incorrectly identifying content and creating and testing new builds. We've made some good progress and resolved a few different issues including build script errors, recursive dependencies, different asset classes, when and how updates were released (all wonderfully technical stuff that does my head in at times).

Short story is we're continuing to look into this and work out which things we can do quickly and easily an what we can do longer term to improve the whole process.

Thanks for your patience.

Tony_Hilliam said:

I've raised a task about that request, although it does have some downsides:
- it increases the size of the download for everyone, with only a small % requiring the file
- it's likely to also mean that people could include other "unwanted" attachments (such as some virus/executable)

So there may be a better way to achieve the desired result (such as some sort of source file repository).

Anyway, to update you further on our progress, we've been working through the various build processes to identify any contributing factors to incorrectly identifying content and creating and testing new builds. We've made some good progress and resolved a few different issues including build script errors, recursive dependencies, different asset classes, when and how updates were released (all wonderfully technical stuff that does my head in at times).

Short story is we're continuing to look into this and work out which things we can do quickly and easily an what we can do longer term to improve the whole process.

Thanks for your patience.

Click to expand...

Tony:

Thanks for the reply. After I retired from the Army I became a commercial Windows software engineer and application developer from 1993-2005 so am familiar with the various technical issues involved with application development. Addressing your points:

1. Keeping the source code within the CDP file is actually meant to save space over all. Most of the size of the mesh file project often resides in the textures which are going to be with the content item file anyway. Separating them would mean having to have two sets of everything as you are not going to be able to load the mesh project files without the textures and animation files and in the end would take up even more space if the project file must be in a separate location. You have a valid point that it it does increase the size of the overall download some what, but I believe the benefits here would more then compensate for that and not all content authors are going to do this. By including the mesh project file we would be encouraging a whole new generation of content developers and allowing for a lot of variations on the original item. That is a win-win for us all. Having the project file would also allow you all at N3V to easily address content issues when going to future major versions where needed, which is something you cannot do now since you do not have the project files.

2. As for "unwanted" attachments and the possible dangers behind that you can easily deal with that by specifying exact allowable specific file extension types, which I believe you are already doing anyway when you screen the contents of a new CDP file. Allow only file extension types for Gmax/3DS Max and Blender project files and nothing else. It is really that simple.

Bob

I continue to get reports by reports of people not having the same built-in TRS19 content I do.

See this link and the replies that follow it:

https://forums.auran.com/trainz/sho...Official-Support-Thread&p=1759188#post1759188

What made this case interesting is that it was for a build 4.6 item that I show as built-in to my version of TRS19 (kuid2:58422:9730001:5) but apparently only kuid2:58422:9730001:4 format for Puffingbilly's version of TRS19, despite having installed the DLCs.

This is making my life as a TRS19 route/session developer difficult.

When is there going to be final resolution to this issue?

Bob

I have the full version of TRS19 (Build 100464) with all DLCs installed and <kuid2:58422:9730001:4> too.

This is probably a subject for a new topic; but I think N3V needs to work toward a more fault-tolerant game. I don't see how anyone even uses it anymore without a background in computer programming.

pitkin said:

This is probably a subject for a new topic; but I think N3V needs to work toward a more fault-tolerant game. I don't see how anyone even uses it anymore without a background in computer programming.

Click to expand...

I said this sometime ago as well. For those that don't want to tinker, the program becomes an overly complex mess when they start exploring the finer aspects such as Interlocking Towers. When I first looked at them, they made my head hurt and my brain tired. I promptly closed them because of the too many parts to make them work thing. It's not the ITs either. We have interfaces such as the TurfFX stuff written in "Programmer", and so many other assets such as schedule rules, turntable indexes, industry queues, and many, many more things.

I for one believe in the KISS principle. Keep it Simple, (and) Stupid. The simpler the operation, the better things run even in complex situations. Not all of us are computer-oriented souls who worked in IT for decades. I did and retired, and technology has surpassed me a lot very quickly, and now I'm too tired to want to stay on the moving curve, besides I don't need to any longer. Playing a game, or enjoying a hobby shouldn't require staying up on career-oriented technology.

i agree with pitkin the game has gotten really complex.
the real shame is the loss of really nice trees. speed tree group,tree green group(conformed to the terrain really nice), and lost all the 50'6" boxcars. i'm sure there are others i haven't found yet but with each improvement we lose some really nice assets.
not really a complaint since the presentation of the game while running is nice.
ejb
p.s. mr JCitron thanks for your help on many things you have helped me on you are a champion.

HPL said:

I have the full version of TRS19 (Build 100464) with all DLCs installed and <kuid2:58422:9730001:4> too.

Click to expand...

This is what it shows in my full TRS19 version in the Content Manager:



BTW my version of TRS19 comes directly from the N3V store website and is not the Steam version. All free DLCs have been installed.

Bob

MSGSapper said:

my version of TRS19 comes directly from the N3V store website and is not the Steam version. All free DLCs have been installed.

Bob

Click to expand...

Same, but no trace of version 5 of this asset...

v4 is builtin obsolete in TRS19, probably been updated by one of the DLC downloads.