StrategyWiki talk:Community Portal/2006/June

Community Issues Talk Page

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

(That was FilthySwine again.) I would disagree, because that would just make this page pointless - it would be a list which would constantly need updating, yet serve no purpose because all the titles and content would be on the talk page anyway. This is the community issues page, and I don't believe the talk page here needs to be used. --DrBob 14:10, 2 June 2006 (PDT)

Notes for Echelon

In clearing some of the older discussions, I found a few things that I forgot to implement. I'm listing them here so I won't forget again.

SVG uploading support
Investigate and implement Open Source FLV uploads and Open Source panoramic screenshots by the end of the summer.

--ech elon 19:28, 20 June 2006 (PDT)

Intro Pages

Since consensus has been [[/Intro Pages|reached]], I think this should be put into action and be made official in some way. And I have already done the Z:OoT guide so I think they should all be changed as long as it causes the benefits that this change is supposed to cause. Namely better organization, and navigation. -- Mason11987 ^{(Talk - Contributions)} 20:48, 19 June 2006 (PDT)

Just go to Special:Whatlinkshere/Template:Cover and you'll get a list of all the pages still using the [[Template:cover|cover]] template. --DrBob (Talk) 22:53, 20 June 2006 (PDT)

Image Categories

I finally got my wish and now we have a dynamic home page, but unfortunately I didn't forsee the next problem with it: we've run out of images. Not uploaded images, mind you, just images ready to be used. This is bad, as it makes us look empty, irresponsible, lazy, etc. The obvious reason is that users aren't updating the front page; which is not unexpected. But I suspect another as well: lack of organization on our parts.

The Image list is incredibly hard to read, and pretty much never tells you anything you need or want to know. After going through a thousand .gif's of maps for one game that I don't even know the name of looking for game artwork, without knowing what I was clicking on next due to non-descript filenames, I devised a solution.

Images need categories too. They could be any of these: screenshots, game artwork, map, box art, or item. This could help out those who choose front page images out a great deal. There should also be a field when a file is uploaded to add the name of the game it came from, so that when someone goes through the Image list they can see that "such and such image is from this game and is this type." Perhaps even a search function could be implemented, so that users could search for specific categories/games/systems.

I just wanted to know your guys' thoughts on this. I hope that was coherent. Cosmo _{let's chat}

I would agree with categorising the images, but I can't see the necessity for hacking MediaWiki to add stuff to the image upload system. We could change the language strings to encourage people to name images responsibly, and encourage them to link back to the game for which the image has been taken, but hacking MediaWiki's too much. Personally, I've been prefixing all my images for Counter-Strike: Source with "css_", to separate them from everything else, and it works nicely. :-) --DrBob 14:15, 2 June 2006 (PDT)

I was unaware doing some of that would require hacking MediaWiki, so I suppose some of that is now out of the question. I've also named my images things like "mf-bleh" or "metroidfusion-file" to seperate them. Cosmo _{let's chat}

Another possibility is using an external image rotator so there's a different picture every time you visit, however that of course doesn't allow captions. Garrett^Talk 15:22, 2 June 2006 (PDT)

I can't figure out how to get the captions working on the front page anyways! XD Cosmo _{let's chat}

OK, check out this image. Thanks to an obscure MediaWiki feature thumbnails are able to be automatically generated and sourced by this outside rotator. The images have to be manually added to the rotator, BUT the rotation time can be set for as little as a minute or as long as a week. However the lack of captions or hyperlinks is still a setback to this method. Garrett^Talk 16:08, 2 June 2006 (PDT)

Well, you CAN categorize images. We have a a system of image galleries at sporewiki shown here which rely on categories. The same can be done here, just make the naming the same as the game. If there is a game guide for Zelda: Ocarina of Time then create a [[:Category:. Zelda: Ocarina of Time images]] that all of the images related to that game are placed in. You can create other categorizations with maps and such by just adding them to [[:Category:Map images]] or anything like that. It creates a fairly easy to view display so you can fine the good ones easily. And of course the cats can have categories as well. That would be quite a task, but starting off a basic sorting program for images is a good start. -- Mason11987 ^{(Talk - Contributions)} 18:55, 2 June 2006 (PDT)

