StrategyWiki talk:Community Portal

This page is for discussion of general community issues. To start a new thread click here. Resolved threads are gradually archived; see the archives box below.

Key Issues:
 * License
 * Articles to delete
 * Others to be added...

Cleanup project
I've created a page consolidating all my cleanup efforts, and I'm hoping it can make it somewhere useful, like Cleanup. I would like to make it a recognised "sub-project", and possibly involve more people in maintaining and cleaning StrategyWiki. I would also like User:DrBob/Wikify to be made official, and used on pages which need wikification, so they can more easily be found. --DrBob (Talk) 23:36, 15 June 2006 (PDT)
 * Can I recommend a kind of policy similar to sporewiki's cleanup page? http://www.sporewiki.com/SporeWiki:Cleanup?

Official StrategyWiki law
Wikipedia has many "Wikipedia:Insert_law_here" pages, detailing the guidelines and ways in which Wikipedia should be used and layed-out. I propose that we write a few of these – mainly based around editing structure – to help people format their pages properly. May I also suggest that we have one listing all the system templates we've created (such as wip, stub, etc.) so that they can all be found in one place, perhaps with an example? --DrBob (Talk) 23:38, 15 June 2006 (PDT)
 * I definitly think this should happen. I think once a policy that gets disscussed here is finalized, It should be made into a Law page, written up nice and clearly, and the discussion that was once here moved to the talk page of the law. The only problem now is that we haven't really finalized any big policies yet. --blendmaster 13:51, 16 June 2006 (PDT)
 * My biggest recommendation is to implement these few policies/guidelines (like their wikipedia examples, but not exactly the same obviously): Be bold, Assume good faith, and a policy stating that noone "owns" a guide.  Wikipedia has something like that last one, but I can't find it.  It's best for this kind of thing, as long as everyone is bold in adding what they think is useful, and noone thinks they own the article, they will assume good faith in discussing the changes maturly.  Besides these three, everything else is specific instances.  As long as everyone follows these, this site will function perfectly well I believe. -- Mason11987 (Talk - Contributions) 07:57, 18 June 2006 (PDT)

Including enemy lists, item lists, and other big table data
Should guides here include big tables of data like enemy lists, shop prices, loot statistics, and other data that comes in large tables? Somthing like the enemy lists here. Although they would be useful to have on site, they would be very hard to maintain in a wiki format. Subtle vandalism (i.e changing a few values at a time) would be extremely hard to detect and hard to verify if it was a legit change or not. What do you guys think?--blendmaster 09:51, 16 June 2006 (PDT)


 * Do most strategy guides give such tables? I think we should do so.  I'm familiar with wiki tables if help is needed.  Wolfman2000 20:15, 16 June 2006 (PDT)


 * I would agree with including this data, just as long as the guide does have other useful content (i.e. it's not just a big table listing data). If the tables are huge, they should go on an appropriate sub-page. --DrBob (Talk) 03:20, 17 June 2006 (PDT)


 * An enemy list is better then nothing. It'd be best to have a full guide, but if someone wants to add an enemy list or item list to a guide that doesn't exist, starting up the guide even with just these things is the best way to get other people to write full guides right?  Just as long as all new guides get the appropriate guide structure (whatever that may be) then the link to an empty walkthrough should exist, and a lot of people will follow red links and write something up just because it isn't here.  -- Mason11987 (Talk - Contributions) 08:01, 18 June 2006 (PDT)

CSS class for "notice" templates
It would be useful if there was a CSS class for "notice" templates which are stuck at the top of a page, such as Template:wip and Template:stub. This would mean styles aren't duplicated across templates, and remain consistent. May I advise "messagebox" be the class name, and "float: center; margin: 10px; border: 1px solid #7d87bc; background-color: #d0d5f1; padding: 3px; font-size: larger;" as the properties for the class? --DrBob (Talk) 10:37, 16 June 2006 (PDT)
 * You are a sysop, you can edit MediaWiki:BlueCloud.css can't you? :) Would you mind adding it to MediaWiki:Monobook.css while you're at it? Thanks. -- Mason11987 (Talk - Contributions) 08:03, 18 June 2006 (PDT)
 * I've added it (I wasn't a sysop when I first brought this up), but haven't used it in any templates yet. --DrBob (Talk) 23:01, 20 June 2006 (PDT)

More project administrators?
I've made DrBob an administrator so that he can do some of the more routine organizational work that he tends to do. I was thinking we could use a few extra administrators as well in order to block spam and keep the wiki clean. If any of you would like to take the job let me know. (Depending on the number of applicants we may or may not do this by a voting process. I'm not really sure of the best way to handle it this early on.) echelon  11:48, 17 June 2006 (PDT)
 * I might be interested in being an admin, though I don't exactly have the most time in the world right now. How much work would be involved here?  I'd like to help out in any way I can, but I don't want to make a commitment to something that will be too much for me to handle at the moment.  If, on the other hand, being an admin would be something I can do without spending hours online, I'd be very willing to take it on.--Dukeruckley 11:05, 19 June 2006 (PDT)


 * For now, the only added benefits of being an admin (or sysop) is being able to edit protected pages, protect/unprotect pages, and delete/restore pages. We'll still be democratic, so being a sysop doesn't give you extra "voting power". Normal users may look to sysops to perform special tasks (such as editing protected pages, deleting pages, etc.) or they may look to you for advise. I believe sysops can also ban troublesome users, and since they can edit protected pages, they can also ammend the spam blacklist as necessary. As for your question, I do not think that sysops need commit any more time than they would as normal users. A sysop needs only commit to do extra misc. tasks, help resolve situations involving problematic or disruptive users, and help out users in need. echelon [[Image:Ocarina.gif|...]] 02:26, 23 June 2006 (PDT)


 * Well, I think I can handle that! Just let me know.--Dukeruckley 05:27, 23 June 2006 (PDT)


 * However, you do also need to be able to fly, and pull bunches of flowers out of your sleeves. *ducks* --DrBob (Talk) 08:58, 23 June 2006 (PDT)


 * I'm not Superman! (Not that Superman pulls flowers out of his sleeves...)  What ended up being the decision, sysop or not?  I never heard anything.  Note:  I'm not trying to sound pushy, I'm just curious.--Dukeruckley 13:08, 5 July 2006 (PDT)


 * I don't think there was one: the decision is afaik up to echelon, but you've got my vote. :-) --DrBob (Talk) 13:42, 5 July 2006 (PDT)
 * I had to leave a message on his talk page to have him sysop after he suggested it on my talk page. I recommend you do the same. -- Mason11987 (Talk - Contributions) 21:41, 5 July 2006 (PDT)


 * Finally taken care of! Sorry I missed this earlier. With the three additions to the team we've made, I think we're set.  ech elon  23:47, 5 July 2006 (PDT)


 * Thank you!--Dukeruckley 06:39, 6 July 2006 (PDT)

Release days should not be a category
Currently games are being categorized by what day of the year they were released on, see Final Fantasy VI. I believe that these categories should be removed and the date should simply be linked because:


 * Categorizing a game based upon the year is useful and will let you examine games that were released around the same time. Categorizing games based upon the individual day they were released on is little more than a curiousity and won't let you compare anything useful.
 * The purpose of finding out what games were released on a particular day can be accomplished by simply examining what links to that day of the month, as in http://strategywiki.net/wiki/Special:Whatlinkshere/April_2. Having an "April 2" category adds next to nothing and its purpose can be accomplished more easily otherwise.
 * While we're at it, the category for years, http://strategywiki.net/wiki/Category:1994 should really be "Games released in 1994"

I can understand the need to want to order and categorize this kind of information, but the day of a month a game was released on can be handled by a link, you don't need to really see it as a category at the bottom of the page whne you're looking for related information. Categories should be for things like genres or titles in a series that you would naturally group together, there's not a similar need to group by days--BigCow 14:00, 17 June 2006 (PDT)


 * It doesn't take any time at all to add these categories, they take up no real space, and they can be useful for some things, such as finding out what games were released on your birthday (or some other important date). The average user won't look at "what links here" for a day page, and the listing there isn't as concrete as that provided by a category. If we use categories, we can explicitly link them in to articles, but if we use "what links here", all sorts of other fluff will be listed: I've seen many articles which talk about dates other than their release dates (such as the release dates of other, related games) which would confuse people reading the "what links here" listing.

