StrategyWiki talk:Community Portal

This talk page is for discussion of general community issues. To start a new thread click here. Resolved threads removed one day thereafter. You can find them in the history.

System requirements in infobox

My friend gave me the idea: it would be useful if (for PC games at least), there was a section in the infobox template for basic system requirements, such as RAM and processor speed. --DrBob 10:13, 23 May 2006 (PDT)

Sounds like a good idea to me. <("<) Alex (>")> 21:04, 23 May 2006 (PDT)

Redesign of <gallery> markup

The <gallery> tag produces an eyesore of a gallery. Could it be redesigned? An example of a gallery would be Counter-Strike: Source/Player models; the labels for each image are too far away from the image in question, and formatted like normal text. I would suggest that they be moved closer to the image, and formatted like the labels for thumbnail images. --DrBob 10:58, 21 May 2006 (PDT)

I've restored the Monobook default for now. You may need to hard-refresh (Ctrl-F5 in most Windows browsers) MediaWiki:BlueCloud.css and/or gallery pages before you'll see the results. Garrett^Talk 18:40, 21 May 2006 (PDT)

That's loads better. Thanks. :) --DrBob 23:34, 21 May 2006 (PDT)

Licencing: CC-BY-SA instead of GFDL?

Hi,

May I inquire what was the reason to go with the GFDL as a licence instead of a Creative Commons licence such as cc-by-sa?

Thanks, Nyenyec 15:17, 21 April 2006 (PDT)

Well the biggest advantage is that content from other wiki sites (Wikibooks, [Gameinfo], etc.) can be copied here because we all share the same license. However I wasn't here at the time of the decision so the reasoning may be more complex for all I know. Garrett^Talk 17:11, 21 April 2006 (PDT)

GFDL is Wikipedia-compatible, and that was a huge factor. We wanted to remain compatible with the largest collection of open content game information, guides, etc. We want to promote a working relationship between the projects.

Initially I almost considered something of a proprietary dual license that I termed a "community license"--we would place the content under the GFDL and also give the StrategyWiki organization--which isn't even an entity yet--full rights to all submissions. That was intended so that we would have the option of changing to any new or better open media license of the community's choosing in the future without being locked into GFDL exclusively. Basically, all content would still be licensed under the GFDL, but there would also be the option of choosing another license later by community vote. I scrapped that idea because it was too complicated, and I feared it would make users apprehensive.

If and when we gain traction, however, we may be able to ask the community what they think of a relicense or dual license, or even this "community license" that I just talked about. Of course if we decide to do this, the application of it would NOT be retroactive unless we can find the permission of those authors who have submitted work. I would be fine with having all of my work relicensed, and several other StrategyWikians might as well. Others may not, however. Or we may not be able to find them all. Anything we couldn't relicense could be either tagged or rewritten.

We are in an early enough stage to shake things up, but we'd have to have a community consensus. After this Digg thing, I'd like to see what happens to the community. Will it grow stronger? Will we gain more help? Once I have a fuller view of this, we'll probably put this and other issues up for debate. --echelon ^talk 17:27, 21 April 2006 (PDT)

Urg.. I see why some people prefer CC-BY-SA to GFDL. And it's not a nice reality. If that article is true, then we might want to consider some dual-licensing and relicensing in the future. I know it's impossible to change anything we already have to CC-BY-SA, but in the future we might want to make future articles CC-BY-SA. I'd like to hear your opinions on this issue. --echelon ^talk 23:03, 13 May 2006 (PDT)

Yes that article captures the gist of it perfectly. I for one would certainly support changing to CC-BY-SA. In addition to the reasons they gave I think its simplicity makes it simple for the average user to understand, and perhaps making them more likely to feel confident about licensing their contributions. However if a change is to be made it must be done NOW. Re-labelling the site itself is the fiddly bit.

The per-guide implementation however is easy, and can be done via templates. Take a look at the bottom of my user page for an example. Unfortunately IE's hatred of CSS means it doesn't work for it; however this is just the code I had on-hand, there are definitely more compatible methods. Anyway, this means licenses can be added or overridden (a button can be placed over top of another just as easily as beside it) straight from a template.

Wikinews recently changed their copyright from PD to CC-BY, see their copyright page for more (and especially note the wording of their footer). That might give you some ideas. But, anyway, this is definitely a decision that must be made as quickly as possible to both minimise the workload and also the amount of content under the GFDL. Garrett^Talk 02:29, 14 May 2006 (PDT)

Having this discussion now should be an immediate priority for us. I can't believe I didn't consider the impact of doing nothing about this before. We need everyone who edits here to contribute their thoughts and opinions on this issue so we can make a wise choice. While I'd like to switch licenses now, whatever we do will have a large impact on our future. Picking a license that prohibits multi-licensing and isn't future-compatible will box us into a hole that we don't want to be in. First, let's look at the available options and weigh what each provides for us. We need a long-term solution that will work for many, many years. Perhaps beyond the scope of our own time here, to best accomodate whomever future contributors and users of this project may be.

If we can't decide on CC or BSD or something else, I also have another possible idea that I had thought about before. What about a "StrategyWiki License" that pertains specifically to the contents of this wiki? We would create this with the future in mind, so that we could predict and adapt to any future legal issues that may arise. Therefore, the first thing we would state is that people can "at their choice, use this version or any later version" of the license. Sort of like the GPL, this gives us future-compatibility. Secondly, we could draw up the terms of the license to be as dual-licensing friendly as we want to be and as copyleft as we want to be. After reading about CC-BY-SA, I feel it is much more open and far less restrictive than the GFDL. Moreover, the most important advantage a custom license would give this project is that the project can adapt--with a custom license, we could retroactively apply important changes to anything licensed under a StrategyWiki license. Older content wouldn't be stuck in the past forever. (So long as that is part of the provisions for contributing.) Older revisions would still be under the license version they were initially published under, but the project as a whole would be under the latest version of the license--this is what I mean by "future expandability".

Now, there are three problems that come to mind with this (and you may be able to think of more). The first, and greatest, is that the license could evolve into something bad. Who is to prevent this from happening? We could say that the license would be democratic, but there is always a small fear inside me that it could be pulled into the depths of something that takes away usage rights of the public and grants it to some all-powerful group. Think the FSF, who ask all contributors to waive their rights to copyright on all contributed code. Bad, bad, bad! I could only see an FSF scenario becoming more restrictive, more GFDLish. Then again, IIRC, I believe it was the Debian project that manages to do fairly well in licensing? The only goal I am aiming for is to ensure StrategyWiki content is always going to be relevent, useful, and free to use with as little restriction as possible. Is a custom license too bad for its own good? Is it overkill?

