StrategyWiki talk:Community Portal

This page is for discussion of general community issues; if you just want to ask a question to more experienced users of the site, please use the staff lounge. To start a new thread click here. Resolved threads are gradually archived; see the archives box to the right.

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)

Both have been done. --DrBob (Talk) 06:15, 23 October 2006 (CDT)

Display bug with IE
I've been noticing this and felt I should bring it up. It seems the All game Nav template is causing it too. Anyway, if you look at a page in IE that has that template, it seems it is too wide and it causes the text under it to be sort of "cut off" by the table. Any text following the headers (the 2 equal signs on either side) is okay. I'm surprised this hasn't been addressed. --Sivak 14:18, 25 July 2006 (CDT)


 * "Cut off" by which table? I've just looked at Counter-Strike: Source in IE7 beta 2 and the All Game Nav is too wide, but I'm getting no other problems with it. Could you perhaps link to a screenshot (or upload one as long as you promise to have it deleted afterwards :-P )? --DrBob (Talk) 14:29, 25 July 2006 (CDT)


 * I checked using IE6 on the EarthBound main page and I think he's talking about this: click here to see image-- Duke  Ruckley  14:54, 25 July 2006 (CDT)


 * Yeah, same here as dukeruckley. It seems the left edge of the main content has negative padding or something. But, it only happens on pages that have the All Game Nav on them, as far as I checked. I looked at an ealier revision of EarthBound without the All Game Nav, and it looked fine.--blendmaster 22:09, 25 July 2006 (CDT)


 * Ah. Are you sure this only happens on pages using All Game Nav? I'll look into it later, but it's probably a symptom of one of IE's box model problems. :-( --DrBob (Talk) 15:01, 25 July 2006 (CDT)


 * Why can't everyone just get Firefox? :p --Antaios 14:59, 25 July 2006 (CDT)


 * If only. However, we do have to support everyone. :-( --DrBob (Talk) 15:01, 25 July 2006 (CDT)


 * I put a screenshot of my own. It seems maybe the images on the left which make up the menu are overlapping somehow.  Check the area I put a red box over.  It gets "uncut" after a short way down.  click here to see image  --Sivak 09:42, 27 July 2006 (CDT)


 * I think you're probably right. I checked the same pages uses Monobook and there is no problem there, so it might be the skin itself.-- Duke  Ruckley  09:46, 27 July 2006 (CDT)
 * That's partly it (the top is a JPEG while the rest is a GIF) but that still doesn't explain IE drawing it too far to the left. GarrettTalk 22:52, 27 July 2006 (CDT)

I notice that all these comments are from several months ago, but I just starting using strategywiki and I am having the same "cut off" effect. I can't change browsers because I use public access computers, and many of the computer settings cannot be changed (someone suggested that everyone use firefox, that's not an option for me). This cut off effect appears on almost every page I view in strategywiki, and just as described earlier it seems to cut off the leftmost part of the text at the beginning of each article, but further down the text appears fine. New User 03:30, 25 October 2006 (CDT)
 * I do need to get around to fixing this, but I think I actually deleted the screenshot of the problem that somebody contributed before. Would you mind screenshotting the problem and uploading it here, making sure to put in the image description? Thanks. --DrBob (Talk) 07:06, 27 October 2006 (CDT)
 * I can't take a screenshot because I am using a public access computer. I am in a library, using the computer provided for patrons of the library.  I am limited in the choices of programs I can run on this computer, and uploading files is not allowed.  I can only describe the way it appears... it looks like this image has an area to the right of the blue borderline which is white, and that white mass of pixels is covering up a small part of the article's text.  Further down the page, below the area where this image appears as part of the border/background, the text appears as it should.  I hope that helps. New User 05:31, 30 October 2006 (CST)


 * I've taken a screenshot of the bug and uploaded it here. --aniki21 05:39, 30 October 2006 (CST)
 * Thanks. :-) I've taken a look, and -- without testing anything (hopefully this'll work) -- I've come up with something. New User, could you add the following to your user CSS?

{ margin-left: -7px; }
 * 1) centrecontent
 * --DrBob (Talk) 11:17, 30 October 2006 (CST)
 * I pasted that into the css, and it didn't change anything. New User 02:31, 31 October 2006 (CST)
 * Did you do a hard refresh? (Ctrl+F5 on Windows). GarrettTalk 03:14, 31 October 2006 (CST)
 * Yes. In fact, I am using a different terminal now and it still looks the same. New User 06:29, 31 October 2006 (CST)
 * You missed the capitalization. It has to be BlueCloud.css. -- Prod (Talk) 08:36, 31 October 2006 (CST)
 * I see. I didn't capitalize because when editing the page BlueCloud.css, a warning appears that says not to capitalize.  Now, I have pasted the above in both css and still no change in the appearance of the articles. New User 03:11, 1 November 2006 (CST)
 * Should be fixed now. :-) --DrBob (Talk) 13:16, 1 November 2006 (CST)

I just noticed another display bug. It looks like on articles with a particularly large All Game Nav template (that is, if the template is filled with custom links), the text of the links in the All Game Nave overlaps with the [show]/[hide] switch in the right-hand corner. I have only seen this on this page, because I haven't seen another article yet with such a full All Game Nav template. New User 03:39, 1 November 2006 (CST)
 * That one isn't only on IE, it's on any browser i think. Just resize your window and it will overlap.  -- Prod (Talk) 09:03, 1 November 2006 (CST)
 * Fixed. :-) --DrBob (Talk) 16:06, 1 November 2006 (CST)

