An Appeal To All Content Creators

My view on the system is that it works pretty well. If a user wants to have two separate versions of an asset for compatibility reasons, then having two separate KUIDs is the way to go.

Shane

I seem to recall this was one of the arguments in FAVOR of retaining pre-3.7 support on the DLS back in April. Indeed, it was used to justify even retaining TB 2.9 or earlier support.

If 2.9 uploads were still supported, I'd be happy to make two versions of an asset: one at TB 2.9 for legacy use. and a new one at 3.5 or 3.7 or T:ANE or whatever. As it stands now, it's not worth breaking TS2009/TS2010 compatibility to update my content, nor is it worth going to the trouble of creating two versions with two different kuids.
 
Whenever I build my content, I always leave the build at build 2.9, as it makes it wildly usuable through TRSZ2009 and up to T:ANE. If I release something on the DLS, for example, my Thunderbolt 1003 model, I now have to up the build to 3.5.
 
That would be ok if not for the fact that N3V has messed up the in-game updater somehow such that not only are my splines broken, I cannot even rollback to an older version. Such a broken system can cause missing objects that will easily go unnoticed. My splines are still broken, and after an hour of various convoluted attempts to rectify this I've given up. For now the only way to prevent further occurrences is to not update assets at all, which like all things N3V is a silly workaround.

Hi Ish, thanks for your perspective. What I still don't understand about this logic - and many others have pointed this out before especially in the DLS 3.7 furore - is that an asset can be built to perfectly satisfy TANE's requirements and still be of an older build number. In fact, just now I cloned several 3.7 assets, edited the the config to read 3.5 and committed them. All showed up perfectly error- and warning-free. Yes, many prolific creators like you have thousands of uploads and it would be unreasonable to ask that all of them be backdated. But I don't think it's too much to edit a single digit in the config just before uploading and after verifying that it works in TANE. After all, 2.9 and earlier assets work fine in 3.6 today, why would new assets be any different?

If your asset was problematic in TS12 to begin with, it wouldn't pass TANE validation anyway. If your simple asset is error free in TANE, it will be error free in TS12.

Good Afternoon Sir ...

Before all of this chaos I have always uploaded under 2.9 ... -- I would have continue with 2.9 today if it wasn't for these changes from N3V! Since I create simple items the only issue I had with 3.7 was the textures, but thanks to Pev Tools I was able to fix hundreds of items quite quickly! And also to John, our dear technie friend, who suggested 3rd party software to speed things up to modifying the config files, too!

However, I understand where you are coming from, sir, as many have expressed their feelings in these forums; But, for me, I got cold feet -- I will tell you a story... There's this one creator, who has thousands and thousands of items (He has me beat by 3 thousand I think), and we talked via email about this subject one whole day, going back and forth, etc ... and what to do.... finally, I told him this, more or less "I will be uploading to 3.7, because it will gurantee that the item will work now, and more importantly in the future! TANE build from what i have been told is 4.1, so it seems for now that 3.7 and 4.1 seem to be same! Complex items, like anim, scripting may have issues, or may not, but once that's settle it could clone, or copy so that the same script work with 3.7 ..." .... this is how it went, and I suggested to him to create under build 3.7 ...

I suggested this, because of what happened to the creators when build 2.7 was dropped for 2.9, and then what just happened recently! --- it was just a headache! I mean, seriously, I upload in bulks, and for those who visit the Marsz blog knows this, so imagine my surprise when over 200 items where rejected! --- My blood was boiling, etc ... Yes, I know, N3V dropped the ball, but I can't afford to get caught off guard like that again! It's playing it safe!!!

Honestly, what N3V worked on many levels, even though they did this rollback!

All in all, TANE for me is for working on the Marsz layout which immense is size, and My Earth Route Metro, where as i will keep T12 for creating and testing items!

Take care now!!!

Ishie
 
Hello Ishie, nice to hear from you.

I can try to understand how you feel, even though I am by any measure a content creator. N3V really cocked up big time on both the latest DLS fiasco and abrupt end of 2.9 uploads. They have promised that when the time comes for 3.5/3.6 to be dropped, much earlier notice will be given so that creators like you have enough time to finish uploading. I do respect your decision despite being disappointed at how such a situation has been created due to N3V's utter incompetence.

For people running TANE or whatever latest greatest version of Trainz is out this week, they could care less what build an asset is. But not everyone plays the latest version for various reasons, and unnecessarily bumping up build numbers can cause problems for them and/or restricts their access to an otherwise perfectly good asset. This is what I'm trying to emphasize with this thread.
 
The latter case is exactly the problem. I create a lot of custom content for my SEPTA route being built in TS2010. If I increment the kuid of even a single asset, say, to update the Trainz-build to 3.5 in accordance with N3V's DLS upload policy, Trainz will automatically update the expected kuid of that asset to the new increment the next time I save the route in Surveyor, even though the route is otherwise fully TS2010-compatible as well as all the content.

I don't get it. You can't save a route without the build number of the route being updated to the current game version. How can there be an asset with a higher build number included in that route? - that asset will not be a valid asset for the system where the route was saved.

If your route is going to be 'fully TS2010-compatible' then it can only be created on a TS2010 system, and that 3.5-build asset could not be on that system.

I agree that needing an installation of each version of Trainz in order to be able to create assets for that particular version is a nuisance, but I can't see that you can reliably test any asset (route or otherwise) using a version higher than the build number.

If the route builder is building routes using assets (whatever version) that haven't been released that's an error in the route, not in the versioning system.
 
Whenever I build my content, I always leave the build at build 2.9, as it makes it wildly usuable through TRSZ2009 and up to T:ANE. If I release something on the DLS, for example, my Thunderbolt 1003 model, I now have to up the build to 3.5.