The second disadvantage is that a custom license is unknown. New contributors to our project may see our license, but without the familiarity of Creative Commons, GFDL, or BSD, they won't have a clue whether our license is actually authentic and can be trusted. Or what it states without reading it all themselves.

The third and final disadvantage of a custom license is that it has to hold up, legally. Who would write it? I'm not a lawyer. Could we just copy from the CC-BY-SA and delete/change what we don't like about it? Or add things we feel are missing? Ths is yet one more question that needs to be answered.

While a custom license for this project would be a lot of work, I do feel that the advantage of forward-proofing contributions for change of license would be a significant gain that would save us large amounts of trouble in the future. Maybe we could simply state this in an ammendment to a copied Creative Commons license? What are you thoughts? --echelon ^talk 11:15, 14 May 2006 (PDT)

I have several comments but I will try to be concise:

Creative Commons. I tend to dislike CC licenses because authors tend to choose the noncommercial (NC) variants. If we pick CC-BY-SA, then we do not have that problem.
Attribution Withdrawl. The CC-BY-SA 2.5 licenses have an attribution withdrawl clause, which appears to agree with the recommendations in the debian-legal Summary of Creative Commons 2.0 Licenses. However, even though Debian thinks that it is okay, I personally dislike this clause:
- If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any credit as required by clause 4(c), as requested. – clause 4(a) of CC-BY-SA 2.5 Legal Code
Transparent copies. The GFDL requires everyone who distributes "more than 100" copies of a guide to provide a "Transparent" copy (in human-editable text such as the MediaWiki markup, not in generated PDF or Microsoft Word). The CC-BY-SA seems to lack that requirement, which is another reason why I normally prefer the GFDL. However, I only care that this wiki has a Transparent version. If we always use MediaWiki, I can Special:Export/Main Page and get the wiki markup, even if wiki is CC-BY-SA.
Custom license. The text of the CC-BY-SA 2.5 is itself under in the public domain: "We do not assert a copyright in the text of our licenses. So yes, CC will let you edit the CC license to make a new license.
Dual-licensing. It might make sense to declare that after date X, all contributions to StrategyWiki must be licensed under both the GFDL and CC-BY-SA. However, date X would have to after whenever we finish importing Wikibooks content.

My recommendation? Stay GFDL; or switch to a dual-license between GFDL and CC-BY-SA. --Kernigh 12:32, 14 May 2006 (PDT)

Hm. Well I'm undecided. I certainly don't like the idea of dual-licensing. Not only does this prevent importing pretty much any other wiki's material but it also could confuse potential contributors. As for the other possibilities, CC has some definite flaws as both you and the Debian people pointed out but it has the advantage of being both well-known and compatible. A custom license has downsides that may outweigh its upsides, but does allow any number of subtle license changes to be made to suit our needs. Garrett^Talk 20:18, 17 May 2006 (PDT)

This is a very sticky issue, and I don't expect us to solve it without more input. I've personally been thinking that we should try to go create a custom license as a direct copy of CC-BY-SA. The reason I don't want us to go with CC-BY-SA is that future versions of that license may turn into something we don't like. If we have our own, there's nothing to stop us from turning our license into anything short of the BSD license, should we ever feel that was the best course of action. (But of corse this is an example only, I don't think that would ever happen.)

The problems with this, however, are the same as I listed before--especially the part about users not knowing the terms of a custom license. I do think I may have come up with a simple solution, however. If we keep the differences between any given version of a custom license and any given role model open source license as small as possible, we could have an easy reference point to show users. Then it would be as simple as pointing out the minor and unique differences in our license. Or, let's say we don't do that. We could just as easily create our own succinct explanation. Anyhow, if we do wind up creating something, I want to run it by the OSI for approval.

Finally, since we're already trying to work on something that addresses the problems inherent in licensing wikis, why don't we work on a license that can be used by all wikis? There's no license I've seen that is really suitable for wikis at all, and there really needs to be one. We could call it "WikiLicense" or something. The major problems with the GFDL are that you must provide full changelogs, you can't easily include copyrighted texts or images, you can't easily multi-license, etc. The problems with Creative Commons is the whole "pick and choose" model. (If something is really "free" it must still be available for use in commercial purposes, whether you like it or not.) Imagine if all wikis used a single license and it made copying possible between all wikis. Wouldn't that be awesome? ech elon 04:22, 19 May 2006 (PDT)

Wikibooks bans game guides!

Check out this Staff Lounge posting. After much debate and indecision, the final decision has been made. I've put us forward as a potential new host (and, really, it's only between us or the less-shiny Gameinfo). This may be just the kick-start StrategyWiki needs, but it is a LOT of content to suddenly acquire. Thoughts? Garrett^Talk 03:53, 22 April 2006 (PDT)

Wow! Seriously wow! This is probably the best shot we've gotten so far in gaining support. We really absolutely need to use this to our advantage. It must be stressed that our wiki is already geared towards game guides and that would be a more natural home for Wikibook's guides than Wikia's Gameinfo. We have a much more polished presentation and are 100% tailored to guides. Not only do we stand the chance to gain a lot of new content in this, but we also stand the chance to gain a lot of new supporters! This is so excellent! --echelon ^talk 04:22, 22 April 2006 (PDT)

Thanks to this move, I showed up :). I'm hoping to help in that transition (I did quite a bit to SM64 and Super Mario world as well as the FFVII guides there :). Mason11987 17:46, 24 April 2006 (PDT)

After checking this out, I wonder what would be the best way to handle this. We could simply copy and paste the pages over, but then we lose the page histories. It was also suggested to do a database dump then combine it with the StrategyWiki database. That wouldn't break anything, would it? Are there tools to do that elegantly? What other pros and cons can you think of, and which would be the best route in your opinion? --echelon ^talk 04:35, 22 April 2006 (PDT)

(this problem has been resolved, see StrategyWiki:Wikibooks Import List)

I'm a wikibooks user (from the MapleStory book) and I've been looking around this site a bit considering that it is one of the main choices of where to move that book. It looks like it could become very popular. I was looking at that page you moved over as a test and I'm slightly confused as to what to look for. It was also mentioned that images had to be moved manually (discussed lower down). What about templates and talk pages? About the wikibooks tech guys not wanting to enable history exporting, perhaps they would be willing to take a list of pages that need to be dumped and send the file(s) directly. I have put up a note on the wikibooks MapleStory talk page about moving the book here. If it is decided to move the book here, what would need to be done to make the transfer as quick and easy as possible? Sorry about this post being essentially a bunch of random disorganized thoughts, but I hope it makes sense. -- Prod 22:29, 2 May 2006 (PDT)

