StrategyWiki talk:Community Portal

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

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

Server performance - We may need multiple servers...
We're currently running StrategyWiki on a dedicated server along with the website dsmeet.com. Both of these websites have a large amount of traffic and their databases are equally sizeable (DSmeet is 367.2 MB, StrategyWiki is 416.8 MB). The problem is not with the space we are using, nor do I think it's with Apache. It's not even our server load, which for the most part remains at a constant "1". My initial diagnosis is that the MySQL server is experiencing a deluge by these two highly websites. So my question is what do we do?

Since StrategyWiki has no ads and generates no revenue (nor do I intend it to do so!), DSmeet serves as the primary breadwinner for this project and pays for the server. We make anywhere between $150-$300 a month, and that figure varies a lot (July's check will be nearly $400 when it gets mailed). My intentions have been to change and expand DSmeet into a more useful and profitable website that can sustain growth for both itself and StrategyWiki, but our intended update will not be ready until the end of August. Currently our server bill is about $100/month (you can see specifications here).

I've been planning along with some of our server technicians (technical friends of mine) about our plan to eventually go colocated. Colocated webhosting, for those of you who do not know, is sort of a step up from dedicated rentals. You actually buy and own the server and then pay to have your server connected to a fast pipeline. You can then install whatever hardware you want, and you generally rent by the U size (how large the server is). You can run one or more servers concurrently in this model.

The obvious hurdle here is cost. While colocating itself can probably be found for $100/mo at the low end (which fits our bandwidth needs exactly), we'll still have to purchase the hardware--approximately $2,000 per server for a *good* server (AFAIK). And if we decide to go with two servers (one for apache, one for MySQL), this quickly becomes a costly measure. I don't think we're quite ready for this yet, and we need to wait until the year's end before we make this jump.

I've also looked at the options that Wikipedia suggests, and there may be a possibility that we can install eAccelerator (or Zend Optimizer), Squid Cache, and/or some other software to aid in this problem. The only problem is that I know next to nothing about these yet, and if it turns out that RAM is our problem these won't exactly help us.

I need to check on some things, so I'll be back with more info in just a little while. This situation isn't as dire as I make it out to be, we're just faced with the growing reality of the popularity of our sites. If you have any suggestions about eAccelerator, Squid, etc. please leave your comments! :)  ech elon  18:05, 26 July 2006 (CDT)


 * Squid Cache has just been installed (whew!) and it appears to be running smoothly. I'm not sure if it's optimally configured yet, so bear with me if you experience any interruptions in being able to reach the server.  ech elon  02:25, 27 July 2006 (CDT)

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


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


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


 * Are there any guides here that are actually done? as in a or  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 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.-- Duke  Ruckley  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


 * (Don't know who that ^ was) The problem with Final Fantasy VII is that it doesn't use the shiny new All Game Nav or anything fancy like that. Anyway, the main page has been sitting at none at all for a while. Should we just replace it with Most Promising Guide or somthing soon? --blendmaster 17:31, 24 July 2006 (CDT)


 * I think it was me. *looks innocent* --DrBob (Talk) 17:53, 24 July 2006 (CDT)

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


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


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

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

Image 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 then you could add buttons to a page with somthing like  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)


 * Okay, now that png support is back up, I can upload the now finished gamecube and ps* control icons. They are named Gamecube- - .png and Playstation- - .png.The directions are in camelcase with Up and Down first and then Left or Right. por exemplo: Gamecube-Control-DownRight.png. The reason everything starts with a capital, is due to a wierd error I found with the existing Template:Button. If you specify a value as just "left" or "right", it will take that as an float argument, like an image, so if I tried to get an image for Control-right.png, specified like it would automatically float it right. So, my plan this time, is to make templates gc and psx for the gamecube and ps* buttons. The arguments would be for button name/direction and type of name/direction. But, there will be a qif argument for the type of name, so you specify a button just like  and a direction like , but you wouldn't need to type.
 * Well, I need to upload them now. I'll start with the gamecube ones and do the ps* ones later. they are all 24x24px, which I found is a happy medium between fitting in with the text and being pretty. I will also make the gc and psx templates. Admins, don't delete the old generic buttons and the button template yet, because then Super Smash Bros. Melee/Basics will break. xbox and n64 buttons are next. --blendmaster 14:02, 24 July 2006 (CDT)
 * Super Smash Bros. Melee/Basics has been migrated. Looks pretty cool, huh? --blendmaster 17:39, 24 July 2006 (CDT)
 * Schweet. :-) --DrBob (Talk) 17:54, 24 July 2006 (CDT)
 * Awesome, now just give me the PS control images for Biohazard and I'll be twice as happy. :p --Antaios 18:54, 24 July 2006 (CDT)
 * w00t. --blendmaster 11:46, 25 July 2006 (CDT)
 * Thanks, blendmaster!. Looking forward to the xbox ones. Sympleko 12:50, 25 July 2006 (CDT)
 * Looks great mate, keep it up! :) --Antaios 12:48, 25 July 2006 (CDT)
 * Awesome job blend. Just out of curiosity, would you have any plans to do icons for a generic arcade joystick?  (You know, black stick, red top... something along those lines.)  I could really use those for games like Street Fighter II.  And I uploaded the [[Image:Punch.gif]] and [[Image:Kick.gif]] icons that Capcom used, but they're pretty low quality and could probably use replacement as well... (shoot, forgot to sign) Procyon 20:43, 25 July 2006 (CDT)
 * Hmm, good question. I guess I'll just have to make some shiny svg versions of those. If you see any color highquality ones you like, or even a shot of the buttons on an arcade cabinet or somthing, show me them, And I'll do my best. --blendmaster 22:03, 25 July 2006 (CDT)


 * Ok xbox and 360 buttons are up. I know the analog stick images are just recolors of the ps2 ones, but that was the best way to make them look nice and still be understandable. They are colored after the xbox360 controller, but they can be used for xbox too, as I included both the xbo360 left and right "bumpers" as well as the white and black buttons. One problem with it at the moment is that MediaWiki randomly decided one of the images is corrupted, even though it was made the same way every other button is. Xbox-Rstick-Down.png is perfectly fine with imageshack yet MediaWiki wont render it. I've uploaded it several times, rasterized with different programs like the gimp and it still doesn't display, Which leads me to believe there's something wierd about the name of the image. This has happened before too. Well, besides that enjoy the buttons. --blendmaster 15:28, 27 July 2006 (CDT)

