Talk:Grand Theft Auto: San Andreas

Welcome to the discussion page for the wiki book Grand Theft Auto: San Andreas. To minimize editing conflicts, use the + button at the top of the page, rather than the edit this page button.

Historical

 * This walkthrough needs more work including screenshots and maps. --24.59.197.201 17:11, 8 Nov 2004 (UTC)


 * Please, add as you see fit. This books needs a lot of filling out.  As it is a highly popular game, a good walkthrough here might encourage similar work with other games.  --Alpharigel 22:40, 9 Nov 2004 (UTC)


 * I'm delighted to see someone else is actual concern about the game guides, i'll try to give you a hand with the gta guide, and develkop a standard format. --CGorman 16:05, 12 Nov 2004 (UTC)


 * I suggest we wait untill the PC version to take screenshots. --142.46.130.26 00:45, 23 May 2005


 * Added FAQ sub-page. Tidied this page, and added some proposed style guidelines. --Aya 15:48, 14 Jun 2005 (UTC)


 * Added font-formatting explanation. --Master Thief Garrett 03:07, 15 Jun 2005 (UTC)


 * Added more FAQ content. Major changes to this page. --Aya 17:20, 15 Jun 2005 (UTC)


 * Moved contents from the main page to its own page, and added all active pages to it, in an effort to keep track of what content we have already. More major changes to this page. --Aya 21:35, 15 Jun 2005 (UTC)

Mission page renaming
The mission pages are getting ridiculously long names. Like Grand Theft Auto: San Andreas: Sean "Sweet" Johnson I.

Then if Aya makes his individual mission pages we'll have even *longer* names.

What I suggest is that we have pages named like Grand Theft Auto: San Andreas: Missions: Sweet: Mission Here. Short and simple. We don't need the person's surnames etc., just the main name used for them. Similarly, the character page for him would be Grand Theft Auto: San Andreas: Characters: Sweet.

That is if we change Grand Theft Auto >> GTA for the longer page names of course. But they definitely need to be threaded together somehow, and not just by the character. Master Thief Garrett 01:51, 16 Jun 2005 (UTC)

UPDATE: upon further investigation of the Wikibooks mechanics, shortening the name is not advisable as those pages would be "orphaned" from the actual namespace. Master Thief Garrett 03:09, 16 Jun 2005 (UTC)

Re: Mission page renaming
I'm worried (although no-one else seems to be) about namespace collisions across the whole Wikibooks site. Some Wikibooks have taken extremely common page names like Appendix in the global namespace.

I figured it would be polite to minimise this 'pollution' by ensuring a consistent prefix which is guaranteed never to collide with anything else. I don't see a big problem if we at least keep the global prefix as per the above standards, especially considering every page so far already uses that convention. Bear in mind that I initially wrote the standards based on what was convention at the time. Much easier than changing all existing content to meet a new set of standards.

Regarding new mission pages (if I ever get around to it), I was considering dropping the name of the mission 'boss' from the page name completely. I want to minimise the number of pages containing indices, since these need to be updated if any page names change, so I'm just thinking of a separate content-page for each significant concept, and one HUGE contents page to index it.

As far as I can see there are two choices:


 * Use separate namespaces
 * Use disambiguation where necessary

The former will produce pages named:


 * Grand Theft Auto: San Andreas: Mission: Ryder
 * Grand Theft Auto: San Andreas: Character: Ryder
 * Grand Theft Auto: San Andreas: Vehicle: Infernus

And the latter:


 * Grand Theft Auto: San Andreas: Ryder (mission)
 * Grand Theft Auto: San Andreas: Ryder (character)
 * Grand Theft Auto: San Andreas: Infernus

