Team Fortress Wiki:Discussion

create a new section

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)