While I agree there are items on the DLS that display a considerable "lack of workmanship and/or quality" (but who am I to judge?), I have more problems with your suggested solution - far too many to go into here. The idea has been suggested before and, thankfully, never taken up. JCitron's "star download rating" suggestion would be a far better option although distinguishing between downloads that are automated (because its a dependency) and those that are manual (because "gee that looks good") would be a problem.
You're a human being and automatically judge, as am I. Nonetheless, there ought to be a weeding route available to protect the integrity of the DLS and the time of the Trainz community. John's Rating by Stars might be an avenue, but lacks the pointedness some sort of complaint procedure would entail.
Extend it another level, for example--You, me or John download an asset and find it's broken and can't be repaired--the meshes have Unicode characters or whatnot so Trainz is rejecting the filename of the texture which in English is Sandy Brown. (e.g. Container 2 or 20 by Lothar of HP-Trainz.--A BI in TS09 and TRS2006, with an asset-filename being one of those and the username the other) or a recent update with a typo--had two of those last week. If we had an email addy to report shoddy workmanship, or simple correctable errors like typos the vaunted DLS input filter somehow missed, it would benefit the greater community by saving all of us TIME! That most precious of commodities.
The decision in the end on the first would be N3V's, the keeper of the community Treasure Chest--and I expect them to weed out the junk, as I expect them to clean up assets with embedded errors. In the second, they would and should contact the creator and require a fixed asset to spec. None of us can legally change a mesh, for starters, so the CC has got to be in the loop when currently active. As an immediate action, the asset if that new should be quarantined until fixed--and any asset dependent upon it. In the case of resident long time faulty kuids and the new one with typos, IMHO, the kuid record would and should be overwritten and replaced so the bleeding stops there--making the DLS content "right", so it doesn't jump out and sandbag some other new or old-hand Trainzer. Many users, don't want to have any asset hassles--lack a technical background and it's insights, and expect turnkey fixes, not a CM one must master and manipulate to get a properly updated runnable asset.
- Unfortunately, I surmise fixing V1.3--V1.5 assets so TS09-TS12 read them fine may well break them for Trainz and UTC, since my experience is they need a mesh-table to keep N3V written Trainz versions happy--funny how they worked okay in the Greg Lane managed product family. Either the new Trainz expects things not possible in the old Trainz (anim and kin files) or they need to make the asset with ambiguous texture references compatible with a translation step, else the texture will need be duplicated in both locations using it.
Zac's reply made perfect sense. There is a big difference between being "made to last" (like old drying machines) and "keeping up with technology" (like software/hardware). The drying machines of 20+ years ago were not energy efficient, were prone to catch fire (because people did not keep the lint filters clean) and had higher maintenance costs - my 20 year old dryer cost a fortune to repair and, after its last breakdown, ended up on the tip.
I didn't say Zec didn't make sense, when
I said we needed push-back on this, you can see it's never been a popular dictate. I was saying the policy needed a head transplant. I said his post has the same Crappy attitude that tics off the user base. In particular:
This restriction is mainly due to these versions no longer having free DLS access and technical support after this date. It's not much good having new content appearing on the DLS for versions we don't support, and that can't access the content via the built-in download rools. It should be noted that we also do not ensure that the online functions of Trainz/Content Manager will remain functional after this time (so you may need to use the DLS website, if you have a First Class Ticket or a newer version in your account).
Has two erroneous statements to my way of thinking--
"It's not much good having new content appearing on the DLS for versions we don't support" is contrary to Tony's promise TANE would still run older content fine. Ditto v1.3 content. If they did
a proper translation step on the front end, some straight forward pre-processing, before evaluation of errors. the great majority of faults all of us WASTE OUR TIME fixing when the software coding can fix it automatically so we never see them, AND those assets are thereafter in full compliance locally is a pretty big boondoggle. The part about 'which we don't support' is pure nonsense. There are 250,000 assets on the DLS to handle elegantly, A few thousand or tens of thousands more will make no difference whatever. The cases just need handled, so it's a CON, SPIN, or MALARKY. Sophistry! Certainly disengenuous!
- As a text book writer and teacher of so many years, you really want to tell me that they couldn't take the TRS2004/06 code which can find a same-named texture in two different sub-folder meshes and make them work in current era Trainz like they did and do in older Trainz. Sorry. Not going to believe anyone's competence that suggests they can't write such an handler function.
The premise that each texture spec must be explicit only holds validity if the the texture.txt files allow relative pathspecs and they don't. A mesh in a night folder calling for a texture in a _body sub-folder have no means of specifying a path! (e.g.
'Primary=..\otherfolder\texturename.tga' hasn't worked for me when I tried it. The current implementations force LARGE texture files be duplicated, which is just insane from an efficiency and memory management standpoint.
- Both those considerations suggest they ought be taking a CRC on the textures or some such comparison, and building a lookup table of textures needed when loading the GUIs, for there are likely loads of duplicates--white is white, black is black, and there are certainly loads of assets using monochromatic 'UNIFORM' textures... Is there a way to specify a HTML or rgb color for such? I've never seen either in a texture.txt file, and I think the only place I've seen rgb codes is inside smoke effects containers. Allowing such in a texture spec would not only trim memory size, but simplify such constructions. Most graphics software can pick a color off and give those codes afterall. // F
The same applies to computer hardware and software - the first version of Trainz is approaching its 13th birthday. The hardware it ran on was primitive by today's standards. Because computer technology is advancing considerably faster than dryer technology, very few of us would want to continue using a software (or hardware) package that was half a decade old (or even less).
Must be nice to have excess funds. Want to pay my kids college loans, their grad school costs, and help out my retirement plan? Being self-employed, if I don't set it aside and act frugally unless needs must, I won't be able to retire at all someday. Not everyone has a cushy government funded pension, and not all of us even have a big company to lean on, even sick pay. But I do expect GM or Mercedes to keep making cars with round tires, not suddenly tell me Firestone is going to stop providing round wheels because their new models all have square tires. If it's not broken, don't try to tell me an incremental code change HAD TO BREAK IT because some wet behind the ears programmer team arrogantly failed to consider the impact on thousands of users and hundreds of thousands of assets when
they chose the most convenient path for them. If Hilliam were a least bit programming savvy, they'd find a pay cut for the next six years to match whatever raises they got since TS09. // F
My old XP machine (which ran my copy of that original version of Trainz) spent the last few years of its life running Ubuntu before it, like my dryer, ended up on the tip. My current Windows 7 (32 bit) machine with its Core 2 CPU will soon be replaced by an i7 based Windows 8.1 (64 bit) machine so that I can run T:ANE and spend less time waiting for other things to "boot up".
My condolences on the Windows 8 outlook. Make sure to run everything Trainz in Windows 7 compatibility mode as per the results of the Validations, validations, validations thread! // Frank
