Team Fortress Wiki:Discussion

create a new section

Why aren't bugs subjected to the same scrutiny as trivia

The bugs section on certain pages are getting quite large and getting filled with what I'd argue are trivial 'bugs'.

Why aren't we subjecting bugs to the same moderation process as trivia? I.e. why are we listing casual observations (clipping bugs), in addition to actual, substantial bugs (not working in the correct manner). Frankly, clipping bugs aren't interesting in the slightest (something is bound to clip with something else given the huge number of potential combinations in cosmetics/weapons we have, it's simply inconceivable to think Valve will cook up potentially thousands of different animation libraries to satisfy some minor clipping issue between items); I believe they should be removed altogether and replace with a note on the Hats/Misc/Weapon pages saying along the lines of "due to the limited animation set of the classes and weapons, certain items may not fit ideally with the class' pose and animations". We even have an (albeit small) section in the style guide about bugs and clipping; so why aren't we filtering?

I guess this will naturally lead into a discussion about redefining exactly what a bug is. Where do we draw the line between aesthetics/functionality/clipping? Is the lack of a fitting reload animation for the Loch-n-Load truly a bug in the strictest sense, or can we expand the definition to include cases like that? i.e. Can we justify its inclusion based on the assumption that the Demoman should be loading his grenades into the chambers ala the Grenade Launcher rather than seemingly dropping them? The weapon still functionally works, only the aesthetics are messed up. I'd argue that is a bug by the way, as it runs contrary to expected user behaviour.

Then there's the issue of view/world model discrepancies. They aren't always bugs; part of basic modelling theory is that you try and make the view model more interesting than the world model and remove parts that the user won't see on your game/mods default fov, ergo it follows that there will be discrepancies, however small, between the view/world models. Take a look at any Valve game in the past, the viewmodel is intentionally skewed. Now there's an exception with c_models where there's only one model which the game displays, so it follows that there shouldn't be any differences in world/view, so there may be a bug to note.

What about shared content? Let's take the case of the Crusader's Crossbow, it reuses the sound and arrow of the Hunstman but is that a bug in itself? I'd argue no; it's simply Valve reusing existing assets to avoid the need to record or model new assets. But then a counterpoint could be raised by way of the item's description, which states clearly that the item fires a "bolt"; what then is the definition of a "bolt"? Does an arrow fall into this definition? If yes, then it's not a bug. If no, then by all means list it as such, but don't list the re-used sound, as there's no indication that it should use unique sounds. This is the kind of moderation I'd like to see employed by the Wiki.

Although this next point extends from the previous one, there's the issue of certain weapons reusing sounds where they clearly shouldn't (Scout melees for instance); my stance is simply so: if the item has the sound override defined in the item schema, then it's not a bug except where that override is not working. We know for a fact that The Solemn Vow uses the Ubersaw sounds on purpose from only a casual glance at the schema, and I know this runs contrary to what I noted earlier about "expected user behaviour", so we should note cases like that in the opening paragraph rather than as a bug.

Which brings me to the point of unused content; these are not bugs by their very definition, they are simply unused. However, in the case where the content is clearly supposed to be used (i.e. the schema defines it as such) but isn't, then it's a bug, as we expect that content to be used but through some programmatic error either related or unrelated to the schema example, it isn't.

My stance is that there's a bug if:

• It runs contrary to the info listed in the backpack description
• There is significant disruption in the animation of the item
• The behaviour of the item was broken by a patch or through interaction from another item (i.e. unlimited Spy revolver crits from the interaction between the Sapper, Kritzkrieg and Buildings).

In addition, I feel we should:

• Discuss the bug on the relevant talk page as exemplified in the above Crossbow example; and
• Bring proof of the bug to bear, the burden of proof lies with the one posting the bug and as always we should assume good faith but also investigate if the bug is true rather than let it slip by; and
• Write up thorough guidelines defining what may be considered a bug, replacing the pitiful three lines we currently have that pretty much every editor has ignored or failed to enforce judging by the lists upon lists of clipping issues we had/have noted.

Thoughts, please. i-ghost 07:03, 18 November 2011 (PST)

 Support I think this is a very good idea, at the very least discussion about stricter bug guidelines should be started. Personally, however, at this point I agree with the ideas for bug/not bug that you have put there. -Mr. Magoolachub 16:51, 18 November 2011 (PST)

 Support I agree 100% with the clipping bugs thing. I see a lot of 'bugs' of the form 'this item will clip with the character model for a split second during a taunt if you look hard enough'. Clipping happens, it's impossible to eliminate. The only instances where I think it should be noted is when it's extreme, like the Larrikin Robin taunt. Otherwise, not noteworthy and just article clutter. In regards to other bugs, I think it's only notable if the behaviour is unintended or it's so noticeable it breaks the immersion. Basically I agree with that short list you posted. —Moussekateer·talk 16:55, 18 November 2011 (PST)

 Support The bug section certainly needs a good cleanup, but I think there's probably going to need to be a little more give in the rules compared to trivia. Sometimes a weapon might be working completely as intended, but it's just "off" like the Loch-n-Load and the Crossbow Bolts. And then there's the instance of something not being there when other, similar weapons have that. Stuff like crit glow, melee crit animations, crit sounds, etc. Something like the Detonator uses the Flaregun's crit sound when firing. This is using the sound the weapon is coded for, however, it's just odd and the player is bound to notice and think something is wrong. Something, however, like incredibly minor clipping like the Chargin' Targe clipping can totally get culled. Balladofwindfishes 17:03, 18 November 2011 (PST)

 Support Lots of good points and I agree with most, however I do think that clipping issues should still be listed for all hats and misc items. Some people put a lot of effort into gathering tems that they want for their classes to wear, and it can be annoying to find that two items clip when worn together. » Cooper Kid (blether) • (contreebs) 17:35, 18 November 2011 (PST)

 Comment That's actually a very good point. There's no easy way to see two items previewed on at the same time, and people may rely on the Wiki to see if there's specific major clipping errors with items. We may not want to make a hard rule eliminating all clipping errors. Balladofwindfishes 18:04, 18 November 2011 (PST)

In most cases it's fairly obvious if the item will clip, especially now that we have equip regions. A reader will simply go "oh, that goes in the this equip region, it'll probably clip with other items which go near this one", or, judging from the class images we have they'll go "oh, that's going to clip with x, y and z". These are simple observations, again something we don't allow in the trivia sections. For instance, it's fairly obvious that the Googly Gazer will clip with the Clockwerk's Helm; so would that need to be noted (as indeed it is already)? If it's obvious that it's going to clip simply from imagining the two items together on the class, does it need to be noted? i-ghost 09:38, 19 November 2011 (PST)

There's a few that aren't too obvious. The Apparition's Aspect, for example, looks like it could work with a number of items, but actually has a great deal of clipping. But those are pretty rare exceptions, so yea, I agree that maybe such a robust documentation of clipping errors on cosmetics may not be as needed. Balladofwindfishes 14:13, 19 November 2011 (PST)

 Comment What if we just remove all clipping errors about the item itself? Like the Warrior's Spirit clipping itself, or the Soda Popper's bands with the Scout's hands and also things like "The Shortstop's hammer doesn't move when firing" should also be removed. Only if it's really noticeable, like the Overdose's air cylinders. GianAwesome 09:33, 19 November 2011 (PST)

That's what I've been getting at. It simply follows from simple logical deductions and observation (again something we don't allow on the trivia sections) that new items may not always fit with old poses. i-ghost 09:38, 19 November 2011 (PST)

The case of the Warrior's Spirit clipping is because of an error the creator made with the version he submitted during the contest. It was intended to fit like it does on the current version he re-submitted on the workshop, but something apparently went wrong with the submission and we have what we have now. That's a bug in my eyes, not a generic clipping error like the Pocket Medic's ridiculous clipping bug with the laughing taunt (which I think shouldn't even be listed). In some cases I don't like a blanket rules that all clipping errors shouldn't be listed because many of them actually are errors. The blighted beak back in the day was placed incorrectly on Medic's head. Valve knew this, the creator knew this. It was wrong, and a bug. And yet a blanket statement that all item clipping shouldn't be mentioned would mean this isn't a bug in the Wiki's eyes, when even in Valve's eyes it was a bug. I don't think bugs should be as easy and rigid to moderate as trivia, because trivia is generally a fun fact about the item, but is usually unrelated to the in-game experience. For bugs, every single one of those the player has a chance to experience. I think we need a more adaptive rule of "if the player thinks this looks wrong, and it looks wrong to me as an editor, and it's reasonably fixable, is blatantly noticeable even in still screenshots, it's probably worth mentioning." However, I do have to say I agree the rest of those bugs (Soda Popper clipping and the Shortstop's hammer) are not worth mentioning. That's another thing with clipping errors in client view. Many of these errors stem from a high viewmodel setting, but I don't think Valve takes that into consideration, so those may not be bugs. Many of the clipping bugs in that case shouldn't be mentioned because, while Valve gives the option of higher view models, they don't seem too concerned with making sure things don't clip at that high of a view. Well, this is a pretty long post right now, so I just want to end it by saying I really do think we need better bug rules and a general bug cleanup, I just don't agree with a hard, inflexible rule system that wouldn't allow for bugs that the average player would perceive as a bug and would feel is missing from the article. Balladofwindfishes 14:13, 19 November 2011 (PST)

 Support I missed this discussion up until now. I definitely support it. I recently removed a "bug" from the Sight for Sore Eyes article about the model's jiggle bones freezing in place when the client's framerate drops below 45fps, complete with an explanation of the cvar that causes that behavior. How anyone can post that as a bug is beyond me. If we mention clipping it should only be in extreme cases. Likewise for view model issues; if it doesn't show up on viewmodel_fov 54 don't mention it. Dragonsbrethren 13:47, 23 November 2011 (PST)

 Support with a proposal - how about listing cosmetic and gameplay bugs in different subsections? SiPlus 03:17, 25 November 2011 (PST)

 Neutral The bug section, ever since it was implemented on weapon pages, has always come under fire from the self-righteous editors who feel strict control is necessary over 'unruly' sections. This is something I have always found obnoxious and unnecessary (why they don't turn their attention to more needy pages is beyond me), as it led to elitism and edit wars that should not be part of a community project. The point of the wiki is to inform and educate, and it is one of many sources for the community. If you start removing things that you, a select bunch of unelected people, consider irrelevant and unnecessary, you are doing nothing beneficial. You only need to look at SPUF, for instance, to see people still talking about clipping and errors that you have removed. Furthermore, you only incite new editors to try and replace this information (assuming they have not seen the discussion about removing it), thus leading to more reverts and consequently more work for yourselves. I had already attempted to bring some order to the bugs section, such as sorting by priority according to game-breaking ability. If this is not enough for some of you, I do not know what to suggest. Hence, a neutral vote. Of course I am strictly against any kind of cull you are trying to propose, but I do agree some sort of order needs to be made (hat pages possibly do not need clipping bugs). But it will be a sad day for the wiki when you start getting 'Bug executioners'. You notice how Trivia is now barren and barely touched? Bugs is likely to go the same way. --Focusknock 04:07, 26 November 2011 (PST)

Why not just move to remove the bug sections if you feel it's so much trouble? I'm only asking for some moderation, something which is mentioned in the Style Guide yet something that's somehow slipped by without being enforced or elaborated upon. You can think of this discussion as a movement to simply finish that section of the Style Guide; this isn't a self-righteous quest for some ulterior motive, I'm here for the same reason you are: to improve the Wiki. "This weapon/item can grant infinite critical hits if used in a certain way" is infinitely more useful to the reader than "this weapon/item will clip with the Demoman's left ass cheek if he performs the x taunt, but only if you move the camera to this y position". Yes, certain clipping bugs do need to be mentioned outside of the incredibly obvious ones as we've discussed above (where the reader can deduce this from images on the Wiki), but obscure clipping bugs aren't useful in the slightest, we need some sort of middle ground. Clipping happens; it's happened since launch and is a natural occurrence in virtually every video game ever, but we don't call all instances of it a 'bug'. Well, only here it seems. i-ghost 07:52, 30 November 2011 (PST)

I'm going to have to go with Focusknock on this. I've already stated this in the discussion, but just to reiterate, I think it's important that we allow bugs to be a lot more flexible than trivia because bugs are more integral to the game and are more noticed when they are missing. It's going to be a lot harder than just banning clipping bugs because some of the clipping bugs are very much bugs and are fixable (like the Blighted Beak, Dr. Woah). And if we remove the clipping bugs from a hot topic like the Loch-n-Load people are going to notice and they're going to feel that the wiki is missing information because it's not there, and I don't think we want that. Especially when we have to revert it over and over again, when having it on the page was harmless and added something to the article that people would want to read about. Balladofwindfishes 17:43, 26 November 2011 (PST)

It seems to me a solution would be to create separate bugs articles for articles with sections that get out of hand. I'm all for gameplay-affecting bugs getting prominent display in the weapon articles, but I don't think petty stuff like The Original slightly clipping through the Soldier's shoulder is worth listing in the main article at all. Dragonsbrethren 23:30, 27 November 2011 (PST)

I am strongly in  Support of removing most or all item clipping bugs. I think they're not notable at all, and people who are trying to mix and match outfits should just go do that on their own. Maybe it would be more useful to provide a HOWTO article for using itemtest. It's not in the best interest of the Wiki to enumerate such trivial things alongside real bugs. If there is a guide section for bugs best practices, I hope "item clipping" is right at the top of the list of "do not include". --Fashnek 13:42, 1 December 2011 (PST)

This is exactly how I feel about the clipping issues. We don't need to cater to people who want to play dress up. Purely cosmetic. SS2R 11:47, 7 December 2011 (PST)

Cosmetic items are now an intergral part of the game, and is well beyond simply calling it "dress up". Further, some cosmetics just plain don't work in ItemTest, so telling users to just go use that wouldn't work. I'm not 100% against removing clipping bugs, but I just needed to reply to the two previous comments. Balladofwindfishes 11:52, 7 December 2011 (PST)

May I suggest instead that what you consider as genuine bugs and what are clipping errors be separated instead? Since there seem to be a significant number of clipping errors, but also quite a few genuine bugs, it seems more logical to separate the two, such that those genuinely interested in only either one will be able to immediately get what they want. While clipping issues might seem trivial to some, it is undeniable that some people will want to check if there are clipping issues with their desired item combinations. Naturally there will be a slight problem of what constitutes a bug and/or a clipping error, as well as errors with ragdoll physics, etc etc, but this should be a start. Chaosshaun 21:06, 6 December 2011 (PST)

New point to raise: holding multiple actions

What about this so called 'bug': "While holding reload and firing" or "while holding primary and secondary fire you can (insert looping animations here)". This is taken from the Pistol and various rocket launcher pages. This is only a side effect of Valve introducing the ability to cancel all reload animations at any time, a feature not present at launch for all weapons (I can't cite the exact patch, but I have the SFM build and it's not present there). As a result, it only follows that you'll be able to force the animations to behave a little weirdly, and it's not something that's happening 'naturally' by the game; the user is forcing it (contrast with the Loch-n-Load where the messed up animations are there by default without any user intervention). Thoughts? i-ghost 07:52, 30 November 2011 (PST)

I think that is a bug, in the sense that your gun should not be trying to reload while you are holding +reload if you are holding +attack or +attack2. Even if you do remove this behavior from the lists, I think enough people will consider them bugs that they will get added over and over, and I don't think this particular instance is far enough from a bug (if it even is a non-bug) to warrant that kind of effort. I say leave +reload plus (other action) animation behaviors as bugs. As for the matter of forcing it, a great percentage of the bugs must be manually produced. The fact that some undesirable action is possible is generally a bug, in my opinion. This is especially true if it causes a sound effect in the world (Syringe gun +reload/+attack). --Fashnek 13:42, 1 December 2011 (PST)

I think in this case the user has to actively try to do the bug, doing something Valve didn't intend. Now, that doesn't mean entirely that doing things against what Valve intends is outright not a bug, but in this case, this is such a minor graphical oddity, I don't think removing it would cause people to wonder where it went. I don't forsee any edit wars trying to add it back in. Balladofwindfishes 13:53, 1 December 2011 (PST)

I've started removing all of these. Calling them "forced bugs". It's catchy. SS2R 05:46, 3 December 2011 (PST)

Does it Being Acknowledged as a Bug by the Creator Override Rules?

I think this is something that needs to be addressed before we put in hard rules to be enforced. What if the creator, for whatever reason, says something is a bug even if goes against the rules? I'm reminded of Hermes which has minor clipping, however, that clipping is apparently an actual bug and the version the creator submitted did not clip. When Valve implemented it, they did it incorrectly and the creator is working with them to try and fix it. What would we do in that case? I know in trivia, generally whatever a creator (or Valve) says about an item is deemed okay, but what about bugs? Balladofwindfishes 17:46, 5 December 2011 (PST)

Anything that a creator says in regards to an item I would call worthy of being a bug, despite whatever rules we end up deciding on. Hermes is a perfect example. SS2R 04:01, 6 December 2011 (PST)

Left Handed "Bugs"

Going through some pages, I noticed some bugs (and one trivia entry) that noted something was suppose to be the right hand version, but it appears left handed, etc. Like the Direct Hit kill icon or the Sharp Dresser. But TF2 allows the player to pick which hand the character uses. If the player wants, the character can be left handed, and this is just a simple option in the game. So are these really bugs? We don't know if the class's are right or left handed, and in the game they can be either, it just defaults to right. Further, some of these kill icons are done that way because of visual interest. The Direct Hit kill icon would look confusing and boring and confusing if it were facing right rather than left. The kill icons weren't made on accident, so I don't think it's really a bug. Balladofwindfishes 07:30, 8 December 2011 (PST)

I'm not sure what you're arguing here. Kill icons or viewmodels? Left handed models are an option within the game, so it is expected they should be held to the same standard as the right handed models. I do not think the Electrosapper text appearing backwards in left handed mode is acceptable. It's an oversight from flipping the viewmodel, and is probably unintended; you can't look at it and go hmm that's normal. As for kill icons, it's part of consistency. The Tribalman's Shiv kill icon, for example, is upside down and inconsistant with the in game model, yet a fix is being made for that by the creator. Why shouldn't the same apply to other items? I can probably agree Direct Hit is a moot point since the scope is one of its features and so needs to be visible, but it should be recognisble simply from the shape even if facing the other way with the scope hidden. It was probably not made by accident, but then is that an excuse to let it slide?--Focusknock 10:14, 8 December 2011 (PST)

But there isn't consistency in kill icons. Looking at all the icons in the game, the stock icons are very different from the new unlockables, which are all even more still different from the Uber update icons. And there isn't really any "buggy" thing about the kill icons not totally being accurate to the original weapon. Even stock kill icons were kind of weird and may have differences in them (like the pistol or the original fist icon). The flipping text thing is sort of buggy, and when making this discussion those cases didn't actually cross my mind. I was thinking more along the lines of "this item is shown as left handed here, but in-game it is right handed" type bugs. Because saying the class is right handed isn't exactly true and is information I don't think we know as a fact, and it's information that can be changed at the user's choice. Balladofwindfishes 10:21, 8 December 2011 (PST)

Left handed view-models are simply a model flip and texture flip and is not how the game plays by default; it's the same as listing auto-reload bugs, cl_autoreload is off by default so we shouldn't list any associated bugs. TF2 doesn't have a way to magically transform the text on textures to not read backwards; if this was a case of true independent left-handed viewmodels which have independent textures but still loaded the right-handed textures, then sure it would be a bug. i-ghost 10:22, 8 December 2011 (PST)

I'm inclined to agree. Sure, backward text and oddities resulting from left-handed views are probably unintended, but they are expected results given that the view-models are simply flipped. Additionally, if any of the kill icons portray the left-handed model shouldn't be listed. The kill icons are meant to be symbolic so it shouldn't matter that the icon is 100% accurate, only that it portrays the weapon such that it is recognizable. A bit of artistic license shouldn't be considered a bug. -- - _{(talk | contribs)} -- 10:37, 8 December 2011 (PST)

Ballad, I shall have to agree. Whether the kill icons are bugs or not comes down to defining what is a bug. My argument is the kill icons should be consistant and the fact they are not consistant is credible for this wiki. Once again, the adage 'someone will notice it anyway' comes into play, eg 'Hey that direct hit icon is facing the wrong way!'. The fact it looks boring facing the right way is irrelevant. I'd have to agree, however, that the kill icon inconsistency isn't so much a bug under these new rules as an annoying hitch. As for I-ghost, fair enough.--Focusknock 10:45, 8 December 2011 (PST)

Removal Starting

I've spent the morning going through all the weapons for Scout, Soldier, Pyro and Demoman. I went through each Bugs section and, based on the general consensus here and while discussing it in IRC, removed all the bugs I believed no longer served a purpose. Right off the bat, there was a debate about some, and others everyone agreed on. For the time being, I'll stop and see what people think about going this direction in regards to removal. What's left behind is also things I was unsure about. As important as adding information is to the site removing it is just as important, and having fresh eyes go over things sounds good. I'll admit, reading bugs that actually feel/sound like bugs looks nice. I can't tell you how excited I am to not see that every single Scout weapon clips with his palm on every page. Removing the clipping things is going to be much easier on hats due to their cosmetic nature, but there are plenty of bugs in within the weapons that are debatable. SS2R 05:46, 3 December 2011 (PST)

Weapons are done, at least for their once over. 305 hat/misc pages to go. SS2R 11:40, 7 December 2011 (PST)

I've edited the weapon guidelines to reflect the decision. --Focusknock 03:29, 8 December 2011 (PST)

Item owner lists addition (HOUWAR)

You know how we have pages for owners of various items such as wiki caps and golden wrenches, should we also have one for people that own HOUWAR? (Hat of undeniable wealth and respect) Ihasnotomato

I would say maybe that kind of list would not be so good as people trade the HOUWAR all the time. It is also unknown how many people actually completed the potato pack. If there is hundreds it may not be so easy for us to list every one. seb26 17:48, 26 November 2011 (PST)

 Disagree Wiki caps are given out by the wiki and Golden Wrench owners are listed. As for as I know, there is no such list for the HOUWAR. Ownership tends to change a lot as well, making it hard to track. Scootz 17:51, 26 November 2011 (PST)

Ah, ok i didn't realize it was tradeable, thanks! Ihasnotomato

Well it is not tradable but it can be gift-wrapped (Wiki Cap, Saxxy, etc cannot) I recall seeing a number of HOUWARs on SourceOP selling for a lot in cash, it would be a nightmare to try and maintain a list like that D: seb26 22:33, 26 November 2011 (PST)

I know for a fact some people own more then one HOUWAR and they are traded quite regularly too. I don't think there is any point for a list. Wariopunk 08:00, 5 December 2011 (PST)

Proposing a Class Bio template addition

I'd like to propose an addition to the Class bio template; "Other Badges" or "Old Badges". Instead of having the template pull up the RED/BLU badges like it currently does, I think if added, users should be able to manually add in other badge images, like so:

| otherbadges = [[File:Sniper_badge_old_RED.png|50px]] [[File:Sniper_badge_old_BLU.png|50px]]

I'm proposing this, because as evidenced by this subpage I made in my userspace, some classes have old badges that were used in early trailers/screenshots and such. Plus, now that we have the original Skull 'n Crossbones Heavy emblem (contributed by Yeipigsl), our collection of class badges, both currently-used and from old versions of the game is complete, and we should add the ability to display older badges in the Class Bio template. Comments? Opinions? Post 'em! 404: User Not Found ^(talk) 14:44, 27 November 2011 (PST)

Oh, I forgot to mention: If this idea gets implemented, the respective images of previous badges will have to be removed from the Gallery sections on the class pages of classes with old badge designs (e.g. Scout, Soldier, Demoman, Heavy, Sniper) Also, I'm gonna toss in a  Support for myself :P 404: User Not Found ^(talk) 14:46, 27 November 2011 (PST)

I just did a preview test on the Class Bio template, and I think the following code addition, added directly below "Badges" should be sufficient for this idea to be implemented:

    {{#if: {{{otherbadges|}}} |
    {{!}} '''{{lang
      | en = Beta/Unused Badges:
      }}''' {{!!}} {{{otherbadges}}}

Just pop that in below Badges and everything is good to go. Then on the appropriate pages, you add (this is just an example):

    | otherbadges = [[File:Sniper_badge_old_RED.png|50px]]  [[File:Sniper_badge_old_BLU.png|50px]]

And boom, everything's good. I still need the community's opinion on this before I implement it, and it does need proper translations for other languages, but yeah, what do you guys think? 404: User Not Found ^(talk) 17:02, 27 November 2011 (PST)

 Neutral I'm on the fence on this. It sounds like a good idea, and wouldn't be difficult to add, especially considering that you have all the code laid out. I personally don't have a problem with it, but some users of the wiki might mistake the badges of the alpha and beta with the current badges. I'm fine with either doing this or having them just stay in the gallery section. Lets see how other users feels about this. 13:28, 29 November 2011 (PST)

Yeah, there could be some slight confusion with the badges, but I did lay out the names "Former Badges", and "Old Badges", though we could opt for something short, yet descriptive enough that people would realize that the other badges are alpha/beta badges. I did have another idea that I was originally going to post that involved adding a "Badges" section above the "Avatars" (Steam profile avatars) section on each of the class pages, and would be done with gallery tags, just like how I did it on this subpage of mine. But I noticed the existing Badges part of the Class bio template, so I scrapped the original idea. 404: User Not Found ^(talk) 14:01, 29 November 2011 (PST)

I have a better name idea. "Beta/Unused Badges". I've edited the above code to show what I mean. 404: User Not Found ^(talk) 18:36, 29 November 2011 (PST)

Gathering more user input before making changes to the Wiki

I do not think it would be unfair to say that most regular users of the Wiki are unaware that this page even exists, and why would they be, to someone who doesn't actively edit, discussion pages on the whole wouldn't be looked at, especially not a kinda less obvious one like this. While this isn't usually a problem, Focusknock's post in the Why aren't bugs subjected to the same scrutiny as trivia section of this page led me to ponder something. He makes a point about editors being a "select bunch of unelected people" making decisions for a whole community. At first I thought this unfair; the whole point of the Wiki is that we are unelected and anyone at all can join in and edit/contribute to discussions. But then I realised that, while that was true, most users of the Wiki don't do that and in fact would never even see a change like this being proposed before it was implemented.

Even though the Wiki holds doors open for any who want to contribute, many don't and don't know that changes are being proposed, but if they did may in fact not want the change at all as Focusknock suggested. When it is something that is being added this is obviously much less of an issue, but when we are taking something away, I feel the active users of the Wiki should have more of a chance to say whether they want it to happen or not. Therefore, I suggest that if someone has suggested a major revision to the Wiki's content and it has generally been agreed upon, before it is implemented there should be some form of notice on the main page perhaps, so users who don't really edit can be notified that something major is about to happen, a link to the discussion is given and they too can give their input on whether it should happen or not.

Like I said, when something is only being added or it is something somwhat minor this is not so important, and there is also the possibility that things could get a bit out of hand if a mass influx of users started giving input on something. However I feel Focusknock made a good point about a small group of people making decisions for a much larger one, even if anyone can join the smaller group. -Mr. Magoolachub 21:53, 27 November 2011 (PST)

Here's an idea; try posting on the Main Page any heated ongoing discussions. It could be something like, "Why aren't bugs subjected to the same scrutiny as trivia discussion is currently ongoing. Participate now!" or some other promotional caption to alert people to this issue. Fyahweather 21:56, 27 November 2011 (PST)

At the very least, people should be adding their discussions to the Template:CentralDiscussion template, and removing them when the discussions are removed, but they're not doing that. I was the last one to fix it up, and it's already out of date again. Even when people do adjust the template, that bar seems to go unnoticed by most people and the discussions never really get surfaced. I don't really have a solution. It's the nature of a wiki that if it hasn't reached critical mass (and I don't think a TF2 wiki ever will), there aren't enough people to have government/process self-operate. The fact is, not enough people are "on the same page" with the same level of commitment as a bigger wiki. I think the best you can do is try to surface your discussion via IRC and Template:CentralDiscussion. Maybe it's also time to look again at that navbar and decide whether that's really the best way to float up active discussions to the people who want to participate. --Fashnek 13:52, 1 December 2011 (PST)

Badges or Emblems

While I'm still on the topic of class badges/emblems, I've noticed that the Wiki uses both "Badges" and "Emblems" when referring to the class icons that most classes have on their shoulders. In most pages and in update histories, they're referred to as Emblems. In the Class bio template, they're referred to as Badges. This isn't a necessarily urgent matter, but it's something I'd like to get cleared up so I can get the go-ahead to go around and change any instances of <old name> to <new name>. The only thing I'd need administrative help with is the filenames of some of the images in Category:Class badges as a few images are named with "emblem", and the majority are named with "badge", so some re-uploads or image moves would be required to fix the naming. So what should we go with? Badges or Emblems? Personally, when I see the images, I think Emblem. 404: User Not Found ^(talk) 18:43, 29 November 2011 (PST)

I'd agree with emblem. -Mr. Magoolachub 18:10, 30 November 2011 (PST)

I'd go with emblem as well. --Scootz 17:10, 2 December 2011 (PST)

Emblem is better - I think badge implies the misc item badges, like dueling badges. » Cooper Kid (blether) • (contreebs) 18:50, 2 December 2011 (PST)

If the mass vote turns out to be for Emblem, I have no problem whatsoever going around the English articles and changing any references to "Class Badges" to "Class Emblems". I've got plenty of free time. As I've stated before, the class Emblem images are another thing. I'll have to save them all, then re-upload them under a proper naming structure, including the Beta Emblems. Speaking of that, I think "Beta Emblems" would be a better name for that proposed Class Bio template addition I discussed above. 404: User Not Found ^(talk) 19:41, 2 December 2011 (PST)

I chose emblem. Even though symbol is not an option tokens does look like badges and some of the misc just as Cooper Kid stated. This might need someone from valve to settle this argument.--Bigbangbilly 19:24, 4 December 2011 (PST)

I always thought it was Emblem? Wariopunk 07:56, 5 December 2011 (PST)

Well, mass votes go to Emblem. All I require now is the OK/go ahead from an admin to begin converting references to "Badge" over to "Emblem". Dictionary strings for "Badge" will have to be retranslated as "Emblem". As for images, I can reupload under new names and redirect old filenames to the new ones. 404: User Not Found ^(talk) 19:16, 5 December 2011 (PST)

New buy button - which positioning do you prefer.

I've been working on integrating the buy button into the item infobox... here's a few variants with the button positioned in different places, please comment and note which one you prefer - with the topmost infobox being #1, and the bottommost infobox being #4. Ignore the 'Buy now' button in the top right of the page - that's the current implementation that I'm wanting to replace. -RJ 12:50, 2 December 2011 (PST)

1st positioning is the best.  –  Cructo [T][C] 12:51, 2 December 2011 (PST)

That first one is definitely superior in both placement and detail. Mainman ^{(Talk ▪ Contribs.)} 12:54, 2 December 2011 (PST)

Numero uno. MousseBOT 13:00, 2 December 2011 (PST)

 Notice Style 1 has been implemented, but I am still interested in opinions with regards to the positioning of the button, so this discussion remains open. :) -RJ 14:47, 2 December 2011 (PST)

I personally enjoyed style 3. It's not too distracting, but still visible. Mpnov 14:58, 2 December 2011 (PST)

I liked style 3 the best by far. I set up the discussion but I forgot to say anything. If this is done, please adjust Template:CentralDiscussion. --Fashnek 17:08, 2 December 2011 (PST)

Style 4. SS2R 17:13, 2 December 2011 (PST)

I like Style 3 much moreso than the current positioning, the current positioning makes it seem too much like this is a shop - it's not, it's a wiki. While I'd say Style 3, I would much rather any of styles 2, 3 or 4 over the current style 1. -Mr. Magoolachub 03:32, 3 December 2011 (PST)

I like Styles 1, 2, and 4. 1 and 4 more than 2, and I think 3 gets "lost" under the item loadout; not enough contrast. I'd be okay with 1 staying. Dragonsbrethren 15:12, 3 December 2011 (PST)

I support Style 2. It keeps the button from being too prevalent (which makes the wiki look like a store, as was mentioned) without burying it too far down. Mar 15:13, 7 December 2011 (PST)

Trusted editors

What about "Trusted editors" group? We have a lot of users who don't have moderator flag but who can get rights to edit protected pages and not type CAPTCHA each time they add links. --Daniil 06:28, 3 December 2011 (PST)

I'm also for that. Or if it is not possible a refresh captcha button please, sometimes you cant see it or write it correct. TheDoctor(without a small pic) 06:33, 3 December 2011 (PST)

Indeed it can be very annoying if you do lots of small edits. I approve this -- Keisari 06:56, 3 December 2011 (PST)

Approve. Nero123 (talk | contribution) 06:57, 3 December 2011 (PST)

Gud idea Hikkie 07:03, 3 December 2011 (PST)

I'm rather uncomfortable about the idea because other newer editors may think that these people are just plain better than others. I don't think that EVERY good editor has rights to edit protected pages. Fyahweather 09:00, 3 December 2011 (PST)

You forgot about the Wiki Cap :) --Daniil 09:31, 3 December 2011 (PST)

 Support It'd be nice to not have to type the captcha everytime. But I think protected pages are just to much, we should leave them to the mods. Also, we already have a group like that right? The people with green names in the iRC channel. GianAwesome 09:41, 3 December 2011 (PST)

It would be nice to not have to go through the really annoying and sometimes broken Captcha. Seriously, yesterday I was adding in like 3 words and it made me do one because it said I added a new link when I didn't do anything like that at all... However, I don't think users should have access to protected pages. They're protected for a reason, and I think even trusted editors could lose their cool and get into edit wars, or accidentally edit a backbone template (thinking they know what they're doing) and crash the wiki. But yea, being exempt from Captcha would be awesome! Balladofwindfishes 09:58, 3 December 2011 (PST)

Captchas should be fixed but I am not sure about the 'trusted editor' group. There are editors who are more trustworthy than others but to turn it into some exclusive group that is rewarded with no captchas / edit any page they want .. (not to mention people will think Wiki Cap = trusted) seb26 11:20, 3 December 2011 (PST)

 Support Put a disclaimer somewhere that states that it does not boost wikicap eligibility. --Bigbangbilly 19:26, 4 December 2011 (PST)

 Neutral I know I'm a few days late on the topic, but I would like to give my two cents. It would be nice to give certain users more abilities, but at the say time it might develop a bit more of a hierarchy here at the wiki. Currently its simple, Admins > Mods > Users; ignoring the other groups such as bots or bureaucrats. Adding trusted users might not go over so well; as Fyahweather and seb pointed out, some might turn it into an exclusive group of sorts. On the other hand, as a lot of you may have seen, people like me make tons of small edits in small periods of time. So I guess I personally like the idea, but there are some kinks to be dealt with. 19:32, 5 December 2011 (PST)

I was going to suggest maybe setting up an editing-based quiz of sorts that users can do to qualify to have Captcha removed from their editing. But that could be open to exploitation by users giving other users the answers. So I'm stumped on this. 404: User Not Found ^(talk) 20:12, 5 December 2011 (PST)

Well, apparently the greatest reason to create this group is the captcha. So why not make something like a "Global Captcha"? A user is given permission to use it, and after he types it once in a captcha box, he won't be asked to do it again for the next X days. So we can change the global captcha periodicaly, in case we need it. And it wouldn't need a special group for that. GianAwesome 03:58, 6 December 2011 (PST)

There is the 'autoconfirmed' group which is auto given to users who have been registered for x days or made x edits (with these numbers configurable). It is not enabled on this wiki however. I think it would be best to use this group to disable captchas. seb26 11:26, 6 December 2011 (PST)

It's been in discussion for a long time... We kinda stopped talking about it since last summer, but Pilk has been wanting to use the autoconfirmed group to get captcha removal. We should restart talking about it. The question is not of creating a "trusted" editor group, because we have good faith and trust that any editor will try to do good things, but it's true we should get something working for competent editors in order for them not to haev captchas. Tturbo _{( / )} 11:52, 6 December 2011 (PST)

Sorry to get off-topic, but Pilk is a she? O_o 404: User Not Found ^(talk) 19:35, 6 December 2011 (PST)

No it's just me who's a dumbass and typoes a lot (especially in english)... ¬¬ Tturbo _{( / )} 20:38, 6 December 2011 (PST)