The above discussion was rather out of date. Since that time I found a solution. I just take the latest dump, run it against a list using MWDumper, and then upload the result via Special:Import. It's only images that have to be done manually, everything else (even the image description pages) is included in the dump. All I'll need is a list of all the pages, templates, and image description pages you want imported. MWDumper automatically extracts matching talk pages, so you don't need to worry about listing those. Garrett^Talk 00:28, 3 May 2006 (PDT)

OK. At the moment, there is still a bit of discussion about where to move the MapleStory book. If it does move here, where would you like the list of pages that need to be moved? -- Prod 11:07, 4 May 2006 (PDT)

StrategyWiki:Wikibooks Import List/MapleStory would do nicely. You can easily get a list of pages from Special:Allpages over there, it's only the templates and images I can't easily track down using that method. Garrett^Talk 13:46, 4 May 2006 (PDT)

How to transfer

Well, as I've said on IRC the Wikibooks tech guys have refused to re-enable history exporting. However today I found MWDumper, a simple command-line tool that (among other functions) can extract pages from an XML dump based on a filter list. It should be easy to make a full list of pages and then let it crawl through the database dump over lunch or something. After some tinkering it works perfectly. The only slight shortcoming is that the filter file is case sensitive, so it skips anything that has an incorrect capital. Garrett^Talk 04:09, 23 April 2006 (PDT)

OK, check out StrategyWiki:Wikibooks Import List. This is a list I'm gradually compiling in a format MWDumper can understand. Images will have to be handled manually. Garrett^Talk 04:49, 23 April 2006 (PDT)

I see that you are importing the San Andreas Wikibook here. So far I think I have moved about 70% of the material to Strategy Wiki. I know that it's quite important to have the histories of each page but I have edited each page as I moved it (added the bottom navigation, editing spelling/typos and sometimes changed formatting). This would take a long time to get all the pages back to the standard they are now. Is there anyway to just move the history of each page and keep the edited page intact?

I also see that you have copied the first page of the San Andreas guide from Wikibooks and inserted it instead of the previous front page with the reason "moving related sites down, our own content takes priority". Just wondering what that meant because the first page was only our content and had an info box and proper naivgation? Jackhynes 13:48, 23 April 2006 (PDT)

That message was because I imported the San Andreas page as a test, forgetting we already had it! Because my edit over there was slightly newer it took precedence. Importing doesn't overwrite anything though. Any time a Wikibooks edit is newer it's easy to open the history and revert to a revision there (as I've just done, now you've pointed that out). Garrett^Talk 14:15, 23 April 2006 (PDT)

Cheers Garett, that was just what I wanted to here - now I hope all the pages are older! Else I'm gonna have a lot of checking the newer edits then reverting! Jackhynes 14:29, 23 April 2006 (PDT)

Screenshots

What is the situation on screenshots. For one reason or another I know wikipedia doesn't like having a lot of screens in a page, but I think having plenty (although not a huge amount) of images in a guide is extremly useful. Is there some legal restriction which caused wikipedia's stance which is related to the GNU FDL license that you share with them? Or is it a site-specific decision?

I'm just wondering because I recently saw about a dozen (small) GTA images uploaded which will be used on a guide I presume, and I was thinking that I might want to break out my Super Mario World and throw in screenshots for the tricky parts of the game, and that's just one example. Since FFVII will probably be imported I won't be able to do a lot with it (although I did have several edits to it at wikibooks :)), but there are a bunch of other games I already saw that I could add to. And maybe I can help you guys structure the site a little better? I've had experience on a SporeWiki.com where I am a Bureaucrat, and when I first arrived there I completly revamped the organization scheme, so I think I can helpful in that as well. But I'm particularly interested on your ideas on screenshots, so let me know. Mason11987 17:55, 24 April 2006 (PDT)

Wikipedia's screenshot restriction was centered around the very touchy concept of "fair" use for educational purposes. A strategy guide is generally considered stronger fair use than an encyclopedia as the whole work is basically showing how cool the game in question is. As long as the screenshots have a clear purpose and aren't just to look pretty it should be fine. Anyway it's good to have others with experience around. Besides, I don't see any company complaining against fansites hosting quadrillions of images... :) Garrett^Talk 19:53, 24 April 2006 (PDT)

Awesome, thanks for clearing that up :). Mason11987 12:27, 25 April 2006 (PDT)

I'd definitely think that as long as the screenshot is relevant, and you don't overdo it, it'll fall under Fair Use. Hell, people have even done video walkthroughs - those're what, 24 screenshots per second? --aniki21 03:14, 27 April 2006 (PDT)

As I have come to realize, the only reason "fair use" is a problem at Wikipedia is because of the GFDL's restrictions on fair use. A Creative Commons or BSD project would probably render this problem moot. --echelon ^talk 11:17, 14 May 2006 (PDT)

Although this isn't directly connected with screenshots, I wonder if anyone would mind using their singled out images of manuals and/or boxes? Does credit need to be given in the first place, despite the fair use clause? To top it off, the copyright of the original image would belong to the company (whom as Garrett pointed out would be the least likely ones to mind), yet can any fan site legitimately claim that the box art that they've scanned is somehow theirs? If not legally, what would a gentleman do? --theEXIT ^talk 00:02, 17 Mat 2006 (CT)

Comments from a Wikibooks User

Your flagship page, Zelda: Ocarina of Time, has a few formatting issues-I would make the introductory page the table of contents, or perhaps combine it with your little intro page, as it is you have to scroll back up to the top to navigate anywhere, same thing applies to the walkthrough, forcing them to navigate to a new page is kind of annoying.

I've worked on the FF6, Chrono Trigger, FF7, and Quest for Glory wikibooks, the first three are fairly complete content-wise but could use some more media and tables to flesh them out.

If the Wikibooks are going to be exiled here, we'll have to see what we can do. The advantage wikibooks had was that it's a sister project to wikipedia and a natural place to look for more detailed information or for people wanting to add to the general body of knowledge. At the moment, your website is the second google hit for strategy wiki, behind an encyclopedia entry for the site itself. If you want to attract people you'll need a lot more content, particularly on recent games, and attract people willing to contribute over the wiki format.

It'll probably take some advertisement and cross-polination across all the other sources for game guides to try to promote this format. The best thing you could do would be to tie it in to Wikipedia directly to redirect people looking for more info, but that may not be likely.--BigCow 13:53, 25 April 2006 (PDT)

So you're suggesting Template:All Game Nav be repeated at the bottom? That's a good idea (although it will need some formatting changes, or possibly even a separate closing template). As for advertisement, once the Wikibooks content is in full lockdown both its pages and Wikipedia's will be changed to link to mirror(s). Right now this is the only wiki I'm aware of that's intending to fork the content (barring complete forks like Wikibooks.net, which will likely purge their copies at some point anyway) which means we'll get all the incoming Wikipedia attention. The only downside is we don't get a pretty sidebox in the external links section. Garrett^Talk 16:38, 25 April 2006 (PDT)