That would be really helpful, but we would need a lot of people to help us categorize everything... I wonder if we could send out an email asking users to come back and categorize any images they uploaded? Cosmo _{let's chat}

Aniki21 has started already without waiting for anybody. :-P He's using [[:Category:Character art]] (character renders, etc.) and [[:Category:Game art]] (covers, posters, etc.). I think these are reasonable enough to be made official. --DrBob (Talk) 11:31, 6 June 2006 (PDT)

Perhaps a more neutral "Game images" cat would be better? Just tossing it out there. -- Mason11987 ^{(Talk - Contributions)} 20:04, 6 June 2006 (PDT)

That's a bit ambiguous to me. 90% of the images we're uploading will be game images. --DrBob (Talk) 23:01, 6 June 2006 (PDT)

True, but I meant more along the lines of "images" instead of "art" for stuff like that? Like map images, or character images.

Maybe [[:Category:Game art]] should be [[:Category:Cover art]] or [[:Category:Game covers]]... Game art just seems a bit ambiguous to me.--Dukeruckley

I still think we should just use something like screenshots, game artwork, map, box art, or item for categories. It would be precise and easy. Cosmo _{let's chat}

The categories suggested as follows could be sufficient, with just enough so that we can distinguish what things are with no redundancy:

screenshot
sprite
model (3d character, enemy, etc models--the opposite of "sprite")
texture (would we use it enough to warrent it?)
artwork
boxart
photo (for pictures of CDs, cartridges, consoles, or accessories)
map
diagram (created to aid in understanding; these can be graphs, charts, etc.)
character (a further subcategory of 'screenshot', 'sprite', 'model', or 'art'. These include PCs, NPCs, enemies, etc.)
item (also a further subcategory of 'screenshot', 'sprite', 'model', or 'art'. An image of a vehicle, gun, or trap door would be an 'item'.)

We might be able to add game or series categories, but that could also be overkill. The only bad thing about MediaWiki--which we are now experiencing--is that it is sadly not very relational. ech elon 22:13, 15 June 2006 (PDT)

Those look reasonable. Shall I implement them? (If we do implement them, it would be a good idea to write an "official StrategyWiki policy" page regarding their use, just so they're noted down somewhere prominent.) --DrBob (Talk) 22:50, 15 June 2006 (PDT)

Yes, please. Cosmo _{let's chat} 13:40, 16 June 2006 (PDT)

(Cosmo you cheeky bugger. :-P ) I've implemented the following, adapting echelon's list to fit our standards:

All that needs to be done now is for people to categorise their images. :-( --DrBob (Talk) 13:53, 16 June 2006 (PDT)

Date Format

Should we start enacting the wikipedia standard operating posistion of linking Dates(game development, releases et al)? --Filthy swine 06:36, 7 June 2006 (PDT)

"Linking dates may not seem useful; however, please link dates since it enables the use of a user preference in how dates are displayed. An unlinked date, like July 13, 2004, will always be displayed in that manner. If you link the date:

[[July 13]], [[2004]]

Wikipedia will display it in one of the following ways:

July 13, 2004

13 July 2004

2004 July 13

2004-07-13

-according to the preference set by the individual user. (This feature is only available to logged-in users. It only works if the date is linked.)"

That might not be a bad idea. The only problem then is that we have a bunch of linked dates that go nowhere, unless we decide to make pages for them (which I'd say we don't need). Too bad there's no way to allow user preferences to come into effect without linking the dates (unless my understanding is wrong).--Dukeruckley 08:14, 7 June 2006 (PDT)

I would agree here; it could be useful to have a list of games released on each date. Each date should be in a category such as Category:Days for the dates, and Category:Years for the years (as on Wikipedia) just so they're easily accessible. On a different note: Filthy swine, could you please wait for a consensus in the discussion for something before going ahead and doing it? It's quite impolite to just rush off and do things before people've voiced their opinions. --DrBob (Talk) 09:01, 8 June 2006 (PDT)

This could definitely aid in navigation, so I'm all for it. There's certainly little harm in doing it. ech elon 21:54, 15 June 2006 (PDT)

I've started on it. Each date in the infobox is linked to a page, which then redirects to a category of the same name (e.g. 2004), which is also linked in at the bottom of the page. Each year category should be a subcategory of Years, and each day should be a subcategory of Days. --DrBob (Talk) 23:17, 15 June 2006 (PDT)

Board Games

Currently, StrategyWiki is pretty much solely for video and computer games. Are we open to create pages on board games and puzzles as well? For example, I might be interested in starting a Rubik's Cube page. Someone might be interested in a Chess page. Any thoughts? --Dukeruckley 09:58, 7 June 2006 (PDT)

I'm not an official person, but I don't think StrategyWiki is intended for things like that; it's based around video and computer games, and there are other places on the Internet which deal for board games. Let's see what echelon says when he gets back. :-) --DrBob (Talk) 11:22, 7 June 2006 (PDT)

The opening sentence on the main page says the purpose of this site;

"Welcome to StrategyWiki a collaborative wiki that seeks to become the largest source for videogame strategy guides!"

but I wouldn't be opposed to having non-video games. A strategy guide for poker would have relevence in real life as well as a video game of poker. As for the Rubik's Cube, a good Rubik's cube strategy guide is needed to solve it as fast as this guy

Note: my apologies for those of you that can't view a couple of those sites because of Flash issues, but until SVG is shown more support and improved on, it is sometimes the easiest way to do things on the interweb.

--Filthy swine 12:47, 7 June 2006 (PDT)

To clarify myself, this was support for the idea. --Filthy swine 13:20, 7 June 2006 (PDT)

To clarify myself. There are many sites out there for Rubik's Cube strategies, but not many with multiple strategies. I was hoping to throw them all together in one site (and my idea was to do so here). I would hate to have to find another site that I find respectable or create my own. Plus, this wiki would provide an easy way to upload images of the cube to give a visual representation of an algorithm.

While the site does mention that it is for video games, I see more benefits to adding board games than not. There are many places to find guides for video games and less so for board games and puzzles. Adding these could potentially lead to more people joining StrategyWiki in the long run. Meanwhile, as long as someone updates them and turns them into respectable articles, is there a reason not to add them to the site?--Dukeruckley 13:00, 7 June 2006 (PDT)

I am pretty much against the whole thing - I find it unnecassary for a videogame wiki. Cosmo _{let's chat} 13:16, 7 June 2006 (PDT)

It's a bad idea as the main page says that this wiki is for videogames. I don't think people want to see a repeat of what happened at WikiBooks! You can upload guides to board games at WikiKnowledge if you wish. Gerard Foley 16:24, 7 June 2006 (PDT)

So, it's perfectly acceptable then, to create a strategy guide for Rubix, gnuChess or MShearts, but when you decide to make the Civilization II guide, promptly direct anyone interested in playing the board game version of Civilization to another site. This board game business of theirs has nothing to do with this wiki. --Filthy swine 16:51, 7 June 2006 (PDT)

Hmm, the term "strategy guide" has always referred to video game strategies, so people searching for Rubik's cube strategies probably wouldn't go to a site called StrategyWiki. I'm not opposed to the idea to include board game and puzzle guides, but I don't think strategy guide sites would be the best sites for them to be. Unless the meaning of "strategy guide" can be broadened to include board games and such, you would be better off putting the guide on Wikibooks or creating a special wiki for board game strategies. --blendmaster 21:21, 7 June 2006 (PDT)

You've got to be kidding. "Strategy guide" doesn't imply in any way, shape or form that it should only be inferred to mean videogames. "Strategy Guide" has always meant "a guide to strategies", which can apply equally to videogames, board games, or even something like paintball or speechwriting. However, I don't think this is the place for strategy guides on boardgames, and certianly not something as complex as chess. There are enough books out there about chess to fill an entire wiki all by itself. Keeping StrategyWiki focused on videogames isn't a bad thing. --aniki21 04:16, 8 June 2006 (PDT)

Well, if you asked some random person what a strategy guide was, they'd almost always think of video game strategy guides. I'm not saying that strategy guides can't be for any strategies, its just the usage of the term today is pretty video game exlusive. I think it'd be better to put traditional game strategies on another site/wiki not because they should be allowed at this site, just that they would get too many pageviews here. Even if the site slogan didn't say video game strategy guides, someone coming here for chess strategies would say, "Oh, it has strategy guides, probably just for videogames" and find a different site. --blendmaster 15:33, 14 June 2006 (PDT)

From Wikipedia: "Strategy guides are instruction books that contain hints or complete solutions to specific video games. The exact meaning of a "strategy guide" these days is very vague, as most could be easily ranked as "walkthroughs" or "hint collections"." Added to this the fact that we explicitly state on the front page that we're for video games, and I think support for board games is ruled out. --DrBob (Talk) 08:55, 8 June 2006 (PDT)

Okay, fair enough. I'll have to search for somewhere else to do something like that. Meanwhile, I need to figure out what I want to work on the most here (I like this wiki the best out of everything I've looked at because of its layout). I wish I had more time...--Dukeruckley 09:35, 8 June 2006 (PDT)

Wikibooks appears to still have some sections on board games, such as chess: http://en.wikibooks.org/wiki/Chess. You could always get to work over there, and worse case you'll be transwiki'd some place like here.--BigCow 12:43, 15 June 2006 (PDT)

Initially I was going to say that I would have no problem with hosting guides for board games, chess-type games, or card games here. After reading many of your comments against doing so, I must say that my opinion has been swayed. It would be best to keep StrategyWiki soley purposed on videogames, at least at this point in time. My arguments would be the same as those of Gmcfoley, Blendmaster, et al. ech elon 21:52, 15 June 2006 (PDT)

Emulator Usage

Is there any established rule about how emulators and roms/isos/bins/etc can be used for helping with the StrategyWiki's? I can see it has some advantages (mainly the screenshot department), but I do wonder what the stance is in terms of using an emulator fully and not the original console for the walkthrough. Wolfman2000 21:28, 15 June 2006 (PDT)

To be honest, I took most of the screenshots that are present in the Zelda: Ocarina of Time guide with an emulator. I didn't really see the harm--I have three legal copies of the game. It would not have been possible to create crisp (or cheap) captures from the N64 or Gamecube, so I figured emulation on PC would be the fastest and easiest way. I can see where you are coming from, but I personally do not find a moral problem with this. ech elon 21:41, 15 June 2006 (PDT)

Although I think it would be best if this was an understood suggestion as opposed to an official one, since legally owning a rom you didn't personally create of a copy you personally own is illegal, and I would assume your situation echelon falls outside the bounds of legality I think it'd be best to not officially condone the practice at all, as 99% of the time, it is illegal, and with all of your reliance on following legal practice with licenses, that would be a bad thing. -- Mason11987 ^{(Talk - Contributions)} 07:39, 18 June 2006 (PDT)

We certainly can't recommend screenshots be taken using emulators, but unless you want guides to look like this one (or worse!) it's still expected that authors will use them. I think we could adopt Gameinfo's image use policy: "We do not condone or encourage the illegal use of emulators ... but pictures taken by such means are not disallowed (... they are under a "don't ask, don't tell" policy: do not state that the image was taken using an emulator)." As for talking about emulation for other purposes (e.g. translation patches, emulator-only cheats) that's a matter for another day. Garrett^Talk 15:50, 20 June 2006 (PDT)

I like the don't ask don't tell policy. -- Mason11987 ^{(Talk - Contributions)} 23:08, 20 June 2006 (PDT)

Gaining Major Exposure - A look at my plans for StrategyWiki

First off, I'd like to say that I'm back from my studying regimen, and I'm ready to get back to work. I'd like to explain some of the plans that I have for getting StrategyWiki to become a mainstream outlet.

My ultimate goal (which includes StrategyWiki) is to build a large and strong open (source) gaming media, one that I hope will take precedence over the present one. While IGN, Gamespot, and 1up do exist and do provide much information, I feel that they often pander to the lowest common denominator and don't really treat games seriously, take G4 as my case in point; the major gaming websites are owned by huge media conglomerates that ultimately don't care about videogames. The obnoxious use of flash popups and intersital ads on all three leading gaming websites is quite annoying to anyone wanting to glean information from their websites. This is why I hope to outdo them, with a news website just as big but with none of the bloat and baggage.

You may know that I created DSmeet with the help of two other college-level programmers (everything on the website, including the BBS, is custom-made). We've reevaluated and fine-tuned our abilities, and we all think that together with the use of the best open source libraries and development tools that we can build a website on par with, if not exceeding, what IGN has currently. We aim to complete this project a week or two prior to this year's Tokyo Game Show (held in late September), and this gives us all summer to work on the project. We'll probably spend the first two weeks designing the database schema and then shift into designing the program itself. (We're aided by an MVC and user/sessions architecture we have already developed.)

When this website is completed, I hope to publish both the articles on the website and the guides here on a strictly open media license, with as little restriction as possible (I am becoming uncomfortable with the strictness imposed by the GFDL). Both websites will cross-reference one another, so that visitors to either site will be exposed to the other. Consider this to be the same kind of relationship that exists between Gamespot and GameFAQs. After we have the website firmly polished and running smoothly, I will begin to work on extra tools for StrategyWiki such as "cached guides" (including pdf downloads of guides); a "tag" concept, much like exists in Subversion or CVS, allowing us to mark a certain version of a guide with a name to better manage and locate things; and, as we have discussed, video tools to enable short video explanations or complete sectional walkthroughs.

The news website and StrategyWiki are not the ultimate end, and I see this ideal being even greater in scope. I would like to create a *completely* open media relational database of games (like Moby Games) except without any restrictions on use (it would not be MediaWiki-powered, since wikis are not relational); it too will be placed under whatever OS license we choose. I hope that ultimately our efforts in these three quadrants will lead to a better gaming media, and that we can provide inspiration to game developers through our work.

A note about our server: We do have the server capacity to host all of this. If it becomes too big of a hit, we can always order a bigger one, though my plan is to slowly upgrade as needed. By the end of the summer, I will move the StrategyWiki website to our dedicated webserver, which currently houses DSmeet.

Another note about license: I want all three websites to use the same open source license (for consistency). I want it to impose as few restrictions as possible (eg, it ultimately can't be GFDL for the reasons we have previously underscored), but still be copyleft (eg, it can't be public domain): I want others to be able to use and extend our content as they like, but not be able to take it away its openness and horde it for themselves. Creative commons is looking really good right now.

In closing, I don't think that I'll be able to do a lot of guide writing or screen captures this summer (actually, I can't do screen captures at all until I fix my primary laptop with which my gamepad works). However, I will be around to help with technical issues, construction of important templates and and javascripts, and to input my two cents on key issues.

Do you guys have any comments? Complaints? Suggestions? ech elon 21:37, 15 June 2006 (PDT)

I think, for StrategyWiki, you need a better look and feel/site design. IMO it just looks a bit too much like gamefaqs right now. I don't know how good of a graphic designer you are, but StrategyWiki needs a better logo and mediawiki theme, or at least a few tweaks to the ui. DSmeet looks nice, and the logo is unique. Maybe you should have a logo contest for StrategyWiki, or somthing like that. --blendmaster 10:06, 16 June 2006 (PDT)

I personally like the skin we have right now. It is honestly the best theme I've seen yet and it is part of the reason I'm sticking with it here. A change in the logo would be fine, but don't change the skin entirely. It is very clean and easy to follow and it is pretty unique. What kind of tweaks to the UI were you thinking of? As for looking like GameFAQs, the only similarity I really see is the color blue.--Dukeruckley 10:20, 16 June 2006 (PDT)

I would agree with Dukeruckley here. I like the current skin. :-) --DrBob (Talk) 10:32, 16 June 2006 (PDT)

Well, mostly, I just don't like the clouds, and the blueish color scheme, but again its my opinion. On UI tweaks, I think the items on the left side should be running along under the logo horizontally, so the page could spread left more. Also, if possible, I think the built in table of contents for pages could be positioned underneath the toolbar section on the right side, like some of the custom walkthrough table of contents people put there. --blendmaster 13:48, 16 June 2006 (PDT)

I'd like to remind everyone that skins can be chosen (there are a few different ones to pick from) in your preferences. And if there is enough support for one skin, then one of the other skins can be replaced if we want a new one, or another one can be appended to the list. There need not be just one skin. But if there is going to be an option of skins here (with more then one being "mainstream") then maybe a similar option should exist for the site? A site I visit http://www.planetspore.co.uk/ has something like that (although looking at DSmeet, you could do much better then that). I love all your ideas and I'm on board to help out with whatever I can do on mediawiki especially, but with anything else too. On another note, what's up with this spam filter, we can't give outsite links here? -- Mason11987 ^{(Talk - Contributions)} 07:49, 18 June 2006 (PDT)

Cleanup project

I've created [[User:DrBob/Cleanup|a page]] consolidating all my cleanup efforts, and I'm hoping it can make it somewhere useful, like [[StrategyWiki:Cleanup]]. I would like to make it a recognised "sub-project", and possibly involve more people in maintaining and cleaning StrategyWiki. I would also like [[User:DrBob/Wikify]] to be made official, and used on pages which need wikification, so they can more easily be found. --DrBob (Talk) 23:36, 15 June 2006 (PDT)

Can I recommend a kind of policy similar to sporewiki's cleanup page? http://www.sporewiki.com/SporeWiki:Cleanup?

Official StrategyWiki law

Wikipedia has many "Wikipedia:Insert_law_here" pages, detailing the guidelines and ways in which Wikipedia should be used and layed-out. I propose that we write a few of these – mainly based around editing structure – to help people format their pages properly. May I also suggest that we have one listing all the system templates we've created (such as wip, stub, etc.) so that they can all be found in one place, perhaps with an example? --DrBob (Talk) 23:38, 15 June 2006 (PDT)

I definitly think this should happen. I think once a policy that gets disscussed here is finalized, It should be made into a Law page, written up nice and clearly, and the discussion that was once here moved to the talk page of the law. The only problem now is that we haven't really finalized any big policies yet. --blendmaster 13:51, 16 June 2006 (PDT)

My biggest recommendation is to implement these few policies/guidelines (like their wikipedia examples, but not exactly the same obviously): Be bold, Assume good faith, and a policy stating that noone "owns" a guide. Wikipedia has something like that last one, but I can't find it. It's best for this kind of thing, as long as everyone is bold in adding what they think is useful, and noone thinks they own the article, they will assume good faith in discussing the changes maturly. Besides these three, everything else is specific instances. As long as everyone follows these, this site will function perfectly well I believe. -- Mason11987 ^{(Talk - Contributions)} 07:57, 18 June 2006 (PDT)

Including enemy lists, item lists, and other big table data

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

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

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

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

CSS class for "notice" templates

It would be useful if there was a CSS class for "notice" templates which are stuck at the top of a page, such as Template:wip and Template:stub. This would mean styles aren't duplicated across templates, and remain consistent. May I advise "messagebox" be the class name, and "float: center; margin: 10px; border: 1px solid #7d87bc; background-color: #d0d5f1; padding: 3px; font-size: larger;" as the properties for the class? --DrBob (Talk) 10:37, 16 June 2006 (PDT)

You are a sysop, you can edit MediaWiki:Bluecloud.css can't you? :) Would you mind adding it to MediaWiki:Monobook.css while you're at it? Thanks. -- Mason11987 ^{(Talk - Contributions)} 08:03, 18 June 2006 (PDT)

I've added it (I wasn't a sysop when I first brought this up), but haven't used it in any templates yet. --DrBob (Talk) 23:01, 20 June 2006 (PDT)

More project administrators?

I've made DrBob an administrator so that he can do some of the more routine organizational work that he tends to do. I was thinking we could use a few extra administrators as well in order to block spam and keep the wiki clean. If any of you would like to take the job let me know. (Depending on the number of applicants we may or may not do this by a voting process. I'm not really sure of the best way to handle it this early on.) ech elon 11:48, 17 June 2006 (PDT)

I might be interested in being an admin, though I don't exactly have the most time in the world right now. How much work would be involved here? I'd like to help out in any way I can, but I don't want to make a commitment to something that will be too much for me to handle at the moment. If, on the other hand, being an admin would be something I can do without spending hours online, I'd be very willing to take it on.--Dukeruckley 11:05, 19 June 2006 (PDT)

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

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

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

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

I don't think there was one: the decision is afaik up to echelon, but you've got my vote. :-) --DrBob (Talk) 13:42, 5 July 2006 (PDT)

