Team Fortress Wiki:Discussion/Archive 16

The following discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Archive 16: November—December 2011

Basic Strategy Item Set edits by user InShane.

He keeps on editing the sections of these pages, even though they were fin to begin with. It's become increasingly frustration to un-do all of his edits by myself, so I am asking for the help of other to help me clean up these articles. It would be greatly appreciated. AnthonyX 18:55, 1 November 2011 (PDT)

What exactly is he doing? I'd be glad to help. I see his edits. You might want to post it on his talk page though. —Rocket Ship BBQ(•) 19:03, 1 November 2011 (PDT)

He Keeps removing all of the item sets for each class, and only puts in the sets that have bonuses to them. The sets that don't have any bonuses to them are still considered item sets, even the new halloween costumes. AnthonyX 19:13, 1 November 2011 (PDT)

 Comment The new Halloween costumes contribute no strategies. 19:18, 1 November 2011 (PDT)

Currently discussing this in the IRC. Summary: item sets that have no bonuses have no strategy and thus should not be mentioned. Item sets covers all item sets and list whether or not they have bonuses. The strategy pages, on the other hand, need not list those. Set effects, such as +25 HP or an immunity to headshots, provide gameplay effects that should be covered. Saying "BEEP BOOP SON" does not. -- InShane 19:20, 1 November 2011 (PDT)

This is being discussed in the IRC channel right now. I absolutely agree that the Halloween sets, as well as any other cosmetic set, should not be listed on strategy pages. Those pages should not be comprehensive on all official sets. On the other hand, I think there is value to some non-official sets that were deleted. I think the real issue here is of naming. Calling the sections "item sets" creates some confusion; the sections would be better named something like "Loadout-specific strategies." --Fashnek 19:23, 1 November 2011 (PDT)

Currently, the sections are labelled "Item Set Effects" - This should address the fact that the section only covers loadouts that give specific bonuses, specifically sets from the Mannconomy and Medieval updates. -- InShane 19:28, 1 November 2011 (PDT)

While being thorough is a laudable goal, purely cosmetic items that have no effect upon gameplay would not appear to have their own strategies, and individual weapons are usually covered independently. If a persuasive case can be made relating to why cosmetic item sets should be included however, and their strategy can be outlined in detail, then the community could vote and support or oppose its addition. For example, one (but not me ;)) could (perhaps) argue that the Apparition's Aspect provides an advantage, and outline an anti-Sniper strategy for the Pyro. Then the community could vote on it and a determination could be made. As for this year's Halloween costumes, I'm not sure that their addition adds any value (as my Management say). --- Esquilax 19:32, 1 November 2011 (PDT)

 Comment It shouldn't be labelled "Item Set Effects" but instead "Polycount Sets" as the section doesn't describe the effects per se, but rather the set as a whole. —Rocket Ship BBQ(•) 19:41, 1 November 2011 (PDT)

As of now, I intend to have the sections address how to utilize the set effect, and whether weapons required for the set effect have a significant impact on how to do so. -- InShane 19:45, 1 November 2011 (PDT)

The Australian Christmas#Class_sets have effects as well. Let's not get hung up on the official sets. Some of the effects don't really make a difference to strategy at all, and some sets that aren't official Item sets have the most implications on strategy. I don't think this is about sets. This is about loadouts. — The preceding unsigned comment was added by Fashnek (talk) • (contribs) 19:46, 1 November 2011 (PDT)

We're not focused on Item Sets, we're focused on the effects granted by certain loadouts. -- InShane 19:47, 1 November 2011 (PDT)

The effect requires you have the set, which forces you to adapt your strategy. Australian Christmas sets are simply Polycount sets released later. —Rocket Ship BBQ(•) 19:49, 1 November 2011 (PDT)

I agree with the Halloween Sets not being added to the strategy list, since they're just hats and nothing else. I've had my posts removed by InShane as well, and he said that the set has to have a real effect (i.e. Sentry Buster Set 20% Resistance to Sentrys or w/e). While I agree with this, some item sets such as the Black Market Buisness should be listed in the item sets, since A) many people equip this set and B) new players want to know how this could effect their gameplay. Just my thought, and I removed the edit to not get into an argument. — The preceding unsigned comment was added by BillyMays (talk) • (contribs) 18:03, November 3, 2011