The year categories are (imho) named fine as they are, as this wiki is only about games, so people reading it can assume that a year will be related to games releases (and they can't be "Games released in 1994" because we list consoles and perhaps companies in those categories too). If we did that and kept all the current year pages it would be quite involving and complex to keep it all organised (there's a greater potential for error with names such as "Games released in 1994" than there is with a simple year number). --DrBob (Talk) 14:36, 17 June 2006 (PDT)


 * I just think there are better ways to handle all these things. If you want to see the precise day a game was released we can have a master list for that which indexes games by date. And if you can't make the category title specific enough to say what it actually represents, as in "games released in 1994", you should subdivide it into multiple categories, or break it apart. If the category doesn't represent any one thing but could represent any game or company related to 1994 then it's not really a category which makes any sense.--BigCow 14:52, 17 June 2006 (PDT)


 * The problem with master lists is that they're very hard to keep up-to-date, and are prone to corruption. The only master lists we've got at the moment are in Categories, and they're hard enough to keep up-to-date just by looking at what's in the main categories! I think it's OK to have everything which was released in a year in that year's category, as the differences will be obvious (compared to the example above where any page could link to a day, only games/hardware/companies created on that day would be in the category), and the number of games would far outnumber the companies and hardware in the category. I am willing to change my mind on this detail, though. (Just as long as the years stay as numbers.) --DrBob (Talk) 00:00, 18 June 2006 (PDT)


 * The Chrono Trigger article currently has 13 categories. Out of those 13, seven of them are related to the release date. Just as a user interface issue, people don't generally like lists with more than seven items, it's the most we can hold in short term memory. I don't think we need to categorize a game according to three seperate years and four seperate days on which it was released. (for starters, there's no easy mapping between release day and year). If you're going to categorize games based upon release dates at all, you should only count the first release date, otherwise you could have several if you track each region.--BigCow 18:54, 19 June 2006 (PDT)


 * I gotta agree with that, it's simply ugly to look at and I don't see the advantage of having chrono trigger stored on 4 random day of the year categories, especially since ablut 99% of the time, 3 of those links will seem to be incorrect by the person looking for the guide because it won't apply to them. Doing just the initial release seems like the best option to me. -- Mason11987 (Talk - Contributions) 19:40, 19 June 2006 (PDT)


 * I would go with that. --DrBob (Talk) 23:33, 19 June 2006 (PDT)


 * On second thoughts, I wouldn't. All the release dates (should) all be the last categories in the list, so all the more important categories (such as developer and genre) are right at the start of the list, where people will be looking. The categorisation by release date is not so that you can look at other games released on the same day from the bottom of the article; it's so that you can look at the article from the category, so there need be no mapping from day to year at the bottom of the article: people would be going to the category, then navigating to a game from there, and they'll want to see all the games released anywhere in the world on that date if they're in that category. --DrBob (Talk) 12:51, 20 June 2006 (PDT)


 * I would personally be glad to work on and update a master list of games by release date if it would put this issue to rest. And I really don't think looking up games by release dates anywhere in the world makes sense. The same game may have four or five releases in different versions, and we shouldn't need seperate categories to keep track of a European, Asian, or other releases. When the game was first released puts it into a useful context of when it was developed. The other number just says when it was ported to another platform.--BigCow 13:06, 20 June 2006 (PDT)

My whole problem with the whole release day categories are that we are going to have a ton of categories with only one entry in them (until we become a large site). The best thing to do is have categories based on months and years. In other words, if a game was released on July 7, 1999 then it would be in a category July 1999. At least that way you'll be more likely to have more than one game in each category.--Dukeruckley 12:58, 20 June 2006 (PDT)


 * That would also be an improvement over having seven categories, whittling it down to just one.--BigCow 13:06, 20 June 2006 (PDT)


 * The only problem is that in the case of Chrono Trigger it would still only bring it down to four catagories from seven. It was released in March 1995 (SNES) (JP), August 1995 (SNES) (NA), November 1999 (PS) (JP), and June 2001 (PS) (NA). So unless we were to only choose one of the releases it would work. We could get rid of the Final Fantasy Chronicles dates and bring it down to two dates. I could see that working out quite well. Thoughts?--Chrono Warrior 3 15:53, 20 June 2006 (PDT)


 * I still believe that as long as all the dates are the last categories in the list, they're doing no harm there. Most games have only one release date, and of the ones which have several, they usually share years. We're arguing over extremities here. --DrBob (Talk) 23:03, 20 June 2006 (PDT)


 * Bob has convinced me, :) As long as they are the last cats it should be fine. -- Mason11987 (Talk - Contributions) 23:08, 20 June 2006 (PDT)


 * This gets back to the whole Wikipedia is not paper thing. We can use any amount of space we want, the sky's the limit in terms of storing data. I just think that having a bunch of redundant categories looks sloppy and hurts intuitive navigation. We could categorize games according to any number of things (soundtracks composed by Koji Kondo for example), but we need to make a conscious effort to limit ourselves to only the most relevant information to avoid becoming too bulky and unwieldy.--BigCow 09:07, 21 June 2006 (PDT)

Clarified Discussion
Sounds like there are two different discussions going on here... I'm writing this for clarity more than anything. Please respond to each discussion underneath the appropriate paragraph. If you have any more questions, please add an additional bullet to the end.--Dukeruckley 06:15, 21 June 2006 (PDT)


 * First: Are we going to categorize the dates using the exact date (i.e. July 7, 2006) or the month/year (i.e. July 2006) or some other method?


 * I personally feel that we should use the month/year approach to categorization. That way we don't have a ton of categories with only one game in it.  It just makes more sense in the long run.--Dukeruckley 06:15, 21 June 2006 (PDT)


 * I personally feel that the month and the year would be the best method of catagorizing the games. Far fewer pages and less clutter. However is there a method in which to arrange the games by date in the catagory? Such as CT came out March 11, 1995 and let's same game ABC came out March 20, 1995. Could we arrange so that ABC came after CT with the date above it? --Chrono Warrior 3 08:14, 21 June 2006 (PDT)


 * I believe it could via the cat tag would put it in a 01 section I believe. -- Mason11987 (Talk - Contributions) 09:00, 21 June 2006 (PDT)


 * Exact date. Once the wiki gets going, we won't have a tonne of categories with just one game in. Even at the moment, with only (I'm guessing) 50% of the guides actually categorised, we've got plenty of categories with multiple guides. Just because something isn't amazing at the moment doesn't mean it won't get better. Do you think we should abolish, say, the Atari 2600 category just because it's only got one game in it? --DrBob (Talk) 09:04, 21 June 2006 (PDT)


 * But even when the site gets big, a category as specific as a single day will still have only two or three entries in it. By going with a month and year, you end up having many games in the category and then using the idea of organizing the categories it just works out better.  I'd hate to look at a list of categories and see 2000 categories with only two to five entries in them.  It'd be better to have 100 categories with many entries in each and organized in a way that the information you are looking for is easy to find.  It would be must less work and would not clutter the site up as much.--Dukeruckley 09:17, 21 June 2006 (PDT)


 * I also believe that the month and the year together would provide the most useful information, or just linking the year on its own would be fine. --BigCow 09:07, 21 June 2006 (PDT)


 * Once the site gets big, we will have thousands of game guides (because there have been thousands of games made) - that equates to a good 10 entries in each day category, which I think is perfectly acceptable. --DrBob (Talk) 09:03, 23 June 2006 (PDT)


 * Second: Should we categorize games by each release date or just one or two?


 * I don't really care about this one too much... I think it might be easiest to simply categorize it by Japanese release dates (in the case of Chrono Trigger we'd use the Japanese release on the SNES and the Japanese release for FF:C for the PS)--Dukeruckley 06:15, 21 June 2006 (PDT)


 * This is primarily an English site so to most users the JP release date isn't of that much importance. True it doesn't matter much but I feel the NA release should be the one chosen. --Chrono Warrior 3 08:14, 21 June 2006 (PDT)


 * The problem with that is the English language is used often in Europe as well. So why would we choose US over EU?  Honestly, it should be the first release of the game.  So if it's an American game, then the American release would be the one used.  Since CT is a Japanese game, the JP release would be used, etc.--Dukeruckley 08:49, 21 June 2006 (PDT)


 * By each release date. If people are looking through the date categories, they'll be looking for games released on those dates. Just because it isn't the game's first release date doesn't mean it wasn't released for the first time in some part of the world on that date. --DrBob (Talk) 09:04, 21 June 2006 (PDT)


 * I can see that.--Dukeruckley 09:17, 21 June 2006 (PDT)


 * One release date is preferable, and I think the earliest release date makes the most sense. If not, we can use the NA release date since this is an English site, we just need to be consistent.--BigCow 09:07, 21 June 2006 (PDT)


 * What's your reasoning for this, BigCow? One of the driving forces behind Wikipedia is that it doesn't favour one country or nationality over another. Why should here be any different? --DrBob (Talk) 09:03, 23 June 2006 (PDT)


 * That's why I say earliest release date because it doesn't favor one nationality. Granted, Japan will be the most commonly used release date, but in this case there's a reason for it.  The game was first released on a certain date and that's the date that make the most sense to use.  The rest of the dates are really re-releases, just in different countries and languages.  Now if we want to put all of release dates in the article and not make them all categories, I'm completely for that.  It makes sense to do that.  In any case, I don't think many people are going to try and find a game based on the release date.  If someone wants to know what games were released on their birthday, it's not StrategyWiki's goal to provide that really.  It just makes things difficult for us while very few people will actually find it useful.--Dukeruckley 10:57, 23 June 2006 (PDT)


 * Agreed. --BigCow 13:50, 23 June 2006 (PDT)


 * I'd still push for categorisation by all release dates, but I'll go with this for the time being. :-) --DrBob (Talk) 15:11, 23 June 2006 (PDT)