New Pokedex or Partnership?
Hello everyone. I happened to notice some edits that 0-172 was making when it occurred to me that StrategyWiki does not have it's own Pokedex. And it certainly seems that among the many things StrategyWiki should have, a Pokedex should be one of them. However, it didn't take very long until I discovered Bulbapedia and I thought, how awesome is this? So I was curious what many of you felt about approaching them and seeing if we could form some sort of partnership between them and us. Essentially, they could provide all of our visitors with (well presented) Pokedex information instead of forcing us to reinvent the wheel and write something that's been written a million times before, and we could provide their visitors with the actual walkthroughs to Pokemon games. Is this something that we need? No, but I think it would be a great way to form a mutually beneficial partnership with another Wiki site (not that we need that either, I just think it would be neat to cross polinate some of the talent that we have.) OK, I'm getting off my soap box. What do you think? Procyon 20:37, 28 September 2006 (CDT)
 * Nice find :) It would be cool to have them link to SW (we always need more quality contributors ;-) ) We could link to them on all the pokemon guides (if they're that good, we should do that anywayz).  However, how would they link back to us?  I checked out the website, and I'm having a bit of trouble finding where to go. -- Prod 21:09, 28 September 2006 (CDT)


 * Hm. They already have Pokedex entries (e.g. Poliwrath), so I'm not sure they'd need or want an external Pokedex. Also they use the evil BY-NC-SA rather than the GFDL. Hm. Copying the old Wikibook Pokedex here is certainly an idea, although linking to them or Serebii is probably just as good. The MAME guide worked out pretty well so I don't really have a problem with this either way. GarrettTalk 21:40, 28 September 2006 (CDT)


 * I thought perhaps the way that it could work, is that whenever we mention a Pokemon, we externally link to them, like so:
 * "Walk out of Pallet Town until you reach the grass. If you walk around there, you will find a Rattata or a Pidgey."
 * and so on. They appear to have stubs for each of the games like Pokemon Red and Blue so perhaps we could twist their arm to point to us instead. Procyon 22:16, 28 September 2006 (CDT)


 * It's in PD at wikiknowledge so we can easily copy it here. -- Mason11987 (Talk - Contributions) 23:49, 28 September 2006 (CDT)


 * Yes, but like so many things on that site, it's ugly and presented with little care. Personally speaking, I'd rather link to a site like Bulbapedia where you know they care about the content they have, and they will keep it updated with new information since they're passionate about it.  Plus there's the possibility of attracting new talent to our site.  Procyon 08:02, 29 September 2006 (CDT)


 * Procyon makes a good point. While we could certainly have our own Pokedex, I'm kind of leaning towards linking to theirs. We can always change it in the future if something doesn't work out. What we should definitely concentrate on, though, are getting some good Pokemon guides.  ech elon  00:40, 30 September 2006 (CDT)


 * I suggest being BOLD, and making one right now, and also link to theirs "for more information" as I'd hope they'd link to us for more information on guides. -- Mason11987 (Talk - Contributions) 14:46, 8 October 2006 (CDT)
 * And I have been bold. I'll make it a list of red links soon. :)

Well, I would have appreciated a little more patience on the matter. It's not that I object to having a pokedex on StrategyWiki. By all means, if someone is willing to put in the time and effort to make one (and I mean REALLY make a GOOD one) than we should go for it. But it's it just going to be a half-assed attempt to throw something up in order to claim that we have one, then I'd rather just rely on Bulbapedia, who has done a really impressive job. Mason, really question yourself as to how dedicated you're going to be in filling out the 386+ entries that need to be filled out. Either that, or find people who you know will be dedicated to the effort. Procyon 18:42, 8 October 2006 (CDT)
 * I won't be dedicated to it. But that doesn't mean the red links won't inspire those people who will be dedicated to it.  I think the pokedex is definitly within the scope of strategywiki and therefore we should make it as obvious as possible that if someone wants to be dedicated to something like that, then can do so.  But if not that's all good to, that's what the bulbapedia links are for. -- Mason11987 (Talk - Contributions) 20:33, 8 October 2006 (CDT)

So, any news on this? Is there a partnership or not? -- Prod 19:53, 17 October 2006 (CDT)

Parser Functions
Parser extension might make some templates a bit easier to understand as its shorter than qif. I don't know enough about this stuff, but it looks interesting. -- Prod 23:15, 28 September 2006 (CDT)
 * Are these avalaible to test? --inarius 09:51, 29 September 2006 (CDT)
 * Does anyone know if there's a way to create variables and assign values to them? I wanted to do somethere where every other Special Move template shaded itself grey.  So the first one would set some variable to 1, and the next one would read it and if it was 1, shade the table row grey and set the variable to 0.  Then the next one would read it again, see that it was zero, and draw the row white, and so on.  But there doesn't seem to be any way to make your own controls like that.  Just curious.  Procyon 20:05, 29 September 2006 (CDT)

I was looking at the Mega Man 2 page which has references at the bottom. Perhaps we could get http://meta.wikimedia.org/wiki/Cite/Cite.php installed. -- Prod 10:14, 2 October 2006 (CDT)
 * ref and note already serve this purpose fairly adequately. You can see them in action in BS Zelda: Kodai no Sekiban/Cheats. GarrettTalk 14:23, 2 October 2006 (CDT)

Newbie section
It seems that this site is starting to attract larger numbers of people (it's getting tough to keep up with recent changes now) meaning a lot of new people. Many people don't know a lot about wikimarkup and need somewhere to ask questions. What I'm suggesting is some kind of Staff lounge -- Prod 11:45, 1 October 2006 (CDT)
 * Good idea! I'll see what everyone else thinks before implementing it, though. --DrBob (Talk) 13:25, 1 October 2006 (CDT)
 * Agreed, good idea. Procyon 14:58, 1 October 2006 (CDT)
 * I've implemented this as Staff lounge, and basically lifted it from Wikibooks, then changed some stuff. --DrBob (Talk) 13:00, 4 October 2006 (CDT)
 * Sweet, now we don't have to all watch your talk page :P. -- Prod 13:03, 4 October 2006 (CDT)
 * I realized that it's somewhat hard to find that page. Perhaps a link in the nav bar would be helpful. -- Prod 13:49, 9 October 2006 (CDT)

Game Categories
I searched through the archives and couldn't find anything about it, so now is as good a time as any. Should we categorize each page of a game under the game's name (or something similar). For example Category:Super Mario World or Category:Move Lists. It will help us clean up Special:Uncategorizedpages leaving only unused pages hanging around. -- Prod 16:03, 4 October 2006 (CDT)


 * I think this would be a good idea. It will have the added benifit of being able to categorize images by game in addition to the acutal image-type (which I think we should be doing). --inarius 16:20, 4 October 2006 (CDT)
 * I'm definitely against this. This would not encourage maintenance of the table of contents for a game, and thus would actually make it harder for people to find pages (tables of contents should be easier to navigate than category listings). We already have provision for categorising images by game, as you can add a "Game name images" category (note the lower-case "images"). --DrBob (Talk) 16:53, 4 October 2006 (CDT)


 * I'm with DrBob on this one. Honestly, I hate my own Move Lists category page.  I just can't think of a better way to organize it, and it's only just started.  As I and other members add more to it, it's just gonna get uglier and uglier.  That's the only aspect of the project which I'm unhappy with the results of so far.  It seems to me that most of the pages presented here on Strategy Wiki should at least fall under one single platform, unless it's a special project like the Move Lists or the MAME guide, and then I'm not sure what to do.  But I just don't know.  Personally, I think the SMW Category is a bit extraneous.  I think it should be any sub-page's author to properly add a sub-page to the parent page's Table of Contents.  Sub-pages don't need to be categorized as long as someone is doing a good job maintaining the TOC tree.  Just my $0.02 Procyon 16:58, 4 October 2006 (CDT)
 * About maintenance of the TOC page, it doesn't encourage maintenance, but it doesn't deter it either. It's just another category to add at the bottom of the page.  About images, Category:MapleStory images works fine for me, though I'd prefer it to be categorized along with the main guide.  But that's a minor issue.  I'm not too sure how it works, but it would also give a definate link for Related Changes.  I also don't see a reason to remove it if it's already there. -- Prod 17:48, 4 October 2006 (CDT)


 * I really don't see how this would discourage maintenance of the TOC. I guess the only two resources that really need categorization are pages and images. So, I can see how this might not be as useful for pages, since all pages under a particular game should be listed in the TOC, if that's the point you were making. However, I generally work on the Zelda OoT page, and when I contemplate adding even more images to that guide, I think of how big a pain it is to get a list of them, or find the resources already avaliable for that game. I think images really need to be categorized with more detail, and don't find clever/descriptive naming very helpful. Not to mention, renaming an image is more trouble than just adding a category. --inarius 14:28, 14 October 2006 (CDT)


 * I personally don't think it would hurt, but I don't think it would be very useful and mandating something like that would be near impossible and a bad place to focus our efforts. I think our efforts would be better served on a good TOC then a cat page.  Subpages in categories looks very ugly. -- Mason11987 (Talk - Contributions) 18:29, 4 October 2006 (CDT)

Search Plugin
Firefox strategywiki search plugin -- Prod 00:39, 5 October 2006 (CDT)
 * Good work! --DrBob (Talk) 00:59, 5 October 2006 (CDT)
 * Awesome! I like this very much! :)  ech elon  12:49, 6 October 2006 (CDT)

Spoilers
I've been seeing the Template:Spoilers on a few toc pages. Considering the toc is one of the first things (possibly) that the user sees, it seems somewhat...weird. I guess giving away the story by telling where the player goes, or who the bosses are is a spoiler, but how can that be avoided in the toc? -- Prod 20:15, 5 October 2006 (CDT)
 * I think any use of spoilers in the ToC is a bit of a mistake, and that it can be remedied by perhaps changing the link captions, if anything needs to be done. --DrBob (Talk) 01:06, 6 October 2006 (CDT)


 * I agree, Spoiler templates in the TOC isn't the best idea. Titles should be changed to not be as spoilerish (if possible) but as long as they are still useful to the reader who doesn't care about spoilers. -- Mason11987 (Talk - Contributions) 21:53, 7 October 2006 (CDT)

Category:Game
We have a Category:Systems, why not a Category:Game. Put all the main pages in that category (perhaps using the infobox). This way we have a proper place to classify Category:Unreleased games. More importantly, the alphabetical index can go to the game category to find games, rather than Allpages (which isn't very useful). -- Prod 20:55, 8 October 2006 (CDT)
 * I think that category would get quite unwieldy don't you? All the games can be easily found by their system.  -- Mason11987 (Talk - Contributions) 21:52, 8 October 2006 (CDT)
 * Additionally, the search feature works quite well. :-) I think such a category would be redundant. --DrBob (Talk) 00:24, 9 October 2006 (CDT)
 * I mean it as a replacement to Quick index. Motivation being, someone who wants to see what's there, maybe something random to contribute to. Whatever the reason for that quick index applies here as well. -- Prod 00:34, 9 October 2006 (CDT)
 * It is possible to over-categorize, and I think we're rather close to being on the verge of this. Categorization should never be a replacement or an alternative to organization.  The problem is that there is an arithmetically growing number of pages that appear on this site, and it's becoming more important with each passing day that the basic organization of the site be maintained.  If I were to point to a site that has a simple and effective organization, it's gamefaqs.com.  I can't think of a single instance when I failed to find what I was looking for.  While genre, release date, and game series are nice categories, CJayC has obviously determined that a majority of people search for games on a system basis, and we should emphasize our own system selection as a way to introduce new and old users alike to the pages they are looking for. Procyon 09:14, 9 October 2006 (CDT)
 * The way I see it, there are a few basic "types" of pages (excluding subpages). System and Company are already taken, which leaves Game.  They are exclusive categories where things would only be in one.  It wouldn't be much of a problem to add the category to every main page of every game (just include the cat in the infobox template, which should be on every page). -- Prod 09:55, 9 October 2006 (CDT)
 * I dunno, I guess I'm just not understanding your fundamental drive to categorize the one specialty that this site focuses on. When would it ever be unclear to a reader that a game is... a game?  And not that I'm trying to poke holes in your design, but what categories do pages like the MAME guide and the Move Lists fall under?  Clearly not system, company, or game.  Procyon 10:36, 9 October 2006 (CDT)
 * Well, its not for classifying that a game is a game, its for saying that "here's a list of all games". Mame guide should go under systems (or nowhere as it would be a sub page of the systems guide).  Move lists is kinda weird....I guess it could get its own category (which it has).  Essentially, games are what this site focuses on, but how to filter out only the main pages to see which guides we actually have. -- Prod 11:13, 9 October 2006 (CDT)
 * Actually Prod's idea of putting it in the infobox seems exceptionally unobtrusive, and I think it doesn't hurt anything at all. Just throw it in the infobox, then leave cat:game as a top-level cat with cat:systems cat:companies  and cat:genres.  My comment about it being "unwieldy" applied because it would be hard to tag every game, but since it's reasonable and efficient to have an infobox on only the main page of every guide, then this is a perfect way of incorporating it.  I think this addresses Procyon's concerns in that it isn't a replacement or an alternative to organization, it's simply 4 extra letters at the bottom of every page, and it can be done in 15 seconds.  Then we have an easily accessible list of every game, alphabetically.  It sounds quite elegant now that he pointed out the infobox option. -- Mason11987 (Talk - Contributions) 21:49, 9 October 2006 (CDT)
 * Look, I'm not stopping anybody. If you guys are genuinely convinced that it's a good idea then go for it.  I'm not there yet, but I'm not the law of the land around here either.  If Echelon was against the idea (not that I think that he is, I'm just saying hypothetically), then I would say you clearly shouldn't do it.  But I doubt that he would object in this case, so feel free.  I would just like to continue to investigate methods that could improve navigation around the site as I don't think Cat:Game is going to be the solution. Procyon 22:07, 9 October 2006 (CDT)
 * I know you aren't. But discussion normally comes out with the best solutions, and I think throwing Cat:Games in, while still working on very efficient and good navigation (with or without cats) is the best idea.  If I had to add cat:games to every page then it would take away from other, more meaningful efforts, but I just did it so no more spending time on it.  If anyone has a problem with it then we can figure out what would be the best option from then on. -- Mason11987 (Talk - Contributions) 22:27, 9 October 2006 (CDT)
 * After doing it, even it if isn't really "useful" it's kind of cool. Category:Games. :D -- Mason11987 (Talk - Contributions) 22:36, 9 October 2006 (CDT)
 * Even I have to admit that I agree with you Mason, it does look kind of cool. Especially the mix of classic titles with modern titles.  Great job.  Procyon 09:22, 10 October 2006 (CDT)
 * Nice! I didn't realize we had that many guides on the site....320 according to that. Wow.  (definition of "guides" being relative :P). On a related topic, I've been on a lot of forums, and its awesome to have civil discussions like this, which is one of the main reasons I like this site.  -- Prod 23:30, 9 October 2006 (CDT)

I've added this category to All Game Nav's num= value as well. It will take a while for pages to begin appearing in the category, but it will ensure as many pages as possible are caught. GarrettTalk 05:20, 10 October 2006 (CDT)
 * And then we can see which subpages have that num property (which they shouldn't).

One page guides and navs
I noticed that there has been a particular push recently to add game navs to all game pages. It seems like this policy is being enforced whether the page really needs a game nav or not. There are going to be a few games on this site whose depth is so minimal that one page is going to be sufficient to cover the entire game. I can't imagine in this case that a nav is required to "navigate" the one page, which is in essense the introduction, table of contents, and walkthrough. Can we ease up on this? Procyon 15:07, 10 October 2006 (CDT)
 * It occurred to me that Garrett may have added this to Pinball in order to have a stage completion assigned to the page. I've gone ahead and added the stage completion category to the bottom of the page since it accomplishes the same thing.  Was this the only reason or was there something else? Procyon 15:13, 10 October 2006 (CDT)
 * I think all game navs should be on every page for standardisation's sake. As a web designer, I know that people get confused if the means of navigation changes from page to page, and if all game navs are appearing and disappearing willy-nilly, it doesn't help. Additionally, we rely on them for categorisation such as Category:Game and the "num" categories, and it would be self-defeating to add those categories manually (because if, for example, we decided to change/remove those categories, we'd have to additionally go to every page which references it manually, instead of just the all game nav). Another thing is that I can't quite believe that one page will cover a game completely. Every game must have something more than can be said on one page, so sub-paging would be necessary, and so would an all game nav. --DrBob (Talk) 15:34, 10 October 2006 (CDT)
 * Then I must propose that we add conditionals to the Template so that it will dynamically appear properly for games that have a TOC and games that do not. I think it looks horrible with a red TOC and Walkthrough link when they are clearly vestigial.  I'll see what I can do myself.  I'm just not sure how I'm going to do it without breaking the existing ones.  Procyon 16:10, 10 October 2006 (CDT)
 * Well, I've astounded myself by making a revision to a template work on the very first try. Now that I can apply the onepage variable to the nav, I'm satisfied.  It just did not seem like an acceptable solution to force links to appear that were never going to be created.  Procyon 16:25, 10 October 2006 (CDT)
 * Color me converted, I've just gone ahead and created a Template:Fighting Game Nav and a Template:Move Lists Nav, and it's beautiful because it solves the whole problem I had trying to figure out how to solidify the link between the game article and it's corresponding move list. So now problem solved.  The only problem I have remaining is the character set lists, as I don't have a good solution for a nav for those right now.  Something will come to me eventually.  Procyon 17:02, 10 October 2006 (CDT)
 * All game nav can be tweaked to not have the show/hide thing too, if that's what people want. I can work on it. -- Mason11987 (Talk - Contributions) 19:05, 10 October 2006 (CDT)

Categorizing Japanese names as well as American and European names
Garrett and I have been butting heads as of late, and I really don't mean to Garrett. For that, I apologize, but this issue is something I feel quite strongly about. Consider Samurai Shodown. That is how this game is known outside of Japan. In Japan, it's known as Samurai Spirits and as you can see, that title is linked to a redirect to the non-Japanese title. This is all well and good. However, the Samurai Spirits page also contains categorizations. The same categorizations (if applicable) as the Samurai Shodown page. Thus if you were to look in Category:Arcade, you would see both Samurai Shodown and Samurai Spirits listed. In my opinion, this is intentional. I feel it should be done this way for the sake of those who only know the game as Samurai Spirits and not as Samurai Shodown. This way if they navigate to the Arcade category, they will find the Spirits title and proceed to click on it, ultimately being redirected to the Shodown title. I've been following this practice with several games now, such as Street Fighter Alpha/Street Fighter Zero, and Dragon Warrior/Dragon Quest. I feel it's important to allow categorization of alternate titles so that they may be found by those who only know games by said alternate title. If people agree, we should set this as policy. If people disagree, please discuss it here. Procyon 19:25, 10 October 2006 (CDT)

I apologize again, but I have a good example to back up my own argument. Dragon Quest I & II appeared on both the Super Famicom and the Game Boy Color in Japan, but Dragon Warrior I & II only appeared on the GBC outside of Japan. Therefore, while both DQ1&2 and DW1&2 appear in the GBC category, only DQ1&2 appears in the SNES category. And it would not be appropriate to list DW1&2 under the SNES, now for two reasons instead of just one. First and again, if a person only knew the game as Dragon Quest and not as Dragon Warrior, they won't find the game they are looking for under the SNES category. And second, another person will be misinformed if they see DW1&2 listed under the SNES category, believe that it was released with that title for the system when in fact it did not. I'm merely concerned with reporting this knowledge accurately. Finally, using the Street Fighter Alpha/Zero example for illustration, listing both titles is exactly what gamefaqs.com does. (Same goes for Samurai Shodown/Spirits in that first link.) Procyon 19:38, 10 October 2006 (CDT)
 * I don't see any harm in having two correctly spelled titles for a game categorized together. Obviously one should redirect to the other, but having them there would be useful.  Is there a downside to this?  I doubt the issue is frequent enough to create over population of cats (not like that's a bad thing), and it would help navigation.  One of those things that isn't really necessary but it's a nice touch.  The only problem I see is the redirect not getting included in all the categories as the regular as we progress.  That may or may not be an issue. -- Mason11987 (Talk - Contributions) 22:00, 10 October 2006 (CDT)
 * I was thinking this was artificially raising the Category:Games totals, but it isn't, so that objection is removed. I'm not so sure about moving cats to the redirect, though; people might faithfully add the "missing" SNES cats to the main page. Also, those who find out there is "another Dragon Warrior game" on the SNES may well look for it under the English name. Similarly, if for some reason a fan translation exists people will be looking under the Anglicised name. I'm not opposed to the idea, though, it's just I'm wondering what the best way to handle the "missing cats" is. GarrettTalk 23:06, 10 October 2006 (CDT)
 * Well, the way I see it, if people have the forward thinking to realize there is another spelling, then they can duplicate the cats. If noone realizes it, then no harm done.  -- Mason11987 (Talk - Contributions) 23:20, 10 October 2006 (CDT)
 * I see. Yeah, that makes sense. If people keep wrongly catting a page a comment could be left telling them not to. I'm all for this idea now. :) GarrettTalk 23:24, 10 October 2006 (CDT)

Split the PC category?
I've thought this on and off for a while now. DOS is significantly different from Windows, and Vista-exclusive games (e.g. Halo 2) appear to be creating yet another division. Plus, some games have had DOS and Windows versions.

To me, listing these all as PC would be like putting Game Boy B&W, Color and Advance games together just because they can all run on the newest of the three. Plus it's a bit of a misnomer; although Windows is the most common, a "PC" could just as easily be running Linux or even OS X.

Therefore I'm proposing three categories: DOS, Windows, and Vista. Thoughts? GarrettTalk 22:46, 12 October 2006 (CDT)
 * Well, no one makes games for linux :P (none that really count at least), and Mac has its own category already. I have a problem separating Vista from Windows, cause technically it is Windows Vista, but thats irrelevant.  The thing with PC games, is that if you can't run it, you can (theoretically) upgrade your computer (there is no way my 10 year old comp will run vista, let alone Halo 2 :P).  With consoles, you have to buy everything new.  I'm always for categories (so I support you on that basis), but this info is already stated under system requirements (at least it should be), and it would be something someone looks at after they have decided to get the game. Essentially, take this as a null vote >.>.-- Prod 23:13, 12 October 2006 (CDT)
 * Actually, we already have a Linux category (with a couple of games in it). I'm in favour of splitting the PC up into categories which don't share compatibility, so it would probably be best to have MS-DOS, Windows 9x, Windows NT and Windows Vista, splitting them by kernel architecture. --DrBob (Talk) 00:58, 13 October 2006 (CDT)
 * I support everything DrBob just said :). -- Mason11987 (Talk - Contributions) 09:26, 13 October 2006 (CDT)
 * I've noticed the new categories created. Might I suggest leaving it in the PC category, while adding the other categories. -- Prod 13:05, 13 October 2006 (CDT)
 * I wouldn't agree with that. The new categories are already in the PC category, so if somebody's looking for a PC game, it's a simple matter of looking in one of the sub-categories, instead of the PC category itself. --DrBob (Talk) 13:12, 13 October 2006 (CDT)
 * But should cat:vista be a subcat of cat:pc AND a subcat of cat:systems? Or just the former? -- Mason11987 (Talk - Contributions) 13:25, 13 October 2006 (CDT)
 * Vista isn't a technically a system, I'd say just PC. -- Prod 13:29, 13 October 2006 (CDT)
 * What if the person searching doesn't know which system it's for. Most games are typically forward compatible, ie. they can be played on their system as well as any newer one.  Would that mean they are in all the categories or just one (say dos). -- Prod 13:28, 13 October 2006 (CDT)
 * LOL! Isn't that that cat:Games is for?  ^_^; Procyon 13:38, 13 October 2006 (CDT)
 * That's a could point actually, games should belong in PC as well as in all kernel architectures (DOS, windows 9x, windows NT, vista) that they work in. -- Mason11987 (Talk - Contributions) 13:42, 13 October 2006 (CDT)
 * As I said before, I believe that would just be overcategorisation. --DrBob (Talk) 13:52, 13 October 2006 (CDT)

I've split it and recategorised all the articles which were in the PC category. :-) --DrBob (Talk) 07:58, 14 October 2006 (CDT)
 * Do we categorise with the earliest which can handle the game, or the latest? -- Prod (Talk) 09:28, 1 November 2006 (CST)
 * The earliest for which the game was released, as we do with consoles :-) --DrBob (Talk) 11:10, 1 November 2006 (CST)

Template:Welcome
I set up a basic welcome template I took from my design at SporeWiki. What I normally do is when I see red talk links I just do on their talk page to show them that they are welcome and appreciated. I think it's kind of cool and helps keep people hanging around to help out. I put in a few links I thought were useful but definitely add to it if you like. -- Mason11987 (Talk - Contributions) 09:42, 13 October 2006 (CDT)
 * Template:StrategyWiki welcome. -- Prod 09:44, 13 October 2006 (CDT)
 * ...grrr, thanks. -- Mason11987 (Talk - Contributions) 09:45, 13 October 2006 (CDT)
 * what do you think of my changes then? -- Mason11987 (Talk - Contributions) 09:49, 13 October 2006 (CDT)
 * Looks good :D. I'm just glad Template:Welcome redirects to it, cause I keep forgetting what the name of that template is :P. -- Prod 09:53, 13 October 2006 (CDT)
 * And that's the reason why I made a new one. 11:15, 13 October 2006 (CDT)

Image:Future icon.png
can someone with some decent graphics skills make this? Either a clock or calender or something. -- Mason11987 (Talk - Contributions) 12:49, 14 October 2006 (CDT)
 * It's used here: future -- Mason11987 (Talk - Contributions) 12:49, 14 October 2006 (CDT)
 * Done, but I pinched it from the Tango Project (it's allowed). --DrBob (Talk) 13:05, 14 October 2006 (CDT)
 * Very cool, nice pinch. -- Mason11987 (Talk - Contributions) 13:18, 14 October 2006 (CDT)

ESRB
Template:ESRB, used on Guild Wars (check the infobox). Comments?. -- Prod 14:55, 14 October 2006 (CDT)
 * Looks good. The "ESRB:" part could probably be in the template as well. GarrettTalk 15:50, 14 October 2006 (CDT)
 * Done. I'll go ahead and make the others. -- Prod 16:10, 14 October 2006 (CDT)

Should I set these up for some of the other rating systems? -- Prod 16:06, 15 October 2006 (CDT)
 * Go right ahead. --DrBob (Talk) 16:25, 15 October 2006 (CDT)

I think I've gotten all the important ones at Category:Content rating systems (check what links to them). Use them with Infobox. God of War seems to have quite a few examples on it. RSAC is weird since it has three variables. I had to split it into RSACV, RSACS and RSACL. The other confusing are CERO and OFLC since they changed their ratings schemes. The new rating schemes are accessed with the regular acronym, the old one has old at the end of the acronym. The new CERO was only implemented this March, so most older games use the older CERO old parameter. Options are mentioned on the infobox template. -- Prod (Talk) 22:30, 7 November 2006 (CST)
 * These are looking very nice. Great work! --inarius(T) 01:13, 8 November 2006 (CST)

Requested guides
Needs cleanup, but here's a starting point. Requested guides. -- Prod 15:39, 14 October 2006 (CDT)

Large, frequent project tags
Okay...I've brought this up to specific people in the past, but I figured with a growing userbase, and some more time to look around at some of the changes here this would be worthwhile to bring up again. My biggest reason for brinigng this up again was due to a version of the Spore article that I started up, as well as thinking about one of the perfectly reasonable arguments against having many "starter pages". First of all, lets examine the Spore version I just had. Compare that with the version where I changed two of the large project boxes to text versions UNDERNEATH the article here. I also added the article text so you could see what it would look like if that was the case. I'm just curious, after seeing that, am I the only one who sees a pretty obvious change being necessary here? My hope is that the average user who comes to strategywiki will come here in order to look for information. If all of us actually believe that, then tagging an articles with large signs that don't really pertain to the READER is an easy way to make our more modest articles look laughable. Having stub tags at the bottom doesn't mean people won't contribute to a page, as can be seen by looking at wikipedia. There are certain tags which should be at the top of the page which are very pertinent to the reader, such as the "future game" article. I don't see why the average reader needs to know that the page needs to be categorized or fleshed out. If they have information to flesh it out, then they will see the tag at the bottom of the page and will add something, or they just will add somethign because there is an edit tab at the top of every page. I realize this is a big change, but I think it would be for the best, so what does everyone think? -- Mason11987 (Talk - Contributions) 10:21, 15 October 2006 (CDT)
 * I know I've argued against this in the past, but you put a good argument, and I think it's probably the right thing to do. However, I think stub should remain as it currently is, as users should know that what they're reading isn't complete. I'm inclined to say the same for wip, but I could sway either way. Regardless, I would definitely agree that things like cleanup and needcat should be minimised, as it were. :-) --DrBob (Talk) 10:33, 15 October 2006 (CDT)
 * Sweet, I'm not even an admin and I got a personalized message :D. Anywayz, what you've made looks nice and I'm all for it.  Another suggestion would be to have this kind of stuff in the skin.  Have a "developer" skin or something where these templates show up at the top (or not at all, as the category is far more useful), and the default skin has them minimized at the bottom.  Another possibility is a "needs improvement" template which simply lists what needs to be changed in one box rather than a box for each.  Just giving some other options, though I think yours is the easiest (well, except for the skin one, cause I wouldn't have to do anything for that :P). -- Prod 10:49, 15 October 2006 (CDT)
 * The skin idea sounds VERY good, although not being a skin maker I'm not sure how it would work. I don't really think it's a huge issue though.  IN response to DrBob, I think wip  would be fine as a top of the page box as long as it was the only such box.  I don't see why any other message is required at the top of a page that says wip.  Doesn't that say it all? Categorized of course would still be used, but a wip and a stub tag?  and a needs cat tag?  I don't know if it's been done, but I wouldn't be surprised, that's about half of my screen vertically, and I really don't want that to occur. -- Mason11987 (Talk - Contributions) 10:54, 15 October 2006 (CDT)
 * My understanding of Wip and Stub is that stub is for pages that are just starting out, wip is for longer pages which are currently being edited (ie during the previous/next week or two), meaning that both should never be on the same page. -- Prod 10:58, 15 October 2006 (CDT)
 * This skin idea is a very very very good one, and I like it so much I'm implementing it right now. :-D --DrBob (Talk) 11:12, 15 October 2006 (CDT)
 * Sweet, sadly (?) I use monobook style, is this going to look like bluecloud? -- Mason11987 (Talk - Contributions) 11:17, 15 October 2006 (CDT)
 * Also, will this allow a box to be at the bottom for those who don't use the "dev" skin, and at the top for those who do? -- Mason11987 (Talk - Contributions) 11:18, 15 October 2006 (CDT)
 * I'll make it so that the boxes don't appear for users who haven't got a special user CSS file (I'll tell you about it later, once I've got it sorted). It should work on all skins. --DrBob (Talk) 11:21, 15 October 2006 (CDT)
 * I do still think that having a text tag about certain properties of a page is useful, and so I hope this can be arranged in some manner. -- Mason11987 (Talk - Contributions) 11:27, 15 October 2006 (CDT)
 * I've done all I can, but since user CSS seems to be disabled, I can't actually make them appear again. :-P I might have a go at moving things to the bottom. --DrBob (Talk) 12:02, 15 October 2006 (CDT)
 * icons in the header is another possibility. GarrettTalk 20:08, 15 October 2006 (CDT)
 * I'm going to get on this tonight when I return from college. I'm also planning on giving DrBob access to the ftp and database, since he's already got it for Abxy and as these are on the same machine there's no reason for him not to.  ech elon  13:12, 17 October 2006 (CDT)
 * I thought about suggesting icons in the header, but if your icon's work anything like Wikipedia's, then they are significantly less accessible then the current toolbox solution, and the toolbox would allow for slightly longer descriptions per article tag as shown in my example below. Also, I want to point out that I don't really prefer either of these solutions to just some plain text at the bottom of the article, even if it has to be placed there somewhat manually. If we start using these tags, I think we might continually be tempted to go overboard with them, and place things which all potential-editors should see into a substantially less readible place. For example, if any pages were to evetually be protected, that would be a great use of the article tags. Only people who know enough to visit a discussion page and request unprotection (or administrators) will give a hoot that an article is protected. However, and  tags are most useful as an attractor to encourage more participation in expanding an article, which should should be as simple to read/understand as possible without detracting from the flow of the article. --inarius 15:14, 17 October 2006 (CDT)

I think just having them at the bottom will allow those who would be looking for them (us) see them, and also those who are new here who love a game will see them too, as long as the cat is still included I think they're fine just being at the bottom. -- Mason11987 (Talk - Contributions) 21:37, 15 October 2006 (CDT)
 * The problem with that is that it would entail moving all the current tags to the bottom, as it isn't possible with CSS. I think the best way is just to have the boxes hidden for normal users, and people who want to see them can, by adding something to their user CSS (once I've got it sorted). --DrBob (Talk) 10:50, 16 October 2006 (CDT)
 * I think hiding them by default is a really bad idea. I agree with the premise of Mason11987's proposal. But while this website should first and foremost exist as a resource (Strategy Guide) to be read by unsers here for that purpose, it should also strive to be trivially easy to contribute to, and encourage users to do so. --inarius 16:31, 16 October 2006 (CDT)
 * That's definitly true, then text tags would be best? Since that basic idea has been supported I'm going to make some changes to go to that.  If further improvements are wanted, we can work on it, but I think text labels at the bottom of the pages is the best thing for everyone.  -- Mason11987 (Talk - Contributions) 21:24, 16 October 2006 (CDT)
 * I've already explained why having them at the bottom is a bad and impractical idea, but I can easily make them show up for all users in a less obtrusive form. --DrBob (Talk) 00:46, 17 October 2006 (CDT)
 * I'm sorry if I missed it, but where have you? -- Mason11987 (Talk - Contributions) 02:00, 17 October 2006 (CDT)
 * I couldn't find it either, unless he said it on another page. I can't personally see why some being at the top and others at the bottom is a huge problem; we can't stop changing things just because previous uses would be wrong. GarrettTalk 04:37, 17 October 2006 (CDT)
 * "The problem with that is that it would entail moving all the current tags to the bottom, as it isn't possible with CSS. I think the best way is just to have the boxes hidden for normal users, and people who want to see them can, by adding something to their user CSS (once I've got it sorted).", but Garrett makes a cogent point. Regardless, I'm still against having them at the bottom, as that means that people who have got them displayed could easily miss them. --DrBob (Talk) 11:02, 17 October 2006 (CDT)
 * What about putting it in the rightsidebar? That space is wasted on most pages anyway, and it should be possible through css. -- Prod 11:41, 17 October 2006 (CDT)
 * Correct, it's not possible with CSS, but there are so many style-layouts, I wouldn't support approaching this with CSS anyway. As others have mentioned, I think it would be best, to encourage that these templates be manually placed at the end of the article instead of the beggining. Such behaviour could be outlined in StrategyWiki style/layout manuals (i.e. placing the actual template tag after all page content). There is no overwhelming need for a technical solution that will solve alll problems here. Also, as Prod mentions, placing these ion the Toolbox is not a terrible idea. Again, attention would have to be given to how this appears on other skins - and to conserve screen space, I would suggest no more than a simple icon and 1-2 words describing each template. However, this approach would be best suited for article status that almost no readers would be concerned with (i.e. if an article is protected from editing). Here's how it might look:

 Article Tags
 * [[Image:stub_icon.png|25px|left|This article is a stub]] stub


 * --inarius 12:59, 17 October 2006 (CDT)
 * I like that ^. That seems to solve every problem, eveyone will notice it, but it won't cause distraction from the article itself, and it's original too, so we don't look like wikipedia.  Doing this we can manage to keep most of the project stuff off of article pages, which in my opinion is always an improvement. -- Mason11987 (Talk - Contributions) 13:13, 17 October 2006 (CDT)
 * Looks good. However, it should probably have a short blurb about what it means.  Stub is not very descriptive (for a newbie). -- Prod 13:20, 17 October 2006 (CDT)
 * Looks great! As for a description, perhaps that could be given when the icon is moused over. There's a problem though: check out Sandbox. I've inserted two separate sidebars there (simulating how the actual templates would act) and on BlueCloud only the first one shows up (in Monobook both appear but are messed up). So I suppose this would still mean going through all the pages to change things. Another way would be to create a new style where classes determine the vertical position (thus theoretically preventing overlap); this would mean there would be gaps where the templates that haven't been applied go, but it would mean no pages need to be changed. GarrettTalk 14:42, 17 October 2006 (CDT)
 * It does have a description on mouse-over (for the image). The image caption text is stored as the Alt and Title text, so when that code I wrote is placed on a page, the icon has the mouse over text This article is a stub. As for the Toolbox stuff, there's several ways it could be approached. First, the way that content is currently added to the toolbox is not ideal. Evventually, we will probably want a sort of :, which creates the div box and adds whatever content is specified (like the sidebar does currently). This could then be expanded into a more general :, which takes a set of predefined tag names, and adds all of them and their respective templates. --inarius 15:32, 17 October 2006 (CDT)
 * Another change which should make using the Toolbox easier would be to alter the JS function domNavToc to append any .nav_toc classed elements to #nav_right instead of only a single #nav_toc element id. This would open up the possibility of adding inline-content to the Toolbox with seperate top and bottom templates, like is done in Template:Userboxtop. --inarius 18:42, 17 October 2006 (CDT)

