User talk:Jamesmoody

Please do not leave comments here. I am unlikely to spot them.

If you need to contact me, please send me an email. If you do not have my address, send a forum Private Message.

Note: Do not contact me directly for technical support. Technical support requests should be sent to the Helpdesk.

See Wikipedia:Etiquette

Please note that this isn't wikipedia. We might use the same software, but don't assume that their rules and conventions apply here. Jamesmoody (talk) 12:27, 21 August 2013 (EST)

In particular note that we are not "NPOV". Documents on this wiki should reflect N3V Games point of view. Jamesmoody (talk) 12:39, 21 August 2013 (EST)

• Sorry we seem to have a different definition of profanity and the appropriate. S***ty is a rather apt term when things don't work right. For example, I'll address wiki business on the wiki, and expect the same—wiki's are about collaborative efforts, it's fairly plain something you guys have done failed in that respect... things never took off. // FrankB 09:11, 21 August 2013 (EST)

No, we don't have a different definition of profanity. You may see it as acceptable to use such words, but we don't. This includes "bleeping" words out; you're obviously aware of the words you're using, so just don't use them. If you feel the need to use such words, go outside and take a break instead of replying. Keep it up and you'll be banned. It's that simple. Windwalkr (talk) 09:54, 21 August 2013 (EST)

Also, we used a wiki initially because it was easy for us to edit - I can come back and add a page whenever I have new information to publish. If we get some community assistance, that's great - but it really is a secondary consideration. Jamesmoody (talk)

I think it embarrassing that a wiki started so long ago is in such a P*** Poor state, it wasn't even initialized with Public Domain standard help pages, and even ParserFunctions (which I badly need, I couldn't even begin to write Template:N3V-Help-Image and Template:Help-Image a while ago as I can't test conditions, files, parameters, so have a Sh***th temporary placeholder workaround... NOT HAPPY FACE MAKING! {{Tlx}} is not yet useable, which is pretty much needed for any smart template exposition and help... all that TAKES UP AND WASTES my freely donated TIME... So stop that!). // FrankB 09:11, 21 August 2013 (EST)

We're not trying to be wikipedia. We welcome collaboration, but this is NOT a community-owned site. This is a corporate site, with corporate goals. Where our goals align with your goals, that's great. If your goals work against our goals, then our goals take precedence. That may be a harsh way to put it, but I don't want you to misunderstand the reality of the situation here. Windwalkr (talk) 09:54, 21 August 2013 (EST)

Think Chris is or has gotten the picture that I only mean well, and if I wanted to be confrontational, I could really roast the company on the forum, and the Wikibook. I'm only trying to make you all look better, but that certainly means changing the status quo. For starters, if someone comes out with a browser that requires HTML 5, the whole site is non-compliant. There's no Common.css and Common.js files in place. No classes to call, only HTML 4, which have been obsolescent now for what, five or six years?

