User:Fabartus/temp2

Please verify conclusion
Please verify the tag region is obsolescent as I inferred from config.txt entries whilst fixing errors. I made an appropriate annotation here which should be verified. Thanks // Fra nkB 12:18, 13 October 2013 (EST)


 * The "region" tag is obsolete, and hasn't been used for many years. It's been replaced by "category-region" which has a well-defined format. Jamesmoody (talk) 17:55, 14 October 2013 (EST)


 * Thanks James, I'd thought so, but even terms that have gone away need handled, this is but one among others you lot have tried to wish away. They are on the DLS, they are in the config files of stuff you have in JA's... in sum, they need handled on and by the wiki. They should also be handled by your service pacs, installs, and hot fix updates, but here we are five years from the release of TS2009, and you programmers aren't cleaning up diddly locally, sanely, appropriately.


 * Re: Your edit summary here where you took out my attempt at conveying what a new asset builder seeing such should be thinking such data fields could or ought to contain. Turns out I'd asked two others to view that too and make fix ups with apropos descriptors and got an email on that request that you'd made an update before seeing your changes had occured. (Can we get email notifications turned on for this site... another Wiki Boolean setting, irrc.)


 * Bottom line the whole site lacks 'ideas' connectivity of A to B to C because you lot have left stuff blank everywhere. Links are not thoughts, there needs be some glue words making complete thoughts to readers. Null data is null data and conveys ZERO about what the tag does or how it's used inside of or outside of a data structure (container) DEFAULT doesn't convey squat unless there is some understanding of what is being defined. Quoted null-strings are used (one might say overused) throughout the whole data documentation system.
 * If they don't communicate to me with my background they certainly won't be understood without a lot of head scratching by someone without nine years at university and a programing history back to the seventies.
 * We can set off defaults if we convert these things to real wiki-tables and they'll be easier then to edit in any event. (See pseudo-table which does style for exactly that conversion. With some parserFunctions, we can turn them into smart examples, where they can be expanded in a dependent page with a sampling of real-world values passed as parameters, shedding the benefits of understanding across the wiki. That is the table could display one way, then with a click box, display the other. I can see the defaults being useful for cutting and pasting boilerplate to a new asset's config file, or if one was trying to update. Further, on en.Wikipedia, there are tables which can be sorted by columns. There's a lot of power missing in the toolbox here.


 * "Prompting" a recollection of what that definition or a phrase should be,... that makes the field name (tag in your weird nomenclature) make sense, is what I was aiming for. The Asterisks and other such 'text markup' aids can be employed to say that an empty string is default... after you let the kids know what it's for. Alternatively, present both a default table and one with explanations/prompts. If defaults are needed, they belong with the detailed examples after knowledge is built about what things mean/are used for. Many pages have "Categories" as a section title, which is pretty much a useless tag. Categories go after displayed text in the last section, whatever it is, will cover the same need. But an edit which keeps the spirit of the added communication would be more appreciated... I'm trying to translate what you staffers understand to something lay people sans computer training can understand. If I make an text edit at all, it's because something is UNCLEAR.


 * That's a confirm then, trouble is it wasn't handled and does occur in a lot of older content. See Region and especially TL-Obsolete-tag, plus this 'Epbrakes' section for handling obsolescent and obsolete container tags in all like cases. THIS is GOOD documentation, not mentioning a tag is confusing to people that have one on hand staring them in the face. They need a status on what it is or was and what to do with it now (e.g. "replace region tag lines with apropos category-region line in all versions after 2.4" Clear, concise, handled once, and respectful of the all the users time because it's leaving no questions. Saying "It's obsolete" means nothing without giving a solution too.).
 * I'd like to see such inside containers structures like 'epbrakes' handled inline as well, with a notation something like REM  epbrakes   ***** Legacy tag, remove when updating context after version 2.8 *****  or such like. Windwalkr seemed to give in on the point under the community pressure back in July, but until you lot issue hotfixes to TS2009 and up so versions 3.0 and up aren't flagged as errors they are as empty promises&mdash; as most things he's said on the forums.
 * This bizarre 2008-think concept of "THIS WIKI IS ONLY" for TS2009 is safely dead since you lot are dependent on it for 2010 and TS12, as are we. It's time to fix up such legacy data names so their status is neither confusing nor never mentioned. Tagging them as well with the last version such were valid in would be the best thing, imho.
 * In between there are some important shades of grey -- one can write such that obsolescent items are clearly demarcated, which in my lexicon means version 3.x now generates a warning when said tag or practice formerly did not. Identifying when a tech change like that begins would be best. You lot can then actually update the documentation and announce important content-design-affecting changes in advance and actually adopt a practice of communicating effectively with the user community, instead of the current "Surprise! This is how we f***ed you over with this release, aren't you appreciative of all the extra time this change will take from you?" That's Windwalkr's way, isn't it? That has to stop.
 * Quotes without contents we programmers might understand as a null string. But we know of null strings. We should know that defining a null string allocates a certain default block of memory, or at least defines a null pointer, but Lay people just scratch their heads, and worse, don't get a context that will add to gaining an understanding.
 * THE PROBLEM (site wide): You claim it and think of it as a programmer, so your interest is biased. So you list what might be most useful to the savant&mdash; default values... without first defining what the values mean do or how they're used to and for the non-savant. This is very inconsiderate to those trying to learn, really disrespects their time and assumes endless spare time for them.
 * When defining the structure, a default value of null strings aren't integrated to each other when handled in sections down below&mdash; that table is now off screen, has no immediacy showing associations. Outside the table 'tag name' discussions about adjacent lines are in different sections, so have no clear relevance to illustrate their interaction or relationships.
 * On this side of the world we call that "Putting the cart in front of the horse". Show the defaults down the bottom if they are of value. Show the introductory material where the topic is being introduced. Get the message across, then the refinement. Bottom line you lot have organized this looking at it from an informed point of view, not from the pov of someone ignorant of any of it. Yet this is what they have to use to gain that same knowledge.
 * Obsolete in my lexicon means it actually generates Errors' after a version-which-must-be-listed Version X.Y'' -- lingo you lot are very imprecise about&mdash;I'm interested in fixing your documentation, not continuing confusion points, so your elimination of the communication that the field defines a filespec is less than optimal.
 * When writing documentation, think like a user, not a programmer. Better yet, think as a new user trying to get a handle on what all these confusing interrelationships are, and how they interact.
 * Things like region and epbrakes are in things in JA files and on the DLS, hence must be mentioned and handled appropriately. Ignoring them is one of the worst mistakes N3V has made. It wouldn't work at all when and if it were obsolete. '[Such legacy & so ignored tags are 'Obsolescent', at the worst when speaking any version of English.] Benign except to byte-counts. Since the case which made me look for the tag definition wasn't seeing such a error complaint in V-3.3 it is by definition obsolescent, not obsolete.
 * It is further, as I annotated something you want to discourage ongoing use of, so "(depreciated) " as I marked it. We can and should put such definition of terms in the header lead to that big list-table, so that table the terminology is consistent.
 * Such assets can be cloned, and so the fact you lot haven't cleansed the JA files means you've not progressed anywhere near as much as you imagine in cleaning up assets. That's the price of cheating (Validating the common asset, updating the DLS with a kuid2 version, including that with TS2009 et. al. By my standards, or that of any large company you guys do slipshod work. Sorry. Just feel victimized over and over by your Company's past decisions!)
 * As my son pointed out, you should do one release which does nothing but clean up embedded assets and the DLS with virtually no game engine changes except to better handle this legacy interfacing automatically as should have been done from the git-go.
 * Why self-styled ace programmers (Sorry, Windwalkr's forum attitude, as it comes across) can't clean up most error causing situations is beyond understanding. I could have written filters in DOS 5 back in '93 to parse text files and fix many relationships. That PEV wrote PM2IM years ago and you haven't incorporated it automatically is damning. Chain a bunch of filters together in a batch file, and most manual edits you lot have forced on the users could be installed as a fixed version in the DLS. Apparently you can use TrainzUtil to do most of this... Your processing of the data differently means you should be able to translate stuff and generate apropos kuid2 versions... eliminate the old versions--with an alias, reference the new up to date 'In Spec' copy. If you'd begun that in 2009, it'd be done now--even really old routes could have been cleaned up with a few interns--at least so they don't generate errors.

... continuing the conversation:
 * That's one reason I'm surprised at your site's lack of sophistication. Having no help pages means no editor help or manual of style or clarity of how things are done. Clearly Tony Hilliam had higher aspirations for the wiki, the mission statement expected a community effort. That one didn't get generated reflects some of the hostile climate your boss's acerbic edit summaries created, not to mention it was never initialized... ParserFunctions and lack of a common.css are rather damning evidence in support of that point.


 * The best pages on the wiki are the that list article and the reprise of the CCP... neither of which had staff much involved, so far as I can see. The rest of it is a bunch of pages which stop before they say things clearly in the form of lists of things not tied together to make a clear picture. Your familiarity with the topic makes things seem more integrated than they are. Things are actually fairly confusing. Some sophomoric attempt to implement Parent-Child organization ala' a class in computer science just generates confusion on most pages... so the whole suffers clarity. It's not integrated with topic groups, in nav links, nor do you have the ability to do popups or alter the presentation. Given a decent Common.css and parserfunctions, that table you 'fixed in your mind' could present both versions... just click for one mode or the other. I can give you some examples of such on Wikipedia if you're interested. The parent-child thing doesn't work at all. Particularly not just as links without explanation. I provided one example of one of those fixed up somewhere.


 * Personally, I consider any obsoleted or obsolescent legacy tag that is not just ignored by your software to be poor coding for compatibility, a point the user community got on Windwalkr about plainly in July. Just ignore the line and go on. Issuing either a warning or an error is deliberately wasting a users time. It's insulting, and if you weren't trying to use source code as run-time-data, very unnecessary. Elimination of remarks in config files is at least a top five contender for the stupidest thing N3V has done, failed to do, or tried to do. But then you lot were and have been treating source code as run time data... creating a conflict between user needs and convenience to yourselves. Treating source code as was convenient to the programmers, ignoring users needs. Besides being inefficient, not using optimized binary data storage is a really unprofessional mode in this day and age of big hard drives. Frankly I'm shocked at how this thing is configured. Use Binary records, preprocess as you like and build an data base which is not accessed in such an outdated manner.
 * ASIDE, an conclusion: It's pretty clear you all have little experience working big company milieu's where premiums on communication are important. If you had experience working in a department of 30-40 interfacing regularly with two or three or four other departments of similar size, all having to interface with a corporate partner or three with similar large groups, and the government... you'd understand what I mean... That the 4-5 of you can turn around, poke your head over top the cubicle or walk down the hall and discuss what you mean... and never see the havoc that results from unclear relations and definitions is ... the state of affairs. The Wiki screams it, four years and incomplete is not a good thing to have on your resume. That you can leave this reference project unfinished is another. Not a slam, but the conclusion of several of us with reason to talk about you off line, so to speak. For months I defended Windwalkr and N3V against various rants. But now that experienced your bosses bedside manner first hand, I'm actually a tad sympathetic. I think he's war weary and needs a break from being the face on the forums. // Be well James. Fra nkB 06:08, 18 October 2013 (UTC)