Master List of Games
I know we have games listed in catergories, but do we have a page with each game on it? I think it might be useful to put a master list of all games that currently have functional guides. People who browse this site just for fun (not necessarily looking for a particular guide) might find it a hassle to have to keep clicking through different categories. The downside to a master list is of course the effort it would take to keep it up as StrategyWiki gets larger. Any thoughts? --Dukeruckley 06:27, 18 June 2006 (PDT)
 * If you think about how people are going to look for games, they're either going to know which game they're looking for (in which case they'll use search), or want to find out about games in a particular genre, or for a particular console. I can't see many people at all just wanting to see a list of every game we've got, and it would take a lot of effort to keep up-to-date. --DrBob (Talk) 07:29, 18 June 2006 (PDT)
 * Well if NCL was added here, this might be possible, and would require no effort to keep up to date. I'm making another topic to talk about this. -- Mason11987 (Talk - Contributions) 08:08, 18 June 2006 (PDT)
 * Not everyone is always going to know what they're looking for. Especially at the stage we are at right now, where we don't have a whole lot of strategies yet (we have a good amount, but nothing spectacular).  If someone doesn't find the game they're looking for they may think, "what games do they have?" and then want to see a list of games.  Instead of having to click through a bunch of genre or console lists, it might be nice to have a single list of everything.--Dukeruckley 07:22, 19 June 2006 (PDT)
 * Good point. --DrBob (Talk) 09:16, 19 June 2006 (PDT)
 * I was thinking it would be a good idea to categorize guides by overall completion level. We could easily place each level in an overall category of "All guides", thus killing two birds with one stone. Thoughts? echelon [[Image:Ocarina.gif|...]] 10:19, 19 June 2006 (PDT)
 * An interesting idea, though it might be difficult to implement. Mainly, how do we determine which guides are the most complete?  While it might be obvious for some guides, it'll be less obvious for others, namely MMO games that are constantly updating.  Couple that with that fact that the guides on this site will continue to improve and more content added, we'd have to update the list very often.  A simple alphabetical list would probably be the best idea, unless we can think of a way to defines a level of completeness and are willing to update the list often.--Dukeruckley 11:02, 19 June 2006 (PDT)
 * Well we have that 4 boxes things for sections of guides, like the FFVII one, we could just have a template that puts one down for the whole guide, and depending what image you use, it will categorize the guide into a different place. And optionally all guides could ALSO be in a category:guide category which would categorize all of them and sort them alphabetically too. -- Mason11987 (Talk - Contributions) 13:13, 19 June 2006 (PDT)

Spam filter
On another topic I tried to link to: http:// www.planetspore.co.uk/ to show an example of something I was saying but it said the spam filter blocked it. It seems kind of pointless to block potentially legimate site when anyone with some knowledge of mediawiki can get through it anyways as I did. Or perhaps a blacklist with particular sites would be best? Maybe something like the "Filter Set G" extension for adblock for firefox? I'm not sure how these thigns work, but that site shouldn't have been blocked. -- Mason11987 (Talk - Contributions) 07:51, 18 June 2006 (PDT)
 * I'm not sure why planetspore would be blocked, but that's definitely not something we want. I'll make sure to fix it. echelon [[Image:Ocarina.gif|...]] 19:34, 20 June 2006 (PDT)
 * I checked out our blacklist, but I'm not sure what is causing it. There appear to be no matches for planetspore.co.uk on our blacklist... echelon [[Image:Ocarina.gif|...]] 19:58, 20 June 2006 (PDT)
 * I found it. The pl ban also catches planet, so I've disabled it for now. You can easily check things like this by saving a page with a blacklisted URL and reading what the error message says triggered it. GarrettTalk 00:57, 21 June 2006 (PDT)


 * It didn't seem very useful when it blacklisted it before, but thanks for the fig :). -- Mason11987 (Talk - Contributions) 09:00, 21 June 2006 (PDT)

NCL
I'm propossing an addition of the Nice category list extension to server some of the organization issues here. An example of it in use on sporewiki is in the Full creature list which creates a very long and still useful list by only using this code:

In-game creatures
Category:Creature creations

Creature concepts
Category:Creature creation concepts Category:Creature Creation Concepts

I'm sure you can understand how the category works, and it might make the Game categories list easier to keep up to date and therefore slightly more useful, and it might also be able to create a full game list page if we wanted it (why not? lol). Actually, that was the original, it might be better to use the enhanced version which is what we are running on sporewiki. -- Mason11987 (Talk - Contributions) 08:13, 18 June 2006 (PDT)
 * I definitely agree with this. Very useful. :-) --DrBob (Talk) 08:29, 18 June 2006 (PDT)

Max Image Size
I have acquired numerous images of boxart for various games on the internet as of late for this site. However is there a limit as to how large the boxart should be? I know it can't be terribly large however having a set size limit would be good for future progress. I was unable to find any limit while looking over the site. I do know that on Wikipedia that somehow the images automatically scale down some if they are too large, is there any way we could implement that here?--Chrono Warrior 3 21:34, 18 June 2006 (PDT)
 * Scale down when? When uploading them or when displaying them, the second is easy enough to implement, the first might not be so easy. -- Mason11987 (Talk - Contributions) 23:49, 18 June 2006 (PDT)
 * MediaWiki will automatically cache scaled versions of images where pages specify the size of the image to use. The standard size at which box artwork/company logos (etc.) are displayed on the relevant pages is 250px wide. Just upload the images as big as you like, then make sure to put "|250px" after the image name in the image reference (e.g. [[Image:Example.jpg|250px]] ) when writing a page. Also make sure you categorise your images when you upload them. :-) --DrBob (Talk) 09:14, 19 June 2006 (PDT)

Trying a new homepage
Check out some of the changes I made to the homepage. I think it's nice to get rid of those wasteful and annoying "image of the day" things. What do you think about the new format though? Should anything be changed? Do you feel this is an improvement? echelon  03:37, 23 June 2006 (PDT)


 * Looks nice. :-) --DrBob (Talk) 09:07, 23 June 2006 (PDT)


 * Looks a lot better than before. Once Strategywiki grows more though, I think we should have a list of wanted guides, a featured guide, and other more interactive stuff like that. --blendmaster 09:17, 23 June 2006 (PDT)


 * That sounds excellent! Hopefully by that time we'll have someone here who can make it look a lot better than I can. I can sense a lot of potential for the main page, I just don't know how to go about implementing it correctly... echelon [[Image:Ocarina.gif|...]] 12:32, 23 June 2006 (PDT)