Coming in this spring after years of casual browsing to see in detail how little Trainz has progressed, how few changes and how dead this wiki is (Hasn't really progressed much since I first saw it back in late 2009, iirc) has been an eye opener. Not sure what you guys actually do, but I guess you can be proud you don't use coarse language. // FrankB 09:11, 21 August 2013 (EST)

Thankfully, all common browsers work fine on our site, so it's not something that we're remotely concerned about at the current time. Windwalkr (talk) 09:54, 21 August 2013 (EST)

On the other commentary/responses... Talk:TADDaemon, I have to parse what you changed to understand all your answers. Wikiquette when interleaving is to indent in between 'voices' (responses). Numerous people can then address a paragraph's point... or just the two. Taking things out of order to change the original text makes it rather difficult to see the conversational flow. Breaking the context seems to be a bad thought habit in N4V group think. Sign each para/post with four tildes, that adds a date stamp and your sig, which you can customize under preferences. (See mine)

You're quite correct, but nobody here really cares. We don't see the wiki as a workable chat tool. The software is not built with that in mind, and while some conventions have developed on other wikis to make it work "as best possible" we have better tools at our disposal and thus have minimal interest in learning the hacks that people have come up with for dealing with communication in a wiki. James has already suggested you use our forums. If you choose to use a backwards chat process such as this rather than the better tools which we have available, then don't complain when it's hard to use. Windwalkr (talk) 09:54, 21 August 2013 (EST)

I have gone back and fixed that chat page (with indenting and tildes). Please note though that what you posted is still purely a personal rant, and is still not welcome on a corporate site. You may wish to edit it... Jamesmoody (talk) 12:27, 21 August 2013 (EST)

I have to reconstruct the original text to make sense of your rebuttal. Again... a time investment for me. // FrankB 09:11, 21 August 2013 (EST)

... and a time investment for me to learn a new way of formatting text when writing using a tool for what appears to be /obviously/ the wrong purpose, and also by someone elses fairly arbitrary rules. And when I could have been working on something productive instead.

Regardless, as Chris understands, I'm here to help, and TADDaemon with all it's time wasting is NOT something which is working well or properly in the real user world. // FrankB 09:11, 21 August 2013 (EST)

I'm a real world Trainz user too. My first version of Trainz was 1.1.1. I became a betatester for UTC, a content creator for TRS2004, and joined Auran around the time of TC3. I see TADDaemon as an immense improvement over the problems we had previously - particularly from a content creator workflow. As an end user, I /vehemently disagree/ with your apparent viewpoint that TADDaemon is the spawn of satan and should be killed with fire, and that doing so would fix all problems ever. It saves me countless hours waiting for Trainz or CM to start up. I can run multiple CM windows in parallel, and even Trainz at the same time as well, none of which was even remotely practical before TADDaemon. Jamesmoody (talk) 12:27, 21 August 2013 (EST)

I'm like Chris there, what counts is what I see, the trouble for you guys is we have thousands of times the number of eyes, time on the job and places where we're seeing insufficient progress, or worse, a lack of attention or acknowledgement that there are serious issues. I know of three long time content creators, people with hundreds of DLS assets created between them that won't use TS2009 SP3 and beyond because of all the time TADDaemon wastes reconnecting when it should be connected (assuming it's needed at all), why it's active at all when we're in surveyor is a mystery. Makes no sense. You go with the local data base, no one is upgrading or downloading from in surveyor. As you can see, I've got a few Trainz versions to choose from, and TS12 is not one anyone should be happy with as an operator given all it's pauses and time wastes. // FrankB 09:11, 21 August 2013 (EST)

TADDaemon *is* the local database. It existed in pretty much the same form before we split it into it's own process, and we did that because:

* A Trainz crash used to reliably require a DB repair afterwards. Trainz would do it during the loading process. Just a black screen, no progress report. User reports at the time often suggested that Trainz needed a reinstall after crashing because it was "broken". I personally experienced this in TRS2006.

* Multiple processes can use the database at once - e.g. CM and Trainz in parallel, multiple CM windows, etc.

* It frees up process space for Trainz to use for other things. Just "maintaining the database listings" was starting to be a significant drain on process space for people with large installs.

* People *can* and *do* download within the game - the content updates menu, when getting DLC packs, and when joining multiplayer sessions, to name the obvious ones.

To address some other points: TADDaemon is continually necessary because it provides asset listings. When you use the tabs in surveyor, or the filter dialog, or in fact /anything that asks for a list of assets/ (which is way more common than you think as asset scripts can do it), TADDaemon is what gives you that list back. And Trainz can use the process space (i.e. RAM) freed up by using TADDaemon for other things. Jamesmoody (talk) 12:27, 21 August 2013 (EST)

So sorry if you're offended by my casual choice in language, but do credit that we are from different societies. That language doesn't raise anyone's eyebrows over here. // FrankB 09:11, 21 August 2013 (EST)

That kind of language doesn't raise eyebrows in "general society" here either - particularly the more, ummm, bogan parts of society. But it does a lot more than raise eyebrows in some of our critical markets, so we obviously don't want it easily visible in our end user documentation. Jamesmoody (talk) 12:27, 21 August 2013 (EST)

