Trainz Wikibook?

[mawilson]

Submitted for your consideration....

Doubtless many of you are aware of Wikipedia. They have a related site called WikiBooks. To quote the home page "Wikibooks is a Wikimedia community for creating a free library of educational textbooks that anyone can edit."

Now, the forums are a tremendous collection of knowledge relating to Trainz. This is a phenomenal place to get answers to questions. Problem is, even with the search tool, it's difficult to locate specific information here.

A little creative googling will locate a wide variety of tutorials. The ones you can find are generally quite good (thanks, all of you who unknowingly helped me import large chunks of terrain into Trainz). Sadly, some of the tutorials are a bit out of date. Other promising links wind up as 404s. I wonder how much we've lost to 404s.

Anyway... I'd like to suggest that we (okay, mostly you real Trainz wizards) band together to create the ultimate Trainz reference. I see it as a collection of processes, techniques, tips, hints, etc. organized in some semblance of logical organization; a textbook for making the most from Trainz.


I'm not even close to expert on Trainz. I suspect that such project could teach me far more than I could contribute. That said, I'm willing to set up a framework at WikiBooks and assist with importing, editing and 'pretty-fying' material. That is, if there is some interest within the community of Trainzers in pursuing it.

So. There it is. What do y'all say? Bad idea? Good idea? Willing to contribute to the effort?

 

[aardvark1]

It would tkae many thousands of pages just to reslove the continuous debates about which version is better.... 04 vs. 06 vs. TC.

Good luck on that one.

Have fun,
Ron

 

[mawilson]

The book should avoid religious debates and focus on the art and skills used to make great railroads regardless of version. Wikibooks invoke the principle of Neutral Point of View (NPOV) anyway.

 

[atsfrr3000]

So it'd essentially be a user-made instruction manual/bible for Trainz?

Sounds like a good concept, provided we can get enough people involved to cover all of the various aspects of it. Although I think I'd probably split it into books covering Surveyor and all of its functions, CMP and its intricacies, content creation, etc to keep things neat and relevant.

 

[mawilson]

While it could include user manual-ish stuff, I think the focus should be on things not touched on in the manual. Manuals will tell you where an option is and what it will do. They aren't so strong on why you would want to do it or when. Those are the things we ought to focus on.

I was thinking more in terms of multiple parts or 'volumes' to cover the various areas. That way there is one starting point. At the risk of getting technical, Wikibooks use a hierarchy of Mediawiki subpages to organize the book unlike Wikipedia that uses a separate page on the same level for each topic.

So, atsfrr3000, are you in?

 

[atsfrr3000]

I probably won't be able to devote very much time at all to it, to be honest. I haven't played Trainz in several months, although I still hang around here giving tips from what I remember.

However, once it grows to decent size, I would be more than willing to browse over it from time to time and add bits here and there and refine existing content.

 

[mawilson]

From the rousing lack of response, I'm guessing this is a no-go.

 

[johnwhelan]

From the rousing lack of response, I'm guessing this is a no-go.

Go and add a bit, it really could do with the newcomer's thread information being extracted and added in .

Cheerio John

 

[john259]

FWIW I think this is a very commendable idea. I'm not so sure about its practicality though.

Here are some random thoughts based mainly on my experience working with the RBR user documentation. These are all purely my personal opinions of course and not those of RBR:

The workload involved in a project of this nature is enormous. Most people who know the technical stuff aren't interested in documenting it, they naturally want to create things. A methodical clerk needs to plod along behind them doing the documentation.

Having a single entry point to documentation is vital, otherwise most users will be befuddled. Many users will not be able to distinguish between the various subdivisions of the subject and hardly any will be able to distinguish between styles of documentation such as FAQ, KnowledgeBase, Tutorial, Glossary, etc. They just know they have a problem and want to find the answer.

Having control over who can create, edit and delete content is vital.

Having control over the backup arrangements is vital.

It must be possible to move articles between sections as the structure of the document is revised - and all the links to and from the article must be automatically updated as necessary when this is done.

Providing a self-guided help facility is very desirable but far from simple to create.

Input and formatting must be ultra simple, ultra reliable and extremely rapid to respond. A grotty input and formatting system prevents you concentrating on what you're writing. It must be ultra-easy to create links to other articles. Achieving all this with server-based software isn't easy.

Creating different parts of the documentation in different software is asking for trouble.

Most people can't understand how to use CMS software.

Any search facility needs to handle synonyms (eg layout/map/route and junction/points/switch - and scores more like those).

Graphics are highly desirable but a right pain.

