From StrategyWiki, the video game walkthrough and strategy guide wiki
Jump to navigation Jump to search

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

Key Issues:

Archive

Archives

  • Issue 1 - Early SW issues
  • Issue 2 - Wikibooks, Google Adsense
  • Issue 3 - Discussions from Feb/Mar. Read if you're new! Good stuff!
  • Issue 4 - Spoilers, SQL dumps, screenshots, etc. from Mar/April
  • Issue 5 - Design, categorization, etc.
  • Issue 6 - StrategyWiki appearance, more categorisation
  • Issue 7 - Various image/upload formats
  • Issue 8 - Emulators, policy, categories and formats
  • Issue 9 - Relicensing and layout

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. echelon 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. echelon 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. echelon 17:10, 26 June 2006 (PDT)
I think it should be shown by default on the first page. Right now it's little different from the old cover page idea, a click is still required to see the TOC. I also prefer the sidenav just a little bit more since it's always there and makes use of the otherwise wasted right-hand column. GarrettTalk 17:53, 26 June 2006 (PDT)
The sidebar required for the sidenav TOC isn't present in other skins. I am thinking of an option that lets the user choose whichever type of navbar they want, though. (I didn't by any means delete the sidenav script.) Currently, I must say that I prefer this new inline TOC to the sidebar one; it allows much more options, such as organized multi-column navigations and inline images. Plus, you don't have to scroll down the page to see the whole TOC, and that's a very annoying part of the sidenav TOC. Again, I'll still try to find a solution that allows the user to choose either one though. Just keep in mind that I am not done by any means--the new inline TOC needs some kind of image to make it more obvious, a little tidying, a saved user preference, an init variable, etc. echelon 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. echelon 23:04, 26 June 2006 (PDT)
Try it again. You changed the dynamic nav stuff to be specific to TOC related things. This chang allows dynamic nav to be used in all kinds of things, including the todo lists (check your user page in a little bit to see the changes I'm making to that). -- Mason11987 (Talk - Contributions) 23:15, 26 June 2006 (PDT)
When you click on "show" in the new ToC, there is a minor bug where it still says "Show" underneath "hide". In other words, you get two words meshed together. Can that be fixed? Other than that, everything looks great!--Dukeruckley 05:59, 27 June 2006 (PDT)
I'm not that good at javascript so I'm going to leave this to echelon or drbob. It's odd that this bug doesn't exist when using monobook, but does in MediaWiki:BlueCloud.js, even though the .js files are exactly the same...how strange eh? Good luck guys :). -- Mason11987 (Talk - Contributions) 08:23, 27 June 2006 (PDT)
Eh? You called? What do you want me to do? (BTW, I think the ToC template is too big at the moment: imho the border should be removed, to let the ToC contents fit in with the rest of the page.) --DrBob (Talk) 08:52, 27 June 2006 (PDT)
Well, the TOC at the top of every zelda page (and actually the dynamic navigation system as a whole) functions without that little bug duke mentioned only when it's on monobook, on bluecloud it has that bug he mentioned, and with your "BTW", are you referring to the zelda TOC page itself or the dynamic nav system used in all game nav? -- Mason11987 (Talk - Contributions) 09:38, 27 June 2006 (PDT)
I'll take a look at the bug later, but I am referring to the dynamic nav system itself. IMHO, the "Table of Contents" link in the All Game Nav proper (i.e. the one which has always been there) should be emphasised more, and when clicked, expand the full table of contents, with a light grey border around the bottom, left and right to separate it from the content, and perhaps with a "tab" effect applied to the Table of Contents link the user just clicked. I don't like the fact that it's expanded by default (takes up far too much space), and the current border and grey title bar doesn't fit in; neither does the reduced width. --DrBob (Talk) 10:04, 27 June 2006 (PDT)

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