Personally I find the former slightly neater, but I'm fairly easy either way. Aya 03:16, 16 Jun 2005 (UTC)


 * The advantage of the first method is that you can see where a page is "housed" without brackets. Also it creates "clean" URLs, for example "Grand_Theft_Auto:_San_Andreas:_Contents" as opposed to "Grand_Theft_Auto:_San_Andreas:%28Contents%29".
 * Also a visitor who comes across a URL leading to "Grand Theft Auto: San Andreas/Vehicles/Infernus" can cut off the car name to get "Grand Theft Auto: San Andreas/Vehicles", whereas if they decided that "Grand Theft Auto: San Andreas: Ryder" would lead to a core page they would instead get an error. Nothing major, but might as well make it as foolproof as possible IMO.
 * Note the slashes instead of colons, this makes it a lot easier. Look at "Grand Theft Auto: San Andreas/Vehicles/Vehicle Missions", it automatically generates a mini-navigation list. Also for the technical side of things this threads the pages together, whereas with colons it treats the other bits as if they are sub-books and does not attach them to the preceding "directory" they contain like it does with the slashes. Master Thief Garrett 05:23, 16 Jun 2005 (UTC)
 * The problem with not having boss subpages is that things can be revealed too soon. Right now the table of contents lists all the boss names; this could potentially spoil it for someone who hadn't got that far. So perhaps we should at the least have the region subpages, so you'd go to "Grand Theft Auto: San Andreas: Missions: Los Santos: Ryder". That way only by clicking through to the region page would the bosses' identities be revealed. Not ideal, but the original goal of this Wikibook was that the layout be as accidental-spoiler-free as possible. Master Thief Garrett 05:30, 16 Jun 2005 (UTC)

Once more, from the top
Okay. I think we both have different interpretations of what Wikibooks actually is, and the most effective means of using it. I guess it was rather a dumb idea of mine to choose some standards without adequately justifying those choices. This almost always fails to produce standards which get adhered to, in any system where people are not rewarded for following said standards. e.g. In a company, you get paid money to follow their rules. On a wiki there is no obvious financial reward at all. But I hope you at least agree that standards are important on collaborative projects, if only to the extent that we interpret language in the same way. i.e. We share a common 'dictionary'.

For what it's worth, I'm a 28-year-old software developer, and during some of the projects I've had to 'endure', I came across various pitfalls of the processes commonly used within those projects. Most of these don't really pertain to wiki, but some do. I also fairly new to the wiki community, but I really like the idea, because it does to information what web-forums and newsgroups can only dream of.

The dangers of page naming
I've finally read through all the material I can find about page name delimiters, and I'll just summarise what I've found here:

N.B. I use the character '*' to represent any amount of whitespace, including no whitespace. Valid whitespace characters seem to be: '_' and '%20', but not ' ', since this is an illegal character in a URL. All browsers convert it to '%20'.

page name -> wiki interpretation

"*GTASA*" -> a page in the global namespace named "GTASA"

"*Talk*:*GTASA*" -> a page in the "Talk" namespace named "GTASA"

"*GTASA:Ryder*" -> a page in the global namespace named "GTASA:Ryder"

"*GTASA:_Ryder*" -> a page in the global namespace named "GTASA:_Ryder"

"*GTASA/Ryder*" -> a page in the global namespace named "GTASA/Ryder". Provides a link to "GTASA"

"*GTASA/_Ryder*" -> a page in the global namespace named "GTASA/_Ryder". Provides a link to "GTASA"

"*GTASA_/_Ryder*" -> a page in the global namespace named "GTASA_/_Ryder". Provides a link to "GTASA"

Notice the last three are conceptually identical, but will return three different pages. Not really what we want.

The dangers of hierarchies
Hierarchies are probably most familiar in things like URLs. The idea is to use them when something is conceptually a 'child' element of another element. This is great for some applications, but the problem is that with a bunch of disparate concepts, as you might find in a guide for GTA:SA, it's nigh impossible to get everyone to agree which means of arranging things in a hierarchy is best.

e.g. I noticed above that the page 'Vehicle Missions' is a child of the 'Vehicles' page, whereas since it's ultimately talking about missions, and not vehicles, I might have decided to make it a child of the 'Missions' page.

The same is true for most classification schemes. Let's take an example for movies. If I decide on some categories like 'Action', 'Drama', 'Comedy', 'Horror', 'Sci-Fi', etc.

The problem now is that when I want to add a movie to one of these categories, which one should I choose? The movie 'Pulp Fiction' surely belongs to more than one of these categories.

The error here is defining categories which are not mutually-exclusive. A good example of categories might be 'A', 'B', 'C', etc., in which case, there could be little argument that the movie 'Pulp Fiction' should belong in the 'P' category.