.
Here's another edit tag as this discussion is getting long. I'm somewhat against the mini icons. They're small and easily overlooked. The problem with the Template:Toolbox, is that it would require editing onto every page, and it would be fairly confusing for newbies who want to tag pages. This might require JavaScript or something >.>. -- Prod 15:51, 17 October 2006 (CDT)
 * I really like the look and the concept of using the above design, and I think the benefits would far outweigh the problems. Users who have no concept of what these things mean are left unobstructed and oblivious, while more experienced editors know what they are immediately. The problem with this solution is that it must be elegant, expandable and easily adopted for change (for the future may hold future uses for the sidebar as well!), and cross-browser compliant. Finally, there is the ultimate problem that this will only work on the BlueCloud skin--those who use other skins must have a viable alternative to the BlueCloud sidebar. Maybe some Javascript DOM manipulation could work?  ech elon  15:57, 17 October 2006 (CDT)
 * I made Monobook compatible with the sidenav months ago. The other skins don't support most of MediaWiki's more recent tweaks, so us not supporting them won't harm things much. GarrettTalk 17:57, 17 October 2006 (CDT)
 * How about just making the templates smaller? -- Prod 15:57, 17 October 2006 (CDT)

Wip Wip This!!!
 * This is ridiculous. We're descending into flights of fancy which would require several hours worth of laborious labour to change all the templates, making everything a lot more complicated, or otherwise requiring hideous CSS which would not work properly and just act as a house of cards with a big sign in front of it saying "take a leaf blower to me". I think the original idea of just hiding maintainance-type templates from the general public is the best, the simplest, and can be implemented as soon as user CSS is enabled. Keep a level head all of you, please. >:-( --DrBob (Talk) 16:08, 17 October 2006 (CDT)
 * User CSS can probably be enabled right now if you add the appropriate @import to MediaWiki:BlueCloud.css. A bit of a hackjob, sure, but it worked when I added MediaWiki:Common.css compatibility that way. GarrettTalk 17:57, 17 October 2006 (CDT)
 * Actually, am I right in thinking nav_toc could be forked into multiple versions that each places the sidenav item in its own predefined space? I'm not too handy with CSS, but if I'm right that wouldn't require any further work. Plus, as I mentioned above nav_toc is fully compatible with both BlueCloud and Monobook, and the other skins are largely abandoned anyway. GarrettTalk 18:02, 17 October 2006 (CDT)


 * Moving a template tag, or changing one tag to another won't be as laborious as you seem to imply, although yes, it might take hours of work. However, I could never see myself agreeing to hiding these templates from the general public. Editors would have to be fully aware that there are hidden tags in order to enable them, which makes then more-or-less useless to the average user. I mentioned above, I belive the foremost purpose of these tempalates to be to encourage new or innactive users to contribute to an article. They shouldn't distract a reader, but there is no sensible reason to hide them. --inarius 18:53, 17 October 2006 (CDT)
 * I have to disagree, the CSS thing is a nice touch, but if it can't work perfectly, then it shouldn't happen. I am quite against hiding the templates.  I still think it would be best to have stub templates at the bottom of the pages (and considering category:stubs is a mere 198 pages, I would do it myself if there was community support).  The small amount of time it would take to moving a template message in 198 pages is definitly worth it when all of those pages won't have inch/half-inch bold bars distracting from their content.  Although hiding those bars is sounding like a worse and worse idea.  I'd like people to know those pages are stubs, but I'd like them to first notice what the pages already have (specifically they should see the page, then notice that we have suggested there is more to add, not vice-versa, as is currently the case).  -- Mason11987 (Talk - Contributions) 19:11, 17 October 2006 (CDT)
 * My mistake, there is near 350, still not worth leaving as is. -- Mason11987 (Talk - Contributions) 19:13, 17 October 2006 (CDT)