Relicensing plan
Check this out and comment please! (Your comments to this Community Issues post are not necessary, so please do so on the License talk page instead.) echelon  04:05, 23 June 2006 (PDT)

Copyrights rewrite
I'm working on making Copyrights more thorough. You can see the draft at User:Garrett/StrategyWiki:Copyrights. Is the wording simple enough for the average person to comprehend? Does it cover all situations? I'm trying to make it as brief but all-encompassing as possible, while at the same time including rationale for blatantly defying others' copyright claims (as in the case of patch codes). As with the licensing, replying there rather than here would be better. GarrettTalk 22:33, 23 June 2006 (PDT)

You didn't get many comments, but I think it is solid. Let's go ahead and implement this, shall we?  ech elon  20:36, 25 June 2006 (PDT)

Contributors list
I've seen a kind of contributors list on some guides, which seems kind of strange to me. While it's great to be proud of your work, having your name on the guide itself doesn't really help anyone out, and if they really cared who made it, they'd just hit the history button right? Not trying to downplay anyone's contributions, but I don't think the TOC of a guide (or any articlespace page of a guide) is a good place to list who helped out. -- Mason11987 (Talk - Contributions) 00:44, 25 June 2006 (PDT)


 * I did moan about this in my requests for help in articles section. Once I've had a shower, I'm going to create some more templates to put on pages such as this (probably wikify and drivel), and then go through and clean up some of the pages. --DrBob (Talk) 03:28, 25 June 2006 (PDT)
 * I'd first move those sections to the talk page, I really don't think notices that big are necessary, the reader may be impacted by a useless contributors list, but I am possitive they will be impacted by a massive banner on top of the guide. I understand the Wip ones and the spoiler ones being big, but these should be minimal like the corresponding ones on wikipedia, or even just throw cat tags on them instead of those huge templates. -- Mason11987 (Talk - Contributions) 06:59, 25 June 2006 (PDT)


 * Good point. I've removed the banner from drivel, but I'm leaving it in-place in wikify because pages needing wikification are a lot more inconvenient for the user. --DrBob (Talk) 07:05, 25 June 2006 (PDT)


 * Contributor lists are kind of stupid. I've always wondered why Wikibooks has them. If you want to state your history, do so on your user page! Keep it from distracting the reader. As for making templates such as drivel and wikify more or less noticeable, I generally agree that Wikify should be more apparant since it is an important issue that impacts the legibility and conprehensibility in some guides. Drivel should be okay as a minor template though.  ech elon  10:57, 25 June 2006 (PDT)
 * I agree with that, since wikify is more important for readers I believe. -- Mason11987 (Talk - Contributions) 22:50, 25 June 2006 (PDT)

Guide navigation
Currently, we have at least three general guide navigation templates: All Game Nav, All Nav and P/aniki - this is not including the many guide-specific ones. Could we please choose one to be the standard, and get rid of the others? I would personally lean towards All Nav, because it optionally (using qif) combines the P template. However, if we do use it, I think the content should be moved to All Game Nav, as that's referenced in many more places, and so in doing so would cut down the workload of re-referencing everything. If we did do that, the P template would also become obsolete. --DrBob (Talk) 11:30, 25 June 2006 (PDT)


 * Yeah, let's merge All Nav into All Game Nav. The others should be removed. Everyone else in favor of this?  ech elon  11:55, 25 June 2006 (PDT)


 * I agree that there should be a standard one. I like the idea of merging All Nav into All Game Nav. I'm in favor. --Antaios 11:58, 25 June 2006 (PDT)


 * I've deprecated the others, and I'm now going to replace all references to them. --DrBob (Talk) 12:22, 25 June 2006 (PDT)

What about sidenavs (e.g. Template:Zelda: Ocarina of Time Nav), will those ever become part of a standard? At the moment they don't display correctly in skins other than BlueCloud and Monobook, but that's easily corrected. GarrettTalk 20:23, 25 June 2006 (PDT)
 * I'm really waiting for some large amounts of free time, because I have this idea to make a new Javascript system to make not only the sidebars work, but also have them presentable in condensed form. It'll take a lot of work though, so...  ech elon  20:34, 25 June 2006 (PDT)

I just realized there was no such template on SW, so I went ahead and created one, albeit not a very good-looking one. Anyone with better designing skills is more than welcome to improve upon. Alex 19:43, 25 June 2006 (PDT)
 * What about Template:Wikify and Template:Drivel? Are these too specific to the point we need a Cleanup template too? Hm...  ech elon  20:33, 25 June 2006 (PDT)
 * Well, cleanup is a notice that is more broad then wikify, and is an actual message to readers unlike drivel (and as I stated above, I don't think drivel would have been an appropriate reader visible template anyway). -- Mason11987 (Talk - Contributions) 22:53, 25 June 2006 (PDT)
 * Ah, understood. Good point!  ech elon  23:32, 25 June 2006 (PDT)
 * I think this is redundant. All possible cases are covered by wikify, and if the wording on wikify isn't broad enough to cover them, then it can be changed. We're not big enough yet to need hundreds of different templates for each conceivable problem with a page. --DrBob (Talk) 23:40, 25 June 2006 (PDT)
 * Bad grammer, paragraph structure, organization or unclear explanations are all already "wikified" but they still aren't really fit to be here in a "completed" sense, although I do agree that we shouldn't need many templates. I believe wikify covers really simple changes that could be done with a smart enough bot honestly, while cleanup would be stuff that would take much more then that, and much more time then doing wikifying manually. -- Mason11987 (Talk - Contributions) 00:28, 26 June 2006 (PDT)
 * Hm, well I'll let you guys figure it out. I did manage to change the presentation of the template, though I could not include an icon.  ech elon  23:44, 25 June 2006 (PDT)
 * It was really unobtrusive before, but still informative, I really prefered it as it was. -- Mason11987 (Talk - Contributions) 00:28, 26 June 2006 (PDT)
 * Ah, hmm. I was trying to go for a unified look with Template:Wikify, but I see what you are saying.  ech elon  00:57, 26 June 2006 (PDT)
 * I prefer Echelon's version, as paragraphing, organisation, unclear explanations, etc. all affect the user quite considerably (just as much as wikification issues), and so the template should be the same size and have the same emphasis as wikify. (I've been persuaded that this template is necessary.) --DrBob (Talk) 09:31, 26 June 2006 (PDT)
 * I'm afraid to say I didn't know about those other two templates when I made this one, but I do think that there is significant difference to warrant keeping them all. I think the new look is good, but maybe a bit big. Alex 11:43, 26 June 2006 (PDT)

De indenting from DrBob just above... It should have the same size and the same emphasis as the other template, but in reality, I think wikify is incredibly obtrusive. Wikify is for editors, not really readers. Why does every reader definitly need to know that the page needs wikifying. I think it would be best if the casual guide reader missed that comment since that comment would only make their search for their info some amount harder, and it wouldn't help them at all. The average editor would spot even a small notice like the wikipedia cleanup tag. It obviously is noticed, but users can still get the info they want. I really don't see why text that is quite bigger then usual or an image (especially not such a big one) is a good idea at all. -- Mason11987 (Talk - Contributions) 23:04, 26 June 2006 (PDT)


 * If we shrunk it to that size, it would be good. I do like the icons though...  ech elon  23:06, 26 June 2006 (PDT)
 * the icons are fine, but 96x48px? That seems rather large for an image that has absolutly nothing to do with the guide it is on.  It should be big enough so that editors always spot it, but small enough so that casual readers aren't distracted by it or even better completly ignore it. -- Mason11987 (Talk - Contributions) 23:10, 26 June 2006 (PDT)


 * I'm fine with shrinking it/them to the size of needcontrols, and the images could be taken down to 32px high. --DrBob (Talk) 08:50, 27 June 2006 (PDT)