Categories also fail where the category names are poorly defined, as they are right now.

Furthermore the hierarchy might change as new content is added, and if this hierarchy is included in the page name, then the page name will have to change also. From my experience, it's a lot easier to change the content of a page, than it is to change the page's name.

Another problem with using the '/' notation is the implication that the parent node MUST exist. I might want to have a page "foo/bar", but not a page "foo".

Conclusions
To avoid confusion, I shall define the following terms:


 * bookshelf:Conceptially, an index of one of more categories of books on Wikibooks.
 * book:This is perhaps analagous to a paper book. This book may belong to any number of bookshelves.
 * page:This is perhaps analagous to a chapter in a paper book. Note that one of the design goals of Wikibooks was to allow many books to share the same pages. e.g. Most of the Wikibooks relating to computer programming, tend to include the global page containing the ASCII chart.
 * page name:The suffix of the URL used to retrieve a page. i.e. http://en.wikibooks.org/wiki/ page name. Note that many similar suffices may be used to reference the same page, so I shall define it to mean the shortest suffix required to retrieve the page.
 * content page:Conceptually, perhaps, a leaf-node page which contains mostly useful content pertaining to its page name.
 * index page:A page whose primary reason for existence is to provide an index to other pages. The index could be hierarchical, alphabetical, or whatever. A bookshelf page is an example of such a page.


 * Use page names solely to uniquely identify discrete concepts within the scope of the book. They should not be used to denote hierarchy.
 * Keep the page names as short as possible, while making every effort to avoid namespace collision, by using scoping or disambiguation where necessary.
 * To provide a hierarchical model of all the content pages relevant to the book, use an index page to index the existing content. This is the current purpose of the 'Contents' page. If the conceptual hierarchy should need to change, you only need to modify that one page. This also allows you to apply multiple conceptual models to the same information, simply by having multiple index pages. e.g. the 'Index' page will ultimately provide an alphabetical index of the same content pages, and the FAQ page is starting to link back into the main content.
 * To provide a hierarchical model of all the content pages relevant to a smaller scope (e.g. all missions in Los Santos), use another index page.
 * Try to avoid changing the page names of existing pages, or creating too many new content pages until there is a clear page naming standard.

Perhaps it would be clearer if I specified how I ultimately expect the pages to be named. The string "GTASA" should be interpreted as "Grand Theft Auto: San Andreas":-


 * Index pages
 * "GTASA" - Main page, linking only to other index pages.
 * "GTASA: Contents" - Full hierarchical contents, linking to every content page.
 * "GTASA: Index" - Full alphabetical index, linking to every content page.
 * "GTASA: Frequently Asked Questions " - This page is a little hairy, since it contains both indices and content, but I shall put it in here in the hope that ultimately it will only contain links to other pages.
 * Content pages
 * "GTASA: Mission: Ryder" - Anything pertaining to the 'Ryder' mission.
 * "GTASA: Mission: End of the Line" - Anything pertaining to the 'End of the Line' mission.
 * "GTASA: Character: Ryder" - Anything pertaining the the character 'Ryder'
 * "GTASA: Vehicle: Infernus" - Anything pertaining the the vehicle 'Infernus'
 * "GTASA: Item: Night-vision Goggles" - Anything pertaining the the item 'Night-vision Goggles'
 * "GTASA: Item: Night-vision Goggles" - Anything pertaining the the item 'Night-vision Goggles'

If you think having only a single index to all missions is too much of a 'spoiler', then you could create another index page, say, just for Los Santos missions, which would link to the 'Ryder' mission, but not to the 'End of the Line' mission.

The means used to disambiguate the page names is arbitrary. I merely chose the colon (as used typographically rather than in a scoping context. i.e. "foo: bar" rather than "foo:bar"), because this seemed to be the way that the content was already organised. Some other examples:


 * "GTASA: Ryder (mission)"
 * "GTASA: Mission - Ryder"

I really don't care which method is used, providing it's agreed upon. Maybe the colon is a bad idea because it implies a namespace where none exists.

See also: Naming_conventions

Okay. It's 8:00pm here, and I'm off to the pub for a while.