Not only that, but the idea of an intro page to get to your content is an annoying one. The introduction pages for the guides themselves and the walkthrough pages don't really serve a purpose, and should just be merged with the table of contents so they can navigate whereever they want after clicking a guide.--BigCow 09:47, 26 April 2006 (PDT)

Less clicks are always better. -- Mason11987 ^{(Talk - Contributions)} 11:46, 26 April 2006 (PDT)

The idea of the cover page was that it was more like a print strategy guide, but yeah I guess it's mostly for looks and not usefulness... still, this is a major enough change it will need a vote or something, or at least some more feedback from others. Garrett^Talk 16:14, 26 April 2006 (PDT)

A page in a strategy guide is very different than a page on the web. A chapter in a strategy guide could be a single web page, since a web page can span multiple pages of text and images. Your walkthrough pages actually do a good job with this, but you don't need an intro page before you see the actual content, you should scroll down to see the table of contents rather than clicking through it.

I'd be up for putting it to a vote or getting some more feedback, particularly since you want to use this book as the standard.--BigCow 17:53, 26 April 2006 (PDT)

I have to agree with BigCow. So far, the intro pages only cause me trouble and discontent, and I agree they serve no purpose other than looking pretty. If we are going to become the standard, then we need to focus on getting results and looking pretty at the same time, whereas the intro pages only serve for the latter. I highly doubt that anyone is going to save the entire guide in .pdf format and print it, so cover pages are rather pointless. I agree that a vote should be made, sooner the better. Cosmo 12:09, 27 April 2006 (PDT)

Anyone with the authority or ability to do this? The longer we wait, the more has to be changed.--BigCow 12:06, 9 May 2006 (PDT)

Input needed

Input needed in three places: Category talk:Nintendo DS, Category talk:Game Boy Advance, and Category talk:Game Boy. -- Mason11987 ^{(Talk - Contributions)} 17:02, 25 April 2006 (PDT)

Categorization

As can be seen by anyone who is watching the RC, I am a fan of categorization. I think it would be best if we had 3 root categories for the actual content here which will be interconnected. Category:Game System, Category:Game Genre, and Category:Game Company. They'll be connected because some game companies will make game systems (and therefore the game system will also be a subcategory of the game company who makes it [NES is a subcat of nintendo for example]). Now, we also have a lot of uncategorized categories like VTech or Commodore (and yes, I do realize they will almost never be used) which are "console makers". I'd like to categorize them, as well as the nintendo, sega, sony, M$, and other console makers into some category which would encompass all game system makers. I don't know what to call it though, so I thought I'd throw it out there. Console makers isn't really applicable because I want people who only made handhelds to be on there too, maybe "system makers" but that sounds retarded. So what are your thoughts? -- Mason11987 ^{(Talk - Contributions)} 10:43, 27 April 2006 (PDT)

Sounds like a good plan. But again, why not just System, Genre and Company? Since most system makers produce games for their own platforms that could be all-encompassing... of course it could then have Game Company and Platform Company as subcategories, but then you're back to the retarded name problem. :) Garrett^Talk 14:26, 27 April 2006 (PDT)

Ah, that's a good idea...I think that would be better. Before I go changing everything again, do you think it'd be best to call the categories "Category:System" or "Category:Systems" and so on for the other two? -- Mason11987 ^{(Talk - Contributions)} 07:02, 28 April 2006 (PDT)

Hmm... so far we've got singular for genres (e.g. Category:FPS), but in this case I'd say it might as well be plural. Either way it's a very nitpicky thing. Garrett^Talk 19:10, 30 April 2006 (PDT)

True, just figured I'd throw it out there :). -- Mason11987 ^{(Talk - Contributions)} 08:16, 1 May 2006 (PDT)

Copying images from Wikibooks, Wikipedia

I recently used User:File Upload Bot (Kernigh) to copy 80 screenshots that I made for NetHack and originally submitted to Wikimedia Commons for use in Wikibooks. Currently I have both a download bot and upload bot for MediaWiki. Thus I simply give the list of files to the download bot and have it automatically download the images and their descriptions from Commons, then give the folder of images to the upload bot and have it automatically upload the images to StrategyWiki. (I also have the option of editing the image descriptions between the download and upload.) Earlier today, my bot took over both Special:Recentchanges and Special:Newimages.

I suppose that I could point my download bot at Wikibooks or Wikipedia, and use it if someone needs large numbers of game images moved from either wiki. (Most game images are fair use, so they are not on Commons.) I might also be able to make the perl scripts (my hacked version of Commons:File upload service/Script) available. --Kernigh 20:16, 30 April 2006 (PDT)

Actually, so far I've come across very few images. It seems NetHack is by far the most heavily illustrated. But thanks for the offer, and if I come across something major I may call on you then. :) Garrett^Talk 19:28, 1 May 2006 (PDT)

Have you looked at the MapleStory monsters list? I think that qualifies as major :P -- Prod 21:54, 2 May 2006 (PDT)

Whoah. Yeah. I was intending to do the MMOs last for exactly this reason. Garrett^Talk 00:44, 3 May 2006 (PDT)

Transwikification EQ from wikibooks

Greetings :) here a repost from what I just put on the EQ discussion page

"looks like the transition from wikibooks went smooth (granted, some pics didn't come across yet, but we'll get that sorted some stage). what surprised me though was, that I wasn't aware of the change (did I miss something here?). was there an announcement? I always though that things like that should at least be announced on the discussion page i.e. (no vote necessary really from my PoV, but not even an annnouncement?). also, what I hate now is, to get all those pages watched again, which is a pita somehow...but hey..:-( --Kajolus 05:07, 11 May 2006 (PDT)"

in addition: Now I learned, that some other person (User Tendiin, wikibooks) is not able to contribute to the EQ wiki anymore (firewall access issues)...even worse, as he was picking up speed...is there anything we can do?--Kajolus 05:36, 11 May 2006 (PDT)