I had to leave a message on his talk page to have him sysop after he suggested it on my talk page. I recommend you do the same. -- Mason11987 ^{(Talk - Contributions)} 21:41, 5 July 2006 (PDT)

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

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

Release days should not be a category

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Clarified Discussion

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

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

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

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

I believe it could via the cat tag [[category:name|01]] would put it in a 01 section I believe. -- Mason11987 ^{(Talk - Contributions)} 09:00, 21 June 2006 (PDT)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Spam filter

On another topic I tried to link to: http://www.planetspore.co.uk/ to show an example of something I was saying but it said the spam filter blocked it. It seems kind of pointless to block potentially legimate site when anyone with some knowledge of mediawiki can get through it anyways as I did. Or perhaps a blacklist with particular sites would be best? Maybe something like the "Filter Set G" extension for adblock for firefox? I'm not sure how these thigns work, but that site shouldn't have been blocked. -- Mason11987 ^{(Talk - Contributions)} 07:51, 18 June 2006 (PDT)

I'm not sure why planetspore would be blocked, but that's definitely not something we want. I'll make sure to fix it. ech elon 19:34, 20 June 2006 (PDT)

I checked out our blacklist, but I'm not sure what is causing it. There appear to be no matches for planetspore.co.uk on our blacklist... ech elon 19:58, 20 June 2006 (PDT)