But do get used to having other computer professionals taking a serious look at your work, for as far as I'm concerned if I did my job as you guys have seemed to have done yours, the F-22 Raptor would crash every 99th flight, the Patriot missile would turn around and blast it's launcher or control vans, Laser eye surgery would burn through into peoples' cornea, and the Trident missile wouldn't ever threaten to launch from Ohio class submarines... so you'd likely be forcibly learning Chinese or Russian there down under. Those are only a fraction of the complex things I've been part of in my career, and when something runs worse than the version three releases before, something smells.

BTW, Given the ridiculously annoying wait for Parserfunctions, interwikis and so forth, I'm perfectly happy to wait for a talk response here. If you turn on email notification (since you are a site bureaucrat, that's in your toolkit) you can then see when pages change without using a watchlist tab.

The N3V staff admin seems to have trouble changing a boolean value when given a link to the how-to, don't you know. // FrankB 09:11, 21 August 2013 (EST)

You're making the assumption that he's remotely interested in taking advice on configuration from someone outside the company. Again, we work to our goals, not yours. Windwalkr (talk) 09:54, 21 August 2013 (EST)

Perhaps you can help him appear competent in that little thing. Like much of N3V's visible output, it's leaving a bad taste at the moment. Chris wants me to put up new user pages, in the Help namespace, but I'm not about to start that without further cleanup and having things straight first. I've already tagged too much using {{FAB-todo}}, and for every page there, there are three that don't have an overt tag that are dependent upon ParserFunctions.

Best regards // FrankB 09:11, 21 August 2013 (EST)

Small words and big pictures

If you can use some small words and big pictures to explain to me why N3V wouldn't want the power of parserfunctions I'd really appreciate it. Having one template do ten things is much preferable than ten doing ten when the same branching and testing logic that allows that, can allow things like having pop-open collapsed elements like the table {{TBS}}. I'd like to make that and other such table structures where it makes sense so people can expand them or not as it suits them, allowing them to see a big picture in the context. // FrankB 14:22, 12 October 2013 (EST)

It's not that N3V wouldn't want ParserFunctions. It's that someone at N3V wouldn't want to stop what else they are doing long enough to look into it, decide if it's a sensible request, act on it, and test what breaks afterwards. And more to the point, explain what they were doing for the past 'N' hours to their boss, when there's something else more urgent they should have been working on. Jamesmoody (talk) 17:55, 14 October 2013 (EST)

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 // FrankB 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)

Speak and write English to the audience!

re: this edit, YOU may understand what the three or four of you may mean by Classes, but what percent of your users have the first clue? AND BTW... what root? Who understands what you mean by that outside of your cubicle area.

You wrote that the parent class of "TrainzBaseSpec" is "config files". What the .... does that mean. "Config files" isn't a class! It can't be parent to anything. It makes /no sense/ whatsoever. Worse still, you've mis-used and abused so many technical terms with defined meanings so quickly in such a short sentence - that to anyone at the level to get the most out of this document, they'll assume it was written by an imbecile who has no knowledge of what they are talking about, and will assume that the entire contents are wrong. And go looking elsewhere for "better" information.

As to "kinds being classes" -- kinds are closely related to classes, but they don't sit quite right as classes. Example: scenery and scenery-trackside, both exposed under the same 'kind', but both different classes. It's another tag that actually makes the distinction between the two. That's why we list the kind for each class. Is this thing here a class? Yes, it certainly is. It exists in the class structure quite clearly. It isn't a kind though, and I will admit that you can't make a 'trainzbasespec' asset by itself.

As to 'root' - if people don't understand the root of a tree being the base, the starting point that every leaf is eventually connected back to via branches and trunks -- then I really don't know what to say. The point here is that whatever is said has to be /accurate/. You can't say "I edited this to make it more understandable" and leave it /wrong/. Jamesmoody (talk) 13:33, 22 November 2013 (EST)