I've fixed the show/hide problem (a dirty hack, because the function creating the show/hide links was being called twice and I'm not about to debug that) in BlueCloud, but not Monobook because you said the problem doesn't occur with it. I've also created a WIP mockup of what I was thinking of for the ToC stuff, incorporating your idea of bordering the all game nav entirely. --DrBob (Talk) 12:37, 27 June 2006 (PDT)
I think that is very cool, I changed the Counter-Strike:_Source/Table_of_Contents page so that it didn't include the infobox. Perhaps it can be set up so that the infobox is shown on the page whe you view it, but when it is included it sets up the TOC horizontally? It seems like a lot of effort for this to be done on most multi-page guides, but I definitly like the style. I think this will look amazing on the zelda guide, just each guide will have to figure out exactly what will be included in the template. -- Mason11987 (Talk - Contributions) 20:25, 27 June 2006 (PDT)
I made some more changes, so it appears exactly the same on the TOC page itself, but when used in the template it looks much cleaner. -- Mason11987 (Talk - Contributions) 20:33, 27 June 2006 (PDT)

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

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

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

End random section that doesn't belong here

Starting a new indent. While I like the look of the menu that Mason did more than mine (it's more compact, more noticiable to the user, and a little more organized), I can't help but feel that it was a step backwards:
  1. 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.
  2. 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 :( echelon 13:09, 28 June 2006 (PDT)
I'm not quite sure what you mean here, although it has been a long day. Have you looked at my spiffied up version?
I kind of get what you're saying, but I think as it is now it's got it's advantages over the older one, but if you have improvements to this or even a completly different style that has more advantages I think it'd work great. The spiffed up version DrBob made is quite a big improvement over the one I made and I think it takes into account some of your ideas. Also, I didn't get the show/hide on the version you had before, although it IS possible that was my fault. I think the bold change you did with the all game nav got us into a Bold-revert-discuss cycle which is one of the best ways of getting the most out of this. Feel free to change the one I made, but I DO think it is an improvement over what was there before, even if it has it's faults which is completly open to change which DrBob has done. -- Mason11987 (Talk - Contributions) 15:30, 28 June 2006 (PDT)
The version that DrBob is working on looks great! This is the first I've seen of it. It's pretty much a better looking mix of your version and mine. The only thing that might be problematic in his version: I'm not sure about the use of ==Heading== markup, since doing so causes the wiki-generated table of contents (__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! echelon 19:26, 28 June 2006 (PDT)
DrBob's template looks really nice, but I really think we should change the All Game Nav template. Right now, the Introduction and Table of Contents just link straight back to the main page, so its pretty redundant. I think the always visible part of the Table of Contents thing should be customized to the guide, with links to the main sections, such as Walkthrough, Extras, Codes, and stuff like that, instead of the default main page, intro, and toc. --blendmaster 13:16, 29 June 2006 (PDT)
Mine is being developed as a drop-in new version for the All Game Nav, so I can't see any problem with bringing such changes into mine, and then moving them forward to All Game Nav. Your point that many guides just have the ToC and intro redirect to the main page is very valid: we should look around for some other standard pages to put in instead (although the link to the ToC should stay as all guides should have a separate ToC page when this new All Game Nav is rolled out, due to the fact that it references them). --DrBob (Talk) 14:06, 29 June 2006 (PDT)
I'd migrate your version in as the default now, then continue using it as an in progress version. If all game nav is going to be used on every guide (as it's name implies), we may want to have it protected at some point, and having a test version would be great too if we get it in the template namespace also.
But the different links could easily be set up, we just have to figure what would be the best setup. I don't think an "intro" page needs to exist, having a page for the game title (the main page), then a TOC, then a walkthrough would be good enough I think. The rest can go in the TOC dropdown. -- Mason11987 (Talk - Contributions) 22:21, 29 June 2006 (PDT)
I think we need "Walkthrough" as an introduction on how to use the walktrhough portion of the guide. (If there are specifics that the reader must pay attention to, etc.) There is also an ulterior motive for this: SEO (Yahoo *really* loves StrategyWiki). I suggest a "Cheats", "Tips", or "Codes" section for the All_Game_Nav as well. Perhaps the Qif can be used to specify which elements are shown. As for the link to the Table of Contents? That's slightly important: it serves as a link to edit it. Of course it could also be obscured, though. echelon 19:24, 1 July 2006 (PDT)
I've moved mine forward to the All Game 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 All Game 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.--DukeRuckley 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 All Game 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 All Game 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 All Game 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 All Game 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 All Game 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 All Game Nav. --DrBob 16:30, 11 July 2006 (CDT)
I think that was DrBob ^. The Problem with just making the All Game 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 All Game 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. GarrettTalk 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)