I found it. The pl ban also catches planet, so I've disabled it for now. You can easily check things like this by saving a page with a blacklisted URL and reading what the error message says triggered it. Garrett^Talk 00:57, 21 June 2006 (PDT)

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

Max Image Size

I have acquired numerous images of boxart for various games on the internet as of late for this site. However is there a limit as to how large the boxart should be? I know it can't be terribly large however having a set size limit would be good for future progress. I was unable to find any limit while looking over the site. I do know that on Wikipedia that somehow the images automatically scale down some if they are too large, is there any way we could implement that here?--Chrono Warrior 3 21:34, 18 June 2006 (PDT)

Scale down when? When uploading them or when displaying them, the second is easy enough to implement, the first might not be so easy. -- Mason11987 ^{(Talk - Contributions)} 23:49, 18 June 2006 (PDT)

MediaWiki will automatically cache scaled versions of images where pages specify the size of the image to use. The standard size at which box artwork/company logos (etc.) are displayed on the relevant pages is 250px wide. Just upload the images as big as you like, then make sure to put "|250px" after the image name in the image reference (e.g. [[Image:Example.jpg|250px]]) when writing a page. Also make sure you categorise your images when you upload them. :-) --DrBob (Talk) 09:14, 19 June 2006 (PDT)

Trying a new homepage

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

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

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

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

StrategyWiki:Copyrights rewrite

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

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

Master List of Games

I know we have games listed in catergories, but do we have a page with each game on it? I think it might be useful to put a master list of all games that currently have functional guides. People who browse this site just for fun (not necessarily looking for a particular guide) might find it a hassle to have to keep clicking through different categories. The downside to a master list is of course the effort it would take to keep it up as StrategyWiki gets larger. Any thoughts? --Dukeruckley 06:27, 18 June 2006 (PDT)

If you think about how people are going to look for games, they're either going to know which game they're looking for (in which case they'll use search), or want to find out about games in a particular genre, or for a particular console. I can't see many people at all just wanting to see a list of every game we've got, and it would take a lot of effort to keep up-to-date. --DrBob (Talk) 07:29, 18 June 2006 (PDT)

Well if NCL was added here, this might be possible, and would require no effort to keep up to date. I'm making another topic to talk about this. -- Mason11987 ^{(Talk - Contributions)} 08:08, 18 June 2006 (PDT)

Not everyone is always going to know what they're looking for. Especially at the stage we are at right now, where we don't have a whole lot of strategies yet (we have a good amount, but nothing spectacular). If someone doesn't find the game they're looking for they may think, "what games do they have?" and then want to see a list of games. Instead of having to click through a bunch of genre or console lists, it might be nice to have a single list of everything.--Dukeruckley 07:22, 19 June 2006 (PDT)

Good point. --DrBob (Talk) 09:16, 19 June 2006 (PDT)

I was thinking it would be a good idea to categorize guides by overall completion level. We could easily place each level in an overall category of "All guides", thus killing two birds with one stone. Thoughts? ech elon 10:19, 19 June 2006 (PDT)

An interesting idea, though it might be difficult to implement. Mainly, how do we determine which guides are the most complete? While it might be obvious for some guides, it'll be less obvious for others, namely MMO games that are constantly updating. Couple that with that fact that the guides on this site will continue to improve and more content added, we'd have to update the list very often. A simple alphabetical list would probably be the best idea, unless we can think of a way to defines a level of completeness and are willing to update the list often.--Dukeruckley 11:02, 19 June 2006 (PDT)

Well we have that 4 boxes things for sections of guides, like the FFVII one, we could just have a template that puts one down for the whole guide, and depending what image you use, it will categorize the guide into a different place. And optionally all guides could ALSO be in a [[:category:guide]] category which would categorize all of them and sort them alphabetically too. -- Mason11987 ^{(Talk - Contributions)} 13:13, 19 June 2006 (PDT)

NCL

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

==In-game creatures==
<ncl headings=head headstart=3>Category:Creature creations</ncl>

==Creature concepts==
<ncl headstart="3">Category:Creature creation concepts</ncl>
<ncl headstart="3">Category:Creature Creation Concepts</ncl>

[[Category:Full content lists]]

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

I definitely agree with this. Very useful. :-) --DrBob (Talk) 08:29, 18 June 2006 (PDT)