Bah, I knew I'd slip up eventually! :( Anyway, the official policy change has been being discussed for close to a month now at the Staff Lounge, although the issue had been brought up on and off for a good year beforehand. I decided to start moving the stagnant guides and worry about the active ones later, so that as much was dealt with as possible before any deadlines arose to complicate matters further. Yesterday I made another big effort, and it seems in all that busyness I forgot which ones I'd identified as still active! So, er, sorry! :(

As for re-watchlisting this list will help. You'll also find some pages on that list that seem to have become orphaned from the rest of the guide. You may also like to turn on "Add pages you edit to your watchlist" (under Editing in Special:Preferences).

As for the firewall, hm... echelon might have some ideas. It seems strange that Wikibooks can get through, although it could be that the firewall specifically allows Wikipedia, and thus anything else Wikimedia is hosting works too.

So, anyway, I hope that explains everything. Garrett^Talk 21:08, 11 May 2006 (PDT)

Template:Title

This might be useful to some people...

User:Mason11987/MyTitlePage

If you need an explanation, let me know :). Hope you like it.

stolen from [1] :). -- Mason11987 ^{(Talk - Contributions)} 15:18, 9 May 2006 (PDT)

That's pretty interesting, though I wouldn't suggest its use on a widespread basis. --echelon ^talk 22:59, 13 May 2006 (PDT)

Auto-linking large pages, and Intro Pages

Two things, judging by the recently trans-wiki'd Chrono Trigger guide it looks like strategy wikis doesn't automatically link pages over the 32kb limit, setting them as edit links instead. Any way to fix this? Also, getting a decision on having intro pages that force the user to click through them to get any content would be helpful. --BigCow 10:53, 11 May 2006 (PDT)

No, that's because I checked it over while importing other pages. Doing so cached the redlinked copy. It's just how things have been configured. Garrett^Talk 23:35, 11 May 2006 (PDT)

In Favor of eliminating intro pages/merging them with the table of contents

For - The intro pages, while they look nice, serve no immediate benefit to the reader. They do not improve organization (as having multiple pages does) and they do not make it easier to find information. Everything in a wiki designed for strategy guides should revolve around the easiest and most complete way of guiding the users of the wiki. In that sense if a piece of the wiki would better benefit the user if it were changed, then it should be so, especially if it is no great burden to the editors (in this sense, it would take LESS work to make intro-less guides). So I see no reason for intro pages to exist and I think the first page of a guide should have a brief intro of the game, and a set of as many other useful links as possible, organized as well as possible. -- Mason11987 ^{(Talk - Contributions)} 13:14, 11 May 2006 (PDT)

For - Mason said it well. Having to click through intro screens is poor web design. You should scroll down to see more content, not have to navigate to another site which has the content you actually want to see. The first page of a guide should be like a portal, linking you to all the places you might want to visit, and providing some information to make that process easier.--BigCow 15:29, 11 May 2006 (PDT)

For - yeah, pretty but pointless. {{All Game Nav}} may become a little empty though... unless the game name and Table of Contents both link to the guide's main page. Garrett^Talk 23:35, 11 May 2006 (PDT)

For - I never actually saw the point in them, honestly. Cosmo 07:29, 12 May 2006 (PDT)

For - works good for the super smash bros melee page: Super Smash Bros. Melee. --blendmaster 13:26, 13 May 2006 (PDT)