Item sets without effects are essentially specific loadouts, with a hat or misc. item added for flair. Because these sets are just specific loadouts, individual item strategies cover what is needed. Entries generally already take care of weapon synergy, such as what secondary weapons work with what primary weapons, unless most possible loadouts with said weapon are viable. -- InShane 19:11, 3 November 2011 (PDT)

I see what you mean, makes sense :) -- BillyMays 16:27, 4 November 2011 (PDT)

Quality Checklist?

On every Wiki page that has to do with an item, it's a bit troublesome to have to read between the lines for the item quality's the item can be in.

I propose we can have a sort of quality checklist, or some other format of the sort, that allows us to easily see the quality the selected item can be in — The preceding unsigned comment was added by BillyMays (talk) • (contribs) 00:11, 4 November 2011

This can be quite a tricky subject to add to articles. A number of items that normally don't exist in certain qualities (i.e. Vintage Earbuds) exist due in part to a Customer Support issue awhile back. People would delete an item, then make a support ticket and they would be refunded their item in Vintage. However, I am all for this suggestion, though it would require revamping our infoboxes for weapons & hats to include some sort of quality-colored checkboxes, showing that the item is available in that quality. Perhaps a page could be constructed to list some "oddities", such as the Vintage Earbuds, and how they were obtained. Adding a page on the subject would be a great thing because a lot of players don't know the history behind those illegitimate Vintage items, and how they were obtained. I vote  Support. 404: User Not Found ^(talk) 17:58, 4 November 2011 (PDT)

It would definitely be difficult to add to the Wiki, but maybe in the future it could be done. Thanks for supporting :) BillyMays

 Support but definitely omit the ones that aren't normal. We should only be listing whether the items have legitimately been obtainable in a given quality. For example, most recent promo items have been obtainable in either Vintage or Genuine quality. If an item wasn't given out in a given quality, it shouldn't be listed. Otherwise, you would have to list Vintage versions of every older item, which makes no sense. --Fashnek 11:38, 14 November 2011 (PST)

 Support We just need to find a good way to implement this. I think writing down every word (Vintage, Unusual etc...) would make the table look to big. Maybe a character representing every quality with a tooltip? Like "V"? Also, should we add Community and Self-Made? GianAwesome 19:02, 14 November 2011 (PST)

Ahoy, long reply ahead! Frankly, I'd do it similar to what Pilk had in his armory subpage awhile ago. Rounded-corner rectangles, borders colored based on the quality, and backgrounds colored similar to the ingame backpack, with TF2 Build text inside showing the quality name. Tooltips could be applied for things like Vintage Cheater's Lament, stating "Items in this quality were obtained via a customer support error and are rare.". It would require a makeover of the item infobox, but it's do-able. Technically speaking, every item is available in every quality, but it all boils down to which quality Valve decides to release an item in. This of course has no bearing on this idea, but I thought I'd state it anyway. Regardless, I'd love to personally go around listing which item(s) are available in which quality/qualities. I'm personally a fan of unused content and/or "oddities" like the Vintage Bill's Hat/Cheater's Lament/Max's Severed Head. Also, while I'm on the subject, I think Valve-quality items shouldn't be listed simply because normal players cannot obtain the item in Valve quality, and every single item is theoretically available in the quality, if Valve sees fit to create them for themselves. I know there's probably a few people here who'd think this is a "dumb idea" and shouldn't be implemented, but personally I think that because we are a Wiki, we should provide any and all information that we can about this type of thing. 404: User Not Found ^(talk) 19:41, 14 November 2011 (PST)

