Difference between revisions of "Team Fortress Wiki:Discussion"

From Team Fortress Wiki
Jump to: navigation, search
(Team Fortress Wiki SOPA blackout)
(#savetf2: re)
 
Line 1: Line 1:
 
__NEWSECTIONLINK__
 
__NEWSECTIONLINK__
<div class="plainlinks" style="margin:1em -0.56em; background:#ededed; padding:0.65em 1em; font-size:175%; border:1px solid #aaa; border-left:0px; border-right:0px; text-align:center;">[{{fullurl:Team_Fortress_Wiki:Discussion|action=edit&section=new}} '''create a new section''']</div>
+
<div class="plainlinks" style="margin:1em -0.56em; background:#ededed; padding:0.65em 1em; font-size:175%; border:1px solid #aaa; border-left:0px; border-right:0px; text-align:center;">[{{fullurl:Team_Fortress_Wiki:Discussion|action=edit&section=new}} '''Create a new section''']</div>
 
<div style="margin-bottom:1em;">{{CentralDiscussion}}
 
<div style="margin-bottom:1em;">{{CentralDiscussion}}
 
</div>{{TFWiki navbar}}
 
</div>{{TFWiki navbar}}
{{Discussion archives/2011}}
 
{{Discussion archives/2010}}
 
<!-- Uncomment this when the tabbed boxes discussion has been archived: {{TOC float|right}} -->
 
 
[[Category:Team Fortress Wiki]]
 
[[Category:Team Fortress Wiki]]
[[Category:Team Fortress Wiki discussion| ]]
+
[[Category:Team Fortress Wiki discussion]]
 +
{| width="100%"
 +
|__TOC__
 +
|{{Discussion archives}}
 +
|}
 +
{{clr}}
  
== 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'.
+
== Dark Mode ==
  
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 [[Help:Style guide/Trivia#Bugs|style guide]] about bugs and clipping; so why aren't we filtering?
+
I don't think I even need to explain this. Wikipedia itself has it, so do other wikis. I do have a browser extension for dark mode, and optimally a dark theme for TFwiki should still keep muted earthy orangish tones and such, but at this point with my eye strain I'd take anything. It would encourage more dedicated editing streaks, perhaps, since many of us are night owls too.--[[File:Leaderboard class allclass.png|15px|link=]] [[User:Akolyth|<span style="font-size: 14px; font-family: Trebuchet MS">'''Akolyth'''</span>]] ([[User_talk:Akolyth|talk]]) 03:23, 16 October 2023 (UTC)
  
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.
+
:Easier said than done, it's being worked on but we can't promise anything.<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 11:13, 16 October 2023 (UTC)
  
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.
+
== Valve Store ==
  
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.
+
The official Store has been closed down for months now by Valve, and there's no reasonable smidgeon of proof to believe it's coming back any time soon. The Wiki, in many articles, links directly to the Store still, or mentions it, but even tooltips for certain hats will just say they're "not available". This is kind of awkward, and makes the average user waste a click (the horror, I know). And even I get a false hope sometimes that it changed, but it's Valve after all. Should something be done about this, and how? Can there be an automatic disclaimer the Store is gone? Should links be removed? Just let the dead ends sit forever?--[[File:Leaderboard class allclass.png|15px|link=]] [[User:Akolyth|<span style="font-size: 14px; font-family: Trebuchet MS">'''Akolyth'''</span>]] ([[User_talk:Akolyth|talk]]) 02:44, 18 October 2023 (UTC)
  
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.
+
:Try to find an archive.org version of it, otherwise just add a tooltip saying it's not available anymore due to store shutdown.<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 11:12, 18 October 2023 (UTC)
  
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.
+
== Painted variants with both Styles and separate Classes images, a design proposal ==
  
My stance is that there's a bug if:
+
Hi. So, I have several mockups of things to suggest which I'll be writing it up eventually. For now, I was making changes to the [[Robot Chicken Hat]] page, and was thinking about adding class variants to the paint gallery, as each class changes the hat's design a little (taller combs, different beak designs, etc.). However, if I were to make those paint variants per class, the current way we put styles and classes to the table looks... off, to say the least. At the moment, if I were to make it consistent with the rest of the Wiki, it would look like this: [https://i.imgur.com/gfdAUBL https://i.imgur.com/gfdAUBL]. But, instead, I thought about this mock-up: [https://i.imgur.com/QmQCLsK https://i.imgur.com/QmQCLsK]. Not only this looks more visually appealing, but it also takes a lot less space. The only problem that it may be confusing for cosmetics that separate styles by a group of classes ([[Cotton Head]], [[Brotherhood of Arms]], etc.). So... I thought about just making the class buttons that aren't active a little darker (same thing with the Style name): [https://i.imgur.com/Fiw1zRT https://i.imgur.com/Fiw1zRT]. Here's another example with the Cotton Head: [https://i.imgur.com/ZhkQwGG https://i.imgur.com/ZhkQwGG]. Mouse-hovering the class icons could also show their class names ("Pyro, Medic, Spy" and "Other classes" in the case of Cotton Head) Thoughts? [[File:User Gabrielwoj Signature Icon.png|15px|Headphones style when?|link=User:Gabrielwoj]] - [[File:User Gabrielwoj Signature 1.png|link=User:Gabrielwoj]] ▪ [[File:User Gabrielwoj Signature 2.png|link=Special:Contribs/Gabrielwoj]] - [[File:User Gabrielwoj Signature 3.png|link=User talk:Gabrielwoj]] 13:11, 18 October 2023 (UTC)
  
*It runs contrary to the info listed in the backpack description
+
:I like this proposal, although I think it's not necessary for every page. Only for the ones where the tabs become too much.<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 13:15, 18 October 2023 (UTC)
*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:
+
== Inconsistency regarding items with one team color, but shows team-colored parts of a player model ==
  
*Discuss the bug on the relevant talk page as exemplified in the above Crossbow example; and
+
Hello. So, when I started adding tabs to the paint variants, and just browsing the Wiki as a whole, I noticed that a couple pages are inconsistent in regards to the unpainted variants. In almost every case of cosmetics that use part of the player model, but only has 1 skin (not team-colored), the team-colors syntax isn't added to the tab, and we only have the UNPAINTED version on the paint variants table (example includes the [[Soldier's Stash]], [[Horrible Horns]] on Spy, and much more), but some other pages still shows the BLU variant of a player model despite the item only having one skin ([[Texas Half-Pants]], [[Millennial Mercenary]]'s Streaming 2Fort style, [[Exquisite Rack]], [[Battle Bob]]'s With Helmet style, [[Bacteria Blocker]]'s Headphones style, etc).
*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. [[User:I-ghost|i-ghost]] 07:03, 18 November 2011 (PST)
+
Some other pages also includes two identical RED and BLU images for the infobox, just because the item has two materials per team, but still uses the same exact texture and values (basically two identical .vmt files). I don't remember what pages has it now, but there are some pages that has that. I did that on [[Decorated Veteran]] since I've heard about doing that in the past before: "even if they look identical, put in two separate uploads". There's also no current way to just show one skin on the infobox (however that's something I'm looking to suggest soon enough on my mega infobox improvements topic).
  
:{{c|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. -[[User:Mr. Magoolachub|Mr. Magoolachub]] 16:51, 18 November 2011 (PST)
+
Because we use the infobox, as well the RED and BLU parts of the paint variants table to show the different Skin Colors of the ITEM, I would say to actually cleaning it up these inconsistencies. So, for instance, on Texas Half-Pants, there wouldn't RED and BLU images for each style, because they look identical on either team, and, there's only two skins on the model (one for the Tan style, the other for the Midnight style [older cosmetics used a different way in handling styles, as opposed to separate models, many old cosmetics would use different skins for styles, and the Item Schema would redirect what skins to use depending on the style chosen]). The colors change on the images right now, because it's the colors of Engi's default pants, but not the actual item model changing colors. Meaning that, the RED / BLU on the infobox would be removed, the BLU_... images would be deleted, and the RED_ images would be moved to the _UNPAINTED.png suffix instead.
::{{c|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. '''<span style="font-family:Georgia;font-size:83%;">—[[File:User Moussekateer signature sprite.png|31px|link=User:Moussekateer]][[User:Moussekateer|<span style="color:black">Moussekateer</span>]]·[[User talk:Moussekateer|<span style="color:black;font-size:82%;">talk</span>]]</span>''' 16:55, 18 November 2011 (PST)
 
:::{{c|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. [[User:Balladofwindfishes|Balladofwindfishes]] 17:03, 18 November 2011 (PST)
 
::::{{c|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. '''» [[User:Cooper Kid|<span style="color:red">Coo</span><span style ="color:gray">per</span><span style ="color:blue"> Kid</span>]]''' <small>([[User_talk:Cooper Kid|blether]]) • ([[Special:Contributions/Cooper Kid|contreebs]])</small> 17:35, 18 November 2011 (PST)
 
:::::{{c|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. [[User:Balladofwindfishes|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? [[User:I-ghost|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. [[User:Balladofwindfishes|Balladofwindfishes]] 14:13, 19 November 2011 (PST)
 
:::::{{c|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.  [[User:GianAwesome|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. [[User:I-ghost|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. [[User:Balladofwindfishes|Balladofwindfishes]] 14:13, 19 November 2011 (PST)
 
::::::::{{c|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. [[User:Dragonsbrethren|Dragonsbrethren]] 13:47, 23 November 2011 (PST)
 
:{{c|Support}} with a proposal - how about listing cosmetic and gameplay bugs in different subsections? [[User:SiPlus|SiPlus]] 03:17, 25 November 2011 (PST)
 
:{{c|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. --<span style="color:purple">'''''[[User:Focusknock|Focusknock]]'''''</span> 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. [[User:I-ghost|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. [[User:Balladofwindfishes|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. [[User:Dragonsbrethren|Dragonsbrethren]] 23:30, 27 November 2011 (PST)
 
::I am '''strongly''' in {{c|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". --[[User:Fashnek|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. [[User:SS2R|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. [[User:Balladofwindfishes|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. [[User:Chaosshaun|Chaosshaun]] 21:06, 6 December 2011 (PST)
 
  
=== New point to raise: holding multiple actions ===
+
Some may argue that, since the team-colored paint can image previews also change the pants colors, that these should stay in, but, I don't agree. These are to show the item's team-colors being affected (both the UNPAINTED versions and the team-colored paint cans), not the player model's team-colors, but let me know what do you think.
  
: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? [[User:I-ghost|i-ghost]] 07:52, 30 November 2011 (PST)
+
Items that have 0 changes on team-colors despite having them (same exact .vmt values), I'd also say to get rid of it, as they provide no real information for the reader other than perhaps modders, so they don't need to go all the way of decompiling models to add team-color support, for instance. Some require close inspection however. The [[Mann-Bird of Aberdeen]] looks like to be the case, but the green area is just slightly brighter on BLU. I'd still keep the same colors for Styles and classes (like [[Team Captain]] for Heavy), until a more fully-fledged infobox edit comes along the way that adds support to just 1 skin on the infobox (like this: [https://i.imgur.com/GQP1ou0 https://i.imgur.com/GQP1ou0]). I will still point out many of these on my eventual discussion of infobox changes in another topic. [[File:User Gabrielwoj Signature Icon.png|15px|Headphones style when?|link=User:Gabrielwoj]] - [[File:User Gabrielwoj Signature 1.png|link=User:Gabrielwoj]] ▪ [[File:User Gabrielwoj Signature 2.png|link=Special:Contribs/Gabrielwoj]] - [[File:User Gabrielwoj Signature 3.png|link=User talk:Gabrielwoj]] 13:43, 18 October 2023 (UTC)
::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). --[[User:Fashnek|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. [[User:Balladofwindfishes|Balladofwindfishes]] 13:53, 1 December 2011 (PST)
 
:::: I've started removing all of these. Calling them "forced bugs".  It's catchy.  [[User:SS2R|SS2R]] 05:46, 3 December 2011 (PST)
 
  
=== Does it Being Acknowledged as a Bug by the Creator Override Rules? ===
+
:I would support every page having both team colours.<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 13:57, 18 October 2023 (UTC)
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? [[User:Balladofwindfishes|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. [[User:SS2R|SS2R]] 04:01, 6 December 2011 (PST)
 
  
=== Left Handed "Bugs" ===
+
== Articles for individual environmental hazards ==
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. [[User:Balladofwindfishes|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?--<span style="color:purple">'''''[[User:Focusknock|Focusknock]]'''''</span> 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. [[User:Balladofwindfishes|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, {{code|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. [[User:I-ghost|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. -- [[Image:User Alex2539 Sig.png|47px|link=User:Alex2539|Alex2539]] - {{mod}} <sub>([[User_talk:Alex2539|talk]] | [[Special:Contributions/Alex2539|contribs]])</sub> -- 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.--<span style="color:purple">'''''[[User:Focusknock|Focusknock]]'''''</span> 10:45, 8 December 2011 (PST)
 
  
=== Removal Starting ===
+
Some of the older environmental hazards have their own articles. Specifically, they are: [[Ghost]], [[Pumpkin bomb]], [[Saw blade]], and [[Train]].
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. [[User:SS2R|SS2R]] 05:46, 3 December 2011 (PST)
 
:: Weapons are done, at least for their once over.  305 hat/misc pages to go. [[User:SS2R|SS2R]] 11:40, 7 December 2011 (PST)
 
:::I've edited the weapon guidelines to reflect the decision. --<span style="color:purple">'''''[[User:Focusknock|Focusknock]]'''''</span> 03:29, 8 December 2011 (PST)
 
:::: Thank you.  [[User:SS2R|SS2R]] 00:42, 9 December 2011 (PST)
 
Scout, Soldier, Pyro and Demoman hats/misc done.  Incoming break time. [[User:SS2R|SS2R]] 01:53, 10 December 2011 (PST)
 
  
=== Crit-boost glowing ===
+
These are some fairly simple hazards: ghost goes "boo", pumpkin bomb goes "boom", blade goes "bzzt", and train goes "''[Train horn noises]''". They all have fairly short articles, and are also covered in the [[Environmental death]] article.
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 {{code|$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'. [[User:I-ghost|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. [[User:Balladofwindfishes|Balladofwindfishes]] 06:20, 6 January 2012 (PST)
 
  
== Item owner lists addition (HOUWAR) ==
+
I propose we change these four into redirects to the Environmental death article, similar to [[Pitfall]].
  
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) [[User:Ihasnotomato|Ihasnotomato]]
+
As for their Update histories, I have three ideas:
 +
* Add the section to the Environmental death article and carry them over.
 +
* Create a separate page for that (similar to the [[Item timeline]] pages).
 +
* Ignore them (essentially already the case for all the hazards that don't have their own articles).
  
: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. [[user:seb26|<small style="background:#f9f9f9;border:1px solid #0070FF;padding:0em 0.5em;color:#000;-webkit-box-shadow:2px 1px 1px #8BBEFF;">'''seb26'''</small>]] 17:48, 26 November 2011 (PST)
+
I am ok with [[Skeletons]] and the Halloween bosses having their own articles, however, as they are more elaborate (which is noticeable by simply comparing article sizes).
  
:{{c|Disagree}} Wiki caps are given out by the wiki and Golden Wrench owners are [http://www.teamfortress.com/engineerupdate/wrenchlog/ 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. [[User:Scootz|Scootz]] 17:51, 26 November 2011 (PST)
+
Opinions? - [[User:BrazilianNut|BrazilianNut]] ([[User talk:BrazilianNut|talk]]) 16:36, 19 October 2023 (UTC)
  
: Ah, ok i didn't realize it was tradeable, thanks! [[User:Ihasnotomato|Ihasnotomato]]
+
:I think some of these pages can add value, such as the specifics in the hazard infobox. I'd push for more articles rather than less, similar to [[List of game modes]], where each hazard has its own page as well as a short description on the overall page. I would prefer this because it would cut down on the clutter on the Environmental death page, for example the pumpkin bomb section is 5 identical hazards that are just reskinned. It would be better to have this in a gallery on its own page, rather than several entries on that page.<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 16:40, 22 October 2023 (UTC)
  
::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: [[user:seb26|<small style="background:#f9f9f9;border:1px solid #0070FF;padding:0em 0.5em;color:#000;-webkit-box-shadow:2px 1px 1px #8BBEFF;">'''seb26'''</small>]] 22:33, 26 November 2011 (PST)
+
:: I believe it is better to keep the pages separate, as putting them all together in one could generate a lot of visual clutter, in addition to having a lot of information for the reader to consume at once. Furthermore, it would be complicated to gather all the update histories on the articles. Essentially, we would be taking separate articles and combining them into one big article, where each section (divided by {{code|<nowiki>== Section title ==</nowiki>}}) would be a "complete" article.<br/>[[User:Tiagoquix|<font color="#1e90ff">Tiagoquix</font>]] ([[User talk:Tiagoquix|<font color="#19c819">talk</font>]]) 18:45, 22 October 2023 (UTC)
  
: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. [[User:Wariopunk|Wariopunk]] 08:00, 5 December 2011 (PST)
+
== A request ==
  
{{discussion close|elsewhere=no}}
+
In Polish language we don't capitalise most words like in English language and the way quality items have their quality displayed looks like this: Rocket launcher (vintage). The problem is that in [[Template:Mann-Conomy Nav]] Vintage quality in Polish and Russian is not capitalised and looks weird in the template where everything is capitalised except this one word. Is it possible to add a new entry in the dictionary for this template only, where 'Vintage' is capitalised for these languages? In Polish it's even more confusing, because [[Classic]] and Vintage share the same translation, so it could be shown in the tempalte as 'Vintage quality' (Jakość klasyczna in Polish). [[File:User Denied signature.jpg|50px|link=User:Denied]] [[User:Denied|Denied]] [[User talk:Denied|(Talk)]] 10:28, 24 October 2023 (UTC)
== Proposing a Class Bio template addition ==
 
  
I'd like to propose an addition to the Class bio template; "Other Badges" or "Old Badges". Instead of having the template pull up the RED/BLU badges like it currently does, I think if added, users should be able to manually add in other badge images, like so:
+
:If it's the very first letter that needs to be capitalised, you can use <nowiki>{{ucfirst:<string>}}</nowiki> to turn the first letter into a capital. For example, <nowiki>{{ucfirst:hello world}}</nowiki> generates {{ucfirst:hello world}}.<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 11:15, 10 November 2023 (UTC)
  
<nowiki>| otherbadges = [[File:Sniper_badge_old_RED.png|50px]] [[File:Sniper_badge_old_BLU.png|50px]]</nowiki>
+
::Could you help me with this? I've changed it in [[Template:Mann-Conomy Nav]] but doesn't seem to capitalise the first letter. [[File:User Denied signature.jpg|50px|link=User:Denied]] [[User:Denied|Denied]] [[User talk:Denied|(Talk)]] 10:54, 17 December 2023 (UTC)
  
I'm proposing this, because as evidenced by [[User:404_User_Not_Found/Class_Emblems|this subpage I made in my userspace]], some classes have old badges that were used in early trailers/screenshots and such. Plus, now that we have [[User:404_User_Not_Found/Class_Emblems#Heavy|the original Skull 'n Crossbones Heavy emblem]] ''(contributed by [[User:Yeipigsl|Yeipigsl]])'', our collection of class badges, both currently-used and from old versions of the game is complete, and we should add the ability to display older badges in the Class Bio template. Comments? Opinions? Post 'em! '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 14:44, 27 November 2011 (PST)
+
:::Hmmm, yeah seems like the automatic translation templates automatically uncapitalise it. If you really wanted to implement this you'd have to use the {{tl|lang}} template instead.<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 13:49, 17 December 2023 (UTC)
:Oh, I forgot to mention: If this idea gets implemented, the respective images of previous badges will have to be removed from the Gallery sections on the class pages of classes with old badge designs ''(e.g. Scout, Soldier, Demoman, Heavy, Sniper)'' Also, I'm gonna toss in a {{c|Support}} for myself :P '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 14:46, 27 November 2011 (PST)
 
  
::I just did a preview test on the Class Bio template, and I think the following code addition, added directly below "Badges" should be sufficient for this idea to be implemented:
+
::::[https://wiki.teamfortress.com/w/index.php?title=Template:Mann-Conomy_Nav&diff=3408072&oldid=3388990 I already did it once and...] [[File:User Denied signature.jpg|50px|link=User:Denied]] [[User:Denied|Denied]] [[User talk:Denied|(Talk)]] 14:19, 18 December 2023 (UTC)
  
    <nowiki>{{#if: {{{otherbadges|}}} |</nowiki>
+
:::::Perhaps leave a hidden comment and use {{tl|lang incomplete}}?<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 14:27, 18 December 2023 (UTC)
    <nowiki>{{!}} '''{{lang</nowiki>
 
    <nowiki>  | en = Beta/Unused Badges:</nowiki>
 
    <nowiki> }}''' {{!!}} {{{otherbadges}}}</nowiki>
 
  
::Just pop that in below Badges and everything is good to go. Then on the appropriate pages, you add ''(this is just an example)'':
+
::::::I've coppied how it looked oryginally but now it shows as red link 'VintageVintage'. Could you look what's wrong with [https://wiki.teamfortress.com/w/index.php?title=Template:Mann-Conomy_Nav&diff=3584139&oldid=3583139 this edit]? Except equals sign. I've fixed it later. [[File:User Denied signature.jpg|50px|link=User:Denied]] [[User:Denied|Denied]] [[User talk:Denied|(Talk)]] 13:21, 19 December 2023 (UTC)
  
    <nowiki>| otherbadges = [[File:Sniper_badge_old_RED.png|50px]]&nbsp;&nbsp;[[File:Sniper_badge_old_BLU.png|50px]]</nowiki>
+
{{Outdent|6}}Looks like you forgot to add a vertical bar, which made the link <nowiki>[[VintageVintage]]</nowiki>.<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 13:31, 19 December 2023 (UTC)
  
::And boom, everything's good. I still need the community's opinion on this before I implement it, and it does need proper translations for other languages, but yeah, what do you guys think? '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 17:02, 27 November 2011 (PST)
+
== Mann Manor/Mountain Lab's history ==
:{{c|Neutral}} I'm on the fence on this. It sounds like a good idea, and wouldn't be difficult to add, especially considering that you have all the ''code'' laid out. I personally don't have a problem with it, but some users of the wiki might mistake the badges of the alpha and beta with the current badges. I'm fine with either doing this or having them just stay in the gallery section. Lets see how other users feels about this. [[File:User_M-NINJA_Signature.png|link=User:M-NINJA]] 13:28, 29 November 2011 (PST)
 
::Yeah, there could be some slight confusion with the badges, but I did lay out the names "Former Badges", and "Old Badges", though we could opt for something short, yet descriptive enough that people would realize that the other badges are alpha/beta badges. I did have another idea that I was originally going to post that involved adding a "Badges" section above the "Avatars" (Steam profile avatars) section on each of the class pages, and would be done with gallery tags, just like how I did it [[User:404 User Not Found/Class Emblems|on this subpage of mine]]. But I noticed the existing Badges part of the Class bio template, so I scrapped the original idea. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 14:01, 29 November 2011 (PST)
 
:::I have a better name idea. "Beta/Unused Badges". I've edited the above code to show what I mean. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 18:36, 29 November 2011 (PST)
 
{{discussion close|end|elsewhere=no}}
 
  
== Gathering more user input before making changes to the Wiki ==
+
I feel maps that we know more detailed information on the history of we should actually have written down so it isn't forgotten, such as for example, Mann Manor/Mountain Lab being an art contest was not the original plan in fact the maps used to have textures before but, that's just what I think. [[User:The American Boot|The American Boot]] ([[User talk:The American Boot|talk]]) 04:34, 10 November 2023 (UTC)
  
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 [[Team_Fortress_Wiki:Discussion#Why_aren't_bugs_subjected_to_the_same_scrutiny_as_trivia|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.
+
:If you think this fact is worth and most player don't know, you can try adding it to Trivia section. Here is a more detailed [[Help:Style_guide/Trivia|Trivia guild]].[[User:Profiteer|Profiteer(奸商)the tryhard]] ([[User talk:Profiteer|talk]]) 05:07, 10 November 2023 (UTC)
  
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.
+
:I'm not sure where this Trivia came from or if there is any source for. The [[Art Pass Contest]] page states that Robin Walker said they had a map that hadn't been worked on for a while and they didn't have time to do an art pass on it (which means the map just had dev textures).<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 21:34, 10 November 2023 (UTC)
  
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. -[[User:Mr. Magoolachub|Mr. Magoolachub]] 21:53, 27 November 2011 (PST)
+
== Weapon articles mentioning taunts that aren't kill taunts ==
: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. [[File:Painted_Vintage_Merryweather_803020.png|24px|link=User talk:Fyahweather]][[User:Flamborsia|<span style="text-shadow:orange 0px 0px 3px;"><font color="#FF6600"><tt><big><u>'''Fyahweather'''</u></big></tt></font></span>]] 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. --[[User:Fashnek|Fashnek]] 13:52, 1 December 2011 (PST)
 
  
{{discussion close|elsewhere=no}}
+
I've noticed a few articles for weapons mentioning that those weapons have a unique taunt that is not a kill taunt, or a variation of the default weapon for that slot (which is still not a kill taunt). These are the [[Lollichop]], which mentions it has a unique taunt based on a scene from Meet the Pyro, and the [[Third Degree]] and [[Neon Annihilator]], which mention the added guitar sounds, respectively. In comparison, the [[Cow Mangler 5000]], [[Scottish Resistance]], and [[Ullapool Caber]], which also have unique taunts, do not mention them since they're not kill taunts, and the [[Vita-Saw]], which has has a variation of the default taunt, does not mention said variation.
== Badges or Emblems ==
 
  
While I'm still on the topic of class badges/emblems, I've noticed that the Wiki uses both "Badges" and "Emblems" when referring to the class icons that most classes have on their shoulders. In most pages and in update histories, they're referred to as Emblems. In the Class bio template, they're referred to as Badges. This isn't a necessarily urgent matter, but it's something I'd like to get cleared up so I can get the go-ahead to go around and change any instances of <old name> to <new name>. The only thing I'd need administrative help with is the filenames of some of the images in [[:Category:Class badges]] as a few images are named with "emblem", and the majority are named with "badge", so some re-uploads or image moves would be required to fix the naming. So what should we go with? Badges or Emblems? Personally, when I see the images, I think Emblem. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 18:43, 29 November 2011 (PST)
+
I think we should remove these notes from the Lollichop, Third Degree, and Neon Annihilator, as they are already all noted in the Pyro taunts page.
:I'd agree with emblem. -[[User:Mr. Magoolachub|Mr. Magoolachub]] 18:10, 30 November 2011 (PST)
 
:I'd go with emblem as well. --[[User:Scootz|Scootz]] 17:10, 2 December 2011 (PST)
 
:Emblem is better - I think badge implies the misc item badges, like dueling badges. '''» [[User:Cooper Kid|<span style="color:red">Coo</span><span style ="color:gray">per</span><span style ="color:blue"> Kid</span>]]''' <small>([[User_talk:Cooper Kid|blether]]) • ([[Special:Contributions/Cooper Kid|contreebs]])</small> 18:50, 2 December 2011 (PST)
 
::If the mass vote turns out to be for Emblem, I have no problem whatsoever going around the English articles and changing any references to "Class Badges" to "Class Emblems". I've got plenty of free time. As I've stated before, the class Emblem images are another thing. I'll have to save them all, then re-upload them under a proper naming structure, including the Beta Emblems. Speaking of that, I think "Beta Emblems" would be a better name for that proposed Class Bio template addition I discussed above. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 19:41, 2 December 2011 (PST)
 
  
:I chose emblem. Even though symbol is not an option tokens does look like badges and some of the misc just as Cooper Kid stated. This might need someone from valve to settle this argument.--[[User:Bigbangbilly|Bigbangbilly]] 19:24, 4 December 2011 (PST)
+
Speaking of the [[Pyro taunts]] page, I think we can move the "as in Meet the Pyro" comment from the Lollichop's description to a new Trivia section and add that Execution is also based in a Meet the Pyro scene (which is not mentioned). - [[User:BrazilianNut|BrazilianNut]] ([[User talk:BrazilianNut|talk]]) 16:45, 7 December 2023 (UTC)
  
:I always thought it was Emblem? [[User:Wariopunk|Wariopunk]] 07:56, 5 December 2011 (PST)
+
:I think variants on an existing taunt should be mentioned, such as different sounds (such as the Third Degree/Neon Annihilator adding guitar sounds and the Vita-Saw having different melodies being played), but the non-kill taunt shouldn't be mentioned (no note about the Lollichop taunt. Although seeing as it's unique to that weapon, I think the Trivia can stay).<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 17:14, 7 December 2023 (UTC)
  
:Well, mass votes go to Emblem. All I require now is the OK/go ahead from an admin to begin converting references to "Badge" over to "Emblem". Dictionary strings for "Badge" will have to be retranslated as "Emblem". As for images, I can reupload under new names and redirect old filenames to the new ones. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 19:16, 5 December 2011 (PST)
+
== Main menu Smissmas 2023 header localization ==
::[http://www.youtube.com/watch?v=qybUFnY7Y8w OK/go] — [[User:WindPower|<span style="font-weight:bold;">Wind</span>]] 00:58, 9 December 2011 (PST)
 
:::I just woke up, it's like 4am here, so give me a little while to get a coffee and start my morning right, then I'll start off with the re-uploading of images, and turning the old versions into redirects. From there I can do a full wiki search for anything to do with Badges and change it over to Emblems. I've been planning this out for a few days now. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 01:00, 9 December 2011 (PST)
 
::::[[:Category:Class badges]] has been cleared out and deleted. Do what you need to do. [[User:I-ghost|i-ghost]] 02:23, 9 December 2011 (PST)
 
:::::It's 5:36am right now, and I do have to work tonight from 5pm - 12am, but I will have quite a lot of spare time throughout the day (yes, even at work), so I will be working off of [[Special:WantedFiles|Wanted Files]], to get rid of all the red links. If an admin who has a Bot could create a filter, once I finish fixing up anything related to the Beta emblems (in trivia, and adding things to Class Bio), a filter will need to be made to look for <nowiki>"<class>_badge_<RED/BLU>.png"</nowiki>, and change it to <nowiki>"<class>_emblem_<RED/BLU>.png"</nowiki>. That would simplify this process tenfold. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 02:36, 9 December 2011 (PST)
 
{{discussion close|end|elsewhere=no}}
 
  
== New buy button - which positioning do you prefer. ==
+
'Smissmas 2023' is localized but 'December 7 - January 7' is not. Is it possible to localize it too? [[File:User Denied signature.jpg|50px|link=User:Denied]] [[User:Denied|Denied]] [[User talk:Denied|(Talk)]] 10:29, 17 December 2023 (UTC)
  
I've been working on integrating the buy button into the item infobox...  [[Whoopee_Cap/RJackson_new_buy_button|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. -[[User:RJackson|<span class="modbg" style="margin-right:1px;text-shadow: #538237 1px 1px 0px;">RJ</span>]] 12:50, 2 December 2011 (PST)
+
:See [[Template:Dictionary/common_strings#.5BMain_Page.5D_Smissmas_2023|Dictionary common strings]].<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 13:37, 17 December 2023 (UTC)
:1st positioning is the best. {{n}} [[User:Cructo|{{tf2b|text=Cructo|size=15px}}]] <span style="font-size:10px"><nowiki>[</nowiki>[[User_talk:Cructo|T]]<nowiki>][</nowiki>[[Special:Contributions/Cructo|C]]<nowiki>]</nowiki></span> 12:51, 2 December 2011 (PST)
 
: That first one is definitely superior in both placement and detail. [[User:Mainman|<span style="text-shadow:#0099FF 0px 0px 3px;color:steelblue;font-size:95%;font-weight:bold" title="Mainman"><u>Mainman</u></span>]] <sup>([[User talk:Mainman|Talk]] ▪ [[Special:Contributions/Mainman|Contribs.]])</sup> 12:54, 2 December 2011 (PST)
 
: Numero uno. [[User:MousseBOT|MousseBOT]] 13:00, 2 December 2011 (PST)
 
:{{c|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. :) -[[User:RJackson|<span class="modbg" style="margin-right:1px;text-shadow: #538237 1px 1px 0px;">RJ</span>]] 14:47, 2 December 2011 (PST)
 
:: I personally enjoyed style 3. It's not too distracting, but still visible. [[User:Mpnov|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]]. --[[User:Fashnek|Fashnek]] 17:08, 2 December 2011 (PST)
 
:: Style 4. [[User:SS2R|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. -[[User:Mr. Magoolachub|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. [[User:Dragonsbrethren|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. [[File:Building_icon_Metal.png|16px|link=User_talk:Mar]] '''[[User:Mar|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. [[User:Atmo|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? '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 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. —[[File:User Rocket Ship BBQ Awesomepyro.png|24px]][[User:Rocket Ship BBQ|Rocket Ship BBQ]]([[File:Speech voice.png|20px|link=User talk:Rocket Ship BBQ]]•[[File:Intel neutral pickedup.png|20px|link=Special:Contributions/Rocket Ship BBQ]]) 14:25, 29 December 2011 (PST)
 
  
== Trusted editors ==
+
:: Thanks. [[File:User Denied signature.jpg|50px|link=User:Denied]] [[User:Denied|Denied]] [[User talk:Denied|(Talk)]] 14:19, 18 December 2023 (UTC)
  
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. --[[File:Login_Soldier.png|link=User:Daniil]][[User:Daniil|Daniil]] 06:28, 3 December 2011 (PST)
+
== Link of the wiki team fortress energie drink don't work ==
: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. [[User:TheDoctor|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 -- [[User:Keisari|Keisari]] [[File:BottleScreen.png|24px|link=User_talk:Keisari]] 06:56, 3 December 2011 (PST)
 
::: Approve. [[User:Nero123|<span style="color:#FF9B00;font-size:13px;font-family:'TF2 Build';text-shadow:#e3e3e3 1px 1px 0px;">Nero123</span>]] <span style="font-size:10px">([[User talk:Nero123|talk]] | [[Special:Contributions/Nero123|contribution]])</span> 06:57, 3 December 2011 (PST)
 
::::Gud idea [[User:Restline|<span style="color:black">'''Hikkie'''</span>]][[File:User_Restline_Signature.png|31px|link=User:Restline]] 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. [[File:Painted_Vintage_Merryweather_803020.png|24px|link=User talk:Fyahweather]][[User:Flamborsia|<span style="text-shadow:orange 0px 0px 3px;"><font color="#FF6600"><tt><big><u>'''Fyahweather'''</u></big></tt></font></span>]] 09:00, 3 December 2011 (PST)
 
::::::You forgot about the Wiki Cap :) --[[File:Login_Soldier.png|link=User:Daniil]][[User:Daniil|Daniil]] 09:31, 3 December 2011 (PST)
 
:::::{{c|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. [[User:GianAwesome|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! [[User:Balladofwindfishes|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) [[user:seb26|<small style="background:#f9f9f9;border:1px solid #0070FF;padding:0em 0.5em;color:#000;-webkit-box-shadow:2px 1px 1px #8BBEFF;">'''seb26'''</small>]] 11:20, 3 December 2011 (PST)
 
:::::{{c|Support}} Put a disclaimer somewhere that states that it does not boost wikicap eligibility. --[[User:Bigbangbilly|Bigbangbilly]] 19:26, 4 December 2011 (PST)
 
::::::{{c|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. [[File:User_M-NINJA_Signature.png|link=User:M-NINJA]] 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. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 20:12, 5 December 2011 (PST)
+
[[https://wiki.teamfortress.com/wiki/Team_Fortress_Wiki:Wiki_Birthday#Official.E2.84.A2_Team_Fortress_Energy_Drink]] you see this page on the wiki contain a team fortress wiki energie drink with a link for have it but it don't work and is not secure, can someone help me ? <small>''The preceding unsigned comment was added by'' '''[[User:Nonolemage|Nonolemage]]''' ([[User talk:Nonolemage|talk]]) ([[Special:Contributions/Nonolemage|contribs]]) 2023-12-21, 13:46 UTC</small>
::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. [[User:GianAwesome|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. [[user:seb26|<small style="background:#f9f9f9;border:1px solid #0070FF;padding:0em 0.5em;color:#000;-webkit-box-shadow:2px 1px 1px #8BBEFF;">'''seb26'''</small>]] 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. [[User:Tturbo|<span style="font-family:TF2 Build; color:#476291 ">Tturbo</span>]] [[File:Killicon_ambassadorhs_unused.png|50px|link=User:Tturbo]] <sub><sub>([[File:Speech voice.png|20px|link=User talk:Tturbo]] / [[File:Intel neutral pickedup.png|20px|link=Special:Contributions/Tturbo]])</sub></sub> 11:52, 6 December 2011 (PST)
 
:::::Sorry to get off-topic, but Pilk is a she? O_o '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 19:35, 6 December 2011 (PST)
 
::::::No it's just me who's a dumbass and typoes a lot (especially in english)... ¬¬ [[User:Tturbo|<span style="font-family:TF2 Build; color:#476291 ">Tturbo</span>]] [[File:Killicon_ambassadorhs_unused.png|50px|link=User:Tturbo]] <sub><sub>([[File:Speech voice.png|20px|link=User talk:Tturbo]] / [[File:Intel neutral pickedup.png|20px|link=Special:Contributions/Tturbo]])</sub></sub> 20:38, 6 December 2011 (PST)
 
:So...what's the decision? [[User:GianAwesome|GianAwesome]] 17:52, 10 December 2011 (PST)
 
:{{c|Support}} I had to type in capchas when I edited my own userpage. That's just silly. --[[User:Stevoisiak|Stevoisiak]] 08:22, 17 December 2011 (PST)
 
  
== Disambigs based on item type ==
+
:Please sign your messages using <nowiki>~~~~</nowiki>.
 +
:The website appears to be down and no archive of it exists, so unless someone here happens to have a copy we can't do much.<br>[[File:BLU Wiki Cap.png|20px|link=List of Wiki Cap owners]] | [[Help:Group rights|<span style="color:green;font-family:TF2 Build;">s</span>]] | [[User:GrampaSwood|<font color="DB9C1F">GrampaSwood</font>]] [[File:PraisetheSun.png|20px|alt=Praise the Sun!]] ([[User talk:GrampaSwood|<font color="DB9C1F">talk</font>]]) ([[Special:Contributions/GrampaSwood|<font color="DB9C1F">contribs</font>]]) 13:46, 21 December 2023 (UTC)
  
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. {{n}} [[User:EpicEric|<span style="color:#5885A2;font-size:15px;font-family:'Trebuchet MS';text-shadow:#e3e3e3 1px 1px 0px;"><b>Epic Eric</b></span>]] <small> ([[User talk:EpicEric|T]] <nowiki>|</nowiki> [[Special:Contributions/EpicEric|C]])</small> 07:10, 13 December 2011 (PST)
+
== Multiple Suggestions related to Infobox, etc ==
:First, let me start. I {{c|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#See also|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 (disambiguation)|Rocket Launcher]]", or the [[Weapons#Sniper|Sniper's melees]], which are listed as "[[Dagger|Daggers]]" (you can see more about the first example in [[User talk:EpicEric#Stock weapon disambig pages|my talk page]]). Finally, for all the unpracticity and redundancy it brings, I'm not in favour of adding these disambiguations. {{n}} [[User:EpicEric|<span style="color:#5885A2;font-size:15px;font-family:'Trebuchet MS';text-shadow:#e3e3e3 1px 1px 0px;"><b>Epic Eric</b></span>]] <small> ([[User talk:EpicEric|T]] <nowiki>|</nowiki> [[Special:Contributions/EpicEric|C]])</small> 07:10, 13 December 2011 (PST)
 
:{{c|Agree|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 (disambiguation)|pistol]] and [[Knife (disambiguation)|knife]] are very important, as there are options there used by several classes, in different weapon slots. '''» [[User:Cooper Kid|<span style="color:red">Coo</span><span style ="color:gray">per</span><span style ="color:blue"> Kid</span>]]''' <small>([[User_talk:Cooper Kid|blether]]) • ([[Special:Contributions/Cooper Kid|contreebs]])</small> 08:22, 13 December 2011 (PST)
 
:{{c|-|Naw}} TF2 has too many silly item types (i.e. [[Holy Mackerel|fish]], [[Righteous Bison|indivisible particle smasher]], [[Ullapool Caber|stick bomb]]), which can cause much confusion ([[Mad Milk|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. —[[File:User Rocket Ship BBQ Awesomepyro.png|24px]][[User:Rocket Ship BBQ|Rocket Ship BBQ]]([[File:Speech voice.png|20px|link=User talk:Rocket Ship BBQ]]•[[File:Intel neutral pickedup.png|20px|link=Special:Contributions/Rocket Ship BBQ]]) 14:41, 29 December 2011 (PST)
 
  
== Festive Weapons ==
+
Hi. I have been wanting to write this in the past, but, well, finally here it is. I have a couple suggestions about things related to infobox, and other things to make the design of the Wiki flow better on certain articles. I will be posting here as it covers a multitude of topics, as opposed to posting each one of them on their respective templates. When adding "Support" and "Not Support" on your responses, please make sure to add the number (and letter) behind to specify what you are supporting (or not supporting) as a change (like: "1-c"). With that said, let's get going:
  
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. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 08:43, 16 December 2011 (PST)
+
<hr>
:Oh, and you might want to check [http://www.tf2items.com/allitems.php?d=1 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. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 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. [[User:Balladofwindfishes|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. [[User:SS2R|SS2R]] 18:07, 18 December 2011 (PST)
 
<div style="margin-left: 40px; border:1px #999 dashed">'''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 <nowiki>{{Backpack item}}</nowiki>, 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.
 
&ndash; [[User:Fashnek|<span style="text-size:1.5em;font-weight:bold;color:#363;text-shadow:0 0 0.8em #6c6;">fashnek</span>]] <sub>([[User talk:Fashnek|talk]]&#183;[[Special:Contributions/Fashnek|c]])</sub> 18:21, 18 December 2011 (PST)
 
</div>
 
:::: 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. [[User:Balladofwindfishes|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. &ndash; [[User:Fashnek|<span style="text-size:1.5em;font-weight:bold;color:#363;text-shadow:0 0 0.8em #6c6;">fashnek</span>]] <sub>([[User talk:Fashnek|talk]]&#183;[[Special:Contributions/Fashnek|c]])</sub> 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. [[User:Balladofwindfishes|Balladofwindfishes]] 18:38, 18 December 2011 (PST)
 
::::{{c|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 [[user:seb26|<small style="background:#f9f9f9;border:1px solid #0070FF;padding:0em 0.5em;color:#000;-webkit-box-shadow:2px 1px 1px #8BBEFF;">'''seb26'''</small>]] 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. [[User:Balladofwindfishes|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. [[user:seb26|<small style="background:#f9f9f9;border:1px solid #0070FF;padding:0em 0.5em;color:#000;-webkit-box-shadow:2px 1px 1px #8BBEFF;">'''seb26'''</small>]] 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. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 21:01, 18 December 2011 (PST)
 
::Oops, seems I didn't notice that link to [[Festive weapons]] that already exists. My bad! '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 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|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. '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 16:40, 23 December 2011 (PST)
 
  
== Projectile Movement Speed integration ? ==
+
1) Implement a way on the {{code|Item infobox}} template where if a style or class has only one team-color compared to other styles with team-colors, include an icon in the middle of both teams. For instance:
  
The Projectile movement speed should maybe integrated as a hint into the Damage and function times. The reason i want to integrated it is, that the Manmelter shoots a faster projectile then the flaregun. And if both are the same, then the damage output is higher(slightly) because of the faster movement speed of the projectile. The reloading is not affected by this, but i think it should be mentioned. Also i hope someone can find out how fast the [[Projectile|Projectiles]] movement speed  is for the various items. What do you think about my idea??? [[User:TheDoctor|TheDoctor]] 13:45, 22 December 2011 (PST)
+
a) The Heavy variant of the [[Team Captain]] only has one color, but the page right now includes a duplicate of the RED variant as a workaround. What I suggest is doing this: [https://i.imgur.com/YgQHk5z https://i.imgur.com/YgQHk5z]. Make the Heavy variant only one file, and center it. It should be pretty clear that because of the image is in the middle, is that it looks like that on both teams.
: That shouldn't be too hard to implement, if one were to look into the schema. It's probably listed in there. [[User:Balladofwindfishes|Balladofwindfishes]] 11:00, 3 January 2012 (PST)
 
:: I don't know where it is listed. Could you tell me where to look for it or just add it into the projectile article? Always wondered about these sci-fi weapons how fast they move. [[User:TheDoctor|TheDoctor]] 12:19, 3 January 2012 (PST)
 
  
== Template:Strange quality table ==
+
b) For items with styles that only has one color (not team-colored), do the same thing as well. In the example of [[Close Quarters Cover]], include the "Alert" style on the infobox in the middle of the "RED" and "BLU" sections of the infobox, something like this: [https://i.imgur.com/lARBQME https://i.imgur.com/lARBQME].
  
Hi all, I edited [[Template:Strange quality table|this template]], and some of the translation strings are now outdated. Seb mentioned I should pop a comment in here. [[User:Rebmcr|Rebmcr]] 17:22, 23 December 2011 (PST)
+
c) For items that are not team-colored, but have class-specific variants, include a new part colored in grey called "Both Teams", and include each image on the middle as well. For example, the [[Dead Little Buddy]] have 3 model variants, one for Pyro, one for Demoman, and the other for the remaining classes. The idea is this: [https://i.imgur.com/xPD9PMO https://i.imgur.com/xPD9PMO].
:Everything looks fine to me when I view the template. I don't see any redlinks =\ '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 18:48, 23 December 2011 (PST)
 
::The notes at the bottom have changed, and need to be re-translated. [[User:Rebmcr|<span style="display:inline-block;font-family:&#34;TF2 Build&#34;,sans-serif;font-size:150%;border:none;"><span style="background-color:#FF2A55;color:#002A55;padding:2px 0px 1px 10px;border-radius:10px 0px 0px 10px;text-shadow:0px 0px 2px white;">reb</span><span style="background-color:#002A55;color:#FF2A55;padding:2px 10px 1px 1px;border-radius:0px 10px 10px 0px;text-shadow:0px 0px 1px white;">mcr</span></span>]] 13:52, 26 December 2011 (PST)
 
:::I meant to say that you should post about the new design of the template here so that people can post thoughts / votes before it is published [[user:seb26|<small style="background:#f9f9f9;border:1px solid #0070FF;padding:0em 0.5em;color:#000;-webkit-box-shadow:2px 1px 1px #8BBEFF;">'''seb26'''</small>]] 13:54, 26 December 2011 (PST)
 
::::I see. Misunderstood that one. Well, [http://wiki.teamfortress.com/w/index.php?title=Template:Strange_quality_table&oldid=872763|here] is the old version, and the [[Template:Strange quality table|new one]]. [[User:Rebmcr|<span style="display:inline-block;font-family:&#34;TF2 Build&#34;,sans-serif;font-size:150%;border:none;"><span style="background-color:#FF2A55;color:#002A55;padding:2px 0px 1px 10px;border-radius:10px 0px 0px 10px;text-shadow:0px 0px 2px white;">reb</span><span style="background-color:#002A55;color:#FF2A55;padding:2px 10px 1px 1px;border-radius:0px 10px 10px 0px;text-shadow:0px 0px 1px white;">mcr</span></span>]] 13:59, 26 December 2011 (PST)
 
:::::I was quite attached to the old version, but it's glad to see change happening. Next time you go to completely revamp a table or something, follow Seb's advice and '''do not''' edit the actual template. Instead, create a copy of it in your namespace, make the appropriate edits, then post here and get peoples opinions on it. If consensus is reached and everyone likes it, then you can change the actual template. If not, no changes are to be made. Understando? '''Just a friendly tip from''' '''[[User:404 User Not Found|404: User Not Found]]''' <sup>[[User_talk:404_User_Not_Found|(talk)]]</sup> 14:06, 26 December 2011 (PST)
 
  
== Skins Vs Saxton Hale in error ==
+
d) Although I do not have a mock-up right now, I thought of also doing the same as above for items that has only one color. So, for instance, the [[Jumper's Jeepcap]] would have a "Both Teams" section, and it would include the "UNPAINTED" variant on the center. Items with styles with just one color, like [[Mustachioed Mann]], would be similar to Dead Little Buddy, including each style on the infobox, alongside their names. Items like [[Carl]] that has no styles, but is neutral-colored, would also have the "Both Teams" part.
  
 +
<hr>
  
Hello, good afternoon!
+
2) Get rid of the current "2D" images of Weapons, and use "Item icons" instead. The 2D weapon images are not consistent throughout the Wiki. They have different lighting, different angles, and so on. What I suggest is doing something similar to another Wiki I also contributed (one related to a TF2 sourcemod): [https://i.imgur.com/vbvPbGP https://i.imgur.com/vbvPbGP]. This looks extremely clean, and every page would have in this angle. The 2D image only includes the RED variant, just like we use RED classes on our cosmetic previews.
Pleasure, my name is Marianne (call me Mary)
 
TF2 game since May of last year, I'm addicted to Arena, but recently (yesterday) has a problem (not sure which) and the Skins VS does not appear ...
 
I do not know if anyone has had any such problem (If they'd love it if I had indicated to the right place and shut the increasing discussion), but it turns out that instead of Saxton, vagina, etc. Brutal Sniper ... the word ERROR appears ... were it not so bother (or bizarre) I was leaving anyway, but that happens even when I hit the word does not damage the ... only in some points, so It's impossible to play ... I even thought about deleting it and downloading again, but before doing so wanted to see here if you do not have any other solution
 
  
Thanks for the help now.
+
<hr>
Mary <small>— ''The preceding unsigned comment was added by'' '''[[User:TheEagle|TheEagle]]''' ([[User talk:TheEagle|talk]]) • ([[Special:Contributions/TheEagle|contribs]]) 17:22, 3 January 2012</small>
 
:Best to go to the [http://forums.steampowered.com/forums/forumdisplay.php?f=80 forums] for troubleshooting problems, Wiki talk pages are for discussing the articles. '''» [[User:Cooper Kid|<span style="color:red">Coo</span><span style ="color:gray">per</span><span style ="color:blue"> Kid</span>]]''' <small>([[User_talk:Cooper Kid|blether]]) • ([[Special:Contributions/Cooper Kid|contreebs]])</small> 10:05, 3 January 2012 (PST)
 
  
== The Great Steam Gift Pile Article? ==
+
3) Add the "RED" and "BLU" sections on the infobox for Weapon pages, even if the 3D image allows you to switch between teams. Right now, the RED variant is used as the 2D image (for team-colored weapons), while the 2D BLU variant awkwardly sits on the Gallery section. My suggestion would be this: [https://i.imgur.com/dM9z7Oo https://i.imgur.com/dM9z7Oo]
  
It's a bit late now, but should this event have an article like the summer sale and trasure hunt? It had 3 TF2 items related to the event, and it might be nice to have for archival purposes and for a link on the promotion infobox explaining what it is. I'm not sure users in a year or two would know much about it, so I think we'd be better off writing it now while we still know a lot about it and still have resources out there that easily list the achievements. [[User:Balladofwindfishes|Balladofwindfishes]] 08:23, 4 January 2012 (PST)
+
<hr>
: Agree on this one. -- [[User:Keisari|Keisari]] [[File:BottleScreen.png|24px|link=User_talk:Keisari]] 08:26, 4 January 2012 (PST)
 
: {{c|support|Da}}. '''» [[User:Cooper Kid|<span style="color:red">Coo</span><span style ="color:gray">per</span><span style ="color:blue"> Kid</span>]]''' <small>([[User_talk:Cooper Kid|blether]]) • ([[Special:Contributions/Cooper Kid|contreebs]])</small> 10:03, 4 January 2012 (PST)
 
: {{c|agree}} but what should the article be called? I'm not sure if the event was called "Great Steam Gift Pile", "Steam Great Gift Pile", "Steam Christmas Sale 2011", or whatever. ._. —[[File:User Rocket Ship BBQ Awesomepyro.png|24px]][[User:Rocket Ship BBQ|Rocket Ship BBQ]]([[File:Speech voice.png|20px|link=User talk:Rocket Ship BBQ]]•[[File:Intel neutral pickedup.png|20px|link=Special:Contributions/Rocket Ship BBQ]]) 15:57, 4 January 2012 (PST)
 
::It was The Great Steam Gift Pile. '''» [[User:Cooper Kid|<span style="color:red">Coo</span><span style ="color:gray">per</span><span style ="color:blue"> Kid</span>]]''' <small>([[User_talk:Cooper Kid|blether]]) • ([[Special:Contributions/Cooper Kid|contreebs]])</small> 16:09, 4 January 2012 (PST)
 
:::I thought that was just the name of the gift pile, not the name of the event... —[[File:User Rocket Ship BBQ Awesomepyro.png|24px]][[User:Rocket Ship BBQ|Rocket Ship BBQ]]([[File:Speech voice.png|20px|link=User talk:Rocket Ship BBQ]]•[[File:Intel neutral pickedup.png|20px|link=Special:Contributions/Rocket Ship BBQ]]) 16:12, 4 January 2012 (PST)
 
: {{c|agree}} I agree that it should get its own page, but the question remains what it should be called precisely. The Great Steam Gift Pile? I say we stick with the original name of the event. [[User:Warlike|Warlike]] 16:15, 4 January 2012 (PST)
 
::Good point Rocket Ship BBQ. The official group just called the event the "Holiday Sale", can anyone remember how it was labeled on the Store page? '''» [[User:Cooper Kid|<span style="color:red">Coo</span><span style ="color:gray">per</span><span style ="color:blue"> Kid</span>]]''' <small>([[User_talk:Cooper Kid|blether]]) • ([[Special:Contributions/Cooper Kid|contreebs]])</small> 17:39, 4 January 2012 (PST)
 
  
== TF2 Item Name Comparison Tool ==
+
4) For cosmetic pages that has styles alongside class changes on the Painted Variants table, include additional buttons that include class icons. The idea is to remove clutter on pages with a lot of tabs to choose from (see [https://wiki.teamfortress.com/w/index.php?title=Boarder%27s_Beanie&oldid=3594086 this page]). In technical terms, the style buttons would be responsible to change the "style" part of the filename, while the class buttons would change the class part of the filename. If the first class is chosen, then the code needs to get rid of the class part of the filename, as the first class is always the default: [https://i.imgur.com/QmQCLsK https://i.imgur.com/QmQCLsK]
  
One of the Dutch moderators over at the Steam Translation Server made [http://flitskikker.com/steam/tf2items/ a little tool] that can be used to easily see all the translations for every item currently in-game, both name and description.<br>
+
a) Additionally, text could be placed on each row, one for "Style:", and the other for "Class:" for the second row, just so it's a little more intuitive and understandable for everyone.
It is still a work in progress, but it is already in a functioning state and he thought that some of fella's here on the Wiki might like it. [http://flitskikker.com/steam/tf2items/?item=304 Here is an example page of how it looks like]. Have fun! -- <span style="font-family:TF2 Build;font-size:90%;">[[File:Killicon train.png|40px|link=User:Hefaistus]] [[User:Hefaistus|<font color="#FF9933">Hefaistus</font>]]</span> - [[User talk:Hefaistus|<span style="color:black;font-size:82%;">talk</span>]] 05:46, 15 January 2012 (PST)
 
  
== Entity names ==
+
<hr>
  
It appears that the pages for items don't include entity names, example '''tf_weapon_robot_arm'''.
+
5) Include "infobox images" for separate styles, and add buttons that let you change it. The idea is to include identical images (with identical classes and facial flexing), with the only thing changing the model. For example, [[Main Cast]] would look like this: [https://imgur.com/a/OmTIYVs https://imgur.com/a/OmTIYVs].
Whilst it may not be useful for >95% of visitors, I feel it is still worth documenting, probably in the infobox for each article.
 
Weapons would be prioritised over cosmetics, simply because that is probably more useful to mod/plugin coders, for kill/assist/etc. events.
 
What do you guys think? [[User:Rebmcr|<span style="font-family:&#34;TF2 Build&#34;,sans-serif;font-size:120%"><span style="color:#FF2A55;">reb</span><span style="color:#002A55;">mcr</span></span>]] 14:57, 17 January 2012 (PST)
 
* Just realised that this would not even require translation. BONUS! [[User:Rebmcr|<span style="font-family:&#34;TF2 Build&#34;,sans-serif;font-size:120%"><span style="color:#FF2A55;">reb</span><span style="color:#002A55;">mcr</span></span>]] 14:58, 17 January 2012 (PST)
 
:This information is readily available in the schema and isn't really useful to anybody reading the Wiki. Mod authors have their own documentation on the Sourcemod Wiki/forums and know where to look, and the entity/class names aren't the same as the kill-feed/log names fyi. Again, all available in the schema. In any case, we have a list of weapon entity classes [[List of useful console commands|here]]. [[User:I-ghost|i-ghost]] 15:08, 17 January 2012 (PST)
 
:: Should we really leave something out of the official wiki just because it is already on a third-party mod's wiki? Of course it's not essential, but it's extra information about the game, and not exactly detrimental to include. If there's disparity between entity and feed names, is that not even more of a reason to document the differences? [[User:Rebmcr|<span style="font-family:&#34;TF2 Build&#34;,sans-serif;font-size:120%"><span style="color:#FF2A55;">reb</span><span style="color:#002A55;">mcr</span></span>]] 18:06, 17 January 2012 (PST)
 
::: "Whilst it may not be useful for >95% of visitors" which is why it's not needed. That 5% would know where to find it, despite it not being on the Wiki. [[User:Balladofwindfishes|Balladofwindfishes]] 18:09, 17 January 2012 (PST)
 
:::: At the risk of employing an overused quote: "It's not about '''why''', it's about '''why not!'''" [[User:Rebmcr|<span style="font-family:&#34;TF2 Build&#34;,sans-serif;font-size:120%"><span style="color:#FF2A55;">reb</span><span style="color:#002A55;">mcr</span></span>]] 03:41, 18 January 2012 (PST)
 
  
== Team Fortress Wiki SOPA blackout ==
+
<hr>
  
[http://en.wikipedia.org/wiki/Main_Page Certain] [http://www.reddit.com/ high-profile] [http:/
+
6) Include more sections on the Gallery for items with more than one Style. In the past, the [[Robot Chicken Hat]] page did include all 9 classes on the Gallery section, with 2 separate sections, one with the "Beak" style, and the other with "Beakless" style. It would follow the same rule as "5)", with both images looking identical facial-flex and pose-wise. Some pages like [[Dead of Night]] wouldn't include all classes on each section. Classes with lack of grenades wouldn't be there.
 +
 
 +
'''Edit:''' Some users asked for an example, so, when I talked about the Robot Chicken Hat, it originally [https://wiki.teamfortress.com/w/index.php?title=Robot_Chicken_Hat&oldid=1679218 looked like this]. The images don't exist anymore, but you can still see how it looked like. When I wrote the suggestion, I thought something about that (though it could have been changed a little, like include an "Other" title for the remaining images that aren't related to the class images), but, after Swood's suggestion, I'd say that using Tabs would be more ideal, something akin to how we do on the Tournament Medal pages.
 +
 
 +
I did an example on my 2nd Sandbox page. I thought something about this: [https://wiki.teamfortress.com/w/index.php?title=User:Gabrielwoj/Sandbox2&oldid=3598538 https://wiki.teamfortress.com/w/index.php?title=User:Gabrielwoj/Sandbox2&oldid=3598538] (note that a couple images, namely the infobox team-colors, and paint cans, does not show up properly due to the page's name being different, if this were to

Latest revision as of 03:23, 31 May 2024


Dark Mode

I don't think I even need to explain this. Wikipedia itself has it, so do other wikis. I do have a browser extension for dark mode, and optimally a dark theme for TFwiki should still keep muted earthy orangish tones and such, but at this point with my eye strain I'd take anything. It would encourage more dedicated editing streaks, perhaps, since many of us are night owls too.--Leaderboard class allclass.png Akolyth (talk) 03:23, 16 October 2023 (UTC)

Easier said than done, it's being worked on but we can't promise anything.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 11:13, 16 October 2023 (UTC)

Valve Store

The official Store has been closed down for months now by Valve, and there's no reasonable smidgeon of proof to believe it's coming back any time soon. The Wiki, in many articles, links directly to the Store still, or mentions it, but even tooltips for certain hats will just say they're "not available". This is kind of awkward, and makes the average user waste a click (the horror, I know). And even I get a false hope sometimes that it changed, but it's Valve after all. Should something be done about this, and how? Can there be an automatic disclaimer the Store is gone? Should links be removed? Just let the dead ends sit forever?--Leaderboard class allclass.png Akolyth (talk) 02:44, 18 October 2023 (UTC)

Try to find an archive.org version of it, otherwise just add a tooltip saying it's not available anymore due to store shutdown.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 11:12, 18 October 2023 (UTC)

Painted variants with both Styles and separate Classes images, a design proposal

Hi. So, I have several mockups of things to suggest which I'll be writing it up eventually. For now, I was making changes to the Robot Chicken Hat page, and was thinking about adding class variants to the paint gallery, as each class changes the hat's design a little (taller combs, different beak designs, etc.). However, if I were to make those paint variants per class, the current way we put styles and classes to the table looks... off, to say the least. At the moment, if I were to make it consistent with the rest of the Wiki, it would look like this: https://i.imgur.com/gfdAUBL. But, instead, I thought about this mock-up: https://i.imgur.com/QmQCLsK. Not only this looks more visually appealing, but it also takes a lot less space. The only problem that it may be confusing for cosmetics that separate styles by a group of classes (Cotton Head, Brotherhood of Arms, etc.). So... I thought about just making the class buttons that aren't active a little darker (same thing with the Style name): https://i.imgur.com/Fiw1zRT. Here's another example with the Cotton Head: https://i.imgur.com/ZhkQwGG. Mouse-hovering the class icons could also show their class names ("Pyro, Medic, Spy" and "Other classes" in the case of Cotton Head) Thoughts? Headphones style when? - User Gabrielwoj Signature 1.pngUser Gabrielwoj Signature 2.png - User Gabrielwoj Signature 3.png 13:11, 18 October 2023 (UTC)

I like this proposal, although I think it's not necessary for every page. Only for the ones where the tabs become too much.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 13:15, 18 October 2023 (UTC)

Inconsistency regarding items with one team color, but shows team-colored parts of a player model

Hello. So, when I started adding tabs to the paint variants, and just browsing the Wiki as a whole, I noticed that a couple pages are inconsistent in regards to the unpainted variants. In almost every case of cosmetics that use part of the player model, but only has 1 skin (not team-colored), the team-colors syntax isn't added to the tab, and we only have the UNPAINTED version on the paint variants table (example includes the Soldier's Stash, Horrible Horns on Spy, and much more), but some other pages still shows the BLU variant of a player model despite the item only having one skin (Texas Half-Pants, Millennial Mercenary's Streaming 2Fort style, Exquisite Rack, Battle Bob's With Helmet style, Bacteria Blocker's Headphones style, etc).

Some other pages also includes two identical RED and BLU images for the infobox, just because the item has two materials per team, but still uses the same exact texture and values (basically two identical .vmt files). I don't remember what pages has it now, but there are some pages that has that. I did that on Decorated Veteran since I've heard about doing that in the past before: "even if they look identical, put in two separate uploads". There's also no current way to just show one skin on the infobox (however that's something I'm looking to suggest soon enough on my mega infobox improvements topic).

Because we use the infobox, as well the RED and BLU parts of the paint variants table to show the different Skin Colors of the ITEM, I would say to actually cleaning it up these inconsistencies. So, for instance, on Texas Half-Pants, there wouldn't RED and BLU images for each style, because they look identical on either team, and, there's only two skins on the model (one for the Tan style, the other for the Midnight style [older cosmetics used a different way in handling styles, as opposed to separate models, many old cosmetics would use different skins for styles, and the Item Schema would redirect what skins to use depending on the style chosen]). The colors change on the images right now, because it's the colors of Engi's default pants, but not the actual item model changing colors. Meaning that, the RED / BLU on the infobox would be removed, the BLU_... images would be deleted, and the RED_ images would be moved to the _UNPAINTED.png suffix instead.

Some may argue that, since the team-colored paint can image previews also change the pants colors, that these should stay in, but, I don't agree. These are to show the item's team-colors being affected (both the UNPAINTED versions and the team-colored paint cans), not the player model's team-colors, but let me know what do you think.

Items that have 0 changes on team-colors despite having them (same exact .vmt values), I'd also say to get rid of it, as they provide no real information for the reader other than perhaps modders, so they don't need to go all the way of decompiling models to add team-color support, for instance. Some require close inspection however. The Mann-Bird of Aberdeen looks like to be the case, but the green area is just slightly brighter on BLU. I'd still keep the same colors for Styles and classes (like Team Captain for Heavy), until a more fully-fledged infobox edit comes along the way that adds support to just 1 skin on the infobox (like this: https://i.imgur.com/GQP1ou0). I will still point out many of these on my eventual discussion of infobox changes in another topic. Headphones style when? - User Gabrielwoj Signature 1.pngUser Gabrielwoj Signature 2.png - User Gabrielwoj Signature 3.png 13:43, 18 October 2023 (UTC)

I would support every page having both team colours.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 13:57, 18 October 2023 (UTC)

Articles for individual environmental hazards

Some of the older environmental hazards have their own articles. Specifically, they are: Ghost, Pumpkin bomb, Saw blade, and Train.

These are some fairly simple hazards: ghost goes "boo", pumpkin bomb goes "boom", blade goes "bzzt", and train goes "[Train horn noises]". They all have fairly short articles, and are also covered in the Environmental death article.

I propose we change these four into redirects to the Environmental death article, similar to Pitfall.

As for their Update histories, I have three ideas:

  • Add the section to the Environmental death article and carry them over.
  • Create a separate page for that (similar to the Item timeline pages).
  • Ignore them (essentially already the case for all the hazards that don't have their own articles).

I am ok with Skeletons and the Halloween bosses having their own articles, however, as they are more elaborate (which is noticeable by simply comparing article sizes).

Opinions? - BrazilianNut (talk) 16:36, 19 October 2023 (UTC)

I think some of these pages can add value, such as the specifics in the hazard infobox. I'd push for more articles rather than less, similar to List of game modes, where each hazard has its own page as well as a short description on the overall page. I would prefer this because it would cut down on the clutter on the Environmental death page, for example the pumpkin bomb section is 5 identical hazards that are just reskinned. It would be better to have this in a gallery on its own page, rather than several entries on that page.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 16:40, 22 October 2023 (UTC)
I believe it is better to keep the pages separate, as putting them all together in one could generate a lot of visual clutter, in addition to having a lot of information for the reader to consume at once. Furthermore, it would be complicated to gather all the update histories on the articles. Essentially, we would be taking separate articles and combining them into one big article, where each section (divided by == Section title ==) would be a "complete" article.
Tiagoquix (talk) 18:45, 22 October 2023 (UTC)

A request

In Polish language we don't capitalise most words like in English language and the way quality items have their quality displayed looks like this: Rocket launcher (vintage). The problem is that in Template:Mann-Conomy Nav Vintage quality in Polish and Russian is not capitalised and looks weird in the template where everything is capitalised except this one word. Is it possible to add a new entry in the dictionary for this template only, where 'Vintage' is capitalised for these languages? In Polish it's even more confusing, because Classic and Vintage share the same translation, so it could be shown in the tempalte as 'Vintage quality' (Jakość klasyczna in Polish). User Denied signature.jpg Denied (Talk) 10:28, 24 October 2023 (UTC)

If it's the very first letter that needs to be capitalised, you can use {{ucfirst:<string>}} to turn the first letter into a capital. For example, {{ucfirst:hello world}} generates Hello world.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 11:15, 10 November 2023 (UTC)
Could you help me with this? I've changed it in Template:Mann-Conomy Nav but doesn't seem to capitalise the first letter. User Denied signature.jpg Denied (Talk) 10:54, 17 December 2023 (UTC)
Hmmm, yeah seems like the automatic translation templates automatically uncapitalise it. If you really wanted to implement this you'd have to use the {{lang}} template instead.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 13:49, 17 December 2023 (UTC)
I already did it once and... User Denied signature.jpg Denied (Talk) 14:19, 18 December 2023 (UTC)
Perhaps leave a hidden comment and use {{lang incomplete}}?
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 14:27, 18 December 2023 (UTC)
I've coppied how it looked oryginally but now it shows as red link 'VintageVintage'. Could you look what's wrong with this edit? Except equals sign. I've fixed it later. User Denied signature.jpg Denied (Talk) 13:21, 19 December 2023 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────Looks like you forgot to add a vertical bar, which made the link [[VintageVintage]].
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 13:31, 19 December 2023 (UTC)

Mann Manor/Mountain Lab's history

I feel maps that we know more detailed information on the history of we should actually have written down so it isn't forgotten, such as for example, Mann Manor/Mountain Lab being an art contest was not the original plan in fact the maps used to have textures before but, that's just what I think. The American Boot (talk) 04:34, 10 November 2023 (UTC)

If you think this fact is worth and most player don't know, you can try adding it to Trivia section. Here is a more detailed Trivia guild.Profiteer(奸商)the tryhard (talk) 05:07, 10 November 2023 (UTC)
I'm not sure where this Trivia came from or if there is any source for. The Art Pass Contest page states that Robin Walker said they had a map that hadn't been worked on for a while and they didn't have time to do an art pass on it (which means the map just had dev textures).
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 21:34, 10 November 2023 (UTC)

Weapon articles mentioning taunts that aren't kill taunts

I've noticed a few articles for weapons mentioning that those weapons have a unique taunt that is not a kill taunt, or a variation of the default weapon for that slot (which is still not a kill taunt). These are the Lollichop, which mentions it has a unique taunt based on a scene from Meet the Pyro, and the Third Degree and Neon Annihilator, which mention the added guitar sounds, respectively. In comparison, the Cow Mangler 5000, Scottish Resistance, and Ullapool Caber, which also have unique taunts, do not mention them since they're not kill taunts, and the Vita-Saw, which has has a variation of the default taunt, does not mention said variation.

I think we should remove these notes from the Lollichop, Third Degree, and Neon Annihilator, as they are already all noted in the Pyro taunts page.

Speaking of the Pyro taunts page, I think we can move the "as in Meet the Pyro" comment from the Lollichop's description to a new Trivia section and add that Execution is also based in a Meet the Pyro scene (which is not mentioned). - BrazilianNut (talk) 16:45, 7 December 2023 (UTC)

I think variants on an existing taunt should be mentioned, such as different sounds (such as the Third Degree/Neon Annihilator adding guitar sounds and the Vita-Saw having different melodies being played), but the non-kill taunt shouldn't be mentioned (no note about the Lollichop taunt. Although seeing as it's unique to that weapon, I think the Trivia can stay).
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 17:14, 7 December 2023 (UTC)

Main menu Smissmas 2023 header localization

'Smissmas 2023' is localized but 'December 7 - January 7' is not. Is it possible to localize it too? User Denied signature.jpg Denied (Talk) 10:29, 17 December 2023 (UTC)

See Dictionary common strings.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 13:37, 17 December 2023 (UTC)
Thanks. User Denied signature.jpg Denied (Talk) 14:19, 18 December 2023 (UTC)

Link of the wiki team fortress energie drink don't work

[[1]] you see this page on the wiki contain a team fortress wiki energie drink with a link for have it but it don't work and is not secure, can someone help me ? The preceding unsigned comment was added by Nonolemage (talk) • (contribs) 2023-12-21, 13:46 UTC

Please sign your messages using ~~~~.
The website appears to be down and no archive of it exists, so unless someone here happens to have a copy we can't do much.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 13:46, 21 December 2023 (UTC)

Multiple Suggestions related to Infobox, etc

Hi. I have been wanting to write this in the past, but, well, finally here it is. I have a couple suggestions about things related to infobox, and other things to make the design of the Wiki flow better on certain articles. I will be posting here as it covers a multitude of topics, as opposed to posting each one of them on their respective templates. When adding "Support" and "Not Support" on your responses, please make sure to add the number (and letter) behind to specify what you are supporting (or not supporting) as a change (like: "1-c"). With that said, let's get going:


1) Implement a way on the Item infobox template where if a style or class has only one team-color compared to other styles with team-colors, include an icon in the middle of both teams. For instance:

a) The Heavy variant of the Team Captain only has one color, but the page right now includes a duplicate of the RED variant as a workaround. What I suggest is doing this: https://i.imgur.com/YgQHk5z. Make the Heavy variant only one file, and center it. It should be pretty clear that because of the image is in the middle, is that it looks like that on both teams.

b) For items with styles that only has one color (not team-colored), do the same thing as well. In the example of Close Quarters Cover, include the "Alert" style on the infobox in the middle of the "RED" and "BLU" sections of the infobox, something like this: https://i.imgur.com/lARBQME.

c) For items that are not team-colored, but have class-specific variants, include a new part colored in grey called "Both Teams", and include each image on the middle as well. For example, the Dead Little Buddy have 3 model variants, one for Pyro, one for Demoman, and the other for the remaining classes. The idea is this: https://i.imgur.com/xPD9PMO.

d) Although I do not have a mock-up right now, I thought of also doing the same as above for items that has only one color. So, for instance, the Jumper's Jeepcap would have a "Both Teams" section, and it would include the "UNPAINTED" variant on the center. Items with styles with just one color, like Mustachioed Mann, would be similar to Dead Little Buddy, including each style on the infobox, alongside their names. Items like Carl that has no styles, but is neutral-colored, would also have the "Both Teams" part.


2) Get rid of the current "2D" images of Weapons, and use "Item icons" instead. The 2D weapon images are not consistent throughout the Wiki. They have different lighting, different angles, and so on. What I suggest is doing something similar to another Wiki I also contributed (one related to a TF2 sourcemod): https://i.imgur.com/vbvPbGP. This looks extremely clean, and every page would have in this angle. The 2D image only includes the RED variant, just like we use RED classes on our cosmetic previews.


3) Add the "RED" and "BLU" sections on the infobox for Weapon pages, even if the 3D image allows you to switch between teams. Right now, the RED variant is used as the 2D image (for team-colored weapons), while the 2D BLU variant awkwardly sits on the Gallery section. My suggestion would be this: https://i.imgur.com/dM9z7Oo


4) For cosmetic pages that has styles alongside class changes on the Painted Variants table, include additional buttons that include class icons. The idea is to remove clutter on pages with a lot of tabs to choose from (see this page). In technical terms, the style buttons would be responsible to change the "style" part of the filename, while the class buttons would change the class part of the filename. If the first class is chosen, then the code needs to get rid of the class part of the filename, as the first class is always the default: https://i.imgur.com/QmQCLsK

a) Additionally, text could be placed on each row, one for "Style:", and the other for "Class:" for the second row, just so it's a little more intuitive and understandable for everyone.


5) Include "infobox images" for separate styles, and add buttons that let you change it. The idea is to include identical images (with identical classes and facial flexing), with the only thing changing the model. For example, Main Cast would look like this: https://imgur.com/a/OmTIYVs.


6) Include more sections on the Gallery for items with more than one Style. In the past, the Robot Chicken Hat page did include all 9 classes on the Gallery section, with 2 separate sections, one with the "Beak" style, and the other with "Beakless" style. It would follow the same rule as "5)", with both images looking identical facial-flex and pose-wise. Some pages like Dead of Night wouldn't include all classes on each section. Classes with lack of grenades wouldn't be there.

Edit: Some users asked for an example, so, when I talked about the Robot Chicken Hat, it originally looked like this. The images don't exist anymore, but you can still see how it looked like. When I wrote the suggestion, I thought something about that (though it could have been changed a little, like include an "Other" title for the remaining images that aren't related to the class images), but, after Swood's suggestion, I'd say that using Tabs would be more ideal, something akin to how we do on the Tournament Medal pages.

I did an example on my 2nd Sandbox page. I thought something about this: https://wiki.teamfortress.com/w/index.php?title=User:Gabrielwoj/Sandbox2&oldid=3598538 (note that a couple images, namely the infobox team-colors, and paint cans, does not show up properly due to the page's name being different, if this were to be pasted onto the actual page, it would show just as fine). I decided to not make the Tabs centered as regular cosmetic pages are usually not centered, unlike Tournament Medals / Community Medal ones. I also decided to make the gallery width "485px", so it shows 3 images per row, and looks pretty nice and cool with whatever's below that does not require a Tabs section.


7) Lastly. Items that include noticeable team-color differences could also get "Single Color" paint can previews on both teams, even if the paint look identical on the area that is paintable. When Paints were first introduced, they were mostly applied to cosmetics that used the same texture on either team. Now, nowadays, we have cosmetics that include team-colored parts that are not paintable, alongside other parts that are. So, for instance, Brawling Buccaneer would have its Painted variants table from {{Painted variants}} to {{Painted variants full}}, and single color paint can previews for the BLU team would be made, to show how the paint looks like, and despite being painted in the same area, the rest of the item is in another color. Readers might want to know how an item looks on the BLU team. This would take a long time too make for the entirety of the Wiki, and would be a project that would require remaking some paint variants if they do not have Rotation values saved, or if there's another issue that doesn't make them 1:1, but I think it would look good, and useful as well.


8) For items that has several styles / classes on the infobox (such as Manndatory Attire, Beaten and Bruised and Boarder's Beanie‎), make the Infobox template show less of them by default, and include a button with a caption "↓ Show remaining ↓". If possible, make the last one have a "fade" effect, so it's perfectly clear what the button is about. My idea was to include at least 10 of these sections, then fade (because if it reaches 10 of these, it means there's more than one Style per class, where other pages would include 9 of these per class, though, it could be shortened if needed, but personally I would go with 10 sections before the button and fade shows up). It would look like this: https://i.imgur.com/jh6geu6


Edit: 9) Regarding the Styles section. If we include Styles on the infobox, even for items that look the same on either team, is it really necessary to include the "Styles" section on the page, alongside the table, if everything would be on the Infobox? It seems redundant to keep both of them, but, I'd only get rid of the Styles section after everything is added to the infobox, including the single-color Styles on it. Additionally, certain pages that has Styles that change between classes are a little confusing at the moment. Manndatory Attire has only Scout's styles being demonstrated on the table, despite each class changing the visuals.

a) Originally I was going to suggest a class-switcher button, similar to the "4)", but, if "1)" is implemented, I don't see any reason to keep the Styles section. Please let me know if you think there should be either: "An arrange of buttons that lets you change classes on the Styles table" or "Getting rid of the Styles section entirely as it would be redundant with all the styles on the infobox once the "1)" suggestion is implemented.

b) The only problem that getting rid of the Styles section would be problematic for items that has barely any difference unpainted, but has more notable differences when paintable. Items like Onimann mostly change its visuals when painted between styles, and if there's no section for it. However, the painted variants table, alongside the main summary on the top of the page, would both visually show the difference, as well would explain in text what each style does in terms of paint.


Please let me know your thoughts below. Notice that I'm not sure if I would be able to implement some of these suggestions, specially the ones for the "Item infobox" template. If there's enough support, I'd appreciate anyone who could implement suggested changes / additions. Headphones style when? - User Gabrielwoj Signature 1.pngUser Gabrielwoj Signature 2.png - User Gabrielwoj Signature 3.png 21:13, 28 December 2023 (UTC)

1. I think that section should be dedicated to showing off the team colours rather than different styles for different classes. If a cosmetic looks different on different classes I would prefer a different box for it similar to the "Styles" section.
2/3. That's fine by me, though I would also want to add a second button to it for the BLU variant rather than stuffing it in the Gallery.
4/5. I like this.
6. I like this, although I would suggest we use the {{Tabs}} template for it.
7. I like this too, but it would require a ton of work and I'm not sure we'd be able to make it through.
8. I'm not sure that I'm a fan of collapsing a bunch of them. I would prefer having them sorted by class instead similar to {{Tabs}}.
9. See answer on 1.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 21:59, 28 December 2023 (UTC)
1 Pictogram plus.png Agree - All of these changes look very nice, I don't have anything to say about them.
2 / 3 Pictogram question.png Not sure / changes - Would the change to using weapon icons include BLU weapon icons as well? If it does, I would rather have the 2D BLU image in the main infobox when you click on BLU and then switch to the 2D image instead of it being below the main image.
4 Pictogram plus.png Agree - This also looks nice.
5 Pictogram minus.png Disagree - I don't know how I feel about this, I feel like the painted variants sorta already accomplish the goal of knowing what the cosmetic would look like with the different styles. It would also take a lot of work to recreate a lot of infobox images just for this.
6 Pictogram minus.png Disagree - I have the same thoughts about this as 5, it would take a lot of work to redo a bunch of galleries when the styes / painted variants section already get the job done.
7 Pictogram plus.png Sorta Agree - This would look nice, however it would again take a lot of work to get done.
8 Pictogram plus.png Agree / changes - I like the idea, though I agree with what Swood said with that it would look better if it was just in tabs instead.
9 Pictogram question.png Not sure - I sort of agree with the idea of removing the styles section, but I also do like how there's a sort of simplified section for seeing all of the styles instead of it only being part of the infobox and painted variants.
Andrew360 Edit icon.png Speech typing.png Photo Badge Decal Example.png 03:27, 29 December 2023 (UTC)
1 Pictogram minus.png Disagree - Same reason with Swood, I think the style section should do the job.
2 Pictogram plus.png Agree - Good idea!
3 Pictogram plus.png Sorta Agree - Instead of taking space in infobox, Why don't we use the same button used on 3D images?
4 Pictogram plus.png Agree - Yes.
5 Pictogram plus.png Agree - Looks nice, but considered what Andrew says we might not getting those done in recent.
6 Pictogram plus.png Agree - We are gonna do a lot of work then I guess.
7 Pictogram plus.png Agree - Same with Andrew360
8 Pictogram question.png Not sure - Looks good, though yeah, why not use {{Tabs}}?
9 Pictogram question.png Disagree.. or Sorta Agree - If I have to choose one from infobox and style section, I would take style section. In my opinion the infoboxs shouldn't be too long and contain too much information, comparing to a small space on the right side of the page, I think the style section can display the information better. If 8 gets passed then I'm fine with it too. (I just don't want to see infobox gets longer than the page itself.)
Profiteer(奸商)the tryhard (talk) 06:16, 29 December 2023 (UTC)
1 Pictogram plus.png Sorta Agree - Eh, doesn't matter to me either way.
2 Pictogram question.png Not sure - I wanna see how it would look first.
3 Pictogram plus.png Agree - I was kinda the one to start the whole "shoving the blue variant in the gallery" and have always wondered why there wasn't a color toggle for the 2D variants.
4 Pictogram plus.png Strongly agree - I wish it was like this since the beginning!
5 Pictogram question.png Not sure - I like the idea, but it will take a lot of work updating all the pages and such with the change.
6 Pictogram question.png Not sure - Same answer as 5.
7 Pictogram plus.png Agree - I'm only saying yes because we'll only have to edit the templates which are used across all translation pages.
8 Pictogram minus.png Somewhat disagree - There aren't very many items that have loads of different styles like this, I think I'd wait until we get something like a shirt or coat that includes a load of different styles (with team variants).
9 Pictogram minus.png Strongly disagree - Yeah it is necessary to have a styles section, because they mostly show examples of what they look like on the character wearing it. I know that the infobox has styles too, but they're only the raw models.
ShadowMan44 (talk) 01:52, 30 December 2023 (UTC)
So, after some user's responses, I'd like to mention a couple things. In regards to most of "2)" and "3)" responses, here's something I didn't mention. There would be a slight problem for items that are not team-colored if we just implemented a RED and BLU image switcher. The idea of using "Item icons" with the RED variant / neutral-color variant, would that it would make everything consistent and nice looking, While "RED" and "BLU" 2D images are usually very consistent too, the current "2D" images used on weapon pages are all over the place. Using the "Item icon" in conjunction with the RED and BLU team-colors means we could use already existing images on the Wiki, too. Not that I would have a problem if new images had to be created for the Neutral-Colored weapons, but, I still think that using the Item icons would highly benefit here, since how nice they look on weapons.
However, if we go with a RED and BLU switcher, what we could perhaps do is team-colored Item icons, yeah that would be awesome. Not only that, but we also have Item icons for Australiums, and, I even made Australium Festivized icons for TF2B a while ago, that is only used there and not on the Wiki, at the moment.
GrampaSwood 6) Yeah, I didn't think of this, but using Tabs on the Gallery would be pretty good, something we already do in Tournament Medal pages, actually.
GrampaSwood, Andrew360, Profiteer 7) While I can't promise I will be on the Wiki forever, and, with my statement on my userpage being correct (that I won't be as active in 2024), making BLU team-colored variants on "Standalone" models is a faster process than when making when loaded as a "weapon" (e.g.: Cosmetic loaded on a player model). The reason I did all the Boarder's Beanie paint variants is solely because it's a standalone model, I was able to generate the paint variants very quickly (and in high quality and proper colors). I can still do every single style and class on BLU as well, for the Single Color paint variants, for the Beanies, I just haven't done since we are still discussing this.
My Laptop is currently not being used. I have thought of the idea of making an HLMV machine, and letting paint variants being made while I do other things. This is something I thought about in the past, but I would require another monitor (which I can buy, no problem), but I also would need time, something I will not have that much starting 2024. However, I'm also in the point where I feel like I have contributed quite a lot for the Wiki already, so I'm kinda conflicted if I should really do this or not. I would only require to re-install Windows, re-configure HLMV (which can be painful), and things like that, before I can make it an idle HLMV machine that makes paint variants.
ShadowMan44 7) Correct, currently, the "Painted variants full" template states that mouse-hovered "Single colors" states that "due to how the cosmetic's textures are set up, it changes colors between teams". This would require to be changed appropriately, somehow, though I don't think that yet another Painted variants template should be made. It should be possible to just add a parameter of some sort.
Gabrielwoj, Andrew360 5) Despite me suggesting this, I was also not too sure about it, but I decided to post it as a matter of discussion. In most cases, Styles just change the look of an item, without changing the placement of the model, or the model itself. In some other cases, however, it does change something Liquor Locker, Pocket-Medes, etc. While it would be an interesting idea, and I do have a couple cosmetics with all styles made already, most of the rest would require to be remade. This could also be a little difficult for regular HLMV users, as refreshing the model viewer gets rid of the facial flex entirely, but not on HLMV++. While you can unload and load submodels without having to refresh, HLMV does read from "$color2" instead of "$colortint_base", which means if someone forgets about that on an older cosmetic, they'd need to refresh after fixing it from the .vmt.
Profiteer 9) That's a good point. I guess if the Styles section was more populated (actually shows differences between classes), then I suppose that items like Manndatory Attire and Boarder's Beanie wouldn't require that huge amount of styles being shown on the table. But then, there's another problem. Items already show their unpainted RED and BLU variants on the infobox, and how exactly could we categorize "exceptions" to be only on the Styles section if we follow your idea?
ShadowMan44 9) I'm not quite sure if I understood what you said. The styles table on both the Style section and infobox use the same exact images, same files, with some exceptions like the Dead of Night and Pocket-Medes. This is why I mentioned it being redundant, because in most cases, both sections use the same images. Headphones style when? - User Gabrielwoj Signature 1.pngUser Gabrielwoj Signature 2.png - User Gabrielwoj Signature 3.png 11:21, 30 December 2023 (UTC)
So Tekinz and Mgpt talked with me via Steam and Discord DMs, and I'd like to post their opinions on this. Tekinz asked me to post on my behalf, explaining what he told me instead of directly quoting him, while mgpt allowed me to directly translate what he told me. With that said, here's what they had to say:
Tekinz: He told me that he agrees with most of my proposed update and changes, while pin-pointing some specific numbers with further explanation. He adds that for "7)", it would be a huge amount of work, and we would need quite a few active image creators to be able to achieve it in a timely manner, but otherwise it would be a general improvement to the pages. On "8)", he adds that he has no real problems with and thinks it's pretty good, mentioning that if combined with "1)", it would look great. On "9)", he mentioned that it's probably a good idea considering how the Styles section is located pretty far on the page and that it would probably be better to have them focused to the infobox since it's much closer to the top, alongside the rest of relevant images. He further adds that the Styles section always seemed not as important since it was too close to the Trivia and Patch Notes, while also being beneath the huge Painted Variants table that overshadows it.
mgpt:
Pictogram plus.png Agree 1. Everything looks okay to me, if it's easy to implement;
Pictogram plus.png Agree 2. I did take a look on some weapons, and I agree in using "Item icons";
Pictogram plus.png Agree 3. I saw the comments, and Andrew360's idea, and I agree, it has my vote;
Pictogram plus.png Agree 4. You got my vote, very good;
Pictogram minus.png Disagree 5. I agree with Andrew360 and Profiteer, I don't think that it's worth the work, considering there's already images below on the infobox, alongside the painted variants;
Pictogram info.png Info 6. It ends up being the same as "5)", however, I'd like to see an example how it would look like;
Pictogram plus.png Agree 7. I'm not sure if I noticed completely, but would that be switching the template from "Painted variants" to "Painted variants full" In several cosmetics, like how it was done in Brigade Helm? If so, I don't see a problem;
Pictogram info.png Info 7. An idea to the template. Wouldn't it look better if it was something like this, with 2 buttons? https://i.imgur.com/LVXXb4C Or is it being done currently like it's on the page so it's possible to compare both teams at the same time? Probably that;
Pictogram plus.png Agree 8. I like the idea, however, the information still continue to be too deep on the page, wouldn't be better to only show 4 or 5, instead of 9?;
Pictogram info.png Info 9. a) "An arrange of buttons that lets you change classes on the Styles table". In the example of Beaten and Bruised, the images wouldn't be anymore on the infobox, correct?;
Pictogram info.png Info I like "8)"'s idea, but if "9)" is applied, then number "8)" is discarded. Headphones style when? - User Gabrielwoj Signature 1.pngUser Gabrielwoj Signature 2.png - User Gabrielwoj Signature 3.png 12:16, 3 January 2024 (UTC)
I also replied to mgpt regarding some of his questions, so I had the following to say:
7) On number "7)", it would be including previews like how it's done on "Single Color" paint cans on the BLU team, even if when they are applied on the same area, the paint color looks identical to the RED team. Currently, we only use "Painted variants full" in cases of items that has different colorization between teams, such as the case of Stout Shako;
7. a) I liked the idea of including RED and BLU on the top, it would be very intuitive. Post-thoughts: After re-reading his thoughts on this one, I saw that the original idea would be buttons, while I first thought they were simply two sections that would separate the teams more properly, visually. I thought if maybe that by doing so, we could include a faint red and a faint blue background to separate them both, and make the template a little more nice to look at, as currently there's a bunch of paint variants all included in one table.
8) In regards to the default quantity, it would still be discussed, but the main idea would be something that could be expanded to show the remaining. I finished the Boarder's Beanie images, and the infobox ended up being very lengthy. The table for Painted variants will probably change if "4)" is implemented.
9) The images would still stay on the infobox section, but the idea would be that on the Styles table, it would include an array of buttons with each of the classes icons, so it could be changed, similar to what it has been suggested on "4)". The only thing that, if "1)" is implemented, the Styles section may not be as necessary anymore. Headphones style when? - User Gabrielwoj Signature 1.pngUser Gabrielwoj Signature 2.png - User Gabrielwoj Signature 3.png 12:16, 3 January 2024 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── 1 Pictogram question.png Not sure It sure would be easy to implement but I feel this would discount the usefulness of the class gallery or style section.
2/3 Pictogram plus.png Agree It would clean up the inconsistencies from the 2D weapon images and make them extremely consistent. The item icons are used all over the wiki in subtle ways such as in crafting recipes or in big lists of weapons but it's time for those to be the defacto 2D image for weapons. Bring Shugo-style to the infobox!
4 Pictogram plus.png Agree Adding the class icons in place of the class name plus sorting the paint table by class would greatly improve the user experience. (I always stress when uploading paint galleries with multiple styles that I may upload to the incorrect style/class)
5 Pictogram minus.png Disagree On top of remaking all the infobox images being an immense amount of work, I feel this would also take away from the usefulness of the style box.
6 Pictogram question.png Not sure I would be more open to this than #5 but I often find that the class gallery images often take me the most time to complete and be happy with. Trying to find good and unique poses and appropriate facial flexes for all 9 classes takes me a fair amount of time. I wish I was faster at it.
7 Pictogram question.png Not sure I kind of agree on this point but I feel it could just be on a cosmetic-by-cosmetic basis. Like we do now, I think, we could only implement this on hats that would benefit from a full paint gallery.
8 Pictogram plus.png Agree I agree with the others on this point, {{Tabs}} would be great for this. I am more for moving the class styles out of the infobox and moving them to the style box. I feel more and more pages suffer from having a long infobox with the inclusion of more all-class, multi-style hats. If they were moved to the style box with tabs, I think many pages would look a whole lot cleaner and compact.
9 Pictogram minus.png Disagree See #8
H20verdrive (talk) 01:22, 7 January 2024 (UTC)

I've been mildly intimidated, procrastinating voting on this for a week, but here we go:
1. Pictogram plus.png Agree Very good stuff.
2. Pictogram question.png Abstain Not sure about this, it might seem awkward on some items. Like others have said I'd want to see it first.
3. Pictogram plus.png Weak Agree Seems necessary, but I wonder if there's a more cohesive way to display them.
4. Pictogram plus.png Agree Looks nice, more visual and less clutter.
5. Pictogram plus.png Weak Agree Seems alright.
6. Pictogram question.png Abstain It seems a bit clunky and as someone said, might take a lot of work, but theoretically seems useful.
7. Pictogram plus.png Weak Agree As H20verdrive said, probably an item-by-item basis (maybe a "limited run" at first for the articles that need it most?) is best.
8. Pictogram plus.png Agree Looks cool; long infoboxes do need help, but I think it's most contingent upon all-class items.
9. Pictogram minus.png Weak Disagree As all others said, this needs tweaking and removing Styles might be too radical, BUT the "arrange of buttons" might work.
Overall, if I had to give a vote for the whole package, Pictogram plus.png Agree, with tweaking.--Leaderboard class allclass.png Akolyth (talk) 02:21, 10 January 2024 (UTC)
Well, we got a lot of responses with this discussion, thank you everyone for reading and replying. I guess we could start making some of these proposed changes? Ones that got the most positive votes, while discarding ones that didn't get much positive reception. Perhaps let's talk what should be the best options according to your guys voting. I don't have time to actually write up new template codes and stuff at the moment, however some already have templates available for that (#7), and others should be a little more straightforward in changing (I would imagine that including the Shugo style icons for weapons be quite straightforward, if that would go through). Headphones style when? - User Gabrielwoj Signature 1.pngUser Gabrielwoj Signature 2.png - User Gabrielwoj Signature 3.png 00:26, 27 January 2024 (UTC)
Swood suggested me to make a table having total votes from everyone:
Suggestion 1 Pictogram plus.png Agree: 7 Pictogram minus.png Disagree: 1 Pictogram question.png Abstain: 2
Suggestion 2 Pictogram plus.png Agree: 7 Pictogram minus.png Disagree: 0 Pictogram question.png Abstain: 1
Suggestion 3 Pictogram plus.png Agree: 9 Pictogram minus.png Disagree: 0 Pictogram question.png Abstain: 1
Suggestion 4 Pictogram plus.png Agree: 10 Pictogram minus.png Disagree: 0 Pictogram question.png Abstain: 0
Suggestion 5 Pictogram plus.png Agree: 4 Pictogram minus.png Disagree: 4 Pictogram question.png Abstain: 2
Suggestion 6 Pictogram plus.png Agree: 4 Pictogram minus.png Disagree: 1 Pictogram question.png Abstain: 4
Suggestion 7 Pictogram plus.png Agree: 8 Pictogram minus.png Disagree: 0 Pictogram question.png Abstain: 1
Suggestion 8 Pictogram plus.png Agree: 8 Pictogram minus.png Disagree: 1 Pictogram question.png Abstain: 2
Suggestion 9 Pictogram plus.png Agree: 2 Pictogram minus.png Disagree: 3 Pictogram question.png Abstain: 4

My own votings have been included too. I agree with all of the changes I proposed except "5)", which I only suggested since I already had some Style images laying around on my computer, ready to be uploaded if it were to be accepted. Headphones style when? - User Gabrielwoj Signature 1.pngUser Gabrielwoj Signature 2.png - User Gabrielwoj Signature 3.png 17:49, 31 January 2024 (UTC)

Userbox, and creator page

Hey! I have a question, how i add userbox and how i add some decoration to my page like evryone did ? Nonolemage (talk) 13:21, 8 January 2024 (UTC)

For userboxes see Team Fortress Wiki:User info boxes. Otherwise, the rest of the decoration is up to you. You may be interested in {{User infobox}}.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 13:27, 8 January 2024 (UTC)
Thanks for the info box ! But how exactly i decorate my page ? Like how i use custom image or something like thats ? Did you have a page thats can help me to do this ?Nonolemage (talk) 13:59, 9 January 2024 (UTC)
Help:Images may help you with how to place images, for images to use, simply upload them using the upload page. The correct format for images only used on your User page is "User Nonolemage [file name]", so for example "User Nonolemage profile picture.png" or "User Nonolemage scout loadout.jpg". When uploading them on the upload page, include [[Category:User images]] in the summary box. This should be done for every image you want to use on your User page.
As for more complicated design, that is usually done using CSS and/or Javascript. I can't help you much with that.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 14:08, 9 January 2024 (UTC)
Thanks you a lot ! You realy helped me ! Nonolemage (talk) 14:10, 9 January 2024 (UTC)

Civilian Image

Should we change the image of the Civilian ? Because it's the scout in A pose but the civilain got some real texture thats can be use and found Nonolemage (talk) 12:54, 11 January 2024 (UTC)

That is how the Civilian class looked when it was still available in TF2, Civilian (Classic) is the TFC version.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 12:57, 11 January 2024 (UTC)
Oh, but i play a mod of tf2 (tf2c) thats show a finished model of the civilain so maybe i can add a picture of it in the galery for show what it looked finished ? Or it's not important ?Nonolemage (talk) 13:04, 11 January 2024 (UTC)
That's not an official version of it, that's fan-made. No Civilian model or textures has been made for TF2.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 13:11, 11 January 2024 (UTC)

Weapon in user page

Hey it's AGAIN me ! I see some people have a list of weapon they used for evry class but i don't know how to do this, can someone help me ? Nonolemage (talk) 07:32, 14 January 2024 (UTC)

Well, you could try learning how to use wikitables, there are also templates like Template:Backpack item and Template:User weapon checklist you could use to this effect.
Luno 🪐🌕 Talk / Contributions / Team 03:20, 15 January 2024 (UTC)

Allweapons Nav template

Hi! I've created two mockups as potential replacements for the current Allweapons Nav template. I'd like to get your opinion. You can check out the templates on my sandbox user page (Nav 1 and Nav 2). The "Secondary" label for "All classes" in Nav 2 appears a bit off, and I'm having trouble fixing it. Thanks! Mgpt (talk) 02:59, 16 January 2024 (UTC)

I don't really see what's wrong with the current one.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 11:59, 16 January 2024 (UTC)
Outdated/It's not a "real" nav like the others (Hat/Tool Nav). If someone else comments please compare both so you can see the differences Mgpt (talk) 16:05, 16 January 2024 (UTC)
I did compare both, but it doesn't exactly answer what's wrong with the current one. If people really wanted it changed I'd go for Nav 1, but I would still like to see stock and non-stock separated.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 16:16, 16 January 2024 (UTC)
There's already a nav for them on the weapon page and stock is always the first (they can be in italic, would that work?). I personally prefer Nav 2 because it is actually a nav (not a table) but also consistent with Hat and Tool Nav. Edit: About the availability strings, they shouldn't be there, especially because they're outdated and were added more than 10 years ago. Definitely not the purpose of the template. Mgpt (talk) 20:11, 16 January 2024 (UTC)
I'd prefer for them to be separated regardless, if only in a little box above all of them or with a line separating them. Both the current one and both your versions are technically tables either way, I think a differently structured nav doesn't necessarily make it not a nav or somehow inferior.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 20:39, 16 January 2024 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Personally, I prefer Nav 1. I like the structure of the current Weapon Nav the way it is, I just don't like the availability strings cluttering things up, and the taunts needlessly listing which weapons they're for. Nav 1 simplifies things in a way that's easier to read, certainly. I'd also be fine with Stock weapons being separated, perhaps with a "Stock" header and then a line break before the others.

Incidentally, re: "the 'Secondary' label for 'All classes' in Nav 2 appears a bit off, and I'm having trouble fixing it."

  • That should be a "Melee" label, as you've probably realized by now.
  • It's looking off because the single list of weapons you've used isn't enough to fill out the space of the column. You'd need at least three lists to fill out the space that the "All Classes" column takes, so the single list you gave sits in the middle. — User ThatHatGuy Signature Icon.png 10:21, 17 January 2024 (UTC)
I made some changes, thanks for the input Mgpt (talk) 03:18, 18 January 2024 (UTC)
Nav 1 seems almost set to me, I like the Normal quality grey indication, while still being separated by slot. My only slight nitpick now would be that I'd prefer if the non-stock weapons were organized by release order -- at the moment, reskins of stock are still at the top of the non-stock section, which doesn't make as much sense, now that we've agreed on separating stock into its own box. — User ThatHatGuy Signature Icon.png 03:33, 18 January 2024 (UTC)
I initially added them randomly from the Weapons page, but I'll definitely reorganize them by release order :D I may scrap the all class section, the idea was not to repeat weapons, but we have the Shotgun, so... Mgpt (talk) 03:45, 18 January 2024 (UTC)
Updated the template Mgpt (talk) 19:01, 22 January 2024 (UTC)

About the 2023 leak

Hello ! Im a translator of the unused content and i see on the social media a leak from 2023 of some map and iteam thats has been abandoned or unfinished. So i was thinking if i can work on it for make some page on the unused content section. (The leak is from a valve employer) Nonolemage (talk) 15:52, 22 January 2024 (UTC)

As long as you source all of these changes and abide by the leaked content policy. This leak was also not from a Valve employee, as far as I know.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 15:57, 22 January 2024 (UTC)
So if i understand, i donnt have the right to put any picture of anything if it's from a leak ? And by the way, how did the code for cited content from leak work ? And if it's not from a valve employer, from who it's from ? (Sorry for all my question and thanks for anwsering me ;-;) Nonolemage (talk) 16:08, 22 January 2024 (UTC)
Don't link to any places that host leaked content (so do not link to a Tweet containing a picture of a leaked model, or containing a link to a Google Drive with the leaked content, etc.), do not directly upload media of leaked content or copy-paste code, and do not link to or upload media of recreations of leaked content. All the information you put on the page should contain a reference to where you got it from (see the examples on the policy). It's likely someone with a Source engine license that leaked everything.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 16:19, 22 January 2024 (UTC)
I understand, thanks a lot for your help again and i will do evrything you say ! Nonolemage (talk) 16:38, 22 January 2024 (UTC)

Community Medal Nav (closed)

I feel a bit lost with the medal scheme and how it has been handled. Where exactly is this template supposed to be used? I know that {{Hat Nav}} lists the same contents, which I recently updated. I think we should either use this one and remove the medal section from Hat Nav or just use Hat Nav, no? Thanks in advance Mgpt (talk) 21:28, 24 January 2024 (UTC)

With the ever-increasing MvM medals, we should remove it from the Hat Nav and keep this one. The Hat Nav will cause pages to be too large at some point.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 21:29, 24 January 2024 (UTC)
Would adding an 'Other' section with two links for Community and Tournament medals work then? With this approach, we also need to update the "Competitive play" Nav. Also, both templates use images, is there a specific reason for that?
Edit: They're also cosmetic items, so they should still be mentioned, in my opinion Mgpt (talk) 21:40, 24 January 2024 (UTC)
I would put the 2 links in the hat nav, then keep the medal nav separately. The comp nav can get rid of it imo, and just having a tournament medal link. I prefer having this separate one.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 22:07, 24 January 2024 (UTC)
I like the template, but it's too big. We don't need images for all the medals: they are exactly the same and this won't scale well if Valve ever allows new medals again (see comp nav). — Tark 00:16, 25 January 2024 (UTC)
Disagree with "they're exactly the same," they're clearly, almost all of them, not exactly the same, but I know that my opinions about all this don't matter too much anyhow. I would be fine with listing the names of the medals instead, but then they'd all have the name of the operation over and over again, and it would be very clunky to look at. That's how it was in the promo nav to begin with, and that's what I wanted to change -- but then, that would require extra name strings that are just "Shimmering Souvenir", for example, and Swood already said that was too much. The images were my way of compromising on that, considering the Competitive nav already did that, but then that's wrong too, so whatever, I can't do any of this properly. — User ThatHatGuy Signature Icon.png 03:47, 25 January 2024 (UTC)
They are all the same just with a unique hex paint the MVM ones have been reused over and over, there is no model difference between them other than the paint, If the medals were "different" they would have unique models to go alongside them, but back on subject, theres so many of these damn things it would be nice to be able to filter them out entirely.
Cheddar (talk) 13:57, 25 January 2024 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── By "exactly the same", I meant all the MvM medals that share the same model but have a different paint applied. An average user doesn't care if the medal is pink or green, they are way more interested in the model itself. The same applies to the comp nav: we don't have an icon for every season of each tournament, only for different models.
I personally don't see how extra strings are too much and I agree that the icons look way better than whatever is going on with the comp nav template. My point here is that this template currently is too big and has too much repetitive information to work as a navbox.
Also, I know that it is common for us to get attached to our creations (in this case, the template), but suggested changes to a template are usual business. Please don't take it personally, your opinions always matter. — Tark 14:06, 25 January 2024 (UTC)

If I remember correctly, the "too many strings" were in reference to another nav, where I suggested removing them and replacing them with links to the operation page's rewards section. There were a few medals for each operation with a link to the same section each time. Having too many strings was in reference to the promo nav, not the one we're talking about.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 14:40, 25 January 2024 (UTC)
So if it's suddenly not too much trouble to localize different name strings for use within this nav specifically, for reasons I won't pretend to understand, nor do I care to ask about further, I propose that if we absolutely must, we strip the pictures and the paint splats, and in the case of MVM operations, we have the link to the operation, and then within that category, plain-text names of just the medals, stripped of the operation name and years, when necessary. (That is, "Operation Galvanized Gauntlet Bejeweled Bounty 2023" becomes "Bejeweled Bounty", and so on. Cleaner, easier to read, and you already get that it's supposed to be within that operation.
I would fight for the pictures, but it's clear that's not about to happen for me, and it's best for me to give it up and take the bullet, like I always have to. I'll believe that my opinions always matter when they start being correct ones to have. — User ThatHatGuy Signature Icon.png 14:54, 25 January 2024 (UTC)
ThatHatGuy I'm not against your template creation but I searched a little more and its being used with {{Hat Nav}} so we need to decide which one we gonna use, because currently, they have the same contents. Given the opinions above, I think a more neutral solution would be to move the Hat Nav contents to these two templates, so they stay similar to each other. Mgpt (talk) 18:35, 25 January 2024 (UTC)
That didn't matter when some of those event pages, for years, had both the Hat Nav and the Promo Nav on them. The Promo Nav, by definition, has the same stuff that's already on the Hat Nav. Community medals used to be listed individually on there too. Now all of a sudden, there's a new nav, that I made because Swood wanted to separate the Community Medals into their own page, and suddenly, that's something worthy of being dissected and put under a microscope.
Fix it how you all want. I've said my piece about it, but clearly I don't know what I'm doing. — User ThatHatGuy Signature Icon.png 00:53, 26 January 2024 (UTC)
closed given the recent discussion Mgpt (talk) 02:26, 31 January 2024 (UTC)

Trivias without confirmations

Since recent policy change now requiring trivias to have linked confirmations from contributors, there are still many old items that have trivias based on speculations (especially items made by Valve which can't really be confirmed). What should be done with them? User Denied signature.jpg Denied (Talk) 09:07, 30 January 2024 (UTC)

Leave them, we'd have to clear out pretty much most trivia sections otherwise. Unless you find proof of the contrary, just leave them.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 11:02, 30 January 2024 (UTC)
What about this one? A promo item that directly references a game from said promotion, but trivia is about completly different character. User Denied signature.jpg Denied (Talk) 08:06, 31 January 2024 (UTC)
I believe it's a invalid trivia, though changing the name of character and game would be better compare to completely remove the trivia Profiteer the tryhard (talk|contribute) 08:20, 31 January 2024 (UTC)
"It is based on one of the male soldiers' hairstyles in the video game UFO: Enemy Unknown" in the first paragraph. User Denied signature.jpg Denied (Talk) 08:43, 31 January 2024 (UTC)
Yeah my bad, mention it 2 times is kind of surplus just remove it. Profiteer the tryhard (talk|contribute) 09:03, 31 January 2024 (UTC)
Promo items should have their reference stated in the intro, not Trivia. Feel free to remove, it is possible that the Crafty Hair is modelled after hair that is modelled after said character.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 12:24, 31 January 2024 (UTC)

Reports/Missing template translations reporting erroneous data

It seems like a very handy feature (as handy as the entire reports page), and oddly enough, it seems to report the same thing for all languages (34 templates), and according to the quick look I did, none of them report missing translations?
I don't know who would be able to fix this, if it's even broken to begin with, maybe Darkid?
Do note that I didn't touch template translating very much in my time here, I looked up the line numbers using Notepad++. Luno 🪐🌕 Talk / Contributions / Team 03:05, 12 February 2024 (UTC)

For the first result it looks like fr is not declared in the {{Translation switching| line which probably leads to it showing up in that report. I'm going to guess it's the same for all the other ones. Jh34ghu43gu (talk) 03:10, 12 February 2024 (UTC)
I can take a look, thanks for the ping. Darkid « TalkContribs » 03:10, 12 February 2024 (UTC)
Damn, that was as quick as Dustbowl backcap, I sort of expected the "declare thing", but I doubt each of the members would forget to put it in, if that's the issue.
I would also expect hundreds of entries with varying results for every lang, not 34. Luno 🪐🌕 Talk / Contributions / Team 03:24, 12 February 2024 (UTC)
Hmm, looks like I might've screwed up when I changed the regex on Feb 1st (or at least, page history shows a major diff there). Fixing that now, should be corrected tomorrow. Darkid « TalkContribs » 03:59, 12 February 2024 (UTC)
+622,418 bytes coming through, seems about right! Looks like it's working again, thanks Darkid. Luno 🪐🌕 Talk / Contributions / Team 01:52, 13 February 2024 (UTC)

A technical request for "Used by" template

"Localized versions of this template are not necessary." Well, they actually are needed, due to inflection of words in some languages. For Polish, "{{Used by|all}}" and "{{Used by|Soldier|etc.}}" sound fine, but "{{Used by|all-except|" needs translation switching, as it sounds very bad when names of classes are not inflected. I don't know about other languages, but some may require it too. For Polish, here's how it should look to be grammatically correct (only for "{{Used by|all-except|"):

Scout = Skauta
Soldier = Żołnierza
Pyro = Pyro
Demoman = Demomana
Heavy = Grubego
Enginner = Inżyniera
Medic = Medyka
Sniper = Snajpera
Spy = Szpiega

User Denied signature.jpg Denied (Talk) 14:07, 14 February 2024 (UTC)

These requests should really be on the template's talk page instead.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 14:13, 14 February 2024 (UTC)
Thanks. I've moved it there. User Denied signature.jpg Denied (Talk) 08:28, 15 February 2024 (UTC)

Where can I interact with the community?

Is there a discord or something to interact with the community? Thank You.

QS Quark (talk) 13:49, 23 March 2024 (UTC)

You can join the IRC if you want. There is no Discord (and we also won't make one).
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 13:59, 23 March 2024 (UTC)

April fool's?

I've been absent a bit because of health issues lately, sorry, but I noticed there's no April Fools thing this year there? :(--Leaderboard class allclass.png Akolyth (talk) 02:43, 2 April 2024 (UTC)

Probably, yes. Since I didn't notice anything relate to April fools event other than the page itself (normally there will be someone create a April fools sandbox page before April fools event).Profiteer the tryhard (talk|contribute) 03:45, 2 April 2024 (UTC)
The only thing that was planned was a patch, no other efforts were made, unfortunately.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 08:17, 2 April 2024 (UTC)

TFC logo feedback

Hey folks,

We're considering creating a special version of the wiki logo for Classic pages because we think it would add a nice touch. You can check out our current iteration here: logo example.

This logo would only be visible on pages with the "(Classic)" suffix, so it shouldn't affect other types of pages (TF2 and QTF, in particular - we'll of course test it beforehand, similar to our current localized logos test).

But what I'm really here for is to gather feedback. Do you have any strong opinions against it? Maybe a new design in mind? Please let us know! — Tark 14:42, 3 May 2024 (UTC)

Pictogram plus.png  I like it, for obvious reasons. I've been using it myself as a subtitute for the regular logo for a while now, and I've grown quite used to it, so I can personally say that you'll get used to it even if it looks a bit odd from the start.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 14:45, 3 May 2024 (UTC)
Pictogram plus.png  I like it too, I feel like it adds to the fact that this is the Team Fortress wiki, not just the Team Fortress 2 wiki, in a way. Personally, I don't think I would have any negative opinions against it, since a lot of times you're focused more on an article than the top left corner of the screen. Either way, I feel like it's a welcome, if small, touch to the wiki. ♡ JupiterSphere ♡ ( ◡‿◡ *) ⊱✿⊰ Talk To Me! ⊱✿⊰ 14:51, 3 May 2024 (UTC)
Pictogram plus.png  Mediarch User Mediarch PFP.pngTalkMy Edits 17:02, 3 May 2024 (UTC)
I see no issues with the logo.
CheddarTalk 19:44, 3 May 2024 (UTC)
I've enabled the logo for logged-in users. Please let me know if you find any issues.
If everything goes smoothly, I plan to push it sometime in July, along with translations. — Tark 21:06, 9 May 2024 (UTC)

Zombies,Saxton, and V-Script Classes

(if it doesn’t appear, this is signed by Deluxe Fortress, Saturday May 18 2024) (Skip first paragraph to skip the bone and directly to the meat) In the official Zombie Infection game mode, the classes don’t act the same as zombies. They act slightly or completely different from what they were or are from abilities to their role in the team. This ranges from exaggerating their features (such as scout, who has even less health for holy speed) to heavy and engineer (heavy becoming a building buster; engineer becoming a building buster ) and have different stats alongside their main abilities, mainly the (almost) universal 25+ max health increase. They each act very differently and uniquely compared to their human counterparts.

So my suggestion is to make 9 pages for each of the zombie once mercenaries because of how differently they act and what makes them tick. This is a bit much and a bit of points can be bounced back and forth if this is reasonable or not. I can see the point I made first, zombies should have their own pages because of how differently they act. But then again, listing all the stats and finding a zi_ Zombie image that can be turned a full 360• will be extremely tedious. However, same can be said for the first basic human 9 classes.

If the first point is made or not, I’d like to bring up the rest of V-Script and VSH. Saxton Hale, though taking heavy as a place holder, is 100% not heavy, he is Saxton Hale. So should he get his own page separate from the Comic Illustration page and striped directly from the VSH page to have his own page? It’d be easier for navigating and the Disambiguation page would have to be updated, but I can see it being better as its own page so details like Hammer Units Per Blank can be listed and trivia can be separated and therefor shortened if needed. This would require more work, but I think this is more important than the zombies since he’s basically the 11th class.

My 3rd point is community maps. Certain maps like Crasher and CP_Carrier have the classes be drastically different and could have their own page, but is definitely not necessary in my eyes.

My final point is if we get a new gamemode or map that introduces a new class,mechanic,items, or maybe Ms. Pauling in the future illustrated in VSH, do they deserve their own page (or fuse pages, as I could see the comic and gameplay version being fused), get their own content pages?

Thank you for reading, sorry it was long, from Deluxe Fortress DeluxeFortress (talk) 03:14, 19 May 2024 (UTC)

Just asking, anyone know how to get to the point faster? I kinda need that skill right now and the Goliath of text above me kinda concerns me cause I don’t want to put a dang TDA about what an optimal mask is and why it says that on pyros “nose”, and suggestions are appreciated, ty DeluxeFortress (talk) 04:18, 19 May 2024 (UTC)
Pictogram minus.png  I don't think this is a good idea, as game mode-specific info should be on the game mode itself. On the game mode articles right now it's already adequately covered and there isn't nearly as much information on these classes as there is on the regular classes. Regular classes have many unique weapons, unique personalities, many cosmetics, an associated storyline, unique gameplay aspects, etc. For the Zombie classes they would purely be a description of their abilities and the shared universal changes. Looking at the table on Zombie Infection, this would amount to an article that's taken up more by pictures than by actual information.
As for Saxton Hale, he would have a bit more information but it would largely be Saxton Hale with the information from Versus Saxton Hale merged into a single section. I don't think merging the articles is a good idea, personally.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 10:01, 19 May 2024 (UTC)
I can fully see your point, I don’t have anything to say after that, but I still want other people to reply so I can see everyone’s opinions. Thank you GrampaSwood.
DeluxeFortress (talk) 18:10, 19 May 2024 (UTC)
Pictogram minus.png  I also agree with what GrampaSwood said. I think the specific stats and what makes them tick seems to be covered in the main Zombie infection page. Anything not mentioned in the Zombie infection page could be covered in a little more detail in the Community Zombie Infection strategy page. I think it's better to keep all the gamemode specific information concentrated instead of spreading it out across a bunch of seperate pages that wouldn't have a ton of detail to go over. Same thoughts apply to Saxton Hale. Mediarch User Mediarch PFP.pngTalkMy Edits 18:31, 19 May 2024 (UTC)
Remember to indent your replies with :, and also to add your signature after your message rather than before.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 18:13, 19 May 2024 (UTC)
I’m still new to this, thank you regardless and have a good morning, or evening, or night I don’t know your time zone. DeluxeFortress (talk) 18:33, 19 May 2024 (UTC)
To Mediarch, I couldn’t see your reply because of internet issues so here I am now. I completely did not think about the strategy pages, I just remembered those as the competitive players haven. Thank you, and also, should the Editing:Style apply to comments, replies, etc? What I mean by that is “lol,ty,r u ok”..etc in replies like these?
DeluxeFortress (talk) 18:40, 19 May 2024 (UTC)
No, the style guides don't apply to the discussions, you can write however you want as long as you remain friendly. See Help:Discussion for the guidelines instead.
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 18:44, 19 May 2024 (UTC)
Thank you (for the third time today), I have now read Help:Discussion and I’ll look into the help pages for answers instead of discussion. Seriously cannot thank you enough today

Dell (talk) 19:21, 19 May 2024 (UTC)

Homewrecker and The Zombie Engineer

In Zombie Infection, the Engineer has the ability to throw and EMP grenade that can disable Sentries to help his team push through human defenses. However, the Homewrecker and the Neon Annihilator can destroy Sappers. So can the 2 melees destroy the Engineer’s grenades or is the Homewrecker a direct downgrade in Zombie Infection as no Spies can use the Sapper? The main reason I’m asking this is because I was going to add a strategy for the Neon and I didn’t want to edit the main strategy I was going to put and have to put the possible destroying grenades mechanic after, where I’d be going back to the edit I just made and changing it to add another. To put in simple terms, I’ve 2 strategies for a weapon, I know I can put 1, but not the other, so I went here to see if anyone knew the answer to this question here. I’m guessing “probably not”, but I don’t want to fully shut down the possibility and have to edit an edit which I learned was unfavorable. Sorry this was long. Dell (talk) 00:01, 22 May 2024 (UTC)

Seeing as the EMP Grenade is not a Sapper, it's safe to assume they can't be used to destroy it. Also, be careful with spaces in front of talk page entries, as they put the whole thing in a box with may mess with formatting (e.g. indents can't be used).
BLU Wiki Cap.png | s | GrampaSwood Praise the Sun! (talk) (contribs) 10:18, 22 May 2024 (UTC)

#savetf2

Deer wiki admins. there is a petition going around supporting #savetf2 on the website save.tf. I think this wiki should support this petition by advertising the site on the main page I think this would help the petition a lot and by proxy help TF2 in general a lot so if the admins (or whoever edits the main page) were to do so I would be very happy. Yours truly Manman24 (talk) 00:44, 31 May 2024 (UTC)

I feel as though this isn't neccessary. Whilst it is a nice sentiment, it doesn't really have a place in the wiki. Specifically, not promoted at the Main Page, or anything that is high traffic. What you can do, however, is promote it on your userpage to show your support! Cheers — jestie. Beggar's Bazooka.png Talk Speech voice.png 02:33, 31 May 2024 (UTC)
Hello! We appreciate the invitation, but participating in this petition as a group goes against our Community engagement policy. That said, all wiki members are free to support community activities personally, as long as it doesn't imply official endorsement from the wiki.
Thank you for understanding. — Tark 03:23, 31 May 2024 (UTC)