From the standpoint of the customers you guys are most anxious to seduce, land, and hook--the younger crowd who will indubitably be trying to make sense of this unfinished collection of documents (2500+ routes on the DLS are a big big attraction! And that means error fixing, and so you have a big big 250,000 asset problem as even Hilliam knows--and have wasted five years it might have been resolved), to those new customers, and to the old technically challenged... the ROOT to them in the heat of the moment of frustration at having to figure out what another friggin' error is... is the fact each asset has a config text file which need certain items.

My presentation may not have been the best, but " Each of the TrainzBaseSpec file elements can be specified in any asset that has a defining Config.txt file." conveys the relationships far clearer than a school-boy abstraction of Classes.

That information may be useful and important, but it clearly and obviously doesn't belong under the header of 'Parent class'. It tells me NOTHING about what the parent class is, nor relates to it in any way, shape or form.

In fact, it should be so elsewhere, it's probably best placed in an "introduction to config files" type page - and not here /at all/. Jamesmoody (talk) 13:33, 22 November 2013 (EST)

That certain of those elements in the spec are mandatory is enforced by error checking. It's addressed in any case, iirc. Similarly Parent and Child classes just muddle the understanding of the users. In point of fact, the config.txt files for a KIND require those common items to be defined, set the threshold level for warnings and errors and define how the text INI file is processed and considered... without a config file to hold it, all those tag labels in the TrainzBaseSpec have no substance, they are merely conjectural, ideas. Recording them in a config.txt file puts them in context.

wut? Now you are confusing /me/. That's such a muddle of misused terms I'm not even sure what you mean. Jamesmoody (talk) 13:33, 22 November 2013 (EST)

KINDs are your true classes

No they aren't. Classes are our true classes. Most of them are also kinds, but there are classes that don't have a kind, and also others which share a 'kind'. Jamesmoody (talk) 13:33, 22 November 2013 (EST)

the TrainzBaseSpec is just a collection of common elements defined within each, or sometimes not.

Nope, it's the root of a literal programming class structure. It exists as a class in code and in validation. That class is inherited by other classes which do map onto kinds. You might consider it a virtual class from the end user perspective, as they can't define one directly. But that doesn't /stop it being a class/. Jamesmoody (talk) 13:33, 22 November 2013 (EST)

The software system uses them to bootstrap the asset, in effect. Since they define all asset types in your software, calling such a disparate changeable set of data definitions a class, means your true classes are meaningless. I have a bit of trouble wrapping my head around such a reversal of cause and effect. Put another way, The trainzBaseSpec is a mix of things which must be defined and others which may optionally be defined (user ID, description, licenses, email, etc.) to make a KIND--which provides the commonality one can then classify as a class.

Oh wow, you've gone off on a tangent again. The class system is primary. The kind system is laid across the top of that. Jamesmoody (talk) 13:33, 22 November 2013 (EST)

Things in the TrainzBaseSpec can be defined in any asset

Yes, because the other classes inherit from this one. That's how inheritance works. Inheritance is defined through parents and children. Part of the point of these pages is to list all the parent and child relationships - which we've done. Jamesmoody (talk) 13:33, 22 November 2013 (EST)

or you guys really need to drop programming and work on the documentation before moving forward with anything. Perhaps you misread or interpreted the quoted string. If you guys understood that (and begin acting like) you are in a collaborative enterprise with thousands of interactive colleagues and associates, that you are, perhaps you could begin to see you aren't facilitating understanding with such an edit, but stepping on it. // FrankB 11:33, 22 November 2013 (EST)

I disagree. That section is answering the question "what is the parent class of trainzbasespec" -- and the one and only correct answer is "nothing" no matter how much you debate it. I added one extra line to try to explain, in *correct* terms, why that was the case. Given you seemed to want to write a completely misplaced essay in that location.

No matter how much you fail at understanding classes, inheritance and so on, it doesn't change the fact that trainzbasespec doesn't have a parent. Jamesmoody (talk) 13:33, 22 November 2013 (EST)