The system must be as future-proof as possible. It's all too easy to get caught out by a software update. If possible the source material should be in plain text files which offer some slight hope of being imported into any future software.

HTH, I'm trying to be as positive as possible. And of course the RBR user documentation breaks most of these rules

John

 

[mawilson]

John,

I' m sure glad you were being positive! I'll try to respond to some of your points. (Sorry, this is going to be long)

The workload involved in a project of this nature is enormous.

How do you eat an elephant? One bite at a time. Actually, you hit on why I started with a recruiting post. It will take a team and a bunch of sometimes contributors to make it real.

Having a single entry point to documentation is vital

Wikibooks are, well, books. The "root" of the book is a single page. The rest of the book is a collection of sub-pages hyperlinked together. If users can navigate a table of contents or an index, they can navigate a Wikibook.

Having control over who can create, edit and delete content is vital.

That is problematic with Wikibooks. It runs counter to their basic philosophy. Experience shows that only people with an interest actually edit. Besides, limiting contributors effectively increases the workload on the "approved" team.

Having control over the backup arrangements is vital.

Mediawiki (the underlying engine) retains a detailed edit history. A page can be reverted back to any stage in it's development. It's actually difficult to completely remove anything. The Wikibooks site is maintained by the same folks who keep Wikipedia running.

It must be possible to move articles between sections as the structure of the document is revised

That's easy. The entire document relys on hyperthreading. Since the pages are created dynamically from a database, restructuring the book only involves modifying the TOC.

Providing a self-guided help facility is very desirable

Mediawiki provides the capability to search page titles and page contents. Keep in mind, though, this will be a book of knowledge, not a knowledge base.

Input and formatting must be ultra simple, ultra reliable and extremely rapid to respond.

Mediawiki markup is very rich but, you can do a lot with a handful of basic instructions. The edit page provides an editor similar to this forum, including page preview. Wikibooks provides links to extensive editing how-tos.

It must be ultra-easy to create links to other articles.

Mediawiki links are simpler than HTML links. Like HTML, you can link to individual sections or an image in a page.

Creating different parts of the documentation in different software is asking for trouble.

Not a problem. Wikibooks use a single tool: Mediawiki.

Graphics are highly desirable but a right pain.

Mediawiki supports a wide variety of image formats. They are stored seperately and referenced in the document. Mediawiki provides flexible image placement.

If possible the source material should be in plain text

While not plain text files, the content is stored as text in the database. Wikibooks also provides a couple of tools for downloading the contents of any book or the entire library.

I hope this post allayed some of your concerns.

You may want to consider adding Mediawiki to RBR as a doc tool. It provides full wiki capability and, as a local install you have additional protection capabilities.

 

[john259]

Thanks Mark. Some of my comments were very general and you're right, WikiBooks passes a lot of my "tests". However, I was very worried to see a comment that entire books can be deleted if there are enough votes to do so. Maybe it would make sense to use the WikiBooks software but run it on a private server - if the software is available for such use of course.

RBR has explored various documentation programs and not really ended up totally happy with any of them. Some of that is because we're all individuals with different backgrounds, some of it's because we've got a lot of legacy information which we don't want to lose or have to transfer manually to other software (having to manually recreate all the links between articles would be a nightmare). So at the moment we're tending to battle on as we are. If we started again then a private wiki system might well be the best choice and we are using DokuWiki to some extent.

Getting back to the original subject of this thread (which I diverted us off ) - IMHO it would be a good idea to mock up a framework and see how it goes, unless that would involve a lot of effort or expense of course. I didn't see any instructions on the WikiBooks web site for starting a new book but maybe they keep that option well out of sight otherwise they'd have thousands of aborted projects.

Good luck with it, if it works then it would be an extremely valuable resource.

John

 

[sprinterASC]

As a new user of Trainz I would love to see some kind of Wiki available somewhere. Like other Wikis contributors could add little tidbits of info not present elsewhere plus some info on the "basics" of Trainz-ing.

For example, I downloaded the Clinch-Pro route from TrainzProRoutes. I the accompanying documentation it say to "add 60 hoppers to the yard" etc. What may seem a trivial item to those who are used to it, I have not run the route as I cannot figure it out myself. Little bits of info like that for newer users would be very helpful

Cheers
Bruce

a 3 day Newbie to Trainz.

 

[john259]

Might it be sensible for this project to start by addressing some priorities? Judging by the number of threads here they seem to be:

1. CMP concepts, usage and solutions to common problems.
2. Methods of finding dependencies that aren't on DLS.