The Options
Since this discussion is a bit unwieldy, I think it would be best to consolidate the avalaible solutions to this problem.

The Problem: Having too many non-informational template boxes can serve to distract readers from the article.

The Solutions:
 * 1) Do nothing : It seems that there is a majority consensus that some change in the current standard should be adopted, even if the changes are not immediately implemented on all pages.
 * 2) Move to bottom: Include such template boxes below all article content.
 * 3) Text at bottom: Change to text-based templates wherever possible, and include them after all article content.
 * 4) Icons in header: Modify each template to place a small (~20px) icon in the header. Works in everything but classic.
 * 5) Icons in toolbox: Create a template to facilitate placing marginally larger icons/descriptions in the Toolbox.
 * 6) Shrink templates: Make all the templates smaller/stackable to take up a minimum of screen real estate
 * 7) Hide templates from normal users: Hide the cleanup and improvement templates (but not things like stub) from normal users, and have them shown to users who want to see them, via some user CSS.

DrBob, please add a small description of your proposal. I don't think I would understand it well enough to do it myself.

As for my preference, I find number five, my own suggestion, to be the most attractive one (I guess I'm vain), but I still see no reason to complicate and hide these templates more than already accomplished in number three. At this point, I would recommend implementing three as a policy for future articles, and modifying existing articles as they are encountered. --inarius 19:24, 17 October 2006 (CDT)
 * I've added #6 as that would only entail changing the templates themselves (no need to stick with wikipedia). They could either be at the top and just "magically?" shrink as more boxes are added (this is probably hard to do).  Or they can work like userboxes and just stack under the infobox (on main pages) or under the AGN everywhere else..  I'm somewhat against #2,3,4 because they're way too easy to overlook.  The image one I'm really against, people have to learn what each image means, which a newbie would never be inclined to do ("This page has nothing...but look at the pretty icons" -> *leaves*). -- Prod 19:41, 17 October 2006 (CDT)
 * 5 is my definite favourite. Other than the CSS issues (which I'm pretty sure aren't all that major) it's clean and unobtrusive, and makes good use of the sidebar's mass of whitespace. We'd also have to move templates like Template:Final Fantasy VII/Nav down far enough that they don't conflict (or just get rid of them altogether). GarrettTalk 20:25, 17 October 2006 (CDT)
 * Well, the two concerns are A that people who might like to/need to see those templates need to, and B it needs to allow that while not distracting. I believe #2 is better, but is still distracting, #3 (as I suggested) would solve both problems.  I realize we don't have to be like wikipedia, but a lot of their ideas are really good ones, and our general goal isn't terribly far away from theirs.  #4 fails A in my opinion, #5 COULD, and a stub icon, and text such as "Stub - Add to this guide!" would be sufficient and solve both problems.  #6 may work though.  Ultimatly I think #3 is a great solution, and #5 if implemented correctly and without errors, would be the absolute best! -- Mason11987 (Talk - Contributions) 21:21, 17 October 2006 (CDT)
 * I had a quick look at the CSS/JS #5 would need. It's very straightforward. All that's required is variations of nav_right with unique vertical positioning, and then similarly dupe the JS to move it to the right. Plus it works perfectly in both BlueCloud and Monobook (other skins could be made compatible too). I might have a go at this tonight. GarrettTalk 21:48, 17 October 2006 (CDT)
 * Yes, I know that these changes would not be a big deal. Both the JS and the templates could be made quite straight-forward. --inarius 01:47, 18 October 2006 (CDT)

Out of the options available, I'd have to firmly go with number six, or number seven. Number two would make the templates less visible for everybody, and that can't be good. Number three is just a variation on that theme. Number four would make them easily missable, and the CSS would be hacky. Number five requires the use of Javascript and CSS to rejumble the page, which is never a good idea, especially for such a petty thing, but number six does make the templates less visible for those who aren't looking for them, while keeping them in a prominent place for those who are (as does number seven). --DrBob (Talk) 01:23, 18 October 2006 (CDT) If anybody wants to use my proposal of hiding needcat, cleanup, etc. templates from normal users, and wants to see the templates themselves, just add .developer_header_box{display:block;} to your user CSS file (for example). --DrBob (Talk) 01:37, 18 October 2006 (CDT)


 * Why deliberately hide anything? I think I have pointed out on occasion that I am very much against this. The greatest level of hiding I have suggested has been the article tagging, which is less extreme than any other suggestions to remove the templates from the article content. Anything that we don't want to be less visible, by all means, can be left in the article. Could others weigh in on this? I'd like to know how everyone feels about the prospect of hiding templates. --inarius 02:01, 18 October 2006 (CDT)
 * Why not run an average PC with the cover off? It reduces confusion if "behind-the-scenes" templates like cleanup are hidden. I'm not suggesting we remove the templates, I'm just suggesting they're hidden. If users want to help out, they'll edit regardless of the article tagging, and they could look at the maintenance categories. If they really want to help, all they have to do is edit their user CSS page. It's not hard. --DrBob (Talk) 11:10, 18 October 2006 (CDT)
 * I would go for the text at the top if that was the most agreed upon solution, because they need to be seen by everyone. But garret says he can get it in the sidebar, which would allow it to be easily seen and still not a distraction from the page, after all we are throwing TOCs overthere, people will notice it.  If Garret can do it, I see no reason to not use the toolbox icons, if it works, solves every problem and (as a pleasant bonus) keeps us from having to move templates, we should do it.  If someone is willing enough to modify their user css so that they can see stub templates, then they can more easily be told "hey, look to the right".  -- Mason11987 (Talk - Contributions) 09:23, 18 October 2006 (CDT)
 * Thinking about it some more, putting them in the toolbox would be OK, as I now realise that we're using JS to move the DOM structure around (which is hacky, but acceptable, and much more workable than the CSS equivalent, which would be terrible). I would like to point out that with my suggestion (and perhaps with every suggestion), stub templates would/should remain as they are currently. --DrBob (Talk) 11:10, 18 October 2006 (CDT)
 * Yes, I may have confused things by using the stub template as my example article tag. I also pointed out that was too extreme as stub templates should be readily visible. Other templates make considerably more sense to obscure. However I don't see any harm to placing the stub template below the article contents. I think the first thing on almost any article should be the actual article. -- inarius(T) 11:23, 18 October 2006 (CDT)
 * I resolutely think the stub template should stay at the top. Users need to know that a page is only a stub (it encourages them to edit), and it's a lot cleaner up there. Lower down in the page, its position would be complicated by float issues. --DrBob (Talk) 11:28, 18 October 2006 (CDT)
 * I can write templates to use the sidebar this evening. I can also provide the Javascript if necessary, but of course, I can't implement it. -- inarius(T) 11:17, 18 October 2006 (CDT)

Toolbox Javascript
Before I dive into editing BlueCloud.js, I wanted to pass the JS changes and proposed Toolbox structure by some more experienced editors. I've never edited built-in Wiki Javascript before -- but I am fairly experienced with JS in general.

To test the changes, you must:
 * Place the code at Sandbox/BlueCloud.js in your own BlueCloud.js
 * Place the code at Sandbox/BlueCloud.css in your own BlueCloud.css
 * Clear your cache (Ctrl-F5 should work)
 * View the Toolbox sample

--inarius(T) 12:21, 19 October 2006 (CDT)
 * The only problem I have with this is that you have to add the div nav_toc_append and /div to every page before and after the boxes. And if you put the nav_toc_append in each template, it only shows the first. Is there a way to make it so that the nav_toc_append is in each template rather than each page? This way we only need to add stub rather than   . Apart from that, very nice :D -- Prod 12:26, 19 October 2006 (CDT)
 * I was just about to make this point. You should just change .nav_toc -> .nav_toc_append, and scrap #nav_toc_append. --DrBob (Talk) 12:33, 19 October 2006 (CDT)
 * This could be done, but the JS would have to crawl the whole page DOM instead of just that element. My code will work for what I intended, but your approach could be more flexible. Here's the kind of template I envisioned for the toolbox, modeled after :


 * The toolboxtop template would begin the #nav_toc_append tag, and could add any initial formatting concerns, like another div to box things in, or a heading. The individual templates could then be severely dumbed-down. And toolboxbottom could close the tags. Not to say that I don't like your approach. Since we will want to include things in the Toolbox other than just Article Tags, toolboxtop couldn't add the grey headers, so it might be just as well to do everything by class (.nav_toc_append) --inarius(T) 13:18, 19 October 2006 (CDT)
 * Your approach would be fine if we were talking about a few standalone pages, but we're talking about pages edited regularly by people who don't know (or want to know) about our templates, so would not use the top and bottom templates properly. Added to that, hundreds upon hundreds of pages would have to be edited just to stop them breaking if this was introduced, and that's no easy thing to do. If you're worried about crawling the entire DOM, there's no need. You could just crawl the #bodyContent div. --DrBob (Talk) 14:08, 19 October 2006 (CDT)
 * The real concern is, as far as I know, there's no good JS function to get elements by class with a good level of browser compatibility, and I didn't want to roll my own slow/possibly-shotty version. When I was first writing this, I hadn't heard of getElementsBySelector, which is pretty elegant, but I'm not sure if I should use it. --inarius(T) 14:23, 19 October 2006 (CDT)
 * http://www.robertnyman.com/2005/11/07/the-ultimate-getelementsbyclassname/ --DrBob (Talk) 14:47, 19 October 2006 (CDT)
 * I saw some websites referring to this. Is there some reason you would prefer it over getElementsBySelector? It's smaller -- I guess I'll use it. --inarius(T) 15:03, 19 October 2006 (CDT)

I have updated the code and Toolbox sample. --inarius(T) 15:28, 19 October 2006 (CDT)
 * The rearranging works for me (works in ie7 too). I changed the "templates" so that they were all the same, since template order shouldn't be relevant.  -- Prod 15:45, 19 October 2006 (CDT)
 * I don't like it that way. I think it defeats the point of looking simple and saving screenspace. Part of the idea here was making them small and towards the top so they could be placed on any article, and any other Toolbox-content or mini-TOCs woouldn't be too heavily demoted. As for how I envisioned it, I never really planned for a solution that wouldn't require editing pages, and if that was neccessary, would prefer a total lack of the gray headers to this. However, I did also think of a way that should get the gray header there without requiring the editing of any pages. It might be a little less accessible (browsers with crappy use of CSS or Javascript might simply see the Article Tags when there are _no_ article tags). I'll check it out later tonight. --inarius(T) 17:53, 19 October 2006 (CDT)
 * I agree :P. I think the code works, now it's just a matter of deciding on layout.  I would prefer if there was some kind of description of what to do, but a link to a good description page should suffice.  Of course, we could get rid of the images, and just have a colored box with a few words (perhaps two rows of text total).  I'll change up one of the blocks as a proposal. -- Prod (Talk) 18:02, 19 October 2006 (CDT)
 * I agreegree. Although I seem quite opinionated - beyond how it should work technically, I don't have much of a feeling for how it should be layed out. But with such a small space, I have a general feeling that the smaller the description, the better. The Toolbox is fixed-wdith: increase the browser font size by a few points and all it fits is three words without images on a single line. The images could be made smaller, but some of them don't look great small... Multiple lines would probably look fine... Fancy javascript to expand descriptions is probably going too far, but it wouldn't be less accessible... --inarius(T) 18:20, 19 October 2006 (CDT)

Toolbox Prototype
UPDATE: I have reached what I believe qualifies as a final prototype for the Article Tags. I am please with it and think it is ready to be put into place. I have updated the directions above, to test the code itself, however, so everyone can easily see the changes, a screenshot of the final product is located to the right. All that is required to generate an Article Tag on a given page is to place or  anywhere on the page. Thus, no changes are required for all existing articles. --inarius(T) 12:20, 20 October 2006 (CDT)


 * DrBob has made some changes after-the-fact, and I wanted to show them sepearately so they can be discussed. The original prototypes is left, his is right. We did some discussing about expanding the descriptions above, but not a lot, so no consensus was reached. Personally, I think short and sweet will be a benefit with so much screen space at stake, and I intentionally made each tag description no more than three words. Also, I deliberately didn't include any links for work in progess. The entire header-box for the existing template only contains a single link to the article's edit page, and I think even to new editors, that's a fairly obvious operation. However, eventually, we should make a page that explains what a "work is progress" articles is other than the template itself. At which time, that could be linked to. --inarius(T) 12:41, 20 October 2006 (CDT)
 * I probably should've told you, but those descriptions are actually hideable via the CSS in my user CSS page, which I have now moved out into the wild. --DrBob (Talk) 13:17, 20 October 2006 (CDT)
 * To cite my opinion on the matter, I think this has turned out well. What I would suggest is that when these new templates are incorporated into the old ones, the markup for the old ones should remain, but hidden via CSS. That way, if anybody (such as me) wants to keep the header boxes at the top of the content (i.e. in the current place), they just have to change their user CSS. --DrBob (Talk) 13:48, 20 October 2006 (CDT)
 * That looks great, and those who want those boxes should be easily able to have them. Options are fantastic, this just allows those who aren't that familiar with this system here to get a fantastic looking default option that provides all the info they need, while still allowing them to see the guide without being too distracted.  Well done guys. -- Mason11987 (Talk - Contributions) 14:33, 20 October 2006 (CDT)
 * Yeah, looks great. When will this go live? GarrettTalk 14:39, 20 October 2006 (CDT)
 * Yes, I apparently saw your edits well before they were finished. I do like them a lot - although the hover effect (in compatible browsers) is distracting to me, since it heavily moves the TOC. I edited the CSS to displace the description to the left like a CSS menu. --inarius(T) 15:03, 20 October 2006 (CDT)
 * Wow, that looks even better. :) GarrettTalk 15:39, 20 October 2006 (CDT)
 * Yeah, nice. --DrBob (Talk) 15:39, 20 October 2006 (CDT)

