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.''

Community Issues Talk Page
It is unclear whether or not this page is just for the listing of issues, or for the discussions of those issues as well. It might be better for the issues to be listed here and for them to be discussed on the talk page.

SVG file format
As of now, Strategy Wiki does not allow uploads of *.svg file formats as wikipedia does. These are very small XML based vector graphics. For an example, check out the flag icons on http://en.wikipedia.org/wiki/FF6

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 would result in an embedded Flash with http://youtube.com/watch?v= already appended to the beginning. GarrettTalk 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. GarrettTalk 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). GarrettTalk 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. GarrettTalk 22:29, 22 May 2006 (PDT)


 * If we really want to be as open source-strict as Wikipedia, it's best we show our ownly bias into open source. Meaning, we will have to host our own Ogg videos that will be available for download, since hosting our videos on YouTube or Google Video implies the inclusion of closed source software. Remember, SW is the 100% open source alternative to GameFAQs and every other closed source video game site in the world. We need to show them that a video game site, such as a replacement to GameFAQs, can live off of nothing but non-propriety and free code.--Dan 08:36, 26 May 2006 (PDT)

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)
 * I added the spot (so you can put in the new parameter) like this:


 * It won't be displayed because the section that displays the requirements is optional, and it requires a feature of MediaWiki 1.6. Echelon plans to upgrade soon.  As soon as he does I will tweak the template and it will start displaying the requirements for whatever infobox has them.  We will be able to make any of the other parameters optional too after the upgrade. -- Mason11987 (Talk - Contributions) 10:30, 24 May 2006 (PDT)
 * Great! --DrBob 10:49, 24 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. GarrettTalk 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. GarrettTalk 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. GarrettTalk 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? echelon [[Image:Ocarina.gif|...]] 04:22, 19 May 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... :) GarrettTalk 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. GarrettTalk 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. GarrettTalk 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)

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. may become a little empty though... unless the game name and Table of Contents both link to the guide's main page. GarrettTalk 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 so that people could use that to store side quests and whatnot instead? --theEXIT talk 00:15, 17 May 2006 (CT)

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. GarrettTalk 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. GarrettTalk 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. . 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 or else are shown only when included  . 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. GarrettTalk 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 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

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. echelon [[Image:Ocarina.gif|...]] 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. GarrettTalk 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)
 * This is a very original idea, I love it. However, there is one flaw that's just killing me. QuickTime is closed source. If we could find an open source paranormic viewer, preferably in Javascript (is that possible?), I see no reason why we shouldn't do this.--Dan 11:37, 26 May 2006 (PDT)
 * The goal of this wiki (for me) is to be the best. OSS is good (and I personally love it), but the only alternative to QTVR I could find was SPi-V, which is Shockwave, and costs money. QTVR is decent, and if you don't want to use the official QuickTime player, OSS movie players such as Totem can decode the file and play it as a conventional movie. Writing a viewer in Javascript is a completely implausible idea: Javascript was never designed for rendering images in 3D, and neither were browsers, so the clipping and image distortion functionality needed to implement one isn't available for Javascript. My vote goes for QTVR. --DrBob 12:09, 26 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.


 * Advance Wars: Dual Strike/Walkthrough
 * Freelancer/Walkthrough
 * Fallout/Walkthrough
 * Fallout 2/Walkthrough
 * Primal

I'll do more later. In the meantime check out Pseudonym's FAQs. All GFDL. Wow. GarrettTalk 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)
 * The easiest way is to search-'n'-replace two spaces with one, and then hit delete at the end of each line to bring the next one up. This way the lines run on correctly and you also don't have to cut spaces yourself (except the first one of each paragraph). GarrettTalk 17:00, 26 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)


 * Definitely. And, even better, WikiKnowledge is public domain. GarrettTalk 16:10, 24 May 2006 (PDT)

Upgrade(Issue Resolved)
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. echelon [[Image:Ocarina.gif|...]] 19:20, 23 May 2006 (PDT)


 * I'll put in the Template:Qif then, and when you do the change I can put it in the infobox so sections are optional :). Also, while you're doing stuff, the top-left icon doens't exist on the monobook style. If you'd put it there, I think it'd look nicer. :) -- Mason11987 (Talk - Contributions) 10:15, 24 May 2006 (PDT)


 * I should be able to fully install 1.6 this weekend. Sorry I've been so busy this week! As for the top left icon, what are you referring to? Are you using Monobook instead of BlueCloud? echelon [[Image:Ocarina.gif|...]] 22:17, 25 May 2006 (PDT)


 * Bolded previous comment for clarity. :). The infobox for games will work immediatly when you make the upgrade, all the PC games will have an "unknown" label in the requirements unless someones else puts them in. I did them all individually. -- Mason11987 (Talk - Contributions) 07:25, 26 May 2006 (PDT)


 * The upgrade seems to have broken page listing in categories. For example, Category:Companies: the page doesn't show a list of articles in that category. If you try to edit a category which hasn't been created yet (but has articles linking to it), there is a PHP error. For example, this page gives the following error: Fatal error: Call to undefined function: openshowcategory in /home/.batly/echelonre/strategywiki.net/w/includes/EditPage.php on line 1130 --DrBob 05:45, 27 May 2006 (PDT)


 * Interesting...it appears that EVERY category is broken...I didn't upgrade mediawiki on sporewiki myself, so I'm not sure exactly what could have caused that. But you can contact Zorlac the owner of sporewiki, (try his AIM), he might be able to help you out. In the meantime, I'll take advantage of the optional parameter feature :). -- Mason11987 (Talk - Contributions) 08:55, 27 May 2006 (PDT)


 * Okay, I've got it fixed. If a category appears not to be listing any items, try applying a faux edit to it. echelon [[Image:Ocarina.gif|...]] 11:58, 27 May 2006 (PDT)


 * Great! :-D --DrBob 20:03, 27 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)


 * I do have an idea for that, but we'd first have to solve the the issue of navigation. See the new post I made. echelon [[Image:Ocarina.gif|...]] 22:16, 25 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!
