Team Fortress Wiki:Discussion

create a new section

Scout taunt voice lines in engi's page?

so i was browsing the engineer taunts and found scout voice lines for most of the new taunts, if anyone know's how to fix this please do — The preceding unsigned comment was added by Sir scumbag (talk) • (contribs)

This discussion page isn't the right place to ask about this. Go to the Engineer Taunt's discussion page instead. If its technical issues, then try elsewhere. Thanks. Ashes (talk) 12:12, 10 July 2014 (PDT)

Responsive Wiki

Hi guys, after many edit spams i finally have it going properly and the full wiki functions with it Responsive wiki page.

Mess around and resize your browser, it will not break (at least to know knowledge).

so, what are your thoughts? - Lexar - talk 08:08, 14 July 2014 (PDT)

It's nice, however, I think the Full Moon icon should be centered and with a space between the Moon Status (The Moon Status centered as well). And the latest wiki caps awarded, make the users have a link to their userpages. Other than that, it's great. ▪ - 08:35, 14 July 2014 (PDT)

Items' original names, etc. and trivia

here instead of Help talk:Style guide/Trivia for greater exposure For a while now, trivia relating to items' original names, Workshop descriptions, and such have been deemed as not being notable. I'm personally for these being considered valid trivia, and I'm not sure where this convention (which isn't even noted in the trivia guidelines!) came from. The original names of community-contributed items are even mentioned in the main section of the articles, and it would only make sense to include explanations for the possible references included. I don't think I'm not the only one with this opinion. Due to how this isn't even mentioned in the trivia guidelines or never being properly discussed, confusion is further created about the notability of trivia like this. Due to the things I mentioned, I thought it's finally time to form a concrete guideline relating to this.

tl;dr: Is trivia relating to the original, now unofficial details of the item notable? Why? Why not? (contribs ▪ talk) 10:17, 14 July 2014 (PDT)

 Support - I agree, some items have only its creation due the name or the thing it was based on. In fact, some pages have the original names as a trivia, like the Falconer. ▪ - 10:27, 14 July 2014 (PDT)