SVG file format
I can't upload SVG format images, someone should allow that so I can upload a particular image from wikibooks which is PD. -- Mason11987 (Talk - Contributions) 11:44, 15 October 2006 (CDT)
 * Yup, this has been talked about waaay back. I really want SVG support for the buttons I make. Echelon or another admin just needs to install the plugin for it. --blendmaster 12:48, 15 October 2006 (CDT)
 * It's not even a case of installing a plugin, I think. afaik, all somebody needs to do is change a configuration option, but since those are only accessible via FTP, I can't. :-( --DrBob (Talk) 13:04, 15 October 2006 (CDT)
 * Sorted, and I've uploaded the three merge images. I do think they need replacing though, as they're yucky. :-P --DrBob (Talk) 11:36, 18 October 2006 (CDT)
 * How exactly do I get SVG files to show up properly. When i go to Image:Mergefrom.svg its a png image. When I go to http://strategywiki.org/w/images/0/0f/Mergefrom.svg its the svg code. If I save the file, then open in Firefox, it comes as a proper picture.  Is there something up with the MIME type or is it on my end? -- Prod 11:41, 18 October 2006 (CDT)
 * They're rasterised to PNG for display because most browsers don't support them. --DrBob (Talk) 12:21, 18 October 2006 (CDT)

Trademark/copyright
IANAL, but a lot of websites which have info about games/movies/other peoples products, usually has a disclaimer at the bottom saying that all trademarks are the property of their respective owners, or something similar. Shouldn't there be something like that here? -- Prod 16:44, 15 October 2006 (CDT)
 * Potentially that could be due to their commercial nature? -- Mason11987 (Talk - Contributions) 17:56, 15 October 2006 (CDT)
 * GameFAQs doesn't have one. The discreet link to General disclaimer should be sufficient. GarrettTalk 19:41, 15 October 2006 (CDT)
 * The only problem is it doesn't mention anything about fair use and copyright images in there IIRC. If we add that, it should be fine Minun  12:23, 16 October 2006 (CDT)
 * Agreed. -- Mason11987 (Talk - Contributions) 12:48, 16 October 2006 (CDT)
 * I'll have a disclaimer up when I get home tonight.  ech elon  15:57, 17 October 2006 (CDT)

Half-Life 2 image size
So I started taking in-game screenshots of Half-Life 2 and uploading them...however, the file sizes are very large, exceeding 600,000 bytes most of the time. Should I compress the images or upload them as they are? I know StartegyWiki has a lot of space on the server, but I just want to make sure the size limitations don't exceed too high. I plan on having tons of images for the walkthrough, so expect at least 150+ screenshots for the entire game. I'll stop uploading them now and wait for a general consensus. Thanks. --Antaios 21:24, 16 October 2006 (CDT)
 * Since most images will be shown as thumbnails until enlarged I don't see the need for full resolution, full size images. That's just my opinion though.  I don't think 150+ full size images are necessary for a strategy guide since you don't need to see complete detail in all of them.  Of course having a lot of pictures to explain certain things is great but they don't need to be all full res.  Although if the storage space is a complete non-issue I'm sure echelon will say something different. -- Mason11987 (Talk - Contributions) 21:30, 16 October 2006 (CDT)
 * While we're still on a single server, our hard drive is limited to 100 GB. We run Abxy, DSmeet, and StrategyWiki off this same machine. This includes all of the software--Linux, Apache, whatnot, as well as the software that runs each site. The databases and associated file uploads are also on the server. I haven't tallied the total usage thus far, but I do believe we are still far from reaching our limits. Nevertheless, we should be wise and conservative in our use of uploads until the time we are able to buy additional hardware through Abxy and DSmeet's income. You can still have very nice, fairly large images that have some compression. Why not upload a few examples for us to take a look at?  ech elon  16:00, 17 October 2006 (CDT)
 * Set up a paypal donation thing and I may drop a few bucks on this project. -- Mason11987 (Talk - Contributions) 18:57, 17 October 2006 (CDT)


 * That might be a decent idea. I'll see what I can do about it.  ech elon  23:55, 17 October 2006 (CDT)


 * Yeah, I'll probably have to narrow down the amount of pictures. All of the pics are in-game at 1280 x 1024 resolution with maximum graphics settings, so the pics are expected to be of that quality and size. I'll try compressing a couple to see how it looks; if it still looks good, then I'll start uploading those. --Antaios 20:56, 20 October 2006 (CDT)
 * Try png images, they often look sharper then jpeg (from my experience) and they are smaller. Although someone with more image knowledge could probably give better advice. -- Mason11987 (Talk - Contributions) 11:15, 21 October 2006 (CDT)
 * Try saving both ways, and just compare. I would recommend sticking to images at 640x480 or even lower.  It doesn't have to look amazing, just give the information.  -- Prod (Talk) 11:29, 21 October 2006 (CDT)

"Unofficial" policy of the week
These have to be taken care of sooner rather than later. Perhaps we set one policy as a policy of the week (selected here) for the next 5 or 6 weeks. As Layout is mostly done, I nominate that as the first one (the easiest :P). -- Prod 23:17, 16 October 2006 (CDT)
 * I'll whip up Categorisation as weary as I am of the spelling ;). -- Mason11987 (Talk - Contributions) 23:32, 16 October 2006 (CDT)
 * I prefer the letter 'z' as well, and Firefox keeps complaining about that spelling :P. Well, if you're going to work on that, I'll change my nomination to that one. -- Prod 23:48, 16 October 2006 (CDT)

Nomination for this week: Naming. -- Prod (Talk) 09:08, 22 October 2006 (CDT)

New game template
I created New game. I tried to stick to something every main game page would have, to avoid parameters which would make it less useful. Anything that should be added? -- Prod 21:32, 17 October 2006 (CDT)
 * Good idea! I've added a single parameter for the game's name, and standardised it a bit. :-) --DrBob (Talk) 01:25, 18 October 2006 (CDT)
 * I've replaced it with . This way it's filled in automatically. A similar method could be used to turn  or similar into the full template. GarrettTalk 03:11, 18 October 2006 (CDT)
 * Well AGN shouldn't be subst'd, keep the dynamic nav out of the average page code. This page has useful, organized templates contained within one template that can be subst'd. -- Mason11987 (Talk - Contributions) 09:10, 18 October 2006 (CDT)
 * Should we subst FULLPAGENAME? If the game is moved it won't automatically update, but it will be easier to understand if there is a need to change it then FULLPAGENAME.  I'm not particularly strong either way on this, but I just thought I'd bring it up. -- Mason11987 (Talk - Contributions) 09:12, 18 October 2006 (CDT)
 * I had tried using but that ended up getting substed with New game :P.  I also added the needinfobox because an empty infobox is the same as no infobox. -- Prod 10:21, 18 October 2006 (CDT)
 * I had to rig it, but template complexity (especially when included, and in doing so, becomes very simple) isn't really a bad thing as long as it provides functionality, check out my test in the sandbox. -- Mason11987 (Talk - Contributions) 11:48, 18 October 2006 (CDT)
 * Well, I managed to clean up your solution a bit :P. I would classify what is done as a hack >.> -- Prod 12:01, 18 October 2006 (CDT)
 * Nice, I just tossed in what I knew would work, but that works even better. -- Mason11987 (Talk - Contributions) 14:38, 20 October 2006 (CDT)