Link, 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 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 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 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 Kokiri Sword and the Deku Shield. While you can get the items in any order, getting the sword first may help you acquire the 40 Rupees necessary to purchase the shield.

I think it would be useful before the Saria and Mido if there was 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 or  and  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)


 * Do you mean something about the size of the icon next to my username to designate what the link is? echelon [[Image:Ocarina.gif|...]] 22:10, 25 May 2006 (PDT)


 * I am fairly certain that's what he means, but I am sort of on the fence about this. On one hand, it would look really great. On the other, it may be difficult to do for some guides, and not all writers may be spriters on the side. I'll wait for more input from other users before making a real decision. Cosmo talk

Page neutrality
What do we do with pages who can't maintain a neutral POV like this one? Should this be a new rule which should be enforced?--Dan 09:22, 26 May 2006 (PDT)
 * I would agree that N-POV should be enforced, but not to the extent that it is on Wikipedia. I think it could be quite useful to have other gamers' opinions on games/maps/weapons/etc., but it would be quite biasing to have whole articles with a non-N-POV. --DrBob 12:32, 26 May 2006 (PDT)
 * Whether someone thinks a game is good or not doesn't really have a place in a game guide. There shouldn't really be any opinion whatsoever besides what you think is the best strategy, and others should be able to suggest other strategies.  Whether you think a game is great or horrible gives nothing useful to the reader. -- Mason11987 (Talk - Contributions) 12:43, 26 May 2006 (PDT)
 * Certain historical viewpoints, such as the assessment that Ocarina of Time and Final Fantasy VII were among the best videogames ever created, are valid and have even been stated in Wikipedia. Likewise, I don't think anyone would disagree that E.T. or Superman 64 rank among some of the worst videogames ever. This knowledge is a part of our gamer culture. Nevertheless, the last thing I want any of us to do is discourage people from playing games. I would be more open to having historical, retrospective claims about why gamers should play a game rather than why they should not, and only where they are tactful. My position would be for an NPOV StrategyWiki, especially if this becomes a heated issue in the future. (You know how crazy we gamers are about asserting our opinions...) echelon [[Image:Ocarina.gif|...]] 14:55, 26 May 2006 (PDT)
 * True, I think more of a historical outlook on opinions is better then a personal one. I don't want to see people saying that FF7 is worse then FF8 or vice versa, because that's the kind of thing that coudl annoy some people. -- Mason11987 (Talk - Contributions) 08:48, 27 May 2006 (PDT)

That guide along with many others are imported from GameFAQs (see Talk:Brain Lord). I haven't yet changed the text of any of Pseudonym's guides beyond formatting. GarrettTalk 16:30, 26 May 2006 (PDT)

Image metadata table
The appearance of the metadata table for images isn't too good. There need to be borders, or for it to be styled similar to the infobox template. A metadata table can be seen on the Image:Css_de_dust_b.jpg page. --DrBob 12:30, 26 May 2006 (PDT)
 * It might be useful to find the appropriate system message (or messages) that would need to be edited to fix that, unless someone else knows which ones. -- Mason11987 (Talk - Contributions) 12:43, 26 May 2006 (PDT)
 * I can find relevant language strings, but not the markup itself. Then again, I'm not particularly familiar with how MediaWiki works, so I've probably missed something. :-( --DrBob 16:17, 26 May 2006 (PDT)
 * I've restored the default Monobook CSS but it's not affecting it. I assume it's to do with style layering (BlueCloud has one layer more than Monobook) but my understanding of CSS is too vague to diagnose it beyond that. GarrettTalk 16:27, 26 May 2006 (PDT)

Upgrade Completed! Now our next problem...
We're now running on MediaWiki 1.6.6! You can now use default values in templates. On this note, I need to bring up a potential problem: Our database has grown quite large, and it's difficult to easily manage. While this server has a ton of space available to use, I am getting archive errors every time I try to tar the database. In fact, the database dumps themselves might be to blame; I am not sure mysqldump is handling it correctly. I have tried both with and without the --hex-blob parameter. Any suggestions? echelon  22:14, 26 May 2006 (PDT)

New community portal
Aside from the big task of finding a solution to the intro pages we unanimously voted to remove, I would also like to bring attention to the community portal. I was growing tired with how outdated it was, since with most wikis the portal serves as a valuable information resource and collaboration tool. I think that we should take advangage of it. By emulating Wikibook's model, the page can serve to host a "collaboration of the month", list "wanted guides", and introduce new users to StrategyWiki. Any thoughts and opinions on this? echelon  22:20, 26 May 2006 (PDT)

Requests for help in articles
As I've been going through sorting out categorisation issues, I've found quite a few articles have their own non-standard requests for help, pointers to the editing guidelines, and lists of contributors. I think this is quite poor; it takes the attention away from the article itself, and isn't standardised. Articles like this should be using the wip template, but perhaps it isn't helpful enough to persuade potential contributors to improve the page? Regardless, I think articles like this and this (at the bottom) should be changed and standardised. --DrBob 12:37, 27 May 2006 (PDT)