Actually, we could probably combine the two ideas. Rounded-corner boxes with TF2 Build font showing the first letter of the quality name. "V" for Vintage and the border color would be vintage blue with the dark blue background (using the hex color codes from my UserItem template which uses the hex color codes from the ingame backpack. It'd look good! 404: User Not Found ^(talk) 19:44, 14 November 2011 (PST)

V

G

S

U

Just an example, we can make it look a lot better. GianAwesome 20:20, 14 November 2011 (PST)

Oh god, does that ever look horrible on this old version of IE that my workplace uses. It's like one big block of darkness with four letters in it. I'll look at it when I get home and am able to use good ol' up-to-date FireFox. Nonethless, I'd go with adding a font style to the div's, and putting it as "TF2 Build" font. 404: User Not Found ^(talk) 20:23, 14 November 2011 (PST)

V

G

S

U

I don't think this looks bad, although if you put it much smaller some people might have trouble seeing it, I don't have good eyesight and I was struggling to see the vintage and genuine colours against the small patch of dark background at smaller font sizes. Stewart 20:35, 14 November 2011 (PST)

Looks a lot better, we should also put a link, then we'll just need the translations. GianAwesome 13:12, 15 November 2011 (PST)

I agree with the second one looking better. About the unobtainable vintage items (i.e. Vintage Bill's Hat), I think that maybe in the checklist we can add something of the sorts like "Still Obtainable" or "Able to Get". That way, people will know that Vintage Bill's do exist, just that they're not obtainable anymore. BillyMays 16:06, 15 November 2011 (PST)

Wait, so putting "Still Obtainable" gives the impression that they're not obtainable? Riiiight. But seriously, I'd opt for using "Previously available due to customer support issues, then link "customer support issues" to a new section of the Item quality page that explains how users purposely deleted their items to get them returned in Vintage quality from customer support. 404: User Not Found ^(talk) 19:33, 15 November 2011 (PST)

Putting something along the lines of "Still Obtainable" means that it can still be dropped/crafted/earned in any sort of way. Vintage Bills or other odd glitches would be X'd off on the list with this category, so the users would know that it's not obtainable. BillyMays 18:26, 18 November 2011 (PST)

Better yet, we could have floating tooltips that appear when you hover over the quality letter, similar to what TF2Items.com has, and what Mecha the Slag uses in his SLAG Shop/AW2 Backpack & Loadout. When you hover over the letter, a popup appears with a small text list that would list if the item can be obtained via drop/crafted/etc in any way. If an item in a certain quality cannot be crafted, then the necessary "can be crafted" text would not appear in the tooltip. Genuine items would obviously have "Distributed" as the only obtain method. As for Vintage, you can't craft Vintage items, so maybe "Awarded"? The tooltip method would obviously need some new JS to be added to enable floaty tooltips, and the tooltips would indeed be useful, and it would also allow me to finally set up this new idea I have to revamp the weapon lists on the Advanced Weaponiser article so they don't need Wikitables anymore. 404: User Not Found ^(talk) 19:04, 18 November 2011 (PST)

Item Tooltips on Item Page Links

This is a proposal for a relatively simple, but useful addition to the wiki - mouseover tooltips on links to item pages.

Similar to how items in-game, on steam community, and when linked in chat have mouse-hover tooltips, such tooltips could also be added to links to item pages. This would at the very least make browsing blueprints a lot simpler as users would no longer have to visit each item's page to see the item. Not all links would neccesarily need to be changed, but I believe that this would be a valuable addition to Blueprints at the very least.

I have put together a simple example of what I am suggesting in my user-space. See User:Stewart/sandbox and follow the instructions. Some screenshots of my example are available here: [1] (Note: the tooltip looks broken because that's how it looks on User:Stewart/Sticky_Jumper).

I have seen such systems used to great effect in other wikis, for example here: [2] (if you will excuse the linking of another wiki).

I'm no javascript expert and I'm sure there are more than a few people here who can suggest improvements/changes to my code but at the very least it provides a proof-of-concept for what I'm suggesting. The amount of work required to do this is relatively small, and there are no external dependencies of any kind as the tooltips are generated from the wiki pages which already contain a static version of this. I spoke to Moussekateer on IRC earlier who suggested I post my idea here for discussion, so here it is.

Stewart 13:17, 5 November 2011 (PDT)

 Support unless it lags it too much, although it isn't activating for me on Wowpedia. —Rocket Ship BBQ(•) 13:39, 6 November 2011 (PST)

 Support It's cool and it works and I can see it's uses. Do et. -RJ 15:32, 6 November 2011 (PST)

 Support Just tested it out and it works great. Looks very nice and would prove to be useful. You have my support. MogDog66 15:44, 6 November 2011 (PST)

 Support Would be useful.  –  Cructo [T][C] 17:05, 6 November 2011 (PST)

I have come across issues with items such as Scrap Metal which don't have their own item pages, I'm not sure what could be done about these apart from avoiding trying to show tooltips for these items, perhaps Template:Blueprint could be modified to have ingredient-1-nolink etc arguments that would do this. Stewart 11:09, 10 November 2011 (PST)

First,  Support. I think that adding those links would be the best of the two options. Or we could somehow setup a code that, when set to the correct parameters, or when it is about a certain item, will point to an item tooltip stored somewhere else (maybe in a template specially for it?) and use it, and either linking to a related page (Crafting maybe?) or not linking anywhere.  –  Epic Eric (T | C) 11:33, 10 November 2011 (PST)

Unfortunately, in order for the script to be able to tell where to find the tooltip (other than the target article) would require a custom attribute on the element, and unless the wiki has html 5 enabled data- attributes are not allowed. None of the permitted html attributes allowed by the wiki are appropriate for storing this type of data. Regarding the nolink parameters i think it would be more appropriate to create a dictionary-like template which can be used as a central list of pages which should not have tooltips on their links. Given that the presence of an appropriate backpack tooltip on the target page is not something that should be varied on a link-by-link basis, I think this might be a more appropriate solution to the problem (An example of such behavior is now on User:Stewart/sandbox demonstrated in a blueprint example), unless anybody has any better ideas of course. Stewart 15:42, 10 November 2011 (PST)

 Support but only on the condition that it's done right. I propose that all items in Category:Items (nested) need to be crawled for the tooltip data and the data needs to be compiled into a JS file periodically, or perhaps when those pages are updated. That file would then be cacheable by the browser. At that point it would be simple to make a script that showed tooltips on URLs fitting the pattern. Assumedly this compilation would be done by a bot. I could provide more details if needed. Here's a lazy-loaded (but VERY powerful) version used on Wikipedia: Naviagtion popups --Fashnek 17:42, 13 November 2011 (PST)

This may be the better option and would solve the problem with certain items not having their own item pages (and therefore being unable to show tooltips under my example implementation) although would require a bot to do the work, and with permission to put the appropriate javascript somewhere it can be loaded. Stewart 17:55, 13 November 2011 (PST)

Misc incompatibility / compatibility

There is something I have been curious about for a while but not sure if we should list it. Should the team team fortress wiki have on each misc page compatible and incompatible miscs listed with one another?. This would be used to inform people of what they can and can't equip with one another to stop them from wasting time/money getting their ideal miscs only to find out they wont go together. Thoughts please? - Lexar - talk 01:54, 6 November 2011 (PDT)

Compatibility is quite apparent from the equip regions, I think. — 01:58, 6 November 2011 (PDT)

 Disagree Equip regions covers this just fine IMO. --Stevoisiak 16:04, 13 November 2011 (PST)

 Disagree on the matter of explicitly listing compatibility, but we do need to create a more definitive and precise place to list incompatible/overlapping equip regions. Someone needs to actually figure this out for sure. --Fashnek 11:38, 14 November 2011 (PST)

 Disagree I don't think its needed C. Townshend 13:52, 24 November 2011 (PST)

Heavily revised user hat checklist template.

With several of the sections that are not class-specific growing larger than the sections that are class-specific, it's making the User hat checklist template extremely messy both to update and just look at in general. I've created a revised template in my sandbox and merged the Promo, Event, and Halloween sections into the class-specific sections and All Class sections (both to keep class-specific items together and to make things easier to update). Some ideas I'm still tossing around currently are:

• Giving the All Class Halloween items their own Halloween section (class-specific items would remain in their individual class sections).
• Changing the Ghastly/Ghastlier/Ghastlierest Gibus hats a switch (like the Treasure Hat) so that one would show up instead of all three.

Eventually, I might try to find a way to include coding for item quality, but for the time being I just want to clean up the template; in the long run, it'll make it easier for me and anyone else who updates this template to do so quickly while removing categorization/sections that really aren't necessary and reduce the page size. Any feedback and other ideas for improvement are welcome. ButteredToast 08:19, 8 November 2011 (PST)

Template-ifying Update Page Tables

As you may know, I recently began my project of recoloring Update pages to meet the color schemes laid out in the update navs. This has been mostly successful. However, I have run into the issue of applying these color changes across every language. Hell, this years Halloween page alone took me well over half an hour to do. Repeating this process over 14 different languages would take days. Then I wondered why they weren't in templates. All of the update navs on the bottom of the pages are. All of the tables are identical across all languages. Plus, the tables are essentially raw HTML code. They are a pain to work with, and are generally very messy. A perfect example is what this years halloween class set table looks like to the average editor. Nobody wants to see that. The So I propose that all the tables on update pages that document additions to the game be redone as templates. We already do this on the Mann Co. Store page, so why not on the update pages? --Stevoisiak 13:23, 12 November 2011 (PST)

A reminder about bots. These tasks can be automated -- if you can give a clear and precise description of the changes that need to be made (with examples of various cases), one of the bot owners or myself could put together a script that will take care of these time-consuming edits. --Fashnek 11:38, 14 November 2011 (PST)

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)

Thank you. SS2R 00:42, 9 December 2011 (PST)

Scout, Soldier, Pyro and Demoman hats/misc done. Incoming break time. SS2R 01:53, 10 December 2011 (PST)

Crit-boost glowing

We know that items need a certain set of parameters to glow correctly in their VMT, and those are fine as bugs if said parameters are omitted, but what about items with multiple textures? I've done some research around this and it seems that the game can only colour/tint one texture per item at a time. So if a weapon references/includes more than one texture, only one of them will glow (assuming both are set up correctly). This is why the only the Scottish Resistance attachment glows, and why the Phlogistinator's canister doesn't glow (although the canister's team-colours are also set via $color2; another reason why it can't glow). Knowing this, it looks more like an engine limitation than a bug. I'm inclined to remove these, or at least not note them as 'bugs'. i-ghost 06:07, 6 January 2012 (PST)

I think if we don't list them, but list the others that don't glow at all, players are going to think those pages are missing the bug. If we were going to note them on the page at all, they fit better in bugs than they would in trivia anyway. Balladofwindfishes 06:20, 6 January 2012 (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)

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)

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)