Table of Contents markup
Over a number of guides, I've seen ToC markup which isn't good. It's using outdated, deprecated, non-semantically loaded tags to do the jobs of titles. (I am referring to ToCs which use to emphasise section titles - an example would be The Legend of Zelda: Ocarina of Time.) Instead of this, they should be using headings (usually === Section title === ) to make it more accessible and semantically correct. If you don't know what semantics are, either look them up, or don't reply. ;-) --DrBob (Talk) 12:40, 26 June 2006 (PDT)


 * You're about to see why I did that. Check out The Legend of Zelda: Ocarina of Time again. (If I had used == 's, the new Table of Contents would break the page.  ech elon  16:41, 26 June 2006 (PDT)

A new table of contents
What are your thoughts on The Legend of Zelda: Ocarina of Time's new table of contents system? It needs a bit of polishing, but I think this will become a standard for larger guides.  ech elon  16:44, 26 June 2006 (PDT)
 * It's pretty nice, and I think it should be automatically visible. Or at least easier to notice (it took me a second to see where it is). Alex 16:51, 26 June 2006 (PDT)
 * I'm thinking of storing the show-hide preference in a cookie. You're right about making the link more apparant, though. We need a small icon or something to go with it. Maybe two images: an up and down triange.  ech elon  17:10, 26 June 2006 (PDT)
 * I think it should be shown by default on the first page. Right now it's little different from the old cover page idea, a click is still required to see the TOC. I also prefer the sidenav just a little bit more since it's always there and makes use of the otherwise wasted right-hand column. GarrettTalk 17:53, 26 June 2006 (PDT)
 * The sidebar required for the sidenav TOC isn't present in other skins. I am thinking of an option that lets the user choose whichever type of navbar they want, though. (I didn't by any means delete the sidenav script.) Currently, I must say that I prefer this new inline TOC to the sidebar one; it allows much more options, such as organized multi-column navigations and inline images. Plus, you don't have to scroll down the page to see the whole TOC, and that's a very annoying part of the sidenav TOC. Again, I'll still try to find a solution that allows the user to choose either one though. Just keep in mind that I am not done by any means--the new inline TOC needs some kind of image to make it more obvious, a little tidying, a saved user preference, an init variable, etc.  ech elon  21:45, 26 June 2006 (PDT)
 * I think I made some useful changes that appears to work very well on both bluecloud and monobook. The .js file can be edited so that the nav always shows up by default, but I think having it hidden by default is best (unless you can store it in cookies, that would be even better).  I had to edit a few files to get it to work the best, and couldn't find the "GuideTOC" style anywhere so I used something without that.  Sine that style probably won't be used outside of that template I don't see why it should be a reference in some file that is uneditable, you know?  I think this is simple and clean, while being very useful at the same time.  It could use some polish of course, but I think it's even better now. -- Mason11987 (Talk - Contributions) 22:57, 26 June 2006 (PDT)
 * It looks nicer, but the show/hide doesn't seem to work anymore. (I did dump my cache...) Do you plan to reimplement that? I think the hiding feature is the best attribute of the template. I'll try to add cookies support tomorrow.  ech elon  23:04, 26 June 2006 (PDT)
 * Try it again. You changed the dynamic nav stuff to be specific to TOC related things.  This chang allows dynamic nav to be used in all kinds of things, including the todo lists (check your user page in a little bit to see the changes I'm making to that). -- Mason11987 (Talk - Contributions) 23:15, 26 June 2006 (PDT)
 * When you click on "show" in the new ToC, there is a minor bug where it still says "Show" underneath "hide". In other words, you get two words meshed together.  Can that be fixed?  Other than that, everything looks great!--Dukeruckley 05:59, 27 June 2006 (PDT)
 * I'm not that good at javascript so I'm going to leave this to echelon or drbob. It's odd that this bug doesn't exist when using monobook, but does in MediaWiki:BlueCloud.js, even though the .js files are exactly the same...how strange eh?  Good luck guys :). -- Mason11987 (Talk - Contributions) 08:23, 27 June 2006 (PDT)
 * Eh? You called? What do you want me to do? (BTW, I think the ToC template is too big at the moment: imho the border should be removed, to let the ToC contents fit in with the rest of the page.) --DrBob (Talk) 08:52, 27 June 2006 (PDT)
 * Well, the TOC at the top of every zelda page (and actually the dynamic navigation system as a whole) functions without that little bug duke mentioned only when it's on monobook, on bluecloud it has that bug he mentioned, and with your "BTW", are you referring to the zelda TOC page itself or the dynamic nav system used in all game nav? -- Mason11987 (Talk - Contributions) 09:38, 27 June 2006 (PDT)
 * I'll take a look at the bug later, but I am referring to the dynamic nav system itself. IMHO, the "Table of Contents" link in the All Game Nav proper (i.e. the one which has always been there) should be emphasised more, and when clicked, expand the full table of contents, with a light grey border around the bottom, left and right to separate it from the content, and perhaps with a "tab" effect applied to the Table of Contents link the user just clicked. I don't like the fact that it's expanded by default (takes up far too much space), and the current border and grey title bar doesn't fit in; neither does the reduced width. --DrBob (Talk) 10:04, 27 June 2006 (PDT)

I believe I get what you're saying. It is strange to have a TOC link and also have the dynamic nav, and if possible I would like to be able to have clicking the TOC link bring down the whole nav. Perhaps the entire content of all game nav should have a border around it to seperate it from the content? I think that would make things clearer. It's kind of hard to get exactly what you mean, but if you set up a test All game nav to mess with styles it might be easier to follow. -- Mason11987 (Talk - Contributions) 11:11, 27 June 2006 (PDT)
 * I've fixed the show/hide problem (a dirty hack, because the function creating the show/hide links was being called twice and I'm not about to debug that) in BlueCloud, but not Monobook because you said the problem doesn't occur with it. I've also created a WIP mockup of what I was thinking of for the ToC stuff, incorporating your idea of bordering the all game nav entirely. --DrBob (Talk) 12:37, 27 June 2006 (PDT)
 * I think that is very cool, I changed the Counter-Strike:_Source/Table_of_Contents page so that it didn't include the infobox. Perhaps it can be set up so that the infobox is shown on the page whe you view it, but when it is included it sets up the TOC horizontally?  It seems like a lot of effort for this to be done on most multi-page guides, but I definitly like the style.  I think this will look amazing on the zelda guide, just each guide will have to figure out exactly what will be included in the template. -- Mason11987 (Talk - Contributions) 20:25, 27 June 2006 (PDT)
 * I made some more changes, so it appears exactly the same on the TOC page itself, but when used in the template it looks much cleaner. -- Mason11987 (Talk - Contributions) 20:33, 27 June 2006 (PDT)

'''Whooops... I meant to actually put this on the Todo Talk page, I'll move it there now'''

Another odd fluke... Using MediaWiki:BlueCloud.js, when I click on "edit" where it says "Games I'd Like to Work on Eventually" on my user page it comes up with the edit box for the section below it "Games Currently Playing". Likewise, when I click on edit for "Games Currently Playing" it goes to edit "backburner" which is below that one. Above the To Do list, it work correctly so I think its a problem with the Todo template. Thoughts? (Not a big deal, but something that might need to be addressed at some point).--Dukeruckley 08:04, 28 June 2006 (PDT)

Another note: It does the same thing with other users as well.--Dukeruckley 08:08, 28 June 2006 (PDT)