Back and forward links

On the bottom of pages, there are little back and forward through the Walkthrough links, like << Hyrule Castle | Goron City>>. There should be slightly more of a presence of these links. Another plug example is Template:Earthbound/Nav. What would be better is something styled the same as the All Game Nav, but with only Walkthrough links in the show/hide section and the always visible links would be to Back, Here, and Next in the Walkthrough. Like Template:Earthbound/Nav only standardized. --blendmaster 11:54, 11 July 2006 (CDT)

(I've split up your comment; I hope you don't mind.) I like this idea, and I think I'll try and get round to implementing something for it soon. :-) --DrBob (Talk) 15:01, 11 July 2006 (CDT)
kind of like this? --blendmaster 16:27, 11 July 2006 (CDT)
Yeah, but without all the big images. :-P --DrBob (Talk) 16:56, 11 July 2006 (CDT)
It has been "improved", but it looks as if its missing somthing, don't you think? --blendmaster 17:41, 11 July 2006 (CDT)
I've spiffied it up a bit, cleaned up the markup, and made it fit in more with All Game Nav. --DrBob (Talk) 12:57, 12 July 2006 (CDT)
Ok, looks fine now. But how are the hidden links going to be added in? Unless you made yet another table of contents page to include that just lists the walkthrough part, then you'd have to enter all the links as a variable in the template every time you used it. --blendmaster 11:44, 13 July 2006 (CDT)
I thought you had that sorted. I do suppose the best way to do it would be to add another page, yes. --DrBob (Talk) 13:51, 13 July 2006 (CDT)

Open invitation for Pac-Man Patterns

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

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

Marking GFDL articles

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

Looks fine. I don't know that images need tagging though, Wikipedia and the like merrily use images regardless of what copyleft license they use. How are you going to identify untagged pages though, with a database query? GarrettTalk 19:56, 28 June 2006 (PDT)
Special:Allpages, unfortunately. echelon 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:

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

-- 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. GarrettTalk 22:36, 29 June 2006 (PDT)

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

I made that page, and I'll begin spamming talk pages for contributors to the guides that are GNU FDL. I'll simply paste {{subst: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)

Collaboration of the Month / Guide of the Month

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

My Half-Life walkthrough =D. As for a collaboration, defitenly the SWPL license. --Antaios 20:26, 1 July 2006 (PDT)
The Final Fantasy VII walkthrough seems like a fairly good one as well. It still has a few sections that could use some meat to them and it needs pictures, but it is a decent choice I'd say. Although, Half-Life might be a better choice because we just had an action-RPG, so a different genre might be a good idea.--Dukeruckley 05:01, 3 July 2006 (PDT)
Are there any guides here that are actually done? as in a Template:P or Template:P quality? Because those would make perfect guides of the month. I know StrategyWiki is fairly new, but if we had a guide of the month with a whole bunch of red links, it might make us look bad. Maybe as we are still small, it'd be better to put somthing like a Most Promising Guide, or somthing that suggests its a good guide to edit or somthing. The collaboration of the month still should be the SWPL or Open Media license. --blendmaster 11:52, 13 July 2006 (CDT)
Final Fantasy VII is definitely a Template:P quality guide. There are few (if any, haven't checked all of it) red links and the entire walkthrough is complete save for some minor optional bits of information. I'd recommend it the most I think. A Most Promising Guide would be an idea as well and we can always phase it out when we have some completed guides.--DukeRuckley 11:55, 13 July 2006 (CDT)
It looks like a good choice, yes, but before it can be listed I really think the front page could be cleared up:
  • Add an infobox and box artwork
  • Make the "Materia" and "Equipment" appendices a link to pages
  • Deal with the "stuff to be merged" section
  • Make sure it's categorised fully and properly

Rename the license?

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

So you'd have it called "License" then? :-P I agree with you here, and I think now is the time to change the name if ever, before it gets too complex. --DrBob (Talk) 04:52, 2 July 2006 (PDT)
Guys, check out the suggestions in User:Echelon/Open Media! Leave comments on the talk page there. echelon 23:53, 5 July 2006 (PDT)

Image upload warning

I'm going through categorising all the images, and it's a pain. I have a horrible feeling that people are going to continue to upload uncategorised images, so why not put some Javascript on the image upload form which checks for a category link, and pops up a message box chiding the user if the output of ((form_contents.indexOf("[[Category")==-1)) || (form_contents.indexOf("[[category")==-1))) is true. --DrBob (Talk) 06:43, 2 July 2006 (PDT)