Why is it being included at all? It seems rather gauche to commercialize a community-driven portal of information. Atmo 09:46, 10 December 2011 (PST)

It may indeed seem a bit gauche (what in the blue hell does gauche even mean?), but frankly, it's a wonderful addition in my personal opinion. Thusly allows us to search for a specific item here on the Wiki and purchase it straight from the site as opposed to firing up TF2, sitting through the initial loading phase of the game, then rummaging through the store. Isn't technology wonderful? 404: User Not Found ^(talk) 16:22, 10 December 2011 (PST)

It may be a convenience to some, but only 20-30% of players have purchased anything. In fact in other F2P games only 3-5% of players actually purchase anything, so it is possible that the additional 15-25% on top of that would be simply their only purchase as an upgrade to premium. That makes the button useful to about 10% of players, tops (One time spenders wouldn't find the button nearly as useful as someone who constantly buys items). If we were only able to track how many people have clicked those buttons. Additionally, Style 1 is also the most intrusive style, smacking the button right under the eye-catching picture. If this button has to be on the pages (which it evidently has to be considering it's already implemented), it should be Style 2, or even 3, in my opinion. Less intrusive, and sure, spenders should be able to tolerate a little scrolling. —Rocket Ship BBQ(•) 14:25, 29 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)

So...what's the decision? GianAwesome 17:52, 10 December 2011 (PST)

 Support I had to type in capchas when I edited my own userpage. That's just silly. --Stevoisiak 08:22, 17 December 2011 (PST)