For - Not only have you proved to me that these are redundant, but I have just realized that we may actually want to host more than one type of guide. (I'll start a new topic for this in a moment.) --echelon ^talk 22:49, 13 May 2006 (PDT)

For - It used to be utterly painful to scroll through countless pages of plain text guides only to get to the beginning of the walkthrough. I utterly hated the ones that also include all the character bios, bestiaries, and whatever else BEFORE the actual walkthrough (the appendices are where it's at). It seems, however, that this sort of practice is standard, and I tried my best including some game information there that I would not be able to include otherwise. Perhaps we can include some sort of Appendices tag for {{All Game Nav}} so that people could use that to store side quests and whatnot instead? --theEXIT ^talk 00:15, 17 May 2006 (CT)

Opposed

Undecided

~~As of right now, I must say that I am wholly undecided on this issue. I am awaiting arguments from both sides. --echelon ^talk 12:16, 11 May 2006 (PDT)~~
- My vote changed to for. --echelon ^talk 22:50, 13 May 2006 (PDT)

I used Template:Cover in NetHack because Zelda: Ocarina of Time is using it. It works somewhat well because clicking the image leads to the table of contents (TOC). I would like to just keep having separate covers and TOCs, but there are benefits to having one page as Super Smash Bros. Melee does, and if covers and TOCs do remain separate, we might want to add more links on the covers. --Kernigh 14:00, 13 May 2006 (PDT)

Multiple types of guides

I was just thinking about the possibility of hosting multiple guide types. Many at Gamefaqs have criticized this project for not supporting more than one type of guide. Though I still stand completely firm about no redundancy in this project whatsoever, I can imagine different types of walkthroughs being made. For example, there might be a speed run walkthrough to supplement the regular one. I do not see these as repeating anything, but simply "branching" from the main guide. What do you think? If we do implement this, it may require we change some things about our URL and article naming policy. --echelon ^talk 22:57, 13 May 2006 (PDT)

It'll be kind of an inevitability if the site gets popular enough that people will have more than one type of content they'd want to host, but I think that could still be handled with one main guide. Consider the typical types of guides featured on GameFAQs:

Boss FAQs/Strategy FAQs against the weapons in FF7 for example: covered under our system, since we have more sub-pages than just a walkthrough.
MiniGame Guide: Same thing, see the imported Final Fantasy VII guide.
Game Script: These would actually be nice to have, but they could work as sort of an "Additional Content" thing under the main guide, kind of like a Plot FAQ again.
Specific Character Guides for fighting games like smash bros, same kind of thing
Maps/Charts: Integrated into the walkthroughs or given their own section
Speed Run/Low Level Guides: these are the hardest since they're often a complete departure from a normal walkthrough, and they can be an entire walkthrough of the game with a specific goal in mind. I'd prefer to give them their own section underneath the main guide, as in something like Chrono Trigger/Speed Run/Introduction or something similar. Basically make them a subpage.

The main problem we might have is that people might have very conflicting strategies for a game like Starcraft, or even something like Final Fantasy VIII about the best tactics to use or way to build levels. In some cases we may just need to list multiple strategies or link to different pages which describe different approaches, a Starcraft Guide might have some sub guides on teching, rushing your opponent early, etc.

Our table of contents could read like a complete GameFaqs list of guides, with the advantage of having no redundancy. They would link Plot FAQs and Boss FAQs as separate guides, we'd just consider them to be a part of a single complete guide.--BigCow 00:30, 14 May 2006 (PDT)

Game scripts would be another good idea, but that's not possible under the GFDL (where all content must be either GFDL or the precarious "fair use"). Changing to CC-BY-SA would free up multi-licensing some. Garrett^Talk 03:39, 14 May 2006 (PDT)

I don't think there's any need for more than one guide hub though. Maybe a separate TOC for each walkthrough type, but certainly not a completely separate guide. Supages make that unnecessary. Garrett^Talk 03:37, 14 May 2006 (PDT)

Yeah, I so no need for something like Metroid Fusion (speed run) and Metroid Fusion (1% run) at all, when they can be subpages, as Garrett said. I was thinking of implementing those after I finished my work on MF, as optional quests towards the bottom of the TOC. Cosmo

(I've also added seperate map pages within the guide for things like getting 100%.) Cosmo

I am really new to wiki scripting, but since we have multiple pages with tags everywhere, is there a way to use a command similar to php "include" so that you could pull bits and pieces from a page? For instance, in a game like Zelda, a person may wish to create a little floating blue box page per every Boss (with strategy to beat him), and then simply include them in various files, sorta like the Category tags work. Except instead of providing mere links to a page, it would pull out every boss in order and put it in a nice guide (perhaps even with it's own navigation, etc.) Similar ideas could be applied to everything, so then the information would be stored as pure data, and then TOC would contain every viable option to view that information in a sorted manner... I don't know if that's possible to do with the way Wiki stores things, though. --theEXIT ^talk 00:24 May 17, 2006 (CT)

The easiest way is to transclude a page like a template, e.g. {{:Zelda: Ocarina of Time/Ganondorf}}. Note the : before the page name, without this it'll look in the Template: namespace. You can see this in action at BS Zelda: Kodai no Sekiban/Printable version. This page has no real content of its own, meaning it only has to be updated when an entirely new page is added to the guide.

For really fancy results you can tag parts of a page that are not to be included (<noinclude>) or else are shown only when included (<includeonly>). You can see this demonstrated rather confusingly at this source page vs. this target page. The first has all the text, but due to the mixed tagging each page has its own unique links.

Wikipedia's Navigation popups use a fancy Javascript method to extract a chosen section but I haven't looked into it. For most purposes the other two methods should be sufficient. Garrett^Talk 16:19, 17 May 2006 (PDT)

I've thought about that... But Templates are designed for something else entirely. Despite the fact that you can create {{{Template:GAME_NAME/BOSS_GUIDE/BOSS_NAME}}} it would get confusing quickly. For that very reason I chose to copy/paste my own 'custom' navigation bar with "elite" (pun intended) icons throughout my SQ3 guide. I guess there is no other way, really, to include such pages. Perhaps if the community could decide on a global format for certain data output (like for bosses), the Wiki could be better "suited" to fit our needs. Thanks for the JavaScript link, however... I'll investigate that. --theEXIT ^talk

Vandalism comes to StrategyWiki

At 13 May, this user dropped photos of penis on several pages, mostly in the RuneScape guide: Special:Contributions/P0op0o.

Sysops, please delete the two images uploaded by that user. I would also consider an infinite block. --Kernigh 10:47, 14 May 2006 (PDT)

Banned and deleted. --echelon ^talk 11:27, 14 May 2006 (PDT)

Planning to host DB dump soon

Just a note: I'll be busy much of the week, at least until Wednesday or Thursday. Soon thereafter I am planning to host a tar.bz2 archive of the StrategyWiki database and a seperate archive of our uploaded images/files. I am going to begin on a once a month schedule where I supply a full backup (Minus the user table for security concerns) of everything. This helps to both preserve the content of the website, should anything unfortunate ever occur, and also to aid in distribution. Once we become popular enough, I do believe websites will want to mirror our content, much like Answers.com does for Wikipedia. I look forward to that day when we have become the de facto, and it will make me happy that we've provided such a valuable resource.

The archive files will be located on this server (we have plenty of bandwidth). If you would like to provide suggestions to me on alternative methods of distribution (torrent, mirrors, etc.) let me know. I hope you will all download a copy for safe keeping. --echelon ^talk 09:51, 15 May 2006 (PDT)

I would like to add that as our rate of growth increases, so will the rate of publically available backups. Currently, a once-monthly schedule should suffice unless we can automate it without a big impact to the performance of the site. Note that in addition to this, I personally keep full, regular backups on hand; I may soon make those available to Garrett and any future admins for the safety's sake. --echelon ^talk 09:58, 15 May 2006 (PDT)

The Front Page! (agh)

Every time I look at the front page, it's basically the same. The Digg stuff is fine with me, but the screenshots of the week thing needs to be updated more often or replaced with something else entirely. I'll do it if I have to.

Also, the Zelda screenshot says "Celda!" - Garrett told me in #strategywiki once that this is for "cel-shaded Zelda" but to me it's a glaring typo, and it may give people the idea that guides here are chock-full of typos. If it is cel-shaded Zelda, maybe we should say that it's a pun.

This may be nothing to you guys, and if so, then okay, I can drop it - but it's really driving me mad, and I am not even mentioning the 'current' collaborations. If you need more screenshots or game artwork or anything, I will find it for you! I just really hate static home pages.

How do you guys feel about this? Am I just crazy? Cosmo^Talk

The best way to do a "something of the week" is to use templates which can auto update. This is what I did for the word of the day on the simple English Wiktionary. Here is the code on the main page

{{:Wiktionary:Word of the day/{{CURRENTYEAR}}-{{CURRENTMONTH}}-{{CURRENTDAY}}}}

and the word of the day for today is saved at Wiktionary:Word of the day/2006-05-16. Advantages of this system is they can be set up in advance. Wiktionary's word of the day will continue until the 22nd until more need to be added. You have an auto archive of previous words of the day, and it makes the site look more active then it actually is. Gmcfoley 13:02, 16 May 2006 (PDT)

That could be really good. I am pretty sure though that a SysOp needs to implement it, right? Cosmo^Talk

A SysOp will have to edit the main page, yes, as it's protected. However the rest can be set up by anyone. Another option is to simply drop the "of the week" part as I did on my wiki. Gmcfoley 14:05, 18 May 2006 (PDT)

I added it, albeit that I followed Wikipedia's picture of the day format instead of the ISO 8601 format (YYYY-MM-DD...) Would you prefer this changed to ISO? Also, while SotD and AtoD are at our attention, we should probably create some kind of standard template and archive for them both, as well as a process/policy to select them. echelon ^talk 02:30, 19 May 2006 (PDT)

"{{CURRENTWEEK}} Number of the current week (1-53) according to ISO 8601 with no leading zero." This can be used for the "of the week" parts. The date format for the "of the day" parts are fine, as long as it's not 1/2/06, 2nd of Jan? 1st of Feb? Who knows! Gmcfoley 06:59, 19 May 2006 (PDT)

Yay, thanks echelon! I love that the front page looks more active now. As for ways to do it, I don't care. If ISO is easier, thehn let's do that. But either way, I don't think it matters. Cosmo^Talk

Panoramic screenshots

I made a couple of panoramic screenshots using GoCubic for the Counter-Strike: Source pages. However, every time I try to upload them, I get given a '".mov" is not a recommended image file format.' error message, and I can proceed no further. I think it would be a good thing if people were allowed to upload .mov files, as then the wiki would benefit from panoramic screenshots for games, which really do help show the reader what the level's like. --DrBob 12:58, 17 May 2006 (PDT)

Actually ".mov" is only a container format for various "codecs" of video, audio, image, and text streams; it can contain everything from raw, uncompressed "digital video" streams and linear audio (which use huge amounts of storage) through to MPEG4 format (which compresses well but has patent issues). Thus any decision to allow .mov files would involve the question of which codecs to allow. --Kernigh 22:41, 17 May 2006 (PDT)

This then moves into the "videos" discussion below, but I do think it would be of real use to the wiki if panoramic screenshots were allowed. --DrBob 15:10, 19 May 2006 (PDT)

DrBob, I agree that this could be of a real potential use. If you wouldn't mind, do you think you could create a demonstration to show us exactly how it could be applied to Counter-Strike: Source? I am not certain whether "panoramic screenshots" or downloadable ogg videos or embeded FLV (like Google Video) is better, so it would be great if we could see a demonstration of each technology in use. It may be that we will come to use a combination of two or more of them. ech elon 22:01, 19 May 2006 (PDT)

Even if we do offer FLVs there should still be a downloadable equivalent. It would be great to watch part of a solution while the rest is downloading, and then refer to it later without having to return to the site and wait for the part you've already watched to load all over again before you get to something new. Garrett^Talk 22:47, 19 May 2006 (PDT)

I've put two sample panoramic screenshots up on my site: inside and outside views of Counter-Strike: Source/cs_assault. They're 512px by 512px, which is probably about the right size for the wiki (you can't easily make larger ones in Counter-Strike: Source anyway). :-) --DrBob 06:10, 20 May 2006 (PDT)

Videos

Will there be support for any video files? Although I'm not for adding obnoxious videos of every level to your guide, there are instances when that could be beneficial. If you are going to enable video files, I would recommend Ogg Theora format for two reasons: it's patent-free, and it's an extra step to take and to worry about, which will probably keep vandals from uploading a lot of porn....

theEXIT ^talk 17:07, 17 May 2006 (CT)

This concept actually does interest me. Some problems that come to mind are bandwidth, overuse, redundancy, and quality. But if we could overcome this, I have no problem with video. Ogg format is definitely the most open one to go with. Another possible idea is streaming FLV to embed directly into the website. --echelon ^talk 23:51, 18 May 2006 (PDT)

I admit that this video business would have to imply certain guidelines. So far, in everything that I've thought about, you hardly need videos over a minute in length, and most of the time, the video is supposed to show a particular tactic that is easier to show than to explain. I know that with the use of images, there is a policy that "each image must serve a purpose," yet truth of the matter is: images help layout (like the little cartoony image of Link and Navi in the OoT guide...) and provide a minor decorative frame of refence. With video content, however, that simply is not the case. I have to say that FLV embedding sounds rather obnoxious, or at least I can immediately see how it CAN be extremely obnoxious in wrong hands. All I'm saying, I guess, is that peer review would be more important than ever in this. TheEXIT 05:40, 19 May 2006 (PDT)

Hmm, if there was some way to embed flash into pages, we could use google video or youtube for walkthroughs like that, without worrying about bandwith. The only problem is people could embed other flash stuff into pages, which would be annoying/destructive, so there would have to be some way to only allow google video/youtube/other video sharing site flash files. --blendmaster 09:55, 21 May 2006 (PDT)

That's a good idea, if their policies about outside linking allow that. It would certainly be possible to design a tagging format whereby {{youtube:mFQz98jAcg8}} would result in an embedded Flash with http://youtube.com/watch?v= already appended to the beginning. Garrett^Talk 13:51, 21 May 2006 (PDT)

Flash is good, but there are many people without it, so it would be good if the proposed "youtube" template also took in the name of an image to which it can fall back if the user's browser doesn't have Flash. --DrBob 13:59, 21 May 2006 (PDT)

I think that most of the video format here should be "the last resort" of communication. In that respect, I see nothing wrong with allowing upload/download of ogg-theora files. I can not say that I support the YouTube implementation of video into guides: it can be very annoying, and it also takes away from the polished visual appeal of the guide. Regardless, I do believe that video-based media ought to be allowed, but I'm also afraid that I've opened a can of worms that could make Walkthroughs here more obnoxious than anywhere else... --TheEXIT 15:43, 21 May 2006 (PDT)

Oh, definitely, inline movies would be awful. The way I see it the movie would instead be in a sidebar with a preview thumbnail. Clicking the YouTube option would unfurl an overlay containing the player, while the download option would link to the Ogg. Garrett^Talk 16:55, 21 May 2006 (PDT)

Hmmm... after experimenting with a quick sample I'm not so sure about using YouTube. The player forces video at 4:3, meaning direct emulator output (such as this) can't be used as-is. I haven't tried Google Video yet, but since they say content might be cut when the beta ends I'd still prefer YouTube. If everything else fails perhaps a custom FLV player supporting dynamic perspective could be made (maintaining the logo overlay, thus being technically identical and not violating their Terms of Use). Garrett^Talk 22:12, 21 May 2006 (PDT)

Google video now has the near instant uploads youtube has, and it has a nicer player that resizes dynamically. As long as they don't delete stuff when they go out of beta (which i haven't heard of until now), then they would be the nicer solution. To avoid unnessecary video, you could make it so embedded videos would require approval from an administrator before put on a guide too. --blendmaster 20:03, 22 May 2006 (PDT)

That's sounding good. And now that I've looked at it again it doesn't say what I thought it did, but instead that the videos have to be approved for inclusion at the end of the beta. To me Google Video looks to be aimed more at being an online video store than a place for your own random clips, but I may just be misunderstanding it. As for overuse, really disruptive videos can be added to the spam blacklist. Garrett^Talk 22:29, 22 May 2006 (PDT)

MediaWiki:BlueCloud.css not importing

I've tried making some tweaks to MediaWiki:BlueCloud.css, but it isn't working. Obviously the importing wasn't added after all. Garrett^Talk 22:43, 17 May 2006 (PDT)

The page source dose have

 <style type="text/css">
 <![CDATA[*/
 @import "/w/index.php?title=MediaWiki:BlueCloud.css&action=raw&ctype=text/css&smaxage=18000";
 /*]]>
 </style>

so it looks like it should be working. Gmcfoley 14:10, 18 May 2006 (PDT)

I copied Wikipedia's external link icon override to the CSS but it simply isn't going away (e.g. Template:Cover). It might be a version difference, but I'm sure I used this on a Wikicity back when they were running 1.4. Putting it directly into the true CSS file might get around this but it should be working to begin with. Garrett^Talk 20:29, 18 May 2006 (PDT)

I don't understand why it isn't working, either. Do you think the CSS file is taking precedence over the imported MediaWiki:BlueCloud.css? While editing the static CSS file can be done, it's just not a permanant solution. So there's no question that I want MediaWiki:BlueCloud.css to work. Any clues here? --echelon ^talk 23:55, 18 May 2006 (PDT)

Just to make sure, you did clear your cache right? Gmcfoley 07:02, 19 May 2006 (PDT)

Yeah, Garrett and I just fixed this a little while ago. Sorry for not updating everyone. As he pointed out, the CDATA sections were not properly commented out. ech elon 07:37, 19 May 2006 (PDT)

Redlinks are red again thanks to "@import "/w/index.php?title=-&action=raw&gen=css&maxage=18000&ts=20060519220427";". You should probably just blank its changes, in case it being imported is actually required. Garrett^Talk 15:43, 19 May 2006 (PDT)

I totally forgot that was happening! I had to enable User CSS to test the new sidebar, but I forgot that blank user CSS files make redlinks. For now I've disabled User CSS, but I may take a deeper look into MediaWiki to see if I can find and kill the source of that problem. ech elon 19:56, 19 May 2006 (PDT)

Spam

I noticed a lot of spam on this wiki. This page might help: http://meta.wikimedia.org/wiki/Anti-spam_Features Gmcfoley 16:28, 18 May 2006 (PDT)

Thanks for the excellent suggestion, Gmcfoley! I installed the blocklist, and the page is available here. This should surely help! --echelon ^talk 00:46, 19 May 2006 (PDT)

GFDL goldmine

Today I had the bright idea of searching for GFDL guides... and there's a heap of authors who have already seen the light.

Unfortunately since I don't know much about these games I'm not the best person to wikify them, so if someone else knows the games and could help do it that would be great.

I'll do more later. In the meantime check out Pseudonym's FAQs. All GFDL. Wow. Garrett^Talk 04:29, 23 May 2006 (PDT)

I half wikified the advance wars guide( Im playing through the game right now) by turning all the text headers to wiki headers and removed the text table of contents. Also, does anyone know of a fast way to get rid of the first space of each line quickly? It makes the wiki software format it as preformatted, which i eventually want to get rid of on the text guides. --blendmaster 20:08, 23 May 2006 (PDT)

GameInfo

here is a category from gameinfo.com's wiki. Most of those would be VERY useful to you here. And they are under GFDL also :). -- Mason11987 ^{(Talk - Contributions)} 07:48, 23 May 2006 (PDT)

Upgrade

As stated before, MediaWiki 1.6 is out, and there are several different advantage to it, mostly in the optional parameters addition, which would allow certain items in certain infoboxes and would definitly help with your TOC issue as well as with Allgamenav. You should really look into it. -- Mason11987 ^{(Talk - Contributions)} 14:04, 23 May 2006 (PDT)

Thanks for the reminder again. I've been keeping incredibly busy. I don't know if I can get to it tonight, but I should have it taken care of before this weekend. ech elon 19:20, 23 May 2006 (PDT)

Zelda OOT

Talk:Zelda: Ocarina of Time I'd like some comments about potential merger of the cover and TOC pages. -- Mason11987 ^{(Talk - Contributions)} 14:41, 23 May 2006 (PDT)

Icons

I think there should be some kind of "icon" system in place for in-guide links. Each link could have a small template before it which displays a small "icon" image which shows what that link is for. For instance, in the LOZ:OOT link Zelda: Ocarina of Time/The Beginning there is this section:

== Welcome to the Kokiri Forest! == {{big|L}}ink, our young hero, is the only boy in the Kokiri village without a fairy. Suddenly he is awakened from a particularly disturbing nightmare to find a fairy in his room. The fairy, exasperated, beckons Link to come with it to the '''[[Zelda: Ocarina of Time/The Great Deku Tree|Great Deku Tree]]''', in order that he would hear important, if not urgent, news. The young boy bursts through the doors of his home, only to be greeted by '''[[Zelda: Ocarina of Time/Saria|Saria]]''', his childhood friend. She is overjoyed that Link has finally gotten a fairy of his own, but Link knows deep inside that this was not to be the happy day his friends would expect it to be. The jealous '''[[Zelda: Ocarina of Time/Mido|Mido]]''' will do his best to make sure of that too. Shocked inexplicably by the apparent favor that both Saria and the Great Deku Tree have shown to Link, he will do everything in his power to prevent you from seeing the great tree. He insists that you must have both a sword and a shield before you can pass. What a jealous fellow, indeed! == Getting past Mido == Clearly, this portion of the game was designed in order for you to become accustomed to the controls. Fortunately, this is unlike almost any other in-game tutorial out there: it's fun. Already, you have been presented with a problem—that Mido is blocking your way—and now you must set out to find a solution. You will need to find the '''[[Zelda: Ocarina of Time/Kokiri Sword|Kokiri Sword]]''' and the '''[[Zelda: Ocarina of Time/Deku Shield|Deku Shield]]'''. While you can get the items in any order, [[#Getting the Sword|getting the sword]] first may help you acquire the 40 Rupees necessary to [[#Getting the Shield|purchase the shield]].

I think it would be useful before the Saria and Mido if there was {{npcicon}} which would let you know that that is an NPC, and would link to an NPC page. (Or enemy, or friend page). Also, for the Kokiri Sword and the Deku Shield links, maybe little {{swordicon}} or {{weaponicon}} and {{shieldicon}} to symbolize what they are. In certain games (FF in particular) this would be very useful. That's because the guide could say you picked up a Gyshal Green in a chest or on the ground, and the since we aren't going to have a Gyshal Green page, we could just have that icon to let you know that that is an Item and the link would lead to an item list page or something. I think this would be especially cool because it would liven up the pages and allow for more information in less space when listing tresures that could be found somewhere or things like that. I don't know exactly what images we'd use or anything like that, but I thought it would be fun and useful. I saw it used very well in an awesome FFVII guide (far better then the wikibooks one) I'll just have to find that to show what I mean. It doesn't need to general templates for all guides, they can definitly be specific if there is a need (like deep rpgs might need their own set), but I think it'd be worth it to try to make things like that. Red links in the "feature guide" isn't really a good thing and while just changing it to the weapons page would be useful, this might be an extra touch that differentiates this site from other game guide sites. -- Mason11987 ^{(Talk - Contributions)} 19:17, 23 May 2006 (PDT)