End random section that doesn't belong here


 * Starting a new indent. While I like the look of the menu that Mason did more than mine (it's more compact, more noticiable to the user, and a little more organized), I can't help but feel that it was a step backwards:
 * The new version is attempting to be the show/hide template from Wikipedia, thus in essence trying to be a more general script. The one I designed was specific for the purposes of the Table of Contents alone. In my opinion, the biggest problem with the new one is that it requires a seperate bar for the "show/hide" portion of the Table of Contents, and that looks cluttered. I don't know how many saw the one before, and though it was certainly not perfect, it made the "show/hide" link a part of the All_Games_Nav itself. I think the new one, while more noticable, is a bit too jumbled looking. We need something that employs the benefits of both, but we absolutely have to get rid of that bar at the top; it looks far too cluttered.
 * The original ToC that I designed was not set into any formal kind of standard. Different guides may require different types of data displayed under the Table of Contents--perhaps diagrams or images. While I'm not sure if this is the case or not, but the new one seems like it wouldn't fit those types of things.
 * I hope I'm not trying to backstep or be redundant, but I do feel that we should revert back. The show/hide template for Wikipedia will have uses here, I just don't feel we should use it for the Table of Contents. (Sorry Mason, I know you must've put a lot of work into it :(  ech elon  13:09, 28 June 2006 (PDT)
 * I'm not quite sure what you mean here, although it has been a long day. Have you looked at my spiffied up version?
 * I kind of get what you're saying, but I think as it is now it's got it's advantages over the older one, but if you have improvements to this or even a completly different style that has more advantages I think it'd work great. The spiffed up version DrBob made is quite a big improvement over the one I made and I think it takes into account some of your ideas.  Also, I didn't get the show/hide on the version you had before, although it IS possible that was my fault.  I think the bold change you did with the all game nav got us into a Bold-revert-discuss cycle which is one of the best ways of getting the most out of this.  Feel free to change the one I made, but I DO think it is an improvement over what was there before, even if it has it's faults which is completly open to change which DrBob has done. -- Mason11987 (Talk - Contributions) 15:30, 28 June 2006 (PDT)
 * The version that DrBob is working on looks great! This is the first I've seen of it. It's pretty much a better looking mix of your version and mine. The only thing that might be problematic in his version: I'm not sure about the use of ==Heading== markup, since doing so causes the wiki-generated table of contents to go berzerk. If we could replace the headings with and bold markup, it won't interfere with the toc and would be flawless.
 * As for the show/hide on my version, DOM javascript turned the old "Table of Contents" link into a "Show Table of Contents/Hide Table of Contents" link. It was rather obscure, and it needed some kind of image or something--DrBob's version fixes that and looks even better than before. Let's go with his, and if there are any further improvements to be made, we can make them when they arise.
 * That said, I think this is pretty cool. Our top navigation menu is really slick!  ech elon  19:26, 28 June 2006 (PDT)
 * DrBob's template looks really nice, but I really think we should change the All Game Nav template. Right now, the Introduction and Table of Contents just link straight back to the main page, so its pretty redundant. I think the always visible part of the Table of Contents thing should be customized to the guide, with links to the main sections, such as Walkthrough, Extras, Codes, and stuff like that, instead of the default main page, intro, and toc. --blendmaster 13:16, 29 June 2006 (PDT)
 * Mine is being developed as a drop-in new version for the All Game Nav, so I can't see any problem with bringing such changes into mine, and then moving them forward to All Game Nav. Your point that many guides just have the ToC and intro redirect to the main page is very valid: we should look around for some other standard pages to put in instead (although the link to the ToC should stay as all guides should have a separate ToC page when this new All Game Nav is rolled out, due to the fact that it references them). --DrBob (Talk) 14:06, 29 June 2006 (PDT)
 * I'd migrate your version in as the default now, then continue using it as an in progress version. If all game nav is going to be used on every guide (as it's name implies), we may want to have it protected at some point, and having a test version would be great too if we get it in the template namespace also.
 * But the different links could easily be set up, we just have to figure what would be the best setup. I don't think an "intro" page needs to exist, having a page for the game title (the main page), then a TOC, then a walkthrough would be good enough I think.  The rest can go in the TOC dropdown. -- Mason11987 (Talk - Contributions) 22:21, 29 June 2006 (PDT)
 * I think we need "Walkthrough" as an introduction on how to use the walktrhough portion of the guide. (If there are specifics that the reader must pay attention to, etc.) There is also an ulterior motive for this: SEO (Yahoo *really* loves StrategyWiki). I suggest a "Cheats", "Tips", or "Codes" section for the All_Game_Nav as well. Perhaps the Qif can be used to specify which elements are shown. As for the link to the Table of Contents? That's slightly important: it serves as a link to edit it. Of course it could also be obscured, though.  ech elon  19:24, 1 July 2006 (PDT)

Donkey Kong: A good example or a mess?
Hello. I'm a supporter of this site's mission, and I decided to help out by adding some retro gaming content. I started out by simply transplanting some guides I wrote for early Nintendo games here, namely Donkey Kong, DK Jr., Popeye, and recently Mario Bros. Well, tonight I got a bug up my ass or something and tried to reformat Donkey_Kong in to something... I dunno, more grandiose I suppose. I'm not sure if I succeeded or ruined it horribly. I tried to copy as many examples from the Legend of Zelda: Ocarina of Time pages as I could, like the TOC, next and previous pages at the bottom, and I broke the page up in to multiple pages, which Garrett has been helping me fix up, thank you for cleaning my mess :) But honestly, I'm not sure if it's better now than when it was a simple one page thing (compared to, for example, the Donkey_Kong_Jr. page. Since DK was on more than just the NES, I also wanted to expand it to cover every system that it was on, so I began including port pictures on relevant stages. Anyway, I'm rambling now. Feedback would be most appreciated, either here or on my talk page. Thank you very much.ProcyonTalk 21:31, 27 June 2006 (PDT)
 * Overall, it looks good. Why, however, is the characters page called "Elements"? Also, could you please categorise your images and provide a link to the guide for which they're being uploaded when you upload them? --DrBob (Talk) 22:20, 27 June 2006 (PDT)
 * This guide might be better off in just one page, but maybe not. It's kind of close to that line.  But in this case I'd just defer to the original author.  It looks great for a multi-page guide and if you think it needs multiple pages, then that works :).  I do like the Jr. one too though :). -- Mason11987 (Talk - Contributions) 23:00, 27 June 2006 (PDT)
 * Thank you very much for your feedback guys, I appreciate it. DrBob, I named the page Elements because, as you've pointed out, it also needs a control scheme. So it should contain both characters and controls.  It's an old throw back to Joystik magazine and the Nintendo Player's Guide which I use as inspiration for layout.  However, now that I'm abstracting Donkey Kong from being NES specific to arcade focused and port aware, I will try to include a picture of the original arcade control panel and label that instead.  Then more port pictures to follow (mostly for fun.)Procyon 06:46, 28 June 2006 (PDT)
 * Following up to my own post, I've had a lot of time to clean and fine tune the pages, so I think it's turning out quite nicely. I've added a lot of port screenshots, but I think I'm done with that for the time being (although if someone's favorite version is missing, I hope they'll continue to add to the gallery.)  Thanks to this, I've got a good rough idea on how I want to proceed with Pac-Man.  Feedback, as always, is welcome.  Thanks.Procyon 16:54, 28 June 2006 (PDT)

Game Titles
I think we need to come up with a standard for game titles. For example: we currently have the page for Ocarina as Zelda: Ocarina of Time while it probably should be The Legend of Zelda: Ocarina of Time. The same thing goes for Super Smash Bros which should have a period after Bros. The names to use should be the full name of the game to be consistent. Any shorter names should then redirect to the page with the full name. When StrategyWiki becomes large, I think that this rule will be handy to have in place. If we do decide on following this standard, then we need to act now to begin moving incorrect pages and adding redirects so that it doesn't get overwhelming later.--Dukeruckley 12:51, 28 June 2006 (PDT)


 * I take that back about Smash Bros because it redirects to the correct page already. But take into account CCLP2 which I have no idea what that is...--Dukeruckley 12:54, 28 June 2006 (PDT)


 * I too have no idea about CCLP2, but the other two examples you gave are fine at the moment. :-P --DrBob (Talk) 12:57, 28 June 2006 (PDT)


 * It's fine, sure, but there isn't any reason to not just start it off. Duke, if a game is titled something else, then I think it's perfectly reasonable to move it to the correct title, there is no problem if it's done, but there is definitly benefit.  The only problem is the effort in doing it, so if someone activly wants to do this then I say go for it! -- Mason11987 (Talk - Contributions) 15:30, 28 June 2006 (PDT)

Open invitation for Pac-Man Patterns
In the spirit of StrategyWiki, I started a Pac-Man Patterns section in the Pac-Man entry, so I thought it would be fun if all the usual members of StrategyWiki contributed their favorite pattern to the page. To be honest, I think it's the first of it's kind, a public repository of Pac-Man patterns. If it fills up with lots of contributions, who knows, we could get a lot of press in video game blogs like Joystiq or Kotaku. I look forward to seeing any of your additions! Feedback is welcome. Thanks! Procyon 19:01, 28 June 2006 (PDT)


 * Left comment on that pages talk. -- Mason11987 (Talk - Contributions) 07:33, 29 June 2006 (PDT)