Disambigs based on item type

There has been some discussions regarding adding disambigs on some pages (such as Rocket Launcher) with the criteria being item types (those shown next to the item level, like "Level 1 Rocket Launcher"). The main argument, apparently, is to separate items as to what they would correspond to in real-life. I'd like to know whether you support the addition of these hat notes or not.  –  Epic Eric (T | C) 07:10, 13 December 2011 (PST)

First, let me start. I  Disagree. It'd only make searching for weapons more complicated. I mean, why would people bother to look it for the item type if they can search it for its kill icon/model (on the Weapons page) or by the class wielding it? (both Weapons page and class navigational boxes, like the one shown at the bottom of the Rocket Launcher page). Separating them with the criteria mentioned would only cause more trouble finding a certain weapon, such as the Cow Mangler 5000, which is not listed as a "Rocket Launcher", or the Sniper's melees, which are listed as "Daggers" (you can see more about the first example in my talk page). Finally, for all the unpracticity and redundancy it brings, I'm not in favour of adding these disambiguations.  –  Epic Eric (T | C) 07:10, 13 December 2011 (PST)

 Agreeish While they might not be essential, they certainly aren't doing any harm. I'll add though that the disambig pages for the likes of pistol and knife are very important, as there are options there used by several classes, in different weapon slots. » Cooper Kid (blether) • (contreebs) 08:22, 13 December 2011 (PST)

 Naw TF2 has too many silly item types (i.e. fish, indivisible particle smasher, stick bomb), which can cause much confusion (non-milk substance), and these "item types" are rarely used to refer to items. Additionally, they are purely cosmetic, and many items have unique item types, and therefore have similar performing items with different item types. —Rocket Ship BBQ(•) 14:41, 29 December 2011 (PST)