I covered this over on the IRC somewhat, but I'll restate it here for everyone else. I think that original names would be pretty relevant to include, seeing as they are noted on the page. I'm not so sure about including descriptions, unless the information backs up other trivia regarding the item or item name (like with the Combustible Kabuto, the description references KLK, which the item's design does as well). In regards to sets, that's a lot more awkward. It fits with some items to include the trivia, such as with the Peacenik's Ponytail/Texas Tech-hand, due to the fact that the set was included ingame, but one of the items wasn't included in the set (for obvious reasons). I'm not sure that it's particularly interesting trivia to just say that "These items were contributed as part of this set, but they weren't marked as a set ingame", considering that the pages would already cover whether or not the item is in a set. Additionally, I think I've seen some items that are just put into collections on the workshop because of similar themes or something similar, even though the items wouldn't actually work as a set ingame. --Omolong (talk) 10:35, 14 July 2014 (PDT)

 Support I don't see any reason why this king of trivia can't be included.

Side question: do we need to translate workshop item/item set names for other languages? Maybe, just add translation in brackets alongside with the original name; I can't find anything about this in guidelines. Irvitzer (talk) 14:51, 14 July 2014 (PDT)

weapon demonstration

can i reserve a demonstration on the classic = an i am new to the wiki — The preceding unsigned comment was added by Cmj2003 (talk) • (contribs)

Please go to the weapon demonstration discussion page to reserve weapon demonstrations. This discussion page isn't for that. Ashes (talk) 12:59, 22 July 2014 (PDT)

Released inconsistency

It is all about the {{Item infobox template!
Shown in the item infobox: | released = issue
In the articles, by whoever wants to, there is added a link to a major update or the patch date. I find it confusing that it is not clear what is entered there.
The official documentation says:
When the item was released. Basic text parameter. Not displayed unless defined specifically.
So which is it:
1. Released: Mann vs. Machine Update
2. Released: August 15, 2012 Patch
?
Thanks for any help & informations. Magicalpony (talk) 06:56, 30 July 2014 (PDT)

I prefer Released: Mann vs. Machine Update since I feel more connected to major updates; when I read a specific date that was two years ago I don't think I can remember what happenend back then.

However, this will make the item infobox a little bit more inconsistent than just writing the date everywhere. SackZement <Talk> 07:03, 30 July 2014 (PDT)

It would make it a lot more consistent with pages in general if it noted the patch date rather than the update name, yeah. The update name should be listed in the main description and the Update history (at the very least) as well, so it's not like the actual update associated with it wouldn't be visible at the top of the page, if the patch date was in the infobox. In contrast, if the update name is in the infobox, it would mean that the patch date is only listed in the Update history, which can be a hassle to scroll down to if you just want to find out the date an item came out (for example, if an item has four styles that are all paintable, you'd have to scroll past all of the tables for the painted variants to get to that info). --Omolong (talk) 07:30, 30 July 2014 (PDT)

Sounds reasonable, but sometimes the update name is not listed in the main description (and sometimes not even in the update history) and you have to scroll down to the update history aswell. Can't we have both in the item infobox like in most patch notes (June 23, 2011 Patch (Über Update))? Give it a line break between the patch date and the patch name and the item infobox will still look smooth. SackZement <Talk> 04:45, 31 July 2014 (PDT)

It'd probably be a good idea to make sure that all pages do have the update name in the description and the update history at some point. That idea about putting them both in the infobox could work, though. It would just depend on how it actually looked when put on the page. It could be the best solution, really. --Omolong (talk) 07:32, 31 July 2014 (PDT)

Preview here, feel free to edit at will. I tend to the version with the line break. The one in one line (last one, with nowrap) might be the best as long as it still fits in the infobox, which will be not the case for third community weapon update or something. SackZement <Talk> 08:34, 31 July 2014 (PDT)

I think the first one is best there, really. I think it'd be more consistent if the update names were all on a separate line underneath the patch date, rather than some of them being on the same line, some of them being on a separate line, and some having to wrap from the patch date line to the second line. So yeah, the one with the line break looks best to me. Might be worth getting some staff input on this before we go ahead with changing any pages for it, though. --Omolong (talk) 08:43, 31 July 2014 (PDT)

 Support the version with a line break. (contribs ▪ talk) 09:14, 31 July 2014 (PDT)

 Support SackZement's version with a line break. — Wind 15:24, 3 August 2014 (PDT)

 Done - The pages have been edited to follow SackZement's consistency version. However, item set pages weren't edited due the infobox works differently than the normal item pages. ▪ - 13:03, 19 December 2014 (PST)

 Done - Item sets are all done. ▪ - 06:23, 21 December 2014 (PST)

Availability template(?)

It is all about the {{Item infobox template!
Issue: Availability
Every language needs to update after an update. Simply: Copy over the english information in the other languages (hats/weapons/others). Wouldnt it be more efficient if the info is stored in one place (like th dictionary) and it is automaticly applied for the other languages. I find it inefficient how it is done at the time.
The official documentation says:
The means of obtaining the item. Basic text parameter. Not displayed unless defined specifically.
I think this is outdated and should be thought over at least once.
Thanks for any help & informations. Magicalpony (talk) 06:56, 30 July 2014 (PDT)

This could be a good idea. It would mean that you'd only have to make one edit to update all of the language pages for a single item. It would also make it easier to update a bunch of items from one update that need a new availability (like the Love & War cosmetics being updated to show that they can be received in drops), rather than having to edit every single item and all of their language pages. Something like Template:QuAD could work, but I'd have no idea how to implement it. --Omolong (talk) 07:30, 30 July 2014 (PDT)

While this could be implemented with relative ease using a dictionary, I personally don't think it's required as those strings would only have one very niche use. The manual updating works just fine, I think. (contribs ▪ talk) 09:23, 31 July 2014 (PDT)

This sounds like {{Dictionary/quad}} — Wind 15:24, 3 August 2014 (PDT)

How much strategy in Maps articles?

Due the recent activity on Gorge & 2Fort i asked myself: How much is really a map description and what is in the direct area of strategy?
The Style guide for maps doesnt reveal any significant information about the matter.
Text like: "...often sniper lurk there" or "often a sentry gun is there" are valid information about how to decribe a map? Or should it only be in the community strategy article of a map? Relevant example link: Gorge ; cleanup needed? Magicalpony (talk) 21:13, 11 August 2014 (PDT)

I think stating common spots is not really "strategy" and as long as it's not overused it can actually help to describe (the playstyle of) the map.SackZement <Talk> 02:09, 12 August 2014 (PDT)

Have to agree with SackZement here - the likes of Snipers on the balcony of 2Fort isn't just strategy, but a key map feature present in virtually all games. » Cooper Kid (blether) • (contreebs) 08:24, 12 August 2014 (PDT)

MediaWiki extensions

Is there any plan to introduce MediaWiki extensions such as Mobile Web (Mobile Frontend) or the Visual Editor? Canis (talk) 00:59, 25 September 2014 (PDT)

Craft No. for limited item

New things out of the box are #86 Limited Quantity and can not be bought or craft, I think you need to write NO — The preceding unsigned comment was added by Leonaz (talk) • (contribs)

They're marked as having craft numbers in the schema. Almost all items added to the game this year have been marked as craftable, even if they're not craftable at the time of release, like the Strongbox items. --Omolong (talk) 05:40, 27 September 2014 (PDT)

Leonaz (talk) 06:02, 27 September 2014 (PDT)So you can fix to the NO? — The preceding unsigned comment was added by Leonaz (talk) • (contribs)

It should be marked as yes. An item being craftable and an item having craft numbers are two separate settings in the schema. All of the new cosmetics have craft numbers, and as such, the infobox should state yes for that section. --Omolong (talk) 05:45, 27 September 2014 (PDT)

Leonaz (talk) 06:02, 27 September 2014 (PDT)But they can not be craft or found so it can not get my room forging — The preceding unsigned comment was added by Leonaz (talk) • (contribs)

That is irrelevant to if they have craft numbers. As I said, being craftable and having craft numbers are two separate settings. Also, you should sign your posts with four ~. --Omolong (talk) 05:52, 27 September 2014 (PDT)

Merging Availability and Dictionary/Quad

These both contain the same information, except that quad contains the end quality. Would it be worth the effort to change {{Avail}} to pull information from quad instead? Darkid (Talk | Contribs) 13:37, 1 October 2014 (PDT)

Edit: This change would likely be chainging {{Quad/list}} to add a parameter to put out a different style of info, namely the style that avail uses. Darkid (Talk | Contribs) 22:17, 1 October 2014 (PDT)

Scream Fortress 2014 or Scream Fortress VI?

The page naming for the past Halloween Specials have been remarkably inconsistent. They're either using the title from the Update pages or using the one in the patch notes.

Haunted Hallowe'en Special aka Haunted Hallowe'en Special (2009)

• No patch note title.

Scream Fortress Update aka Second Annu-Hell Scream Fortress Hauntdead Halloween Special

• Patch Note: *Halloween 2010 Event*

Very Scary Halloween Special

• Patch Note: *Halloween 2011 Event*

Spectral Halloween Special

• Patch Note: *Scream Fortress Event 2012*

Scream Fortress Fifth Annual Helloween Special

• Uses patch note title: Scream Fortress 2013

Scream Fortress Sixth Annual Halloween Special

• Patch note: Scream Fortress VI

Half of the pages use some variation of Scream Fortress and the other half uses the update page title.

19:44, 29 October 2014 (PDT)

I've been using Scream Fortress 2014 to keep it consistent with Scream Fortress 2013. The two of them don't have any special name like the previous years do, and it's pretty unwieldy to have it listed as "Scream Fortress Fifth/Sixth Annual Halloween Special". I'd rather use Scream Fortress 2014 instead of Scream Fortress VI for consistency with last year's event. --Omolong (talk) 19:48, 29 October 2014 (PDT)

Seconded, will create templates with these names. Darkid (Talk | Contribs) 06:00, 30 October 2014 (PDT)

2013 actually did have a name: the Helloween Special. VinLAURiA (talk) 17:28, 8 November 2014 (PST)

Unlocked Creepy Crates

Where should they be put? They're named crates, but they don't share the same mechanic as classic crates, since they don't need any key. In this regard, they're more like others "Crate like items". They're also only obtainable through purchasing them on the store. I believe they should get their own page since they're a new system. Just wanted to ask before doing something like that.

Sk8er Of Bodom (talk) 17:44, 30 October 2014 (PDT)

They're still crates, and they don't have a series, so I've been working on them going in Mann Co. Supply Crate/Seriesless crates. --Omolong (talk) 17:46, 30 October 2014 (PDT)

Still doesn't feel right to me. They are even considered as an action slot item by the game. If they are only new seriesless crates, then what's the difference between these and for example the Halloween Goodie Cauldron or Halloween Gift Cauldron? Or the Mann Co. Painting Set? Or all these items in the Crate like items category? Is it just because they actually look like crates and have "crate" in their name? Sk8er Of Bodom (talk) 18:39, 30 October 2014 (PDT)

Thought I responded to this, whoops. Anyway, it might be a good idea to try and get some opinions from other people about this. I think it's better for them to go with crates as it makes them less confusing to look for, seeing as they do look like crates and are called crates. Other people might have different reasons to agree or disagree, so getting their opinions (if possible) could help us come to a proper solution for this. --Omolong (talk) 21:34, 31 October 2014 (PDT)

I would say categorize them under crates. If you look at the Dota 2 system regarding crates or in their case "Treasures" They're still the same as any other treasure before they removed the key system. This is sort of like that. Still a crate just without a key. So no matter how you look at it, its still a crate, you just spend less for the key. Ashes (talk) 10:57, 2 November 2014 (PST)

Update on the wiki mobile (Its a decent menu!)

Been a while I know but i have made some progress here.

any ideas to what you would like to be changed? - Lexar - talk 21:17, 1 November 2014 (PDT)

This is almost functionally complete (yay), but stylistically not (boo). Here's what I think:

• The top-left menu icon doesn't look really like one. It looks very flat and the lines are a bit too fat and wide to be menu-like.
• The menu items aren't differentiated between those that expand and those that don't. It's also not immediately obvious that they're expandable in the first place.
• The menu sub-links are larger in font size than the name of the menu they're in.
• It'd help to have the rest of the page shown in the example, to see how it fits the rest of the page. As-is, I think (imaging the page being there) that it would appear too flat compared to the gradienty/dropshadow-ness that the rest of the page uses.
• If possible, make the two page menus separated like they are in mediawiki (page + discuss on one side, read/edit/history/etc on the other). If not differently-aligned, at least put some separator in the middle to make it clear that they're two different sets of switches.
• Animations would be nice, similar to how there's animations on the wiki sidebar items.
• Where would account information/notifications appear, or the login/register link when logged out?

This sounds like a bunch of complaints but they're all stylistic besides the last one, so yay for ze sound of progress~ — Wind 21:48, 1 November 2014 (PDT)

Thanks Wind,

I hope I understood your points correctly. to see the new one you have to have your browsers viewport at 850 or less (and i know i didn't put the wiki content in there, please forgive). I have made changes here.

complete with little animations and everything.

- Lexar - talk 01:01, 2 November 2014 (PST)

This is really great progress in such a short time.

Still some complaints:

• Need to see it with the page content. This is both to see if it matches stylistically but also to see the transition between modes when the window is resized.
• Menu button still doesn't look like a menu. The lines are too thick and too long. Maybe it could be made into a really obvious button by making it look like

A real buttonA real button with the 3 little lines inside.

• Can you show examples when logged in, and with notifications?
• Have you tried playing with TF2 fonts? No need to use them if they look bad, but if they look OK it might be worth using them, much like they are used for tab names on the current skin.

Yay progress — Wind 01:19, 2 November 2014 (PST)

Thanks, I have worked on these points as best as i could. you should be able to see the menu implemented here, I MAY have to work on the account notification bit, it looks fine, but doesn't really have a defining look to it. Please tell me how you wish the account bit to look with a logged in user and it will be done =D - Lexar - talk 06:47, 2 November 2014 (PST)

Feels pretty great to see it on a real page.

• Need preloading of all resources. This includes the hovered version of the menu button, the hovered version of the search bar toggle button, and the "reversed" version of the search bar toggle button. I advise against putting them as separate images and insert them in a hidden div to preload them. Instead put them inside the same image as the existing version (non-hovered menu button, search bar toggle button) and use the background-position trick, similar to how the dropdown works or how {{TF button}} works. This way, either the element is fully loaded and works 100%, or it isn't loaded at all. There is no intermediate state where only one of the states has loaded.
• The account Soldier picture throws off text alignment This wasn't very noticeable with the non-TF2 font, but now it is noticeable.
• If you set your viewport narrow and refresh the page, the desktop skin appears for a while before the page has finished loading, and then there's a sudden jump when the menu activates. I assume that this is because it's JavaScript doing the "hey this page has a custom Page.css and I should load this now" late into the page load, and that this won't be the case when the CSS @media rules are part of the site's CSS proper.
• Please convert the JavaScript code to a self-contained object under a single variable, similar to almost everything on MediaWiki:Common.js past the "Collapsible tables" section.
• Can the "Log out" link be right-aligned to separate it from the others? (Optional, I just think it'd look nicer)
• I think we could still use some things to make the menu look nicer (especially the sidebar one as it's kind of bland), but I have no specific suggestions. I think the rest of the staff may have some when they take a look at this though, so hopefully there'll be some actionable items out of that

— Wind 14:07, 2 November 2014 (PST)

Rjackson suggested we should not have it looking like a button but instead just leave it being 3 plain while lines on the normal background.

In Rjacksons words "call WindPower a "poopy mc poop head"" as "everybody knows three horizontal lines = menu button"

No idea how it should go but maybe there should be a small discussion on its own about this particular point. - Lexar - talk 04:31, 3 November 2014 (PST)

  Overall: I really like the design, it feels and looks good. Nothing more to say, I think.

  Menu button: I'm rather neutral about this, I like both variants. It'd be also possible to use just the three lines, but distinguish them from the rest of the top bar by adding a darker background.

{ TidB | t | c | wt } 14:09, 3 November 2014 (PST)

Languages sidebar on TFW: and Help: namespaces

{{Mw-langlink}}, which generates the sidebar "Languages" section, currently excludes the Team Fortress Wiki and Help namespaces. This means that pages like Help:Colors/ja do not have appropriate language links on the sidebar. I see two options:

1. Encourage translation of pages within these namespaces, and enable this template in these namespaces
2. Discourage translations of these pages, remove the few that are translated, and leave the template as it is.

Thoughts? Darkid (Talk | Contribs) 15:37, 10 November 2014 (PST)

Mentioning item names too often

Hai, I think we need to mention item names less often. It just came to my mind when I saw Gabriel's recent edits like this and that. Personally, I think this is unnecessary and bloats the page. If we continue using "this item" or something similar, it'd still be clear what item is meant without citing the full name again. I have to admit, I've always used the full item name until now, but I think it's time to change this. Some areas that might need changing include the promotional sentence ("was given to player who pre-ordered"), the community sentence ("was contributed to the Steam Workshop") and the thumbnails ("Steam Workshop thumbnail for the"). I'd like to hear some opinions about it.
{ TidB | t | c | wt } 05:37, 16 November 2014 (PST)

 Neutral A wiki should be a place for unambiguous information which is guaranteed by repeating the item name. However, I neither think writing "this item" would hurt too much, nor think changing it is worth the effort or improves the flow of reading. SackZement <Talk> 02:28, 12 December 2014 (PST)

Alrighty, I'll create German pages with "this item" and the like from now on and leave the rest untouched for now. { TidB | t | c | wt } 06:31, 12 December 2014 (PST)

New Pants Page?

We're starting to get a lot of pants items now with the EOTL update coming out. Should we make a new disambiguation page leading to pants in general? Bruss48 _{(T | C)} 15:47, 11 December 2014 (PST)

Game mode goals

Many of the map articles have a paragraph that describes the goal of the map. For example, Capture the Flag maps have "The goal of the map is to capture the Intelligence three times, while preventing the enemy from doing the same." I think these descriptions are unnecessary and redundant - the goal is already described in the game mode article, and it should be removed from the map article.

However, the description should remain for maps where the goal is different than other maps of the same game mode. For example, Mountain Lab has three successive control points, compared to the usual two on an Attack/Defend map or the five on a Symmetric map. In this case, it would be useful to have the description in the article.

What do you think? Doktor (talk) 21:45, 28 December 2014 (PST)

What happened to the wiki?

There is no more custom theme, but only basic Vector ! Nicolapps 10:15, 10 January 2015 (PST)

Everything is back to normal. I do not know what could this happen. I screenshots in case. Nicolapps 10:20, 10 January 2015 (PST)

Extension:Translate

Mediawiki version 1.24 introduces Extension:Translate, a different way of handling language translation. The primary benefits to this wiki are:

1. Shared content across pages. We currently use a dictionary along with various other templates to accomplish this.
2. Automatic translation linking. We currently use the sidebar, which has some bugs as this is not a standard usage.
3. Flagging outdated translations. This is currently not done.
4. Various statistics (currently compiled by WindBOT, through templates, or by scripts).

The cost to usual editors is this: English pages would have <translate>tags around</translate> text that needed translation. These strings appear to translators for the edit page in another language. Thus, we would have to split our translations into these strings.
The benefit to usual editors is this: Templates and possibly other parts of the pages could be synchronized more easily between languages. It is clearer to translators when a page is outdated. More work done by translators would be re-used.
The benefit to more casual readers is the "quality of translation" links, which indicate if a translation is out of date or incomplete.
Answers to a few concerns I had:

• This extension will not break any pages we currently have. The software only takes control when it finds <translate> tags.
• This extension uses the same language scheme. Pages are linked via slash (Main Page/es), rather than the wikia standard of colon (es:Main Page).

I would  Support this extension (and MediaWiki upgrade) being tested and slowly introduced. Darkid (Talk | Contribs) 08:17, 27 January 2015 (PST)

 Neutral Sounded like the main benefit that is currently not solved in another way (windbot etc.) is finding out of date translations, but I guess articles are out of date because translators do not have the time to keep them updated instead of not knowing which articles should be redone?

The software only takes control when it finds <translate> tags. This sounds good.

this extension (and MediaWiki upgrade) being tested and slowly introduced. This is a very important part. SackZement <Talk> 02:16, 28 January 2015 (PST)

 Why not ? Nicolapps 12:49, 28 January 2015 (PST)