I suggest looking into the uncategorized images page sporewiki has set up and have that installed. But if this code gets put it, If you could explain how it's done, then that'd be appreciated echelon, thanks :). -- Mason11987 (Talk - Contributions) 16:42, 2 July 2006 (PDT)
I think we should do both. :-P The message on form submission to stop more uncategorised images being uploaded, and the uncategorised images page to help deal with the ones which have already been uploaded. Looks quite simple to install the uncategorised images page, and thanks must go to MediaWiki (and SporeWiki) for it. :-D --DrBob (Talk) 23:00, 2 July 2006 (PDT)

Image guidelines

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

Control Images

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

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

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

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

I agree that the png buttons are ugly when littered around the page. One thing that might help is a policy to keep pages platform-agnostic when possible--say "shoot" for instance rather than "hit (triangle button image)", then refer to a rosetta page with all the controls for each platform. Then again, melee games really do need to list the button sequence.
I tried making some buttons with Unicode and CSS at Talk:Grand Theft Auto: San Andreas/Basics/Controls. I thought they looked good except for the ABXY buttons, which of course are kind of important. DrBob pointed out that not all browsers support Unicode, and how they choose to do so is up to the browser. That's a good point: If you saw "Hit this sequence of buttons: ? ? ? ? ?" that would be kind of frustrating!
Using SVG buttons would be wicked cool. The technology is only slightly less accessible than simple images -- the plugin is easily installable and has been stable since 2001. We can use alt text in the contents of the embed element, so people who don't have/don't want SVG support can still read the page. Even better, that alt text is HTML so we can use CSS to style that text however we want (but we should still stay way from exotic unicode glyphs). That would give two reasonably good renditions of the page probably better looking than the current one, and preserve machine-readability. So I say go for it.
In terms of aesthetics, I think it's important that buttons be styled to go with the main page text. If you look at a BradyGames guide you will see that that the buttons with letters use the same font as the text, just bold. Using different fonts tends to jar the eye a little bit. Sympleko 06:19, 7 July 2006 (PDT)
I can't see any problem with the PNG buttons or the markup: once sections like that are written, they're unlikely to be changed, and so it shouldn't be much of a trouble. I'm against moving controls to disambiguation pages for each platform for each game, because that means users would have to follow another link to get to what they probably want to find, which slows everything down. I'm also against new markup for buttons, as it makes upgrading MediaWiki hell due to the hassle of porting all the modifications, then fixing the bugs.
I'm all for SVG images. MediaWiki will automatically rasterise them to PNG unless the user has set SVG to be displayed natively in their browser, so that's OK. Using the same font as the text is fine, as it's all the same anyway (and anybody who decides to make another header template containing a custom, stylised page title will be shot). I agree that the control images should be differentiated by platform and renamed; they're not widely used yet anyway, so it won't be much of a hassle to rename them all. --DrBob (Talk) 09:18, 7 July 2006 (PDT)
I'm in full agreement with DrBob. I think SVG images would be a neat idea, but I don't see much of a problem with the current PNG images. I also think that controls need to be game specific and named as such in order to create a consistent convention for when new game systems come out. In the case of Playstation and Playstation 2 (and a few others), an exception can be made because it is the same controller (except for the addition of the analogs).--Dukeruckley 09:50, 7 July 2006 (PDT)
If nobody else objects, this should go ahead. Dukeruckley, do you want to handle it? :-) --DrBob (Talk) 10:16, 7 July 2006 (PDT)
Personally I'd prefer typing in somthing like
.:left-smash:.
(embedded) instead of
[[Image:Gamecube-Control-Left-Smash.png||left]]
(generic), but since I'm not a great coder, I can't have much say in whether an embedded button markup is implemented or not. On SVG vs. PNG, svg images are a lot smaller(in file size), and are better at scaling to different sizes, if say the main control page had big button images, and all other pages had smaller button images. On using the same font as the text, I convert all the text in my buttons to paths, just because different SVG renderers use different default fonts, which makes the buttons look worse.
One thing no one talked about was the keyboard button images. Are they really neccessary? Well, I guess I'll get started on xbox and other console buttons. I'll can upload the gamecube and ps* buttons whenever the naming scheme is set. --blendmaster 16:30, 7 July 2006 (PDT)
I've said already that custom wikimarkup for buttons is not feasible. It makes MediaWiki upgrades a real pain. Honestly. Keyboard images would look nice, and make pages look interesting, but they wouldn't really add much. I'm sitting on the fence about them, really. As for the naming scheme, just use the initials of the system (e.g. "GC", "PS", "DC", "GB", etc.), then an underscore, then the name of the button/stick movement: e.g. "gc_a.png". Make sure to put them in the controller buttons category. --DrBob (Talk) 17:09, 7 July 2006 (PDT)
Well, then, now I just have to wait for SVG support in this wiki, as SVG is still a "not a recommended format". I do have another idea for naming the buttons. If they were named fairly verbosely, as in Gamecube-Control-Left.svg instead of gc_left.svg, but there was a template called {{gc}} then you could add buttons to a page with somthing like {{gc|left}} or {{ps|X}}, while the button images have nicer names. --blendmaster 13:31, 8 July 2006 (PDT)
For the disambiguation of controls on a single per-guide page, I still think that following another link when you don't know the button attached to the verb (people reading the guide will have at least had some experience with the game on their platform already) is less frustrating than having to translate button names from one platform to another. And as pages grow organically, you definitely don't want button names from different platforms on the same page. So to keep the guides clean it seems like the choices are to either list all the platform controls wherever one of them appears (as in "hit A, or ×, or NUM0, or...") or aim to keep them all in one place. Maybe policy is too strong, but it sounds like a good guideline to me. Sympleko 09:18, 9 July 2006 (CDT)
What some guides are doing (which is good) is to have subheadings for each system on the controls page, and listing the system-specific buttons that way. However, for games with too many controls (or fighting games with many hundreds of different moves attached to combinations of buttons), the best way to do it would be to list alternatives for different systems in-situ. --DrBob (Talk) 11:38, 9 July 2006 (CDT)
I agree on both. I think Grand Theft Auto: San Andreas/Basics/Controls and Super Smash Bros. Melee/Basics are good practice, each for their type of game. Sympleko 12:04, 9 July 2006 (CDT)