Festive Weapons

Festive isn't a new quality (though I haven't checked items_game.txt). From what I can see on TF2Items, they are quality 6 (Unique, which is the norm) which means they are completely new items. The fact that the articles for Festive weapons themselves redirect to the Stock weapon page worries me, and prevents me from adding the items to the Item checklist template. Essentially, someone needs to go through all the articles for Stock weapons with Festive versions and remove the update lines about "Added Festive Quality", get rid of the actual Festive article which I believe redirects to Item quality, and add proper pages for all the "Festive" weapons. 404: User Not Found ^(talk) 08:43, 16 December 2011 (PST)

Oh, and you might want to check this list of all items on TF2Items, because it seems Valve went and added a ton of new UGC tournament medals which I don't think we have an article for or images for. The new medal ID's are from 680 to 698, and there appears to be 3 or 4 different icons in use, for the medals. 404: User Not Found ^(talk) 08:46, 16 December 2011 (PST)

Essentially these items are treated no different than reskins by the game. Since we have articles for the likes of... well any other reskin, these weapons should probably have their own articles. It doesn't matter that they share the base models, because lots of weapons do this (like the Kritzkreig). The game treats them as their own weapons, so we should also. And it's not like the medals with many variants that become a hassle to maintain, these are unique weapons that don't have "Festive" as quality, and are no different to maintain than the other reskin articles. Festive is part of their name. To sum up, they have their own schema id, their own backpack icon, and have a unique appearance, they are no different than a reskin (actually, I'd call them reskins). Give them their own articles. Balladofwindfishes 17:57, 18 December 2011 (PST)

Stickybomb Launcher and Festive Stickybomb Launcher should all have their own page. Festive Strange Stickybomb Launcher should be added onto the Strange page. Festive variants are reskins. Unless you want to remove the Lugermorph, Maul, Objector etc etc pages while you're at it, I don't see a reason why these shouldn't have their own pages. SS2R 18:07, 18 December 2011 (PST)

fashnek: We've been discussing this since the update dropped. Festive is absolutely not a quality and I want someone to change those update notes that imply it is. I've been complaining about it. Regarding Strange, I feel that Strange-quality variants should not have their own page. However, Festive should not be treated the same way as Strange (a variation on the standard item). Originally I thought each Strange item should have a complete article like the other reskins, but I realize there are many cases already where a discrete item (by defindex) shares an article with other discrete items. I think all the Festive weapons should be considered as independent weapons, but they should be in one article. In other words, there should be:

• Stickybomb Launcher (with details about Strange Stickybomb Launcher)
• Strange (describing aspects of Strange quality and listing all weapons that may be Strange)
• Festive weapons (listing/showing all Strange weapons on one page -- complete with {{Backpack item}}, etc. Anything different from the normal weapon.)
• NO Strange Stickybomb Launcher (redirect OK)
• NO Festive Stickybomb Launcher (redirect OK)
• NO Strange Festive Stickybomb Launcher (no redirect)

Under no circumstances should a Strange variant of any weapon (Festive or non-Festive) have its own article. As for the new medals not having an article, we're working on that. – fashnek _(talk·c) 18:21, 18 December 2011 (PST)

I don't like the idea of putting them all into one article, because that seems like something we could effectively do with all reskins. Everything about trying to make these weapons not their own unique articles seems awkward to me. We have to put notes on the stock pages on distribution, and patch notes that don't apply, and have backpack images, and 3D images and everything awkwardly placed into the regular stock weapons, when these items aren't stock weapons and share only their stats and base models with the stock weapons. I think if the schema says they're unique and they have enough of a difference to warrant a new article (which they do, different distribution, different appearance, different update histories, different bugs, etc), we really should make new articles for them. It's only 10 weapons. Another thing is with this set up the items are awkwardly thrown about in the page for the update itself, when they would be better off and easier to see if they were listed in a neat table like the other unique weapons added during the update. Balladofwindfishes 18:27, 18 December 2011 (PST)