Bot
Ban User:Boothby (bot)! He's gone crazy!!! -- Prod 14:54, 18 October 2006 (CDT)
 * I've stopped the bot, and will go about rectifying the damage. (I didn't filter the image names against "Portrait_*".) --DrBob (Talk) 15:14, 18 October 2006 (CDT)
 * All done. :-) --DrBob (Talk) 16:09, 18 October 2006 (CDT)

PC keys?
Should there be a Category:PC keys? I think it would be useful, but I'm not good at graphics, so I'm bringing it up here as the template told me to :). -- Mason11987 (Talk - Contributions) 20:38, 22 October 2006 (CDT)
 * I'd say something more like Category:Keyboard buttons since it isn't for only PC's but all computers (minor distinction :P). -- Prod (Talk) 21:07, 22 October 2006 (CDT)
 * Separated out other talk so we can get more comments about this. -- Mason11987 (Talk - Contributions) 15:29, 25 October 2006 (CDT)
 * Yea, sorry about that. I kinda hijacked your thread. The category is probably needed, especially for games like Final Fantasy VII.  My image skills are pretty bad, but I'd suggest probably white keys, black borders, raised inner square with a nice large letter in the middle.  Also an Enter button shaped like the old ones (the triangle thing).  -- Prod (Talk) 16:34, 25 October 2006 (CDT)
 * DavysBigKeyCaps is a nice font for that. Another way to make keyboard buttons is to make a template with a plain square keyboard image as a background and the letter centered, with special cases for irregular keys. Then, it'd be more accessible as well. --blendmaster 11:45, 29 October 2006 (CST)

Controller button category name changes
some of the category naming at Category:Controller buttons seems inconsistent. I suggest these changes (should be easy for you botters ;) ):
 * Category:Xbox360 controller buttons -> Category:Xbox 360 controller buttons
 * Category:DS controller buttons -> Category:Nintendo Dual Screen controller buttons
 * Category:Playstation controller buttons -> Category:PlayStation controller buttons
 * Finally, the buttons also need to be added to the Category:PlayStation 2 controller buttons and Category:PlayStation Portable controller buttons, though I don't know too much about the differences between the controllers. -- Prod (Talk) 21:07, 22 October 2006 (CDT)
 * Why is everything in Category:Controller buttons as well as their own specific category? -- Prod (Talk) 21:16, 22 October 2006 (CDT)
 * Don't call the Nintendo DS by "Nintendo Dual Screen". That isn't official, nor is it even its colloqual name! I would not support a move to do this. While it might be good to aim for consistency between game platform categories and the button categories, please continue to use the standard naming for each: basically whatever the company uses and the community knows best.  ech elon  23:31, 22 October 2006 (CDT)
 * I would support the first and third movement suggestions, and I'll set my bot on them. :-) --DrBob (Talk) 04:11, 23 October 2006 (CDT)
 * Done. I've now set the bot on removing all images from the Controller buttons category, leaving them just in their system-specific categories. --DrBob (Talk) 04:42, 23 October 2006 (CDT)
 * In that case, I suggest the Category:Nintendo DS controller buttons. As I was looking through the official Nintendo website, I found that they referred to the systems as Nintendo Entertainment System/Super Nintendo Entertainment System (and as the NES/Super NES) rather than as the Nintendo/Super Nintendo. So, Category:NES controller buttons and Category:Super NES controller buttons would seem like the appropriate terms in this case.  For that matter, Category:Super Nintendo should be moved to Category:Super NES (just like Category:NES). -- Prod (Talk) 11:25, 23 October 2006 (CDT)
 * I'm not sure about that. Fans always call it either the Super Nintendo or the SNES, never the Super NES. GarrettTalk 14:47, 23 October 2006 (CDT)
 * Well, those are the official names, and we can set up redirects for the others. -- Prod (Talk) 15:08, 23 October 2006 (CDT)
 * I think they're fine as they are, really. The categories I renamed were definitely wrong, but these ones aren't. --DrBob (Talk) 15:16, 23 October 2006 (CDT)