Marking GFDL articles
I've created Template:GFDL_Article to mark all the existing articles so we can begin the relicensing process. Is everyone ready to do this? (Do you think this template is sufficient?)  ech elon  19:48, 28 June 2006 (PDT)
 * Looks fine. I don't know that images need tagging though, Wikipedia and the like merrily use images regardless of what copyleft license they use. How are you going to identify untagged pages though, with a database query? GarrettTalk 19:56, 28 June 2006 (PDT)
 * Special:Allpages, unfortunately.  ech  elon  21:02, 28 June 2006 (PDT)
 * Are we supposed to mark every page within the article as well (see: Chrono Trigger) or just the introduction/table of contents?  I'm asking because Garrett did every page (as far as I could tell) while Mason did not.--Dukeruckley 08:19, 29 June 2006 (PDT)
 * I'm not sure if we legally have to do more then this, but I think if we change the template to something like "This page, and all subpages of this guide are under GNUFDL...blah blah" then I think that would be better, if we actually can do that. If we absolutly MUST do every page, then we'll do every page. -- Mason11987 (Talk - Contributions) 09:49, 29 June 2006 (PDT)

There are a few suggestions I have, and I'm going to get garret in here to check them out: -- Mason11987 (Talk - Contributions) 22:26, 29 June 2006 (PDT)
 * 1) We should only mark the main guide page, with a note saying all subpages are also under GNU, if this is legally possible AT ALL, it should be done, since you must go through the main page to get to subpages (almost always), I think it would be legit.
 * 2) We should put the single tag at the bottom of the main page, to not distract from the reader, but legally cover our butt. The tag is for almost noone, but still needs to be there, and it should be as minimal as possible.
 * 3) I thought there was another...maybe not...


 * Hm. Well, the problem is that the GFDL really wasn't designed to accommodate for pages as separate as those of a wiki. But yes this is getting silly. I think I'll stop and just do cover pages for now, and if someone whines later we can correct it then. That's the DMCA for ya. :) I'll also suitably amend the template. GarrettTalk 22:36, 29 June 2006 (PDT)

It looks like they are all done, can we do the transition now? That would be best I think, and I'll set up a page for all contributors to offer to release their content into the SWPL. -- Mason11987 (Talk - Contributions) 08:30, 30 June 2006 (PDT)


 * I made that page, and I'll begin spamming talk pages for contributors to the guides that are GNU FDL. I'll simply paste  onto their talk pages, and it should go quickly, feel free to clean up that template while this is going on. -- Mason11987 (Talk - Contributions) 08:46, 30 June 2006 (PDT)

Wikipedia-compatible infobox
Why not allow people to use the same variable names for Template:Infobox as are on Wikipedia:Template:Infobox CVG (e.g. genre instead of categories), to allow a straightforward copy-and-paste? If it's not possible to specify alternate variable names in the same template, one could create a new one and call it Infobox CVG. Seahen 09:39, 29 June 2006 (PDT)
 * People shouldn't really be copying and pasting, especially with the license change coming up. It would be an awful lot of work to change every reference to infobox's parameters, and bringing in another template would just introduce fragmentation. It's not hard to just use the variable names currently in use. --DrBob (Talk) 10:13, 29 June 2006 (PDT)
 * The template could be easily changed (using default values) to work with both the wikipedia parameter names, as well as the strategywiki ones, that way a copy paste of an infobox (while not recommened) would be functional. If I knew the parameters of the wikipedia one, and knew the comparable ones on this one, I could do that.  -- Mason11987 (Talk - Contributions) 22:18, 29 June 2006 (PDT)

Shortcuts
For some reason the Alt-E shortcut (and some others, perhaps all) to edit a page isn't working, this would be extremly useful if I want to go through and tag some/all guides with the GFDL template, so if someone can figure out how to put that in and get it to work, that'd be great. Thanks! -- Mason11987 (Talk - Contributions) 09:54, 29 June 2006 (PDT)
 * I'll put it on my todo list, but it won't be really high-priority. :-) --DrBob (Talk) 10:14, 29 June 2006 (PDT)

Cheat Codes
This site is for cheat codes too, right? I know the Ocarina of Time guide has a dummy link to Gameshark codes, but I haven't seen any other guides with them. --blendmaster 13:25, 29 June 2006 (PDT)


 * Absolutely! We just need to be extra-careful nobody puts any codes that "accidentally delete" your game. ;-)  ech elon  01:08, 30 June 2006 (PDT)


 * Ok. Above, i mentioned that the All Game Nav is kind of useless since 3 of the links are the same page. We could put a standard section called Cheats or Codes as somthing to put in All Game Nav, kind of like the section of Gamefaqs. --blendmaster 16:46, 30 June 2006 (PDT)


 * In actuality, we should only get rid of the intro link, the TOC link should be a seperate page (especially since it's included in the all game nav itself. But yes intro should be gone, and perhaps an optional cheats section link would be good. -- Mason11987 (Talk - Contributions) 19:12, 30 June 2006 (PDT)

Collaboration of the Month / Guide of the Month
July has come up on us, so would anyone like to suggest a Collaboration of the Month or Guide of the Month for the front page? Our collaboration will probably be related to switching from GFDL to SWPL. As for the guide, I'm not sure. What do you guys think?  ech elon  19:13, 1 July 2006 (PDT)


 * My Half-Life walkthrough =D. As for a collaboration, defitenly the SWPL license. --Antaios 20:26, 1 July 2006 (PDT)


 * The Final Fantasy VII walkthrough seems like a fairly good one as well. It still has a few sections that could use some meat to them and it needs pictures, but it is a decent choice I'd say.  Although, Half-Life might be a better choice because we just had an action-RPG, so a different genre might be a good idea.--Dukeruckley 05:01, 3 July 2006 (PDT)

Biohazard Walkthrough problem
Right now the Four Crests walkthrough for Biohazard is greater than 30kb, which apparently may cause some browser display errors. And I'm only about 20% through the entire section (yeah, I got a looooong way to go), so expect it to be HUGE (probably over 100kb). The other levels of Biohazard are very small, and they're nowhere near the size of the Mansion walkthrough. So do you guys think I should split the Four Crests walkthrough into individual sections or just leave it as one huge page? Thanks! --Antaios 20:45, 1 July 2006 (PDT)
 * Split it. DrBob
 * Agreed -- Mason11987 (Talk - Contributions) 22:32, 1 July 2006 (PDT)
 * Agreed x2 --Dukeruckley 05:02, 3 July 2006 (PDT)

Rename the license?
I don't like "StrategyWiki Public License", for several reasons. First, "Public" is unnecessary and might make people think there's some connection with the GNU GPL; also including our name is a mistake. As echelon said, "Imagine if all wikis used a single license and it made copying possible between all wikis. Wouldn't that be awesome?" Yes it would, but I can't imagine other sites would be particularly keen on using a license that so openly belongs to another site. Dropping the Public and removing our name from it are primary goals if we want anyone but us to ever use this. GarrettTalk 04:39, 2 July 2006 (PDT)


 * So you'd have it called "License" then? :-P I agree with you here, and I think now is the time to change the name if ever, before it gets too complex. --DrBob (Talk) 04:52, 2 July 2006 (PDT)


 * Guys, check out the suggestions in User:Echelon/Open Media! Leave comments on the talk page there.  ech elon  23:53, 5 July 2006 (PDT)

Image upload warning
I'm going through categorising all the images, and it's a pain. I have a horrible feeling that people are going to continue to upload uncategorised images, so why not put some Javascript on the image upload form which checks for a category link, and pops up a message box chiding the user if the output of  is true. --DrBob (Talk) 06:43, 2 July 2006 (PDT)
 * I suggest looking into the uncategorized images page sporewiki has set up and have that installed. But if this code gets put it, If you could explain how it's done, then that'd be appreciated echelon, thanks :). -- Mason11987 (Talk - Contributions) 16:42, 2 July 2006 (PDT)
 * I think we should do both. :-P The message on form submission to stop more uncategorised images being uploaded, and the uncategorised images page to help deal with the ones which have already been uploaded. Looks quite simple to install the uncategorised images page, and thanks must go to MediaWiki (and SporeWiki) for it. :-D --DrBob (Talk) 23:00, 2 July 2006 (PDT)