Is what we're writing here going to stay?

Should we bother updating SW while it's being moved? Are things recorded at the temporary location going to make it onto the new server? (Or are we already on the new server, just under an assumed name?) Sympleko 11:28, 9 July 2006 (CDT)

This is the new server, but as noted on the old server, there are some inconsistencies in the copy, thus there is the distinct possibility of everything having to be overwritten. What I would say is that if you want to do some editing, download the source of the article you want to edit, save it as a text file and edit it on your home computer. Once we've got everything sorted and give the go-ahead, feel free to upload it. :-) Personally, the only edits I'm doing at the moment are to test my bot; such edits can easily be re-done if we have to scrap the data. --DrBob (Talk) 11:34, 9 July 2006 (CDT)
Yes, actually. I think this is going to stay. :) echelon 04:04, 10 July 2006 (CDT)
Yep! I'm positive. Everyone can get back to work. I'll have SQL dump files for everyone tomorrow! :) echelon 04:59, 10 July 2006 (CDT)
So will the address be changed back to www.strategywiki.net soon? --blendmaster 11:24, 11 July 2006 (CDT)
I don't know what's going on. Technically I've already changed the name servers to point to the new server, yet it's still resolving to Dreamhost. It's been 48 hours since I've done so as well. I'm beginning to suspect that Dreamhost has put in place a long TTL period, and this in turn has resulting in ISPs caching where the domain resolves to. If so, that's really quite the dirty trick... Try http://dnsstuff.com yourself and you'll see everything is properly resolving there. echelon 14:14, 11 July 2006 (CDT)
Actually, it was my mistake. And a stupid one too. I misspelled 'strategywiki.net' in BIND. At least I hope this is the problem, because if it's really the former then we've got trouble. :( echelon 14:26, 11 July 2006 (CDT)

Backups

This will be the StrategyWiki backup server address. Currently it contains in the folder "before-move" an XML dump of all revisions prior to our move and a tar.bz2 of all the uploaded images from the same time period. Soon I'll upload an bz2 archive of an SQL dump, and we'll host one for every month. Don't abuse this though, because we don't want to waste bandwidth. (You don't all have to download it today!) If someone wants to start a torrent or something, that may be a good idea. echelon 11:29, 12 July 2006 (CDT)

Alternate-language versions of StrategyWiki

I've talked with DrBob about setting up alternate language versions of StrategyWiki, so sometime after we relicense I may create ja.strategywiki.net and en.strategywiki.net. I know a bit of Japanese, so I can probably set that up on my own, but would any of you like to start other language versions? I'd like to link the member database between each version so you can sign in with a single account. echelon 11:31, 12 July 2006 (CDT)

This would be nice, but as I've said before, I'm not good enough with foreign languages yet to consider doing anything other than English. I'd advise we look at how Wikipedia has implemented multi-language stuff to see if we can do it any better. :-) --DrBob (Talk) 12:54, 12 July 2006 (CDT)

Importing Images from Wikipedia: Licensing, Technology

I'd love to get some screenshots from GTA:SA, but it appears the best (only?) way to get screenshots is from a PC game, and I only have the XBox version. I was thinking about importing those posted to Wikipedia.

At first I thought my only "issue" was one of technology; see below. But then I started reading more about the licensing, and it appears that Wikipedia content can't be imported into StrategyWiki. Is that right?

But the screenshots in question aren't owned by Wikipedia, so Wikipedia can't a apply a license to them, can they? The individual image pages indicate that the image is copywritten but they have a case for fair use. We would have the same case, I'd think.

As for the technology...may I create a bot with pywikipedia to automate the uploads? I'm also planning on importing some auto-generated content from the cfg files (vehicle data), so using a bot would be nice. Sympleko 13:12, 12 July 2006 (CDT)

We can import content from Wikipedia as we are technically still GFDL licensed. (I'm considering writing an "Open Media License" as a more broad license alternative to "StrategyWiki Public License".) As for screenshots, I don't think Wikipedia can put those under a license at all since they are fair use. There is nothing "original" in a screenshot unless it is somehow of extrodinary merit (some task that can't normally be accomplished or something). As for using a bot, feel free! Bots are great! :) Let me know when you get it finished, and I'll mark it as a bot. echelon 14:58, 12 July 2006 (CDT)
IANAL but that was the way I saw it, so I'm glad you agree. What about screenshots from other sites? It seems the same reasoning applies: just because somebody snapped a screenshot and uploaded it doesn't mean they "own" it; the producing company owns it and we can use it as much as the snapper can) to screenshots posted on other web sites. OTOH it would probably be impolite to do so without permission at least. Sympleko 06:12, 13 July 2006 (CDT)
Yeah, get permission, and make sure there are no watermarks. Watermarks make us look bad, kiddies. :-P --DrBob (Talk) 10:54, 13 July 2006 (CDT)

Guide organization

Something I alluded to above...I'd like to add a lot of small pages to the GTA guide. Like, a page for every vehicle, lots of location pages, lots of weapon pages, etc. The page could have some statistics about the thing (like in the case of a car, how fast it goes), where it can be found, what it's good for, what if anything IRL it's based for, etc.

It seems like this format, rather than a small set of long pages, is a little more flexible and conducive to expansion. For instance, if you had trouble finding the pilot's entrance to the airport in Los Santos, and once you found it you wanted to add it to SW, where would you put it? There are no missions which start at LSX, so it doesn't fit on any page under Missions/. It should go on a page about the airport. Likewise, any page that mentions the Jetpack or the Tank should link to a page that details how to get it.

Another thing I was wondering about were the directories in SW URLs. Should we continue to put new pages in a directory below the game name? Some of the pages I'm thinking about creating don't have an existing directory to put them in, so I have to think about where they should "go." If I create new directories, I have to think about updating the navigation template and adding a TOC page. On the other hand, I could just leave all the new articles in the top level, categorize them, and then the category page is the TOC page. If you want an article about a mission and a vehicle with the same name, you can use parentheses after, like they do on Wikipedia.

This kind of organiziation would make the guide read less like a book and more like an encyclopedia. But the nonlinear nature of the game and its illusions of an alternate world seem suited to this structure. I talked a little with Duckruckley about these ideas, and he suggested I bring them up here. I wrote a post but forgot to save it, then the server move...anyway, here it is. Does it make sense? Is it a good idea? Sympleko 13:12, 12 July 2006 (CDT)

Always use sub-pages. It's one of our golden rules. Personally, I'd put (for example) all missions as sub-pages of the Missions sub-page of the GTA guide, and all cars as sub-pages of the Cars sub-page of the GTA guide. Another rule is that no sub-pages are categorised, unless for maintenance purposes (e.g. WIP using the wip template). They should be listed in the ToC, but not categorised. This keeps all the games nice and self-contained. --DrBob (Talk) 13:26, 12 July 2006 (CDT)
The only time I don't recommend a new subpage is when there isn't enough pertinent information to constitute a full page of its own. For example, the Secret of Mana Bestiary. Instead of having a page for each individual enemy (as was originally planned) it is organized so that about eight to ten monsters are on each page. That way there isn't a page with just seven or eight lines of information that looks very empty. Otherwise, subpages all the way. And I love how you called me "Duckruckley", made me laugh :).--DukeRuckley 13:34, 12 July 2006 (CDT)
OK, it's good to know the rules. I'll use subpages.
Sorry, Duck. Slip of the keyboard, you know. :-) Sympleko 14:01, 12 July 2006 (CDT)

Problem uploading png files?

I have tried to upload several different PNG files, but everytime I try, I get "The file is corrupt or has an incorrect extension. Please check the file and upload again." Many of these PNG files was saved directly from another site in the PNG format, and some were even manipulated and saved as PNGs by me personally (using GIMP 2.2) so I have no reason to believe that every single one is corrupt. Are there any issues with PNGs? Thanks. Procyon 13:24, 12 July 2006 (CDT)

Shouldn't be. Does your internet have connectivity problems? What browser are you using? --DrBob (Talk) 13:27, 12 July 2006 (CDT)
No connectivity problems that I'm aware of, I was able to upload JPGs and GIFs with no problem. I'm using Firefox 1.5.0.4, which I have used to successfully upload PNGs in the past. Procyon 13:43, 12 July 2006 (CDT)
Same here, with firefox, and gimp2.2/inkscape. --blendmaster 13:45, 12 July 2006 (CDT)
If by "same here" you mean it's broken for you too, then we need to wait for echelon. :-) --DrBob (Talk) 13:50, 12 July 2006 (CDT)
That's really odd... Did it work before we changed servers? I'll take a look into uploading. echelon 15:07, 12 July 2006 (CDT)
Yup. Checkout my image uploads @ 23:58, 5 July 2006. 4 pngs. Procyon 17:33, 12 July 2006 (CDT)
No problem. I don't know if it's related, but there seems to be some problem converting GIFs in to thumbnails, as seen with two GIFs that I use here. Procyon 14:16, 12 July 2006 (CDT)
That's a really weird problem. Clearly the source image exists, but it can't be resized. I'll make sure the GD library is up to date. echelon 15:07, 12 July 2006 (CDT)
I do have the problem, with all png's giving the "corrupt" error.GIFs upload fine. I'm using firefox 1.5.0.4, gimp-2.2, running on gentoo linux, but if the problem's serverside, then I don't think it matters. --blendmaster 20:03, 12 July 2006 (CDT)

TOC Categorization Problems

The All Game Nav is categorizing subpages accidentally, in certain circumstances. Final Fantasy VII began to have the problem when I included the introduction on the main page. The main page is being used as the Table of Contents page, so the All Game Nav is including the categories. I think the best idea would be to always use a Table of Contents page for the All Game Nav as opposed to a title page as a convention. What does everyone else think?--DukeRuckley 14:55, 13 July 2006 (CDT)

To clarify, the problem is mainly that the Table of Contents pages are redirecting to the main page (which has all the categorizations). So when the All Game Nav is used on a subpage, it includes the categorization.--DukeRuckley 15:06, 13 July 2006 (CDT)