Category renaming
This is kinda a separate discussion, heres the summary (in order of controversy, least at the top): My main reasoning is, it's far easier to stick to official company standards (which are easily accessible) rather than community standards. -- Prod (Talk) 11:17, 25 October 2006 (CDT)
 * 1) Add images in Category:PlayStation controller buttons to Category:PlayStation 2 controller buttons and Category:PSP controller buttons (refer to Category:Xbox controller buttons and Category:Xbox 360 controller buttons)
 * Category:DS controller buttons -> Category:Nintendo DS controller buttons (consistency with Category:Nintendo DS rather than Category:DS)
 * Category:Nintendo controller buttons -> Category:NES controller buttons (consistency with Category:NES rather than Category:Nintendo)
 * Category:Super Nintendo -> Category:SNES (Official name)
 * Category:Super Nintendo controller buttons -> Category:SNES controller buttons (refer to #4)
 * Category:GameCube -> Category:Nintendo GameCube (Official name)


 * Agreed on all points. Of course, only the appropriate images should be added to the PS2 and PSP categories. --inarius(T) 15:08, 25 October 2006 (CDT)
 * I can agree with the other changes, but I really don't agree with using Super NES. It's a less common name and even Nintendo calls it the SNES now. GarrettTalk 19:52, 26 October 2006 (CDT)
 * I didn't realize they considered SNES official. I think http://www.nintendo.com/systemsclassic?type=snes is a better example.  Updated above. -- Prod (Talk) 20:43, 26 October 2006 (CDT)
 * OK. I think I'll agree with 1, 2, 3 and 6, and also suggest that Category:PlayStation -> Category:Sony PlayStation (and the same for PlayStation 2, inline with 6). --DrBob (Talk) 07:39, 27 October 2006 (CDT)
 * For Ps -> Sony PS: Nintendo mainly calls it the Nintendo GameCube, whereas Sony calls it the PlayStation. I have no objection to adding Sony, but I don't fell it's necessary either. -- Prod (Talk) 09:47, 27 October 2006 (CDT)

Genesis or Sega Genesis? Official Website, Category:Pages lacking control images/Genesis and Category:Sega Genesis. -- Prod (Talk) 09:59, 29 October 2006 (CST)

Fixed redlinks, but I'm not sure what the consequence is
There's a nasty little line in /includes/SkinTemplate.php that was causing the red links, so I decided to comment it out:

I'm not sure what the function of importing this was, but it's no longer done. All it was doing was changing our default missing article links, which were purple, into ugly red ones.  ech elon  23:28, 22 October 2006 (CDT)

"Disappearing" images?
I don't know how many of you have encountered this strange phenomenon, but I've noticed that some of the pictures that I once uploaded that appeared fine are now no longer appearing. The weird thing about this is that the pictures are clearly there. This has just happened to me with a new Xevious screenshot that I recently uploaded. To see what I'm talking about, check out Pac-Man and go down to the box art gallery. The TI-99/4a box picture is missing. And when you try to look at the Image:PM_TI99_box.jpg page, it's clearly there, but you still can't see the picture. Only when you click on the blue link to PM_TI99_box.jpg can you actually see the image. Well, the same thing just happened on the Xevious/Strategy page. I uploaded a series of pictures to illustrate the position of the hidden Sol Towers. All of them uploaded fine, but the second picture will not appear on the page. Again, if you go to Image:Xevious TowersB.jpg, the page exists, but you still can't see it until you click on the link to Xevious TowersB.jpg. I noticed this for the first time when I tried to upload an portrait of Maki from SFA3. I had to append an underscore to the filename to make this go away, but now that I realize it's happening to older images (like the Pac-Man one) as well as new ones, I thought another solution should be discovered. Procyon 14:48, 25 October 2006 (CDT)


 * I could not reproduce any of these problems in Firefox 1.5. It sounds like a cache problem, or if you are running Internet Explorer, I know it can have issues with storing cookies from URLs containing underscores. Perhaps it has similar issues with cached images? I tried opening a few of these pages in IE6 as well and I still couldn't reproduce it. --inarius(T) 15:13, 25 October 2006 (CDT)


 * It's because you have adblock (plus) with filterset G (most likely). Mediawiki creates thumbnails and puts them in folders with random characters, there is a possibility of the subfolder being called /ad/ and so the image will be blocked.  Make an exception for that image and you'll be fine. -- Mason11987 (Talk - Contributions) 15:31, 25 October 2006 (CDT)


 * And I'm correct, the thumbnail is here:

http: //strategywiki.org/w/images/thumb/a/ad/PM_TI99_box.jpg/89px-PM_TI99_box.jpg


 * Interestingly enough, I also filter out the powered by mediawiki button because it has 88x31 in it's title. How bout that. -- Mason11987 (Talk - Contributions) 15:34, 25 October 2006 (CDT)


 * Thanks Mason! You were absolutely right.  I had no idea, that's so odd.  I set a general exception for strategywiki.org, I just wonder if there's any other way to avoid that.  No matter though, problem solved.   Thanks again. Procyon 15:39, 25 October 2006 (CDT)


 * No problem, I had encountered it a lot before on sporewiki, uploading dozens of images, so it's good to share :). -- Mason11987 (Talk - Contributions) 00:01, 29 October 2006 (CDT)
 * Ah, this also explains the problem I had with some button images. Maybe we should prevent mediawiki from putting images in a directory /ad/ so if someone happens upon this site and has adblock+filtersetG on, they won't think we're sloppy about uploading images or something. --blendmaster 18:30, 25 October 2006 (CDT)


 * I doubt that Echelon or any of us have any direct control over that unfrotunately. It's most likely a hash algorithm that determines what the the two letters are going to be.  It's a bit like asking dice not to roll snake-eyes.  You can't prevent it from happening, even though it's unlikely. Procyon 18:33, 25 October 2006 (CDT)


 * The hash algorithm is the exact same one we use on ABXY:


 * m = md5_file(image);
 * /m{1}/m{1}m{2}/image_filename.extension
 * There's not much we can do about this, unfortunately. Even Wikipedia does this.  ech elon  12:30, 26 October 2006 (CDT)
 * It's actually an amazingly cunning way of doing things, and it's unfortunate that some of the Adblock filter sets don't have exceptions for things like this. --DrBob (Talk) 07:35, 27 October 2006 (CDT)
 * I know it'd probably just be easier to ask the filtersetG people to add wikimedia image directories to a whitelist, but couldn't you just add an if statement to test if m{1}m{2} == "ad", and if it does, use a different hash or something? --blendmaster 12:15, 29 October 2006 (CST)
 * That's a dirty hack, and it really shouldn't be done. Talking to filtersetG is the way to go. --DrBob (Talk) 14:09, 29 October 2006 (CST)

WP template
I created a WP template for linking to wikipedia. I'm not sure if going through wikibooks to get to wikipedia is going to be permanent, but if the way it's done ever does change, it'll only be one place to change it. ex. . On a similar note, can we get a bulbapedia interwiki link? -- Prod (Talk) 10:53, 27 October 2006 (CDT)
 * Now that DrBob has FTP access (I think) it shouldn't be difficult for him to add to the interwiki list. GarrettTalk 13:58, 29 October 2006 (CST)
 * Try now. I've added "wp" and "wikipedia" links to Wikipedia, and "bp" and "bulbapedia" links to Bulbapedia. --DrBob (Talk) 14:22, 29 October 2006 (CST)

ABXY interlinking
How much inter-linking is there going to be between ABXY and StrategyWiki? -- Prod (Talk) 13:38, 1 November 2006 (CST)
 * Each game will link to its article on StrategyWiki, and each article (etc.) which refers to a game will do so by association, afaik. --DrBob (Talk) 16:09, 1 November 2006 (CST)

Posters
I noticed on the main page the suggestion about putting up fliers and posters. Anyone have any good designs? (B/W and color). There are a few small video game stores nearby that might be willing to put up a poster. Perhaps a contest or something? -- Prod (Talk) 11:04, 7 November 2006 (CST)


 * My design is still a work in progress. When I've perfected it, I'll post it here. I've been trying to post fliers all over my campus...  ech elon  09:46, 8 November 2006 (CST)

Zelda Partnership
I feel that a zelda partnership with the HYlia .com would be good becasue they have a bountiful amount of information!! —The preceding unsigned comment was added by Mageman (talk • contribs) 14:30, 9 November 2006 (CDT).
 * Well, for one thing, Hylia.com isn't a wiki, which doesn't exclude them from consideration for partnership, but it certainly doesn't help. For another thing, it doesn't look like they've updated their site since 2004, so it's not clear that it's an active site.  If they have information that would be pertinent to our Legend of Zelda pages, by all means, lets use it and credit them where appropriate, but it's not clear to me how either of site would benefit from a partnership.  Procyon 15:15, 9 November 2006 (CST)
 * Were you meaning hylia.com or THEhylia.com? Either way, I'm not sure what sort of information would be exchanged as it would not have been contributed under a copyleft license. Actually, I've been looking at ZeldaWiki recently; they're GFDL and have only a couple of walkthrough pages at present, so unless they specifically want walkthroughs to be hosted on their wiki linking to ours would be a no-brainer. Since it no longer belongs to any one Zelda site we could get a lot of contributors that way. I'm feeling rather drained after this morning's exam, so if someone wants to beat me to it go right ahead. :) GarrettTalk 18:17, 9 November 2006 (CST)
 * I agree with Garrett, ZeldaWiki is a much better candidate for a partnership. But Garrett, it looks like you already have an in there, so you're probably the best person to propose the partnership.  When I tried with Bulbapedia, it kind of fizzled out because I didn't follow through in a timely fashion, and they just didn't seem to care all that much anyway.  Sure we link to them now, but it's a pretty one sided partnership.  At present I don't think they link to us at all (although I could be wrong.  I'll go check.) Procyon 19:16, 9 November 2006 (CST)

Sidescrolling map size limits
Hello. I've been considering moving on to some of the popular older side scrolling games like Super Mario Bros. and Mega Man. I think that given the power we have here, illustrated maps would be a good thing to provide, but the nature of side scroller maps don't lend themselves well to browsers. The best thing I can think to do is to cut the map up in to parts and present it like so:

description of strip 1

description of strip 2

and so on... So my big question to all of you is: what should the horizontal limit of the width be? 400px? 600px? It's an odd question because regardless of what resolution desktops people have, be it 1024x768 or 1600x1200 or anything, we have to come up with some size where we say, "this is a reasonable size that everyone can see fairly well, regardless of resolution." Personally, I'm considering 600px because in the worst case, if a user runs an 800x600 desktop, and they maximize the browser, shouldn't they still have 600px for the center of StrategyWiki where the guides appear? What are your thoughts on this? Procyon 11:18, 10 November 2006 (CST)