Image Categories Once Again
I was thinking about how the images have been categorized and we definitely need to pick a standard. Personally, I feel that the best idea is categorize by game title and what it is. For example, a sprite from Secret of Mana could be categorized as Category:Secret of Mana sprites instead of just Category:Sprites. The reason is that if an editor was looking to insert a certain picture, they would be able to find it easier by going to the game specific category. This category will, of course, be a subcategory of Category:Sprites.

Another thing that should be taken into account is the naming of the images. I think that each image should beging with the title of the game (or a shortened version of it). Example: A zombie from Secret of Mana could be name  as opposed to just. This is important because then how do we differentiate a zombie from Secret of Mana and one from say Earthbound without this naming convention.

As always, if we adopt some sort of naming convention and categorization convention, we need to do it ASAP. It is a lot of work to go back and rename everything and we'd need to do it before many more images are added. Also, if possible, something should be placed on the upload screen to alert the editors to this convention. Thoughts?--Dukeruckley 07:23, 5 July 2006 (PDT)


 * I've been going through and categorising images, and I think the current system is fine. If a game has enough images to warrant its own category, it should get one, but its category shouldn't be tailored to a specific type of image: what if you want to put the box artwork in that category (it does, after all, belong to the game)? At present, I'm categorising images by sprite/model and character/item for characters or items, and the other categories by themselves for other images. If a game-specific category exists, I'll use it, but I'm not in a hurry to create them.
 * I do agree that we need a naming convention for images. I would agree with a shortened (initialised?) version of the game name, so a Secret of Mana image would become som_image_name.png, for example.
 * There is already a message on the upload screen asking for uploaders to categorise their images, and I was asking for some JS which checks for the presence of tags, but some more prominent and linked documentation would be good. It's on my todo list. :-) --DrBob (Talk) 09:12, 5 July 2006 (PDT)


 * I see what you're saying about the categorization. There are a few sites that do have quite a bit of images:  Secret of Mana and Earthbound come to mind (I'll be adding even more to SoM when I eventually finish that tedious bestiary).  So basically, the solution would be to use Category:Secret of Mana images for all SoM images (including boxart, sprites, etc.).  For games without a lot of images, just use the normal categories.  Should we include the normal categories for the images that are also put in a game specific category?  As for naming conventions, initialized names for the games is exactly what I mean.  som_image_name would be perfect.  The only problem then coming from games that might have the same initials.  Example:  Secret of Mana vs. Sword of Mana.--Dukeruckley 09:29, 5 July 2006 (PDT)


 * The normal categories should always be included. One of the reasons for categorising the images was so that we could have all the (for example) box artwork in one place. Concerning games with the same initials, just extend the initialisation: e.g. Secret of Mana would become seom, and Sword of Mana would become swom.
 * I'm writing some official guidelines for images. They're not finished yet, but I'll make sure they do cover everything which has been discussed here. --DrBob (Talk) 11:11, 5 July 2006 (PDT)

Image guidelines
I've finished writing the image guidelines and they're up for comment. If you've got any gripes or suggestions (particularly for things I've missed), please mention them on the talk page for the guidelines. --DrBob (Talk) 12:17, 5 July 2006 (PDT)

Control Images
I notice DrBob has been going around putting up the Needcontrols template on a lot of guides lately, with requests for controls for specific systems. As of posting, the only controller buttons are my gamecube buttons and the only page that uses them (to my knowledge) is the Super Smash Bros. Melee guide. The current buttons are fairly generic, save for the C-stick stuff and the gcube/xbox specific button colors. Because they were meant to be generic, I named them as such, like Control-up.png and A-button.png. If there are to be specific images for systems, they need to be renamed.

Another problem with the current implementation is that inserting images everywhere makes the markup look horrendous, even with the Button template. Just look at the markup for Super Smash Bros. Melee/Basics to see what I mean. If possible, there should be a away to insert buttons without generic image markup, i.e. the bold tag or the link markup in wiki markup. I don't know how easy it is to put features like this into MediaWiki, but as this is a strategy guide wiki, it would be good to put directly in the code, to keep page markup easy to understand.

One more thing: is there really a need for keyboard button images, like spacebar, tab, and WASD? If this wiki had svg support, there could be away to replace the text in an svg file with a certain letter or symbol before rendering it, but its still kind of overkill.

Well, those are my thoughts on the controller buttons. the unrendered SVG ps2 buttons are still here, if anyone wants to comment on them. --blendmaster 19:05, 6 July 2006 (PDT)


 * I agree that the png buttons are ugly when littered around the page. One thing that might help is a policy to keep pages platform-agnostic when possible--say "shoot" for instance rather than "hit (triangle button image)", then refer to a rosetta page with all the controls for each platform.  Then again, melee games really do need to list the button sequence.


 * I tried making some buttons with Unicode and CSS at Talk:Grand Theft Auto: San Andreas/Basics/Controls. I thought they looked good except for the ABXY buttons, which of course are kind of important.  DrBob pointed out that not all browsers support Unicode, and how they choose to do so is up to the browser.  That's a good point: If you saw "Hit this sequence of buttons: ? ? ? ? ?" that would be kind of frustrating!


 * Using SVG buttons would be wicked cool. The technology is only slightly less accessible than simple images -- the plugin is easily installable and has been stable since 2001.  We can use alt text in the contents of the embed element, so people who don't have/don't want SVG support can still read the page.   Even better, that alt text is HTML so we can use CSS to style that text however we want (but we should still stay way from exotic unicode glyphs).  That would give two reasonably good renditions of the page probably better looking than the current one, and preserve machine-readability. So I say go for it.


 * In terms of aesthetics, I think it's important that buttons be styled to go with the main page text. If you look at a BradyGames guide you will see that that the buttons with letters use the same font as the text, just bold.  Using different fonts tends to jar the eye a little bit. Sympleko 06:19, 7 July 2006 (PDT)


 * I can't see any problem with the PNG buttons or the markup: once sections like that are written, they're unlikely to be changed, and so it shouldn't be much of a trouble. I'm against moving controls to disambiguation pages for each platform for each game, because that means users would have to follow another link to get to what they probably want to find, which slows everything down. I'm also against new markup for buttons, as it makes upgrading MediaWiki hell due to the hassle of porting all the modifications, then fixing the bugs.
 * I'm all for SVG images. MediaWiki will automatically rasterise them to PNG unless the user has set SVG to be displayed natively in their browser, so that's OK. Using the same font as the text is fine, as it's all the same anyway (and anybody who decides to make another header template containing a custom, stylised page title will be shot). I agree that the control images should be differentiated by platform and renamed; they're not widely used yet anyway, so it won't be much of a hassle to rename them all. --DrBob (Talk) 09:18, 7 July 2006 (PDT)


 * I'm in full agreement with DrBob. I think SVG images would be a neat idea, but I don't see much of a problem with the current PNG images.  I also think that controls need to be game specific and named as such in order to create a consistent convention for when new game systems come out.  In the case of Playstation and Playstation 2 (and a few others), an exception can be made because it is the same controller (except for the addition of the analogs).--Dukeruckley 09:50, 7 July 2006 (PDT)


 * If nobody else objects, this should go ahead. Dukeruckley, do you want to handle it? :-) --DrBob (Talk) 10:16, 7 July 2006 (PDT)


 * Personally I'd prefer typing in somthing like .:left-smash:. (embedded) instead of [[Image:Gamecube-Control-Left-Smash.png||left]]  (generic), but since I'm not a great coder, I can't have much say in whether an embedded button markup is implemented or not. On SVG vs. PNG, svg images are a lot smaller(in file size), and are better at scaling to different sizes, if say the main control page had big button images, and all other pages had smaller button images. On using the same font as the text, I convert all the text in my buttons to paths, just because different SVG renderers use different default fonts, which makes the buttons look worse.
 * One thing no one talked about was the keyboard button images. Are they really neccessary? Well, I guess I'll get started on xbox and other console buttons. I'll can upload the gamecube and ps* buttons whenever the naming scheme is set. --blendmaster 16:30, 7 July 2006 (PDT)