Open Media License
I wanted to involve everyone in writing and commenting on the "Open Media License" that I am drawing up. (I think it may be a better alternative to "StrategyWiki Public License".) You can see it here. If you wouldn't mind taking a look over it, making notes of your thoughts and ideas for improvement, and even working on it, that would be excellent. I want to slim it down quite a bit so it's a small license. Once we have a more polished and refined version, I want to show it off to Debian-legal and ask for their assistance in making this thing real. We'll of course want it to conform to all of their standards, as I generally agree with Debian-legal on most licensing issues.  ech elon  01:32, 22 July 2006 (CDT)

New Namespace?
I've been thinking about the possible problems with the "game index" we have at Special:Allpages and Special:Allpages/C. Using these two search methods to find the title you are looking for is confusing, since all subpages of guides are listed first. What if we create a new namespace (hence it would be searchable) called "GameInxex" and create pages that correspond to the index pages for the guides themselves. Examples would be GameIndex:The Legend of Zelda: Ocarina of Time and GameIndex:Half-Life. Using this method, we can create a full, easy to search index of all the titles that exist in our wiki. Thoughts? I may make a demo to see what you think.  ech elon  17:55, 22 July 2006 (CDT)
 * Here's a demonstration. Compare with the main index.  ech elon  18:05, 22 July 2006 (CDT)
 * That would be good. I can't see any negatives to it, unless you specifically need to search for a subpage. --blendmaster 22:10, 22 July 2006 (CDT)
 * Nice, but does it have to have such an ugly name? Why not "Game index" (similar to "User talk")? --DrBob (Talk) 01:38, 23 July 2006 (CDT)
 * I was thinking in camel case because I'm a programmer :P If you think "Game_index" is superior asthetically to "GameIndex", I'll change it.  ech elon  01:06, 24 July 2006 (CDT)


 * I do, because when it's displayed as text on a page, it won't have the underscore. ;-) --DrBob (Talk) 04:02, 24 July 2006 (CDT)


 * Renamed! Also, I just created the Portal: namespace Mason's request on my talk page.  ech elon  06:16, 27 July 2006 (CDT)


 * Why have both? I would think the portal namespace would be better for both purposes. (It's more standardised with other sites such as Wikipedia.) :-) --DrBob (Talk) 08:51, 27 July 2006 (CDT)


 * But wouldn't a "portal" for every single game be overkill? I was thinking portals would be limited to Zelda, Final Fantasy, Dragon Quest and the like. If the portals concept is used for every game, wouldn't it lead to redundancy? People may put content in the portal that should go in the guide.  ech elon  08:55, 27 July 2006 (CDT)


 * Sorry, my mistake. I thought they were both doing the same job, but now I see the distinction. Ignore me please. :-P --DrBob (Talk) 15:00, 28 July 2006 (CDT)


 * I don't see a lot of use of the gameindex feature outside of the search (In which case every guide made should just have a redirect from that namespace). The Portal namespace should just be for getting a group together to work on a set of guides.  Either a series, or even a console.  I imagine there will be some kind of portal hierarchy here as developed at wikipedia.  With a portal dedicated to, the Halo games for example.  Portal:Halo would be a kind of "child portal" to Portal:Xbox.  Basically a way to discuss the guide as a whole and easily discuss organization issues or drives to improve portions of the games in general.  Also a Portal could also be the place were people can simply talk about the game or whatever, since the talk pages for the guide are for talking about the guide, but that's just something minor. -- Mason11987 (Talk - Contributions) 09:53, 27 July 2006 (CDT)

ImageMap Extension
I think the ImageMap Extension could be useful. However I think the coords should instead be retrieved from a normal page using the "raw" action (ala CSS/JS). This would allow diffs and the like to be used, and it would be much simpler than using the upload form and worrying about tracking down misnamed unused map files and all that. It might need tweaking later on when SVG is working, but for now I think this is the only change it needs. GarrettTalk 01:46, 23 July 2006 (CDT)


 * Looks good, but it is a MediaWiki 1.5 extension, and we're on MediaWiki 1.7, so I don't know how compatible it'll be. --DrBob (Talk) 01:49, 23 July 2006 (CDT)


 * I love the possibilities of this extension. I'll see if I can manage to get it to work with a reasonable level of compatibility.  ech elon  01:16, 24 July 2006 (CDT)


 * Here you go. :)  ech elon 


 * This is interesting!  ech elon  08:47, 27 July 2006 (CDT)


 * That is awesome...wow...very very very cool. I'm going to have to try to steal that.  :-D.  This may be one of the most overall useful changes this site has received in quite some time. -- Mason11987 (Talk - Contributions) 09:48, 27 July 2006 (CDT)


 * Cool, but I don't think it's that useful. At least not the most overall useful. It just seems kind of like an excuse to put more images in a guide. I guess it would be sorta useful in a game like Oblivion to include a imagemap of the ingame map in the table of contents, but "overall useful", no. --blendmaster 14:55, 27 July 2006 (CDT)


 * Yeah, it's more "cool" than useful. I don't think we should ever use the extension exclusively either--more of a supplement to other content. I may create a maps section of the Ocarina of Time guide.  ech elon  16:40, 27 July 2006 (CDT)

Making a series overview
I've been doing work on the Adventures of Lolo 2 (Japanese) guide and it's nearly done (98% in fact). My next planned project was to do an overview for the whole Eggerland/Lolo series which lists instructions, info on monsters, gameplay tricks, etc. I was thinking of simply creating an article called "Eggerland series", but was uncertain if that would be the way to go. I chose Eggerland as that was the original name of the games in the series. Just wondering what I should do. Also, is it acceptable to use art from the manuals? --Sivak 00:22, 24 July 2006 (CDT)


 * Is it okay to create an overview? Absolutely! I think that's an excellent idea. But we do need some kind of disambiguation method. Perhaps Eggerland_(overview) is a good method of doing this? I am not certain. We should get lots of opinion as to what the appropriate method should be, because once we settle on a standard we'll have to stick with it. My main concern is making sure that disambiguations and overviews remain easily accessible and placed in standard locations. If we create a Zelda overview, where should it go? Zelda is taken for disambiguation purposes, and it's best not to crowd it with overview data too. Zelda_(overview)?
 * As for manual art/scans, absolutely! Fair use! :)  ech elon  01:11, 24 July 2006 (CDT)


 * I think the best thing to do would be to create a series category (similar to Zelda) and a series page (similar to Zelda) which itself would redirect to the series category, but then put overview information on sub-pages of the series page, and link to it from both the appropriate guides, and a ToC in the series category. That'll keep it all nice and self-contained, and avoid polluting the place with all sorts of bracketed names. :-) This should also be done for series such as Nintendo's Mario (etc.) games – which share characters like there's no tomorrow – and Zelda. --DrBob (Talk) 04:05, 24 July 2006 (CDT)


 * Mason recommended I create the "Portal" namespace, so I recommend you do two things:
 * Create Portal:Eggerland and store common info there.
 * Create Eggerland as a disambiguation.
 * I think that'll work nicely.  ech elon  06:17, 27 July 2006 (CDT)