Any more?

John

 

[johnwhelan]

http://en.wikibooks.org/wiki/Trainz :wave:

Cheerio John

 

[mawilson]

John,

True, books can get voted off Wikibooks but, that is a rare occurance and its never a surprise.

As for creating it outside Wikibooks, that is certainly do-able. The base engine is Mediawiki which is FOSS under GNU. I've had quite a bit of experience with it in the last 8 months. I've hosted three wikis inside a firewall and I've set up sandboxes using Uniform server on USB sticks. It's actually one of the easier installs. I do wish skinning were a bit easier, though.

If we go to a private server (will require some $, but then I have been considering getting some reseller space) then a straight wiki might be better. Call it Encyclopedia Trainz - sort of a Wikipedia for Trainz. It might suit needs similar to Bruce's as well. Something to ponder...

 

[johnwhelan]

there already is a trainz wiki

john

 

[mawilson]

John, Since you've already started the Wikibook, we ought to continue down that path.

Now we need a real structure for the book. And, since we have the book page now, perhaps we should use the associated discussion page to continue.

Just to get things started... Top level structure might look like:

Part One - "Things the manual didn't tell you." I see this as the place for CMP, DLS and other arcane user incantations.
Part Two - "Building the pieces parts." This part covers the fine art of building textures, buildings, trackside objects, splines, etc.
Part Three - "Creating virtual railways. Some assembly required." The focus here is on techniques to use Surveyor to build notional railways as well as model the real ones.
Part Four - "It's alive! It's Alive!" This part covers scripting and other techniques used to impart realistic behaviors and make virtual railroads come alive.
Part Five - "The back of the book." The collected end matter including glossary, index and appendices as necessary.

I don't think the part titles are in the final form but, I think these help get the idea across. Treat the parts as collections at the same level as chapters. Chapters should be divided into sections and sections divided into topics. In Wikibook terms, chapters, sections, and topics are a hierarchy of subpages under the base page.

A plea: If you are interested, please take an active role in creating this book. If it remains the effort of just a few, it will likely die on the vine.

Finally, an offer to the community at large. If you have a tutorial tucked away some place that you would like to see included in the Wikibook, PM approriate permission and the url and I will endeavor to translate it into the book.

 

[doncraig]

Hi All,
I would like to add my 'tuppenceworth' about tutorials, as I am sure there must be many good ones out there. To quote from your last post

"Finally, an offer to the community at large. If you have a tutorial tucked away some place that you would like to see included in the Wikibook, PM approriate permission and the url and I will endeavor to translate it into the book."

I have lost count of the number of tutorials I have started, I have lost count of the number of times I have started them and from all that wasted endeavour I can say I have had success with two.
I would rather see a page on tutorials that teach and work. Rant over.
I did sign in today in Wikipedia at the behest of John Whelan and found quite a reasonable idea coming to fruition, and of course the chance to conduct discussion on what can go in etc.
good luckand take care
Don W
:wave: I am all for it :wave:

 

[johnwhelan]

Hi All,
I would like to add my 'tuppenceworth' about tutorials, as I am sure there must be many good ones out there. To quote from your last post

"Finally, an offer to the community at large. If you have a tutorial tucked away some place that you would like to see included in the Wikibook, PM approriate permission and the url and I will endeavor to translate it into the book."

I have lost count of the number of tutorials I have started, I have lost count of the number of times I have started them and from all that wasted endeavour I can say I have had success with two.
I would rather see a page on tutorials that teach and work. Rant over.
I did sign in today in Wikipedia at the behest of John Whelan and found quite a reasonable idea coming to fruition, and of course the chance to conduct discussion on what can go in etc.
good luckand take care
Don W
:wave: I am all for it :wave:

My thoughts on tutorials are let's build a couple directly in the book. Some of the basic ones like simple loco etc need to be updated with version 1.2 of GMAX and better screen shots and having them in wiki format should mean they are easily updated.

Cheerio John

 

[doncraig]

John,
I agree with that idea, to put a working tutorial directly in to the book, provided it is in Gmax 1.2 format.
I also believe that anyone interested in creating with Gmax should do so in 1.2 and everyone should be encouraged to update to 1.2, after all it is free and it would allow everyone to 'sing from the same hymnbook' so to speak.
I know in my own case it is a 'Complete Idiot's Guide' that is needed when doing a tutorial and I am probably safer if taken 'out of the road of the traffic', but I believe a lot of people can be encouraged to take up Content Creation and this can only be good for the future of Trainz.
Just some thoughts
take care
Don W