Aya 18:56, 16 Jun 2005 (UTC)


 * I wasn't aware that there was a misunderstanding at all, but now I finally see what you're getting at! Yes I did think of the hierarchy of the Vehicle Missions--after I'd moved it! Certainly it should go under missions.
 * But what other examples are there of multiple-location pages like the Pulp Fiction example you gave? From a quick look at the list, pretty much everything might as well stay right where it is until such time as good names are found for "collectible hidden things" and such. For neatness' sake the Burglary guide should go under the Vehicle Missions page, but, again, that's minor.
 * As for implying the parent exists, in the currently applicable situations I can't think of a parent directory that would be unwanted, except for /Cheats/ but I've got plans for content there too.
 * The colons as they look nice and make nicer-looking page auto-titles than the slashes do, but they still imply an upper directory exists. Brackets make users less inclined to think there is a higher level, but as a downside they generate ugly URLs ("Grand_Theft_Auto:_San_Andreas_%28Contents%29").
 * I'm interested in using slashes because that is the standard for nested pages both in many of the other books here and the pages on other Wikis. Also, and more importantly, the MediaWiki engine will eventually support a TOC link on each page that will generate a list of its child pages, but this will not however support colon-based directories. Therefore for future-proofing and overall cohesiveness with the style adopted by the rest of the Wikibooks projects it seems the slash should be the way to go. Hmmm...
 * But hang on, I've got an idea, I'll just post this and do that :) Master Thief Garrett 14:22, 17 Jun 2005 (UTC)

Puzzling out the hierarchy
To try to get some agreement on how pages should be tiered, if at all, here is a list of all current and proposed pages.

Feel free to tweak the list to put the pages into whatever hierarchy or lack of hierarchy you think is right; when we agree on the list it can then become the standard.

Note that I've used / to indicate the hierarchy because it shows up easier than anything else; whether / becomes the standard is another matter.

Pages needing hierarchy decisions

 * Grand Theft Auto: San Andreas
 * /Missions
 * /(mission name here) << each mission will eventually have a page, in the meantime each boss will likely have one
 * /Vehicle Missions
 * /Burglary
 * /Cheats << problem: this page does not exist, solution: put something there that cannot go individually. I had worked out something, but I forget, will update with it when I remember!
 * /PS2
 * /Xbox
 * /PC
 * /Territories << a new page, talking about gang lands in general ; is there a better name for this page?
 * /Gangs << a new page talking about the various gangs in San Andreas ; I've been intending this for a while but wasn't sure how to tier the now-related turf pages with it
 * /Turf Wars << its purpose will change to actually *fighting* for turf, info on turfs in general would go into the parent /Territories page
 * /Territory Glitch
 * /List of Territories << "List of" seems possibly obselete, is there a better and/or shorter name?
 * /"secrets", "collectibles", etc. << this needs a good-sounding name ; this page will talk about the collectibles and what they do in general before delving into the actual lists
 * /Tags
 * /Oysters
 * /Photos
 * /Horseshoes
 * /Unique Jumps
 * /Dating Guide << not sure where this goes, maybe under /Basics or just leave it where it is?
 * /Appearance Guide << perhaps under /Basics?
 * /Controls << this is an obvious one, but should it tier under Basics or be on its own?

Should weapons and items be separate? I mean, would it be best to talk about "/Weapons/SMG" or "/Weapons and Items/SMG"? I really don't know. At the point where each item has a page of its own I'd say having a united "Weapons and Items" page would be preferable to keep repeated babble to a minimum. If /Weapons is just essentially linking to the indepth pages, it would be less obselete if it also listed all the items, if you see what I mean.

Maybe cut "guide" off the pages since the whole book is a guide anyway?

Pages that should remain where they are

 * Grand Theft Auto: San Andreas
 * /100% Completion Checklist
 * /Frequently Asked Questions
 * /Contents
 * /Index
 * /Basics
 * /Mods
 * /Sources
 * /Vehicles

"Almost final" ones (that are already sorted out)

 * /Characters
 * /(character name here) << each character would eventually have their own page

Colons Considered Harmful
Okay. You've given a good reason for using '/', so I've changed the standards to reflect that. Any idea when MediaWiki will support auto-TOC for '/'-based subpages?