No, there would be a page separate from the stock weapons that elaborates on any details of the Festive weapons (all ten). It would be formatted such that each item got whatever specific bugs/trivia/updates it needed. I just don't know if these ten weapons justify ten new articles. I can name a lot of cases where we combine a bunch of items into a single article. This stretches that case a bit, but it's still worth considering. At the same time, I anticipate that ten 3D models would be expensive if combined on one page. I would be okay with either solution. I just don't want to see Strange weapons each having an article, and I don't want to see Festive weapons treated like they're just another quality or characteristic of the regular item. – fashnek _(talk·c) 18:35, 18 December 2011 (PST)

I agree, stranges don't need a page, they're just stranges. But even so, explaining the festive stranges would be a lot less awkward if that was done on the actual page for the specific festive item. And yea, I was thinking with the 3D models, that's 19 3D images on one page, which is a little extreme. Balladofwindfishes 18:38, 18 December 2011 (PST)

 Oppose individual articles for festive weapons. We would be making 10 new pages that would have so very little content apart from "This weapon has Christmas lights that glow and flash", there is little point to going to all of this effort only to make it harder to find information about them. As it stands Festive weapons is a short article really, the only thing I can see being added is 3D images. But to go out of our way just so 3D images can be on their own is not a good enough reason. I agree fully about festive weps being considered as their own independent weapons, but breaking it up into 10 new articles (keep in mind translations now) for basically nothing (or a sense of organisation) is not worth our time seb26 18:38, 18 December 2011 (PST)

What makes them different from a reskin? I think it's harder and more disorganized to have information about the festive items thrown into the stock weapon pages. To me that's akin to talking about the Rune Blade in detail on the Boston Basher article. I just don't like use making the call on what is considered a weapon worthy of an article or not. If the game says they're unique weapons, we treat them no different than any other weapon. Balladofwindfishes 18:43, 18 December 2011 (PST)

We have to make a decision ourselves, we should never follow Valve all the time and even when we should it should not be blindly, we should be using discretion and general agreement to decide what we do. They have proven that they are inconsistent with their things more often than they say they are. I don't mean this rudely because it doesn't really matter too much for normal players or even for them, but small details like capitalization of item names (I was talking about this yesterday) are very important for us because of the kind of site we are built upon. That is why we have to make decisions cos we know what is best structurally. I am saying 10 new articles for the sake of it, is a bad move. As little as I want to start up a debate about reskins again :p, and while I do see festive weapons in a similar way as reskins, I don't see the content about them being so significantly large that each individual weapon would require a separate article. There is simply not enough about each of them to just make it feasible. As it is 'Festive weapons' only lists one bug specific to a weapon, there is no update history and the rest of the content basically applies to every one of them.

The idea of having parts about festive on each weapon article is not too bad a compromise I think. For 3D images we can do the same like the Sandvich does for 'bitten', etc, treat them like alternate skins. If there is more to say about how to obtain a festive version then a section can be created that has that info. Let us not get ahead of ourselves, none of the festive weapons have so much info, let it be placed on the weapon page itself. If somehow the Festive-specific content on say, Bat, becomes so overpowering then we should address it then. It is not a good idea to make 10 new pages when a solution that uses what we already have is so much easier and less work. seb26 19:00, 18 December 2011 (PST)

How about a compromise? Make a page, something like Festive weapons. On that page, have a gallery of 3D images of all the Festive weapons. Make a note on the page how they are also available in Strange quality. Make all the "Festive <Weapon>" redirects link to the Festive weapons page. 404: User Not Found ^(talk) 21:01, 18 December 2011 (PST)

Oops, seems I didn't notice that link to Festive weapons that already exists. My bad! 404: User Not Found ^(talk) 21:02, 18 December 2011 (PST)

Ok, I hate to bring a discussion back to life like this, but I still feel that we should at least include 3D images of all the Festive weapons, in some sort of gallery system on the Festive weapons article. Every weapon that is technically a reskin (Wanga Prick, anyone?) has its own article with its own 3D image. We should at least find a way to implement 3D images for all the Festive Weapons, and as well, find a way to create some sort of 3D image gallery. Just my 2 cents. 404: User Not Found ^(talk) 16:40, 23 December 2011 (PST)

The preceding discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.