Update: I created a test page for Super Mario Bros. which you can view here. Each of the maps except for the remainder of the level is 600px long (the images of the maps have been reduced by 50%.) While making it, I also wondered if I should put all of World 1 on one page, or make four seperate pages for World 1-1, 1-2, 1-3, and 1-4. Procyon 11:31, 10 November 2006 (CST)


 * I like the idea of separating the image, and I don't think it will become too problematic. Another possible solution is to implement inline scrollbars that allow the user to scroll along the image--we might want to make a template to do that. As for the limit, 600px looks fine here. Only really small browser resolutions would have trouble, and we can implement a javascript function to dynamically resize images that are too big for any given resolution. (We do that at ABXY/DSmeet.)  ech elon  13:56, 10 November 2006 (CST)


 * As echelon says, it might be a good idea to have a template which adds a scrollbar, although I can't foresee any major problems with tiny screen resolutions (almost nobody uses them these days, and even if they do, the main site will be broken enough to make a broken image pale in comparison). If you want to upload a full-width image Procyon, leave me a message on my talk page and I'll slap a scrollbar template together for testing. :-) --DrBob (Talk) 14:12, 10 November 2006 (CST)
 * I like the advantages of both ideas. The scrollbar lets you easily see the whole level the way it's played, but the chunk method lets you see tips at a glance. Another possibility would be annotating the map with some sort of universal "tip" icon and use an imagemap to make a Javascript tooltip to pop up when you mouse over it. GarrettTalk 14:27, 10 November 2006 (CST)


 * Wow, I didn't even realize that the scrollbar solution was a possibility. While I like the idea of that from a technological standpoint (it just seems cool), it has some limitations.  As Garrett mentioned, it would make providing tips and strategies for a particular point in a map difficult to do without annotating the map somehow.  Then in order for a reader to understand what the tip is trying to say, s/he would have to scroll to the spot on the map that the tip applied to, if it's not already in view.  Another potential problem is for people who browse the web with tools other than a mouse (e.g. a PSP) who might have difficulty scrolling an image, although I'm certain there are ways to get around that problem.  When I think about how Nintendo Power and other magazines detailed side scrolling games, they broke the maps up in a similar fashion to how I did the SMB test.  Dr. Bob, you can experiment with one of the SMB maps found on this page which is where I got the test version from.  I have to run, but I'll give this problem some more thought.  Procyon 15:16, 10 November 2006 (CST)
 * There's also an image in use for the Mega Man game. I'm just wondering how this goes with "fair use".  Having screenshots from parts of the game, or user created maps is one thing; but having the whole map of the whole game seems a bit of a stretch of the fair use rationale. -- Prod (Talk) 15:40, 10 November 2006 (CST)
 * Using the scrollbar shouldn't be much more of an issue, from an accessibility standpoint, than the use of images in general. All downsized browsers and screen readers will have such problems. I believe the template that DrBob has created will still allow users to click on the image and eventually head to the full picture. This will allow any image-capable browser to view the image without scrollbars. --inarius(T) 20:46, 10 November 2006 (CST)


 * I've created Template:Scrolling map, and I'm now looking into the possibility of upgrading our imagemaps stuff so that you can hover over areas and they will be explained, as done here. In the mean time, that template should be completely fine to use, and I don't think it'll need any modification if I do install some imagemap upgrades. :-) --DrBob (Talk) 17:51, 10 November 2006 (CST)


 * OK, a big thank you to Dr. Bob for starting that template. I applied it to the map on Metal Man's page.  At first, it did not turn out well, because even though the width scrolled, the height did not, so there were about 740 pixels of image before the text started, which was not good.  So I did some research and discovered how to control the width and size of the image and added them as parameters to the template.  That actually worked out quite nice because I could limit just the height of the image to 256, and sure enough, the vertical scroll bar appeared.  So, you can take a look at it and judge for yourself how you like it.  My personal thoughts are that while this approach may not be well suited for a side scrolling action game (especially one like Mega Man where the maps are usually not straight), this may be perfect for a world map of an adventure game.  When I get the chance, I will try to provide an example, perhaps for the Dragon Warrior guide.  Procyon 09:09, 11 November 2006 (CST)
 * I don't think these maps should ever scroll in two directions, nor should they be full sized. Some maps may be huge, and if there were a need for a vertically scrolling map, the template could be split into two, or contain more complicated logic. Please checkout this proposal for a horizontally scrolling map that is automatically zoomed out to a max height of 200 pixels and is also configurable. This would allow for more predictable behavior on the part of the user (Metal Man's lever for instance, is very disorienting when scrolling through a void of blue space). --inarius(T) 02:47, 15 November 2006 (CST)
 * I don't like this. The whole point of having a map is so that you can see the levels, but if it's scaled down, it's not at all helpful. Having it at normal size and with a vertical scrollbar isn't that bad. --DrBob (Talk) 11:10, 15 November 2006 (CST)


 * Ironically, I agree with both of you. I think the key is to figure out which maps lend itself well to vertical scroll bars, and which do not.  Clearly, the map on Metal Man's page is a bad example, and one reason why we shouldn't have a blanket policy on all maps.  That was just an experiment.  I forsee vertical scroll bars being entirely useful for world maps that are square (or rectangular) and there's no void of space (except for the usual vast spans of ocean).  By the way, I completed the walkthrough for Super Mario Bros., and you can see an example of maps that were split up by me for the sake of clarity, and yet still use the scrolling map template as a back up for the sake of formatting.  (I plan on heavily reorganizing that guide now that the walkthroughs are done.)  Procyon 11:18, 15 November 2006 (CST)
 * I guess I can see the use of having the map at full size. I'll think about this a little further. --inarius(T) 13:58, 15 November 2006 (CST)
 * I think that metal man map should be broken into two parts. Maybe with some kind of line to show where they connect (in html?). -- Prod (Talk) 21:21, 15 November 2006 (CST)
 * Trust me, I plan on overhauling the whole Mega Man 2 guide like I did with Super Mario Bros. That map won't stay like that, it will get broken up eventually, I just need time... a lot of it.  Procyon 22:11, 15 November 2006 (CST)


 * Not that I am actively involved in creating these types of guides, but I tend to disagree, which is why I preferred the zoomed out map. I prefer continuity above anything else... Breaking up what is essentially a sidescroller map would only consume less space or allow greater detail if done at inflexion points - for instance splitting the Metal Man map into two horizontal pieces, or two horizontals and a vertical, but this further confuses the overall structure of the level, such that it isn't overtly apparent what happens in that part of the map. I think in most cases, having a bird's eye view of some sort would be incredibly helpful, even if separate close-ups had to be provided to highlight certain details.
 * {|style="float:left"


 * http://img182.imageshack.us/img182/9196/viewfinderrf9.th.gif
 * } One interface for maps, which is most likely more of a wet dream than a reality that I could spend time developing would be a separate zoomed-out view-finder and a zoomed-in detail pane. The viewfinder would ideally not scroll (though it wouldn't be terrible if it did - as long as it still worked), and would contain a box which defined the position of the image in the detail pane. For sidescrollers, this could be made fancier by using something like an image map to constrain the detail image to within a particular boundary, which would work for many shapes of maps and allow the user to feel in control of viewing it. Also, inline links presented similar to page bookmarks could call javascript functions which would automatically reposition the viewfinder to a particular coordinate, in order to highlight a particular element/area of the map. None of this would be particularly un-wiki like, as the creation of a simple and versatile viewfinder could be reduced to three variables, the detail image, the size/shape of the viewport, and the initial position of the viewport. Other configurable elements worth adding would be the image-map constraints, and configurable viewfinder size and position. --inarius(T) 02:13, 16 November 2006 (CST)

Expansions
Do they get their own pages, or subpages of the main game? -- Prod (Talk) 10:10, 12 November 2006 (CST)
 * I suppose it depends on how much they change the game, but I'd be inclined to put them as sub-pages. If a game has multiple expansions, they should probably all go beneath an "Expansions" sub-page of the main game page. --DrBob (Talk) 10:38, 12 November 2006 (CST)
 * I agree with DrBob that there should be an expansion subpage. However, I would treat it as a main page redirect so that you can still categorize the expansion properly and just have it redirect to the appropriate subpage.  Kind of like what I've done in the past for Namco Museum (Dreamcast), Vs. Pinball, and a few others, only redirect to a sub-page, not another main page.  Procyon 17:00, 12 November 2006 (CST)
 * Good idea. :-D --DrBob (Talk) 17:10, 12 November 2006 (CST)

Strategy guide for... Strategywiki?
I think that one of the things that this site needs is a guide on how to use it. We should upgrade the help page to have all of the scripts for strategywiki such as how to categorize, place things such as stub tags on articles, how to write the guide correctly and to clean-up. It'd make more sense for new users to know how to use this stuff correctly rather than to have more experienced members use their time to clean up their articles and add the proper tags. --Navy White 13:10, 14 November 2006 (CST)
 * We are slowly putting together a couple of pages here, which describe things in decent detail (I think; if you think otherwise please bring it up on the relevant guide's talk page, and I'll see what I can do). I believe that if we imposed all this "red tape" on new users it would discourage them from contributing. It's better to have a core team of people who really know what they're doing cleaning the place up, rather than a load of people who've quickly read some documentation and are using their own interpretations of it. That said, having the documentation there doesn't hurt. :-) --DrBob (Talk) 16:37, 14 November 2006 (CST)
 * I started Help:Writing guide which covers various things, but there's still a lot missing. GarrettTalk 18:42, 14 November 2006 (CST)
 * Though it's a bit of a tanget, I actually think this could be a really good idea. In the interest of being less Wikipedia-like (and I have always hated the inherent difficulties of locating instructional Help and Special pages for editing wikis), we could use the strategy guide book-format to walkthrough various levels (beginner, advanced, etc.) of editing, and to collect all pertinent information in a single easy to understand place. This would be easy enough to over-complicate and turn into a complete disaster, but I think it could also turn out well. The goal would be to organize the creation of a new strategy guide into a minimal set of simple steps, and to use lots of images to drive points home. A Table of Contents could look like (I would expect the In-Depth guides to grow somewhat rapidly, and have included these only as a sample of how the overall guide could work):
 * The Basic steps for creating a strategy guide are in bold. Other steps cover more In-Depth concepts you may want to skip.
 * Sign Up -- ''Would contain a brief explaination that to edit any pages you must sign up for a user account, hint at the fact that content will be in the public domain, and walkthrough the process of signing up (with pictures)
 * Change Your Preferences -- ''A quick explaination of user preferences and what they do
 * Ask Questions -- ''Introduce the various places for getting help, how to use talk pages, and how to leave a signature
 * Create a Guide -- ''Searching for any existing guide, creating a new page,, basic wiki markup
 * Do Your Homework -- ''Minimum game info, where to find info, how to handle uncertainty
 * Add Pizazz -- ''Images, nav bars, sidebars, other common templates
 * Save Your Work -- ''Previewing and saving, edit summaries
 * Look For More -- ''How to stay involved with StrategyWiki, a complete outline/list of help pages and policy pages
 * And almost all Footer_Navs would contain two links in each direction, the most noticeable ones leading to the nearest Basic step, and the alternate ones leading to In-Depth steps, probably identified with icons and font sizes:


 * [ID]  = In-Depth guide
 * --inarius(T) 01:35, 15 November 2006 (CST)
 * Sounds good. Do you want to have a go at doing this? Once you've laid out the basic structure you're envisioning, I'm sure people will be able to help. :-) I suppose this would render the pages I linked to as policies, rather than help. --DrBob (Talk) 11:05, 15 November 2006 (CST)
 * I definitely won't have time to get to this until the weekend, and don't have anything against someone else who wants to get it started. I'll make sure to work on it when I get some time. --inarius(T) 14:03, 15 November 2006 (CST)
 * If anyone wants to help make a basic guide, I'll pitch in. A good idea would probably be a starter's page with some basic wiki-code and how to use it as well as strategies to writing a strategy guide. I'm thinking a page called Beginner's Guide for this stuff and later creating pages with all of the fancy things like templates.--Navy White 16:35, 15 November 2006 (CST)

External links to maps
OK, before I start this thread, I have to point out that I know that I've already expressed an over-sensitivity towards the map linking that Snesmaster has contributed. Add to that my own (sometimes overblown) protectiveness for guides that I have started. But I strongly question the value of Snesmaster's most recent contribution, which was to provide a link to maps for, of all games, Mario Bros., a game whose map layout never changes beyond decoration and enemy content. The layout and the enemies found in each stage are already spelled out in the guide. So I have a hard time justifying leaving this link on the guide. However, considering the reactions that I've had in the past, I will not edit this revision, and leave it to everyone else to decide. Procyon 19:51, 14 November 2006 (CST)
 * I don't think it can hurt the guide. I suppose I don't mind either way (but I am sympathetic to your over-protectiveness: I get that a lot) --DrBob (Talk) 11:08, 15 November 2006 (CST)

Cheat Code Wiki Interwiki
I'm the owner of Cheat Code Wiki and I just thought maybe we could make interwiki links or something. Like CheatCodeWiki:Halo or whatever. What do you guys think? --ZimShady 02:34, 19 November 2006 (CST)


 * Why don't we just destroy that wiki and move the content over here? There's no point to making people go to another website to see something that belonged in Strategywiki in the first place. --Navy White 09:48, 19 November 2006 (CST)
 * Don't have to be so harsh on him...With the partnership with bp: (which is only half alive) they already have a huge database and lots of contributors. Your wiki is somewhat small at the moment.
 * I'm also a supporter of centralization. I would prefer if we could have all the pokemon info here, but there's just too much to cover, and they do it better.  For the moment, I'd be more interested in seeing your wiki merged to here. -- Prod (Talk) 10:27, 19 November 2006 (CST)
 * The problem is, Bulbapedia has content that goes beyond our mission statement. Cheats and glitches, however, fit right in. I can't see any reason to link to your site rather than having our own equivalent content. As for a merger, some of this content seems to have come from non-GFDL sources, so I would be very reluctant to see that content moved here. GarrettTalk 13:36, 19 November 2006 (CST)

Browser games?
Can (or should) StrategyWiki cover browser games (e.g. Macromedia Flash games, Macromedia Shockwave, Java, etc.)? We could impose notability requirements, so that only the most viewed games be mentioned. Bibliomaniac15 00:11, 20 November 2006 (CST)
 * Only really notable ones like RuneScape. --DrBob (Talk) 00:26, 20 November 2006 (CST)