You'll also notice a lot of things have moved around. This page was getting too complex, so I thought I'd move parts of it to a metadata section.

Aya 18:49, 17 Jun 2005 (UTC)


 * I really couldn't say. Some of these new ideas take just a week to implement, others take many months. This particular idea is easy to do, but the problem is that more pressing things like bug fixes are need to be done first.
 * Okay. Not too bothered, but I'm a big fan of future-proofing stuff as much as is reasonably possible. I guess I was a tad worried that renaming pages would cause problems, but it doesn't seem that way to me any more. I'm kinda new to wiki, so I had quite a bit of wiki tradition to pick up before I start doing anything too major. Futher, I like to keep things tidy, and leaving hundreds of redirect pages lying around seems a bit messy, but it looks like only an admin can actually delete a page, so there's not a lot I can do about it.


 * I like the template, that's a good idea. I was thinking of doing something similar, but the way you've done it it actually matches the appearance of the existing backwards links! Nice!
 * Yeah. I've been experimenting a lot recently with XHTML/XML/XSLT and CSS, so I figured there must be a way to make the navigation links look more like the ones which are auto-generated. On the subject. I think we should try to restrict the number of non-templated navigation links in pages. Obviously normal links to other related pages are a good idea, but if we want to standardise them across many pages, I think templates are the only way to go.


 * I notice you haven't moved anything around on the hierarchy example, so is that more or less the final thing now? Master Thief Garrett 00:11, 18 Jun 2005 (UTC)
 * Yeah. I'm okay with the way things are as in the "new naming policy" which you came up with; the only exception being "Vehicle Missions" being a child of "Vehicles", which we already discussed. Don't worry about it for now. It'll probably make more sense when we get more content in. Aya 19:17, 18 Jun 2005 (UTC)

Latest Changes
I've made loads of changes today. I'm trying to see if I can squeeze everything into one of the four subpages "Basics", "Missions", "Vehicles" and "Items".

Aya 00:40, 22 Jun 2005 (UTC)


 * All looking good! Burglar should maybe be a subset of /Missions/Vehicles/ though, but that's just a minor thing. Master Thief Garrett 01:30, 22 Jun 2005 (UTC)


 * I wasn't planning on having that many levels of hierarchy. I didn't have much time to explain last night. I'd been editing pages for about 12 hours and was starting to get a little tired. My latest design model is as per the next section: Aya 13:23, 22 Jun 2005 (UTC)

New design model
This is partly based on your comments that page names were getting too long, and that the use of hierarchies (using '/') was a good thing, both of which I agreed with (eventually :-)).

Even though I still believe that a full contents list is beyond the scope of the main page, I still think it a good idea to use the main page as a jumping-off point to the lowest level of the hierarchy (since that way, you can navigate through the entire book without resorting to the contents or index pages). To this end I figured it would be worth minimising the number of immediate children of the main page, to reduce the amount of links in it. This is based on my critique of the main page of the whole wikibooks site, which is far too confusing for a newbie, since is has far too many links in it, and many of them take you to either identical, or, worse still, near-identical duplicate pages which ought to be merged or whatever. The site is a bit of a mess as I had previously mentioned (e.g. the evilness of the page Appendix, which ought to be scoped into some sort of SQL namespace), but I don't have the time to fix the whole thing. Perhaps future releases of MediaWiki will make this easier. Anyways... on with the design:

The current low-level hierarchy looks like this:


 * Grand Theft Auto: San Andreas
 * Grand Theft Auto: San Andreas/Meta
 * Grand Theft Auto: San Andreas/Basics
 * Grand Theft Auto: San Andreas/Missions
 * Grand Theft Auto: San Andreas/Vehicles
 * Grand Theft Auto: San Andreas/Items

I'm also thinking of adding one final page at the lowest level:


 * Grand Theft Auto: San Andreas/Appendices

And now. A quick explanation of what content should go into what sections.


 * Meta - Anything which is to do with the organisation of the book, rather than content for the book. This section won't be in the "brief contents" or "full contents" lists, since it's aimed at people who edit the book, rather than those reading it.
 * Basics - Anything which is fundamental to playing the game, and doesn't fit into any other section (although there might be some crossover with the new Appendices section).
 * Missions - Anything which is a mission. Including: story missions, asset missions, vehicle missions, challenge missions, collection missions.
 * Vehicles - Anything which is a vehicle: cars, bikes, planes, boats, but NOT the jetpack, since this follows the behaviour of an item (in the sense that you can't store it in a garage).
 * Items - All weapons, tool items (spray can, extinguisher), gift items (flowers, dildos), and the jetpack.

Regarding the appendices section, I felt it might be worth including that for things which aren't really that "basic". Futhermore, I think we ought to keep the "basics" section completely free from spoilers, and I'm wondering if that really is the case. I'm thinking at least the 100% completion should go in here, and maybe some other bits and pieces. Perhaps also the dating guide, if it gives away the names of girlfriends, and/or other plot information.

Now the important bit. To minimise the length of page names, all other pages should be direct children of one of these pages. I've checked, and there should be no namespace collisions by putting all missions in the same namespace. Arguably, the side-missions are just as important as the story missions (sometimes more so) for 100% completion.

Regarding the actually subpage names. For the missions section, I've been using the canonical mission name (including capitalisation and punctuation) as per the TEXT/AMERICAN.GXT file on the game DVD. This way, there can be no arguments about correctness.

The same can be done with vehicles (I already have a complete list of all vehicle names, including those which are removed from the game), but I don't think it's worth creating any subpages for these yet, at least until we have some screenshots of what they look like. I can grab all the other canonical data about each vehicle (top speed/acceleration/etc) from the DATA/HANDLING.CFG file and other files on the DVD.

Based on the minimal amount of information we currently have about characters, I don't think it's worth making a separate page for each character, but I wonder where the page ought to go. Is it "basics"; does it contain spoilers; should it be an "appendix"? If we do decide to create subpages, then perhaps it deserves its own root node (i.e. GTASA/Characters/ ).

I shaln't make any more structural changes until you've had a chance to read this, and comment on it. I'm beginning to think perhaps my rule about having no more than 2 levels of hierarchy to be a bit harsh to apply to all sections. One of the reasons I think it's useful in the missions section is to make it easy to reclassify missions later on if need be. At the moment, my classes (e.g. story mission, asset missions, vehicle mission) are as per the bottom of the page Grand Theft Auto: San Andreas/Missions/In the beginning, but this is by no means a final classification. I may decide later on that perhaps it's worth subclassing "required" and "optional" story missions, and this will be a whole lot easier if I don't have to worry about page hierarchies. Page renaming is still a bit messy, since it requires you to manually redirect all links to the old page name. To be honest, I think this feature could be implemented automagically in a wiki server, but I haven't seen one where this is done yet. I was thinking quite seriously about getting involved with the MediaWiki project, but I really despise PHP. PHP is great for small projects, but it's not really that scalable (notice the number of squid proxies this site has to employ to get around that problem). Maybe I'll write my own from scratch. ;-)

For now, I'll carry on with mission walkthroughs until we get a concensus on the remaining organisation. When we do, I'll move it to the "standards" page, and move the section "puzzling out the hierarchy" from the "information" page back to this page. Arguably, I should never have moved it anyway, since it's really "speculation" rather than "infomation".

I hope this re-organisation of the "basics" and "missions" sections hasn't bugged you too much, but discussions via this page are rather slow, and I'd never get anything done otherwise. Perhaps it might be easier to communicate via MSN/Yahoo/ICQ/whatever. FYI: I am:


 * adrian_eyre@hotmail.com for MSN (don't send email there cos I never read it)
 * adrian_eyre@yahoo.com for Yahoo (ditto)

Anyways. Let me know what you think.


 * I can't really talk to you directly at the moment, but the new structure is sounding fine. I'm not at all bothered and it certainly makes sense to put everything extra under Basics. As for Appendices that's also fine, that's just what you'd have in a printed book to cover non-essential stuff.
 * I'm not sure about calling item-collection a "mission", it's not structured or timed or even labelled. Maybe under Appendices since you don't (really) need them anyway?
 * Other than that everything's fine. Except I keep screwing up on OG Loc, bah... :( Master Thief Garrett 06:57, 23 Jun 2005 (UTC)

Content moved from Information page
I've moved the Puzzling out the hierarchy section back to this page, since it wasn't being maintained. It's probably redundant now anyway, but worth keeping in this page for posterity.

I also removed this:


 * the "invisible" parent page Grand Theft Auto: San Andreas/Cheats does not exist; perhaps something could go there, maybe a master cheats overview like GTASanAndreas.net has?

Due to restructuring the content, it no longer seemed relevant.

Aya 21:06, 23 Jun 2005 (UTC)

Final Naming Convention
I've reorganised the remaining pages. There's still a few more bits and pieces to sort out from the Orphaned Pages list, but at least now it's obvious where they need to go.

Check out the metadata pages for the gory details. I'm off to bed.

Aya 00:55, 24 Jun 2005 (UTC)

Misc
Perhaps the text you added to this page should be moved here instead? It's already in the FAQ, as well as in a couple of the walkthroughs that require it. Personally I would've deleted the question. I doubt the user who left it will even return.

I'm assuming you've only just recently acquired the game itself (PC version?). How's it going?

Aya 14:03, 29 Jun 2005 (UTC)

GTA Pages
N.B. Some of this text has been copied from User talk:Aya. - Aya 4 July 2005 14:29 (UTC)

Hi Aya, been doing some patrols of the edits. Can you check the GTA pages for consistency/ correctness? Some newbies had been tinkering around with some pages (and not all are nice cuddly newbies either). There's way too many edits over the weekend for me to look through while at work. :P - Lynx7725 4 July 2005 02:29 (UTC)


 * I have been doing so on a daily basis (for the most part). Every page in the book is in my watchlist, and I tend to check every diff, especially those from non-registered users. The problem recently has been that the Mediawiki upgrade from 1.4 to 1.5 (on or around the 2nd of July) seems to have removed all this history from my watchlist, so I've had to manually go through all the pages' histories to check. I checked all the pages on the 3rd of July, with the exception of the mission walkthroughs (there are about 100 of these), and reverted any intentional or unintentional vandalism. I'll check through the remainder when I get a chance, but I tend to find most of the vandalism happens in the same few pages each time, none of which are mission walkthroughs. - Aya 4 July 2005 14:29 (UTC)

Please let the other GTA contributors know as well. - Lynx7725 4 July 2005 02:29 (UTC)


 * Hopefully, moving this text to our talk page will have that effect. Perhaps in future it might be better to express your concerns on this page, then perhaps provide a link on the talk pages of the users concerned, although personally, I will always check a diff made to this page. - Aya 4 July 2005 14:29 (UTC)

Orphaned GTA Pages
Hi y'all. Can someone please look into the following pages?


 * Grand Theft Auto: San Andreas: B-Plot Missions
 * Grand Theft Auto: San Andreas: B-Plot Missions Wang Cars Missions
 * Grand Theft Auto: San Andreas: B-Plot Missions Zero's RC Missions
 * Grand Theft Auto: San Andreas: Pimping
 * Grand Theft Auto: San Andreas: Wang Cars Missions

Wikibooks' Orphanage has them listed (i.e. not linked to other pages). I'm not sufficiently familiar with your book structure to know whether it's a Wiki error or something wrong with these pages. Thanks in advance. - Lynx7725 7 July 2005 07:07 (UTC)


 * Thanks for helping out, but we were already aware of these. We've made an effort to keep track of all pertinent content (especially since the search function seems to yield results which appear to be months out-of-date).


 * We have a project metadata page, which links to an informational page, containing a list of all orphaned pages. This is slightly more organised than a talk page could ever be. This content will be merged in at some point. It's just a case of who can be bothered to do it (probably it'll end up being me). :-)


 * To be honest, I don't see why these pages are showing up in the Orphanage anyway. I'm beginning to think that this page, and various other 'special' pages are generated using cached content which hasn't been updated for months. I no longer trust them. I'm beginning to wonder if my time would be better spent fixing these problems in the MediaWiki source code, rather than using the system, but I'd much rather do the first project off this list.


 * As for you lack of familiarity with the book's structure, you should find the pages linked from the project metadata page enlightening. ;-)


 * Aya 7 July 2005 16:09 (UTC)