For locomotives (and some others) that's an issue. For many assets you can build to 2.9 standards, test in 09/10/12 as always, then up the build to 3.5, retest in TS12, and upload. Anyone who wants the latest build of your asset can set it back to 2.9 with minimal effort. But for locomotives the changes that have occurred make that difficult. In that case the alternative already proposed - a third-party sight dedicated to pre-3.5 assets - is the only available option.

To assist in understanding N3V's point of view it would be interesting to know how much of the FCT revenue comes from users who want pre-3.5 assets.
 
I don't get it. You can't save a route without the build number of the route being updated to the current game version. How can there be an asset with a higher build number included in that route? - that asset will not be a valid asset for the system where the route was saved.

If your route is going to be 'fully TS2010-compatible' then it can only be created on a TS2010 system, and that 3.5-build asset could not be on that system.

I'm getting a headache from rolling my eyes. It most certainly can be, especially if the final step before uploading and incrementing the kuid is to update the TB to 3.5.
 
I'm getting a headache from rolling my eyes. It most certainly can be, especially if the final step before uploading and incrementing the kuid is to update the TB to 3.5.

Sorry, but I still don't get it. How are you creating routes at one build number that rely on assets that have a higher build number?

Unless, of course, you are adjusting the build number manually, in which case you can certainly stuff up the versioning system. That's why route build numbers are assigned automatically for you.
 
Sorry, but I still don't get it. How are you creating routes at one build number that rely on assets that have a higher build number?

Unless, of course, you are adjusting the build number manually, in which case you can certainly stuff up the versioning system. That's why route build numbers are assigned automatically for you.

Up until now, I haven't been. I've been building my route in TS2010, as a TB 3.3 route. I've been building all my content at that version number (well, actually setting it back at 2.9) and testing it in that same build, usually in my route. Now that I have to adjust my TB to 3.5 if I want to upload to the DLS, that introduces a new issue for both myself and anyone who may get my route.
 
Last edited:
Up until now, I haven't been. I've been building my route in TS2010, as a TB 3.3 route. I've been building all my content at that version number (well, actually setting it back at 2.9) and testing it in that same build, usually in my route. Now that I have to adjust my TB to 3.5 if I want to upload to the DLS, that introduces a new issue for both myself and anyone who may get my route.

OK. But what's the issue?

I think we are at cross purposes. The comment I referred to was "but I'm not updating my older stuff (on the DLS, that is) since I don't want to break compatibility with older versions." Users who download the 2.9/3.3 version are unaffected by the 3.5 version that you uploaded - there is no problem of breaking compatibility.

Perhaps you are referring to the known problem that Trainz can be made to download assets with a higher version number than it can handle. That problem is easily solved by deleting the download.

OTOH if you are saying that you can no longer update the 2.9/3.3 version to a new 2.9/3.3 version then yes, that's what the end of support means. Users with those versions cannot get updates through the DLS - third-party sites are needed.
 
Hello Ishie, nice to hear from you.

But not everyone plays the latest version for various reasons, and unnecessarily bumping up build numbers can cause problems for them and/or restricts their access to an otherwise perfectly good asset. This is what I'm trying to emphasize with this thread.

Good Morning, sir ...
Sorry for the delay in responding -- upgrading motherboard today, and hopefully everything will turn out ok -- Using wife's computer -- this small keyboard driving me crazy here!

I think this is where the content creation community can help out! I can only speak for myself, and I will give you an example -- A dear friend email me about using the snap feature on all updating Marsz Contents, specifically buildings, etc ... I like the snap feature very much, because it aligns everything perfectly, however, since he mix-and-match structures, including adding them on top of each other to create interesting structures the snap feature is not good for him, however, since he's a hardcore trainzer for over 10 years, and a friend I say "You have my permission to update the items, by deleting the snap configuration from the config file, and upload with his own kuids, a simple step that takes 2 mins, without asking me all of the time -- we are friends anyhow, so we talk everything so is not a big deal!

I can't speak for other creators as a whole, but there are those few creators, who have thousands among thouands like Ben and Dave, who are very flexible, and if ask, most likely they'll modified their items to fix the community's wishes!

N3V is dedicated in going forward, and not backwards, and that's understandable from their perspective, so it's up to the content creators to fill in the caps!

Take Care now!!!

Ishie




O
 
I always made my objects with the current build number of my Trainz installation since that's what they are made for. I also only upgrade older ones if I want to add a new feature that didn't exist or wasn't supported in previous builds. By the same token, I don't deliberately use a previous build number.

In an ideal world, each object would be classified by the type of support it needs to function. That way every simple object would have a minimum build tag and not the build of when it was created. This would also require a perfect backward capability in every future build or there would also have to be a maximum build tag to prevent it's use by newer builds that no longer support outdated designs. This presupposes a knowledge of the future that is not very common so not likely to ever be implemented. Retro-fitting that into previous assets would be a huge job, akin to the DLS cleanup and look how long that is taking.
 
Last edited:
But the DLS is the only place where CMP will recognize assets and download them, all others give ? unknown with the kuid number and you have to manually hunt for them. When you download a route either from DLS or elsewhere and check the dependencies in CMP. Which is a big pain in the a when you don't know what it is, and all you have is the kuid number. Some Trainz sites don't have the kuid numbers on the site with the download link so when you put the kuid in Google it cannot find the download link associated with that kuid. and foreign language sites are a pain to navigate even with Google Translate. Why would you quit, Dave? You make good diesels that weren't available before in Trainz and buildings like commercial businesses, etc. You could always create your own site and host future content there, but then you would have to pay for a site vs. uploading free to the DLS.
 
Last edited:
Back
Top