Relicensing plan

[[StrategyWiki_talk:License#Relicense_StrategyWiki_Plan_-_This_is_important.21|Check this out]] and comment please! (Your comments to this Community Issues post are not necessary, so please do so on the License talk page instead.) ech elon 04:05, 23 June 2006 (PDT)

Contributors list

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

I did moan about this in my requests for help in articles section. Once I've had a shower, I'm going to create some more templates to put on pages such as this (probably wikify and drivel), and then go through and clean up some of the pages. --DrBob (Talk) 03:28, 25 June 2006 (PDT)

I'd first move those sections to the talk page, I really don't think notices that big are necessary, the reader may be impacted by a useless contributors list, but I am possitive they will be impacted by a massive banner on top of the guide. I understand the Wip ones and the spoiler ones being big, but these should be minimal like the corresponding ones on wikipedia, or even just throw cat tags on them instead of those huge templates. -- Mason11987 ^{(Talk - Contributions)} 06:59, 25 June 2006 (PDT)

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

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

I agree with that, since wikify is more important for readers I believe. -- Mason11987 ^{(Talk - Contributions)} 22:50, 25 June 2006 (PDT)

Guide navigation

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

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

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

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

What about sidenavs (e.g. [[Template:Zelda: Ocarina of Time Nav]]), will those ever become part of a standard? At the moment they don't display correctly in skins other than BlueCloud and Monobook, but that's easily corrected. Garrett^Talk 20:23, 25 June 2006 (PDT)

I'm really waiting for some large amounts of free time, because I have this idea to make a new Javascript system to make not only the sidebars work, but also have them presentable in condensed form. It'll take a lot of work though, so... ech elon 20:34, 25 June 2006 (PDT)

I just realized there was no such template on SW, so I went ahead and created one, albeit not a very good-looking one. Anyone with better designing skills is more than welcome to improve upon. Alex 19:43, 25 June 2006 (PDT)

What about Template:Wikify and Template:Drivel? Are these too specific to the point we need a Cleanup template too? Hm... ech elon 20:33, 25 June 2006 (PDT)

Well, cleanup is a notice that is more broad then wikify, and is an actual message to readers unlike drivel (and as I stated above, I don't think drivel would have been an appropriate reader visible template anyway). -- Mason11987 ^{(Talk - Contributions)} 22:53, 25 June 2006 (PDT)

Ah, understood. Good point! ech elon 23:32, 25 June 2006 (PDT)

I think this is redundant. All possible cases are covered by wikify, and if the wording on wikify isn't broad enough to cover them, then it can be changed. We're not big enough yet to need hundreds of different templates for each conceivable problem with a page. --DrBob (Talk) 23:40, 25 June 2006 (PDT)

Bad grammer, paragraph structure, organization or unclear explanations are all already "wikified" but they still aren't really fit to be here in a "completed" sense, although I do agree that we shouldn't need many templates. I believe wikify covers really simple changes that could be done with a smart enough bot honestly, while cleanup would be stuff that would take much more then that, and much more time then doing wikifying manually. -- Mason11987 ^{(Talk - Contributions)} 00:28, 26 June 2006 (PDT)

Hm, well I'll let you guys figure it out. I did manage to change the presentation of the template, though I could not include an icon. ech elon 23:44, 25 June 2006 (PDT)

It was really unobtrusive before, but still informative, I really prefered it as it was. -- Mason11987 ^{(Talk - Contributions)} 00:28, 26 June 2006 (PDT)

Ah, hmm. I was trying to go for a unified look with Template:Wikify, but I see what you are saying. ech elon 00:57, 26 June 2006 (PDT)

I prefer Echelon's version, as paragraphing, organisation, unclear explanations, etc. all affect the user quite considerably (just as much as wikification issues), and so the template should be the same size and have the same emphasis as wikify. (I've been persuaded that this template is necessary.) --DrBob (Talk) 09:31, 26 June 2006 (PDT)

I'm afraid to say I didn't know about those other two templates when I made this one, but I do think that there is significant difference to warrant keeping them all. I think the new look is good, but maybe a bit big. Alex 11:43, 26 June 2006 (PDT)

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

If we shrunk it to that size, it would be good. I do like the icons though... ech elon 23:06, 26 June 2006 (PDT)

the icons are fine, but 96x48px? That seems rather large for an image that has absolutly nothing to do with the guide it is on. It should be big enough so that editors always spot it, but small enough so that casual readers aren't distracted by it or even better completly ignore it. -- Mason11987 ^{(Talk - Contributions)} 23:10, 26 June 2006 (PDT)

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

Donkey Kong: A good example or a mess?

Hello. I'm a supporter of this site's mission, and I decided to help out by adding some retro gaming content. I started out by simply transplanting some guides I wrote for early Nintendo games here, namely Donkey Kong, DK Jr., Popeye, and recently Mario Bros. Well, tonight I got a bug up my ass or something and tried to reformat Donkey_Kong in to something... I dunno, more grandiose I suppose. I'm not sure if I succeeded or ruined it horribly. I tried to copy as many examples from the Legend of Zelda: Ocarina of Time pages as I could, like the TOC, next and previous pages at the bottom, and I broke the page up in to multiple pages, which Garrett has been helping me fix up, thank you for cleaning my mess :) But honestly, I'm not sure if it's better now than when it was a simple one page thing (compared to, for example, the Donkey_Kong_Jr. page. Since DK was on more than just the NES, I also wanted to expand it to cover every system that it was on, so I began including port pictures on relevant stages. Anyway, I'm rambling now. Feedback would be most appreciated, either here or on my talk page. Thank you very much.Procyon^Talk 21:31, 27 June 2006 (PDT)

Overall, it looks good. Why, however, is the characters page called "Elements"? Also, could you please categorise your images and provide a link to the guide for which they're being uploaded when you upload them? --DrBob (Talk) 22:20, 27 June 2006 (PDT)

This guide might be better off in just one page, but maybe not. It's kind of close to that line. But in this case I'd just defer to the original author. It looks great for a multi-page guide and if you think it needs multiple pages, then that works :). I do like the Jr. one too though :). -- Mason11987 ^{(Talk - Contributions)} 23:00, 27 June 2006 (PDT)

Thank you very much for your feedback guys, I appreciate it. DrBob, I named the page Elements because, as you've pointed out, it also needs a control scheme. So it should contain both characters and controls. It's an old throw back to Joystik magazine and the Nintendo Player's Guide which I use as inspiration for layout. However, now that I'm abstracting Donkey Kong from being NES specific to arcade focused and port aware, I will try to include a picture of the original arcade control panel and label that instead. Then more port pictures to follow (mostly for fun.)Procyon 06:46, 28 June 2006 (PDT)

Following up to my own post, I've had a lot of time to clean and fine tune the pages, so I think it's turning out quite nicely. I've added a lot of port screenshots, but I think I'm done with that for the time being (although if someone's favorite version is missing, I hope they'll continue to add to the gallery.) Thanks to this, I've got a good rough idea on how I want to proceed with Pac-Man. Feedback, as always, is welcome. Thanks.Procyon 16:54, 28 June 2006 (PDT)

Game Titles

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

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

I too have no idea about Chip's Challenge Level Pack 2, but the other two examples you gave are fine at the moment. :-P --DrBob (Talk) 12:57, 28 June 2006 (PDT)

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

Wikipedia-compatible infobox

Why not allow people to use the same variable names for Template:Infobox as are on Wikipedia:Template:Infobox CVG (e.g. genre instead of categories), to allow a straightforward copy-and-paste? If it's not possible to specify alternate variable names in the same template, one could create a new one and call it Infobox CVG. Seahen 09:39, 29 June 2006 (PDT)

People shouldn't really be copying and pasting, especially with the license change coming up. It would be an awful lot of work to change every reference to infobox's parameters, and bringing in another template would just introduce fragmentation. It's not hard to just use the variable names currently in use. --DrBob (Talk) 10:13, 29 June 2006 (PDT)

The template could be easily changed (using default values) to work with both the wikipedia parameter names, as well as the strategywiki ones, that way a copy paste of an infobox (while not recommened) would be functional. If I knew the parameters of the wikipedia one, and knew the comparable ones on this one, I could do that. -- Mason11987 ^{(Talk - Contributions)} 22:18, 29 June 2006 (PDT)

Cheat Codes

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

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

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

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

Table of Contents markup

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

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

A new table of contents

What are your thoughts on The Legend of Zelda: Ocarina of Time's new table of contents system? It needs a bit of polishing, but I think this will become a standard for larger guides. ech elon 16:44, 26 June 2006 (PDT)

It's pretty nice, and I think it should be automatically visible. Or at least easier to notice (it took me a second to see where it is). Alex 16:51, 26 June 2006 (PDT)

I'm thinking of storing the show-hide preference in a cookie. You're right about making the link more apparant, though. We need a small icon or something to go with it. Maybe two images: an up and down triange. ech elon 17:10, 26 June 2006 (PDT)

I think it should be shown by default on the first page. Right now it's little different from the old cover page idea, a click is still required to see the TOC. I also prefer the sidenav just a little bit more since it's always there and makes use of the otherwise wasted right-hand column. Garrett^Talk 17:53, 26 June 2006 (PDT)

The sidebar required for the sidenav TOC isn't present in other skins. I am thinking of an option that lets the user choose whichever type of navbar they want, though. (I didn't by any means delete the sidenav script.) Currently, I must say that I prefer this new inline TOC to the sidebar one; it allows much more options, such as organized multi-column navigations and inline images. Plus, you don't have to scroll down the page to see the whole TOC, and that's a very annoying part of the sidenav TOC. Again, I'll still try to find a solution that allows the user to choose either one though. Just keep in mind that I am not done by any means--the new inline TOC needs some kind of image to make it more obvious, a little tidying, a saved user preference, an init variable, etc. ech elon 21:45, 26 June 2006 (PDT)

I think I made some useful changes that appears to work very well on both bluecloud and monobook. The .js file can be edited so that the nav always shows up by default, but I think having it hidden by default is best (unless you can store it in cookies, that would be even better). I had to edit a few files to get it to work the best, and couldn't find the "GuideTOC" style anywhere so I used something without that. Sine that style probably won't be used outside of that template I don't see why it should be a reference in some file that is uneditable, you know? I think this is simple and clean, while being very useful at the same time. It could use some polish of course, but I think it's even better now. -- Mason11987 ^{(Talk - Contributions)} 22:57, 26 June 2006 (PDT)

It looks nicer, but the show/hide doesn't seem to work anymore. (I did dump my cache...) Do you plan to reimplement that? I think the hiding feature is the best attribute of the template. I'll try to add cookies support tomorrow. ech elon 23:04, 26 June 2006 (PDT)

Try it again. You changed the dynamic nav stuff to be specific to TOC related things. This chang allows dynamic nav to be used in all kinds of things, including the todo lists (check your user page in a little bit to see the changes I'm making to that). -- Mason11987 ^{(Talk - Contributions)} 23:15, 26 June 2006 (PDT)

When you click on "show" in the new ToC, there is a minor bug where it still says "Show" underneath "hide". In other words, you get two words meshed together. Can that be fixed? Other than that, everything looks great!--Dukeruckley 05:59, 27 June 2006 (PDT)

I'm not that good at javascript so I'm going to leave this to echelon or drbob. It's odd that this bug doesn't exist when using monobook, but does in MediaWiki:Bluecloud.js, even though the .js files are exactly the same...how strange eh? Good luck guys :). -- Mason11987 ^{(Talk - Contributions)} 08:23, 27 June 2006 (PDT)

Eh? You called? What do you want me to do? (BTW, I think the ToC template is too big at the moment: imho the border should be removed, to let the ToC contents fit in with the rest of the page.) --DrBob (Talk) 08:52, 27 June 2006 (PDT)

Well, the TOC at the top of every zelda page (and actually the dynamic navigation system as a whole) functions without that little bug duke mentioned only when it's on monobook, on bluecloud it has that bug he mentioned, and with your "BTW", are you referring to the zelda TOC page itself or the dynamic nav system used in Header Nav? -- Mason11987 ^{(Talk - Contributions)} 09:38, 27 June 2006 (PDT)

I'll take a look at the bug later, but I am referring to the dynamic nav system itself. IMHO, the "Table of Contents" link in the Header Nav proper (i.e. the one which has always been there) should be emphasised more, and when clicked, expand the full table of contents, with a light grey border around the bottom, left and right to separate it from the content, and perhaps with a "tab" effect applied to the Table of Contents link the user just clicked. I don't like the fact that it's expanded by default (takes up far too much space), and the current border and grey title bar doesn't fit in; neither does the reduced width. --DrBob (Talk) 10:04, 27 June 2006 (PDT)

I believe I get what you're saying. It is strange to have a TOC link and also have the dynamic nav, and if possible I would like to be able to have clicking the TOC link bring down the whole nav. Perhaps the entire content of Header Nav should have a border around it to seperate it from the content? I think that would make things clearer. It's kind of hard to get exactly what you mean, but if you set up a test Header Nav to mess with styles it might be easier to follow. -- Mason11987 ^{(Talk - Contributions)} 11:11, 27 June 2006 (PDT)

I've fixed the show/hide problem (a dirty hack, because the function creating the show/hide links was being called twice and I'm not about to debug that) in BlueCloud, but not Monobook because you said the problem doesn't occur with it. I've also created a [[User:DrBob/Header Nav|WIP mockup]] of what I was thinking of for the ToC stuff, incorporating your idea of bordering the Header Nav entirely. --DrBob (Talk) 12:37, 27 June 2006 (PDT)

I think that is very cool, I changed the Counter-Strike:_Source/Table_of_Contents page so that it didn't include the infobox. Perhaps it can be set up so that the infobox is shown on the page whe you view it, but when it is included it sets up the TOC horizontally? It seems like a lot of effort for this to be done on most multi-page guides, but I definitly like the style. I think this will look amazing on the zelda guide, just each guide will have to figure out exactly what will be included in the template. -- Mason11987 ^{(Talk - Contributions)} 20:25, 27 June 2006 (PDT)

I made some more changes, so it appears exactly the same on the TOC page itself, but when used in the template it looks much cleaner. -- Mason11987 ^{(Talk - Contributions)} 20:33, 27 June 2006 (PDT)

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

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

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

End random section that doesn't belong here

Starting a new indent. While I like the look of the menu that Mason did more than mine (it's more compact, more noticiable to the user, and a little more organized), I can't help but feel that it was a step backwards:

The new version is attempting to be the show/hide template from Wikipedia, thus in essence trying to be a more general script. The one I designed was specific for the purposes of the Table of Contents alone. In my opinion, the biggest problem with the new one is that it requires a seperate bar for the "show/hide" portion of the Table of Contents, and that looks cluttered. I don't know how many saw the one before, and though it was certainly not perfect, it made the "show/hide" link a part of the All_Games_Nav itself. I think the new one, while more noticable, is a bit too jumbled looking. We need something that employs the benefits of both, but we absolutely have to get rid of that bar at the top; it looks far too cluttered.
The original ToC that I designed was not set into any formal kind of standard. Different guides may require different types of data displayed under the Table of Contents--perhaps diagrams or images. While I'm not sure if this is the case or not, but the new one seems like it wouldn't fit those types of things.

I hope I'm not trying to backstep or be redundant, but I do feel that we should revert back. The show/hide template for Wikipedia will have uses here, I just don't feel we should use it for the Table of Contents. (Sorry Mason, I know you must've put a lot of work into it :( ech elon 13:09, 28 June 2006 (PDT)

I'm not quite sure what you mean here, although it has been a long day. Have you looked at my [[User:DrBob/Header Nav|spiffied up version]]?

I kind of get what you're saying, but I think as it is now it's got it's advantages over the older one, but if you have improvements to this or even a completly different style that has more advantages I think it'd work great. The spiffed up version DrBob made is quite a big improvement over the one I made and I think it takes into account some of your ideas. Also, I didn't get the show/hide on the version you had before, although it IS possible that was my fault. I think the bold change you did with the Header Nav got us into a Bold-revert-discuss cycle which is one of the best ways of getting the most out of this. Feel free to change the one I made, but I DO think it is an improvement over what was there before, even if it has it's faults which is completly open to change which DrBob has done. -- Mason11987 ^{(Talk - Contributions)} 15:30, 28 June 2006 (PDT)

The version that DrBob is working on looks great! This is the first I've seen of it. It's pretty much a better looking mix of your version and mine. The only thing that might be problematic in his version: I'm not sure about the use of ==Heading== markup, since doing so causes the wiki-generated table of contents (__TOC__) to go berzerk. If we could replace the headings with <big> and bold markup, it won't interfere with the toc and would be flawless.

As for the show/hide on my version, DOM javascript turned the old "Table of Contents" link into a "Show Table of Contents/Hide Table of Contents" link. It was rather obscure, and it needed some kind of image or something--DrBob's version fixes that and looks even better than before. Let's go with his, and if there are any further improvements to be made, we can make them when they arise.

That said, I think this is pretty cool. Our top navigation menu is really slick! ech elon 19:26, 28 June 2006 (PDT)

DrBob's template looks really nice, but I really think we should change the Header Nav template. Right now, the Introduction and Table of Contents just link straight back to the main page, so its pretty redundant. I think the always visible part of the Table of Contents thing should be customized to the guide, with links to the main sections, such as Walkthrough, Extras, Codes, and stuff like that, instead of the default main page, intro, and toc. --blendmaster 13:16, 29 June 2006 (PDT)

Mine is being developed as a drop-in new version for the Header Nav, so I can't see any problem with bringing such changes into mine, and then moving them forward to Header Nav. Your point that many guides just have the ToC and intro redirect to the main page is very valid: we should look around for some other standard pages to put in instead (although the link to the ToC should stay as all guides should have a separate ToC page when this new Header Nav is rolled out, due to the fact that it references them). --DrBob (Talk) 14:06, 29 June 2006 (PDT)

I'd migrate your version in as the default now, then continue using it as an in progress version. If Header Nav is going to be used on every guide (as it's name implies), we may want to have it protected at some point, and having a test version would be great too if we get it in the template namespace also.

But the different links could easily be set up, we just have to figure what would be the best setup. I don't think an "intro" page needs to exist, having a page for the game title (the main page), then a TOC, then a walkthrough would be good enough I think. The rest can go in the TOC dropdown. -- Mason11987 ^{(Talk - Contributions)} 22:21, 29 June 2006 (PDT)

I think we need "Walkthrough" as an introduction on how to use the walktrhough portion of the guide. (If there are specifics that the reader must pay attention to, etc.) There is also an ulterior motive for this: SEO (Yahoo *really* loves StrategyWiki). I suggest a "Cheats", "Tips", or "Codes" section for the Header Nav as well. Perhaps the Qif can be used to specify which elements are shown. As for the link to the Table of Contents? That's slightly important: it serves as a link to edit it. Of course it could also be obscured, though. ech elon 19:24, 1 July 2006 (PDT)

I've moved mine forward to the Header Nav page proper, and removed the "Introduction" link, but I haven't added any extra links, pending decisions in this discussion. Think, people! --DrBob (Talk) 18:25, 7 July 2006 (PDT)

I would try going with a link to an Extra/Appendices page, where all of the cheats, weapons information, enemy information, stage information, etc. link off of a main page. For example, in OoT, this would be under Extras, or in the Biohazard guide, this would be under Appendices. But this can't apply to every guide, since some are split into smaller sections or don't have a universal name. Anyone else think an Extras/Appendices link is important and maybe consider every guide to have an Extras page with all miscalleneous information? --Antaios 05:12, 8 July 2006 (PDT)

I don't think such a general title is what we need. We need to identify something present in most guides with a similar level of specificity as "Walkthrough". I really don't think a "Miscellaneous" page (which is basically what you're suggesting) would be useful. "Cheats" would be good. --DrBob (Talk) 05:59, 8 July 2006 (PDT)

I'm for a "Cheats" section. -- Mason11987 ^{(Talk - Contributions)} 06:53, 8 July 2006 (PDT)

I suppose so. Would the Cheats section have Secrets/Easter Eggs too, or just like Gameshark codes or button combination cheat codes? --Antaios 07:46, 8 July 2006 (PDT)

The cheats section would have whatever's appropriate for the guide. :-) I've added it to Header Nav. --DrBob (Talk) 08:26, 8 July 2006 (PDT)

Ok, cool. I was just making sure. ; ). Looks good though. --Antaios 19:41, 9 July 2006 (CDT)

Sorry, haven't been around in a while. Been very busy... I don't think a Cheats section should be part of the Nav. Particularly because some games don't have any cheats. For example, Earthbound (which I know has been used for a lot of examples lately, but oh well) has no cheats in it. This means that a red link will be at the top of every page, making it look less complete. I'd recommend something more like "Secrets" which would include anything from cheats to easter eggs, etc. Or maybe "Tips and Tricks" would be more appropriate. It should be something less specific, basically.--Duke Ruckley 20:27, 11 July 2006 (CDT)

I think Extras would be good for a standard section, which could include pretty much anything. Then, you just have to include an option in Header Nav to include more custom sections, which could be done with a custom attribute with the default option as blank, the wikicode being {{{custom|}}}. --blendmaster 22:31, 11 July 2006 (CDT)

Well, I went ahead and added a custom attribute. It uses the qif template, but the implementation isn't that good. If someone wants to make it better, please do. --blendmaster 22:52, 11 July 2006 (CDT)

I really don't mind. Redlinks at the top of guides are bad, not many guides would use the cheats section, and now that you've added a custom section blendmaster, I'll remove the cheats link. :-) --DrBob (Talk) 01:01, 12 July 2006 (CDT)

The new table of contents looks really good, but I don't think there should be a hidden table of contents on the main page of a guide. If you look at The Legend of Zelda: Ocarina of Time with the table of contents hidden, there really is no indication of where to go next. The main page should have the table of contents non hidden by default, preferably below the intro rather then with the Header Nav template. Also, there should be links to the Getting Started and Walkthrough portions of the game. Example: Main page of [[Earthbound]. Although it kind of goes overboard with images (I'm sorry), I think it is a good example for a main page of a guide. It has a full table of contents without an extra click, and links to sections that the reader will want to follow if they want to see more of the guide.