What is a spoiler?
So does that mean that locations of pickups and things aren't spoilers? I'm going through the list of items and there are lots of tips like "You can find this here...." or "You get this after you complete this mission...." These all give away game information, just not parts of the story. At some point users have to accept that they're coming to this site to get game information. I'm just looking for some guidance on what's too much spoiling. Right now through my own fault there are two item pages, one without location info and one with. I guess I should merge them, but I'm debating whether a spoiler-free list is useful, too. Sympleko 12:16, 24 July 2006 (CDT)


 * I wouldn't classify the locations of items as spoilers. What I personally would call a spoiler would be telling the ending of the plot (if it's not obvious) before the end of the walkthrough. At the end of the walkthrough (i.e. in the logical place) and if it's appropriate, telling the end of the plot would not be a spoiler. Anywhere else, however, it would. --DrBob (Talk) 16:19, 24 July 2006 (CDT)

Renaming images
Should I create a template that adds a category to images or pages that need to be renamed? I'm thinking that there shouldn't be any text that shows up on the page, just a category for maintenance purposes. There are a bunch of images that should be renamed at some point because of ambiguity and I think if we place them in a category it'll make it easier later (unless I'm missing something already there for this purpose). Images especially need it because they cannot simply be moved and renamed, they have to be re-uploaded which requires downloading the original image.-- Duke Ruckley  14:51, 24 July 2006 (CDT)


 * I was thinking of doing such a template myself actually. By all means go ahead and make one. :-) Make it include the pages in Category:Pages needing renaming. --DrBob (Talk) 16:21, 24 July 2006 (CDT)

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


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


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


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


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


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


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


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


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

Cutscene transcripts
Some of the pages (e.g., Grand Theft Auto: San Andreas/Missions/Big Smoke) have verbatim transcripts of the cutscenes included. Besides being formatted like a screenplay (way too much space for a web page IMO), this seems like a copyvio to me. Should it go? Sympleko 07:12, 26 July 2006 (CDT)


 * Ya, it should go. It is completely unnecessary and is not useful to the user of the website anyway.  It doesn't give any hints or tips on how to play the game at all.  Plus, it just doesn't look very good.-- Duke  Ruckley  07:55, 26 July 2006 (CDT)


 * I agree on all counts. Can somebody delete Grand Theft Auto: San Andreas/Missions/In the beginning/Cutscene then?  It's all transcript.  I already orphaned the page. Sympleko 11:59, 26 July 2006 (CDT)


 * Done :) -- Duke Ruckley  12:18, 26 July 2006 (CDT)


 * You'll also want to see what links to the cutscene templates, do what's necessary with those pages, and then delete the templates themselves. (Danged dialup. :- --DrBob (Talk) 13:40, 26 July 2006 (CDT)


 * Done, there was just one page that linked to the two templates in use, and I deleted it and the templates.-- Duke Ruckley  13:49, 26 July 2006 (CDT)


 * Thanks for finishing what I started. Seems like it was only two pages. Sympleko 08:24, 28 July 2006 (CDT)

Problem (again) with the infobox
http://strategywiki.net/wiki/Final_Fantasy_VII

View that page on monobook and understand my dillema, we'll have to make sure this works on all skins before we apply something like that. -- Mason11987 (Talk - Contributions) 02:18, 27 July 2006 (CDT)

Individual pages for individual developers?
I've noticed that in a couple of a games, only a couple of people or sometimes one person created the game, and I wasn't sure if I should create a separate page for that person. A good example is the list of developers on the Star Sonata page. Should we create separate pages for each developer or no? --Antaios 19:07, 27 July 2006 (CDT)
 * Personally, I don't think we should. Maybe a link to their wikipedia article, but there's no need to include info on lots of different developers in a strategy guide. If you do however, it should just be a short bio with links to the guides of the games they've created. --blendmaster 21:28, 27 July 2006 (CDT)
 * Creating a page for each programmer is overkill, so I suggest we stick with creating pages only for companies themselves. On another note entirely: Look at the Star Sonata homepage! They're linking directly to SW now. That's pretty cool! :)  ech elon 


 * That is cool. Maybe for branding purposes you should ask them to make sure the link text says "StrategyWiki" in it. Sympleko 08:26, 28 July 2006 (CDT)