Chadd04,
You have expressed the fears that many users have when a supplier announces a "cut-off date" for supporting an existing product. SNIP
I suspect the reasoning that N3V are applying here is that if they continue to accept asset uploads for earlier versions of Trainz then they are morally (and perhaps legally???) obliged to continue technical support for those earlier versions of Trainz. For example, continuing help desk support for Trainz 2009 (is that still continuing??).
Arguments on this thread have generally centred (with a lot of side issues and "wallpapering" thrown in) around fixing the older assets so that they will work "error-free" on the latest Trainz version (TS12) without having to increment their build numbers to 3.5 and above. The whole issue of fixing faulty DLS assets has been an ongoing saga in other threads - and I agree, Auran/N3V could have handled it better but no-one is perfect.
I have taken the view that N3V is a commercial operation and cutting costs and maximising sales, not providing lifetime support for legacy products, should be their main priority - for that I have been labelled a "sheep" which I proudly take to be a complement considering the importance of sheep in my country's history (only the best Merino wool and lamb cutlets of course
). N3V are doing what every other software company has to do to survive - keep updating and improving their products, often at the expense of dropping support for earlier releases. Yes, there are some users who believe that TS12 is not an improvement over 2010, or 2009, or even over 2006, but that is their opinion and I have a different opinion. Unfortunately, some people have taken this all too personally.
Peter Ware
Apologies if I hit a nerve there, I was perhaps baaaaing to another drummer! The point is I want you all to know how you were had.
I was and am still agitating factually for a return to sensible processing they tossed with TS09. Not every error can be fixed but to label a legacy tag an fault in an asset is beyond bad programming. Just ignore the darn thing. Perhaps I've been asking for additional errors by not auto-committing... but I felt fixing errors was a great way to get a handle on the data model--and the bugs my son experienced back then--well, I figured I had enough learning curves to get on with-so were best avoided... The GRIPE is the parts of the data model most unscripted assets use has been in place since v2.0-- TRS2004-SP0 with all it's many bugs. I could have written twenty translation modules in my sleep in the time interval just past, and that's what galls. These guys sat on their duffs and let YOU ALL wade through a swerve in requirements which was largely unecessary. And wall paper or not... I aim to prove it. // F
This is the part that makes absolutely no sense, and seems rather contradictory to the rest of your post. If you're not officially supporting TS2009 and TS2010, you don't NEED to test it.
Moreover, if you allow newer assets to take a divergent creation path, you are GUARANTEEING that you will break those assets, much as upgrading to at spline track-LOD-tree assured that affected assets would not work in pre-TS2009 versions of Trainz.
Lastly, the versioning system i.e. the Trainz-build number, along with stringent error-checking of the DLS upload bot, permits the DLS to maintain separate, functional versions for different builds while still maintaining rigorous error-checking. Which is why this entire issue makes no sense, apart from being intended as purely punitive means of locking out otherwise perfectly-good content.
Technically, they have all the error testing code at build XX already in CM, all they need do is apply the same code in a different place with a parser that knows which version to check against. So THAT part, is an outright outrageous bit of balderdash... again. Ain't going to get my confidence restored by sophistry Zec! Also, if you lot want to stand hard and fast with a five year life-cycle, it should be from a stable version--the last SP and it's hotfixes--not the beginning of publication. // Frank
Sorry Zec, I missed your post, apparently we we cross-composing!
I like the fact you are checking uploading, and that you acknowledge the moving process. Not really going to buy that there is any complex time involvement though for adding and maintaining a upload vetting bit of code once it's debugged and been online for a time. Last I looked, modern computer systems can branch on a test, and keeping code that vetts for TB v3.3, v2.9, or 3.7 is just keeping the same code employed with a branch to it as a handler. Something like that already happens in CM, altering the build up and down on the same asset gives a different family of errors, so don't go there.
That's really the beauty of the trainz-build code--I admired it greatly since it tagged data and identified how the data would need processed. Having my DB experience from years agone, the simple beauty of it wowed me. Since then, I've concluded you lot don't appreciate it, and are misusing it's potential. Now you've just decided every asset in a clutch has to be treated as being complex. THAT's misuse. You have kinds, you have scripts, each can be tested and vetted against any asset formulated. Granted the DLS upload vetting was imposed far too late, but I suggested a means to resolve that last spring, which in part Jcitron pointed out tonight it looks like you are implementing. You allude to it yourself above with respect to the changes pending in the DLS operations.
I'm certainly not advocating you guarantee a past asset will work correctly in new technology when scripts are involved--and most all trackside assets are certainly that, but to shut the door on a house when you can branch (There's that word again!) on kind and just generate a rejection message that such and such a kind (mocrossing's) MUST be the current tech level is a far more reasonable approach. Trapping a script type with kind and class a similar decision matrix. By all means, reject those hybrids--I had one bite me last week and I no longer like them either!
Does an asset, whether it be a flip tree or a house that sits off on a distant view need fancy techniques like AlphaHints and normal mappings, etc. Absolutely not. You guys are treating everything like it's right on top of the camera view, and the CC (route builder, or asset maker) has insufficient judgement to know when he should improve the asset (by selecting something else, or getting into other methods like baking textures) at HIS need. I get enough nanny-state bull from the government, I'd rather not get it from a company I like in many ways.
Lastly, I still see no effective policy for expediting the DLS cleanup. Correct me if I'm wrong, but you're not overwriting malformed content with the same kuid, but are just obsoleting it when someone fixes it, are you not? I THOUROUGHLY understand btw that such is contra-indicated for the oldest assets in the library... for the fix your companies new software requires would break THOSE assets in their milieu.
THAT realization was the reason I decided you guys absolutely need to auto-translate as a pre-processing stage.
But that's another problem creating friction with the community, that hopefully TANE will Tame! CM's as configured really suck at that because one has to manually poll THAT asset and by the time you get to where you can drag and drop into the DLH, you loose your sense of what you are doing and where you are... That's a big frustration in day to day data management. Ditto the dance to find a missing dependency even if it's on the DLS.
With a proper pre-processing stage, implementing all those weary repetitive (unecessary) fixes, and each are fairly simple when the parts are all there or not using illegal characters--can and should be, nay MUST BE automated to protect your (hoped for) new customer base from the swerve in input processing after TC3.
You do want to hold and encourage a happy new customer, don't you? (How about us old and tired and vexed current customers too!) Then fix the problem where it can be attacked easily and simply. If the TRS series can make those assets work, and many are simple enough that even I can fix them in a few minutes, then the same processing can be placed in a front end that protects you and us and all those potential new Trainz addicts from that era--and let's them be used.
All that's needed is some software to generate a working replacement config (a work, or intermediate file to further error test as now takes place) and edit the texture.txt paths properly. Given my adventure above, that latter one is high on my wish list! But so are other patchable fixes like bogeys conversions, connecting thumbnails to _art subfolder specimens and such small adjustments.
I hope you and your boss realize it's the unremitting never ending need to make these simple fixes which wear out everyone's patience and leaves a bad taste about the product and company as well. And it's all so preventable so in the end, triply tragic!
One's truly broken--missing parts, texture names in meshes with bad codes (Verbotten!) are justly kicked out as faulty, but if I can fix around a 1000 faulty assets in high volume assets ... and only found at the worst 15 that I couldn't--so can input software. Enough wall paper. // Frank