Just one more thing. If the entire table of contents is under the show/hide thing, is the link to a standalone Table of Contents necessary? I realize the page is there to be included in the Header Nav, but if all the standalone page adds is a spoiler template in the noinclude section, then why link to it anyway if its on every page in the Walkthrough? A solution would be to make the include page in Header Nav, the "lite" table of contents, be under Game Name/toc and not meant to be read standalone. Then make the link version of the table of contents have fleshed out descriptions of each section, to make it worth a standalone page, something like the Table of Contents of Super Smash Bros. Melee, only better. I realize the same thing could be done by including numerous includeonly tags within the Table of contents, but that would make the markup hell. --blendmaster 11:54, 11 July 2006 (CDT) (continued below)

I'm split between referencing the table of contents page under a heading on the main page, which would introduce problems when the ToC page is split into columns, or hacking the Javascript so that the ToC is expanded on the main page. Both have their advantages, but I'd be tempted to go for the second one. There is a discussion somewhere about optional extra links for the Header Nav template.

The discussion about the link to the ToC has been had before, and it's staying. It provides a link to the page so it can be edited, and once I get around to doing the Javascript, it'll control the show/hide of the ToC in the Header Nav. --DrBob 16:30, 11 July 2006 (CDT)

I think that was DrBob ^. The Problem with just making the Header Nav defaultly expanded on the main page is that the intro is then pushed down farther off the page. A hack I did for Earthbound was to make enclose everything on the main page in noincludes except the Table of Contents stuff, and kept the Table of contents page to a redirect. That way, the main page still gets a good table of contents, and whenever the Header Nav calls the Table of Contents page, it will redirect and fetch the main page, minus the intro, infobox, and any categories the main page is, which leaves just the table of contents. The only problems I can think of with this is that people editing the main page might wonder what the noinclude tags are for and remove them, plus the fact its not as clear as a having a separate Table of Contents page. --blendmaster 16:45, 11 July 2006 (CDT)

I can see where you're coming from, but the answer is to have the main page reference the table of contents, not the other way round. That keeps things a lot simpler (no noincludes everywhere), and more organised. --DrBob (Talk) 16:56, 11 July 2006 (CDT)

Is there are way to keep the toc minimized when the page loads? In firefox, it always stays open while the page opens and then closes, which is a annoying. --blendmaster 12:39, 12 July 2006 (CDT)

I'll look into it, but I can't think of a good one off the top of my head. --DrBob (Talk) 12:58, 12 July 2006 (CDT)

It should be possible to use CSS's display:none (which takes effect immediately) and then overrule that with, er, display:auto (?) as soon as the JS kicks in. In other words the CSS change would have to be reverted after the JS contracts the menu, otherwise you've still got the very same problem. Garrett^Talk 21:20, 12 July 2006 (CDT)

Good idea. Done. :-) --DrBob (Talk) 00:58, 13 July 2006 (CDT)

Excellent suggestion Garrett. It works like a charm now. ; ) --Antaios 09:21, 13 July 2006 (CDT)

Open invitation for Pac-Man Patterns

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

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

Marking GFDL articles

I've created [[Template:GFDL_Article]] to mark all the existing articles so we can begin the relicensing process. Is everyone ready to do this? (Do you think this template is sufficient?) ech elon 19:48, 28 June 2006 (PDT)

Looks fine. I don't know that images need tagging though, Wikipedia and the like merrily use images regardless of what copyleft license they use. How are you going to identify untagged pages though, with a database query? Garrett^Talk 19:56, 28 June 2006 (PDT)

Special:Allpages, unfortunately. ech elon 21:02, 28 June 2006 (PDT)

Are we supposed to mark every page within the article as well (see: Chrono Trigger) or just the introduction/table of contents? I'm asking because Garrett did every page (as far as I could tell) while Mason did not.--Dukeruckley 08:19, 29 June 2006 (PDT)

I'm not sure if we legally have to do more then this, but I think if we change the template to something like "This page, and all subpages of this guide are under GNUFDL...blah blah" then I think that would be better, if we actually can do that. If we absolutly MUST do every page, then we'll do every page. -- Mason11987 ^{(Talk - Contributions)} 09:49, 29 June 2006 (PDT)

There are a few suggestions I have, and I'm going to get garret in here to check them out:

We should only mark the main guide page, with a note saying all subpages are also under GNU, if this is legally possible AT ALL, it should be done, since you must go through the main page to get to subpages (almost always), I think it would be legit.
We should put the single tag at the bottom of the main page, to not distract from the reader, but legally cover our butt. The tag is for almost noone, but still needs to be there, and it should be as minimal as possible.
I thought there was another...maybe not...

-- Mason11987 ^{(Talk - Contributions)} 22:26, 29 June 2006 (PDT)

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

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

I made [[StrategyWiki:StrategyWiki_Public_License_editors|that page]], and I'll begin spamming talk pages for contributors to [[:Category:GFDL_articles|the guides that are GNU FDL]]. I'll simply paste {{subst:[[Template:GNUtoSWPL|GNUtoSWPL]]}} onto their talk pages, and it should go quickly, feel free to clean up that template while this is going on. -- Mason11987 ^{(Talk - Contributions)} 08:46, 30 June 2006 (PDT)

Shortcuts

For some reason the Alt-E shortcut (and some others, perhaps all) to edit a page isn't working, this would be extremly useful if I want to go through and tag some/all guides with the GFDL template, so if someone can figure out how to put that in and get it to work, that'd be great. Thanks! -- Mason11987 ^{(Talk - Contributions)} 09:54, 29 June 2006 (PDT)

I'll put it on my todo list, but it won't be really high-priority. :-) --DrBob (Talk) 10:14, 29 June 2006 (PDT)

StrategyWiki talk:Community Portal/2006/June

Contents

Community Issues Talk Page

Notes for Echelon

Intro Pages

Image Categories

Date Format

Board Games

Emulator Usage

Gaining Major Exposure - A look at my plans for StrategyWiki

Cleanup project

Official StrategyWiki law

Including enemy lists, item lists, and other big table data

CSS class for "notice" templates

More project administrators?

Release days should not be a category

Clarified Discussion

Spam filter

Max Image Size

Trying a new homepage

StrategyWiki:Copyrights rewrite

Master List of Games

NCL

Relicensing plan

Contributors list

Guide navigation

{{Cleanup}}

Donkey Kong: A good example or a mess?

Game Titles

Wikipedia-compatible infobox

Cheat Codes

Table of Contents markup

A new table of contents

Open invitation for Pac-Man Patterns

Marking GFDL articles

Shortcuts

Navigation menu

StrategyWiki talk:Community Portal/2006/June

Community Issues Talk Page

Notes for Echelon

Intro Pages

Image Categories

Date Format

Board Games

Emulator Usage

Gaining Major Exposure - A look at my plans for StrategyWiki

Cleanup project

Official StrategyWiki law

Including enemy lists, item lists, and other big table data

CSS class for "notice" templates

More project administrators?

Release days should not be a category

Clarified Discussion

Spam filter

Max Image Size

Trying a new homepage

StrategyWiki:Copyrights rewrite

Master List of Games

NCL

Relicensing plan

Contributors list

Guide navigation

{{Cleanup}}

Donkey Kong: A good example or a mess?

Game Titles

Wikipedia-compatible infobox

Cheat Codes

Table of Contents markup

A new table of contents

Open invitation for Pac-Man Patterns

Marking GFDL articles

Shortcuts

Navigation menu

Search