User talk:WindPower

Weapons/hats checklist

I was wondering what is the template for the weapons/hats checklist auto update. Could you post it to my talk page please? Thank you. Thespy 01:34, 15 February 2011 (UTC)

Is right here~ — Wind 02:04, 15 February 2011 (UTC)

Do I need to put both templates on the page or just one? Thespy 00:29, 16 February 2011 (UTC)

What other template? — Wind 00:32, 16 February 2011 (UTC)

It ees done. —Moussekateer·talk 00:32, 16 February 2011 (UTC)

{{Item checklist | steamid = YourSteamIDHere this and : WindBOT/Item checklists/YourWikiUsername this Thespy 00:50, 16 February 2011 (UTC)

As the page says, you just have to put the latter. — Wind 00:52, 16 February 2011 (UTC)

Wrong Bot Edit

Heya Wind! Hows it going?

Please disable that your Bot keeps doing this to the Steak and the Saw. Thanks Dani 08:26, 15 February 2011 (UTC)

Done — Wind 20:07, 15 February 2011 (UTC)

Pictures

Greetings Wind. My question is – Does wikipedia need any self maded pictures for something? I can draw if it is necessary. Rins (talk | contribs) 06:43, 16 February 2011 (UTC)

This is a wiki, but this is not "wikipedia". Wikipedia is this, Team Fortress Wiki is this. And no, I don't think we need self-made pictures. We do need some improvements to certain images; you can see the list of images that need to be improved here. The thing that needs to be improved is on each image's page — Wind 13:17, 16 February 2011 (UTC)

Saxton Hale Responses

And one more question. I wanna create SaxtonHale_responses page with all his new sounds ( i will upload them ) and all Text phrases. Dr.Eggman told me that all this sounds and phrases are part of mode. You allow me to make it? Rins (talk | contribs) 13:00, 16 February 2011 (UTC)

First, unless the list is really huge, I don't think it needs its own page; just put them on the Saxton Hale mod page. But second, please wait for someone who plays that mod regularly to confirm it — Wind 13:17, 16 February 2011 (UTC)

Ok i will wait here. Rins (talk | contribs) 14:12, 16 February 2011 (UTC) Saxton now have 36 sounds and phrases. U sure that this will fit on mode page? Rins (talk | contribs) 16:44, 16 February 2011 (UTC)

I was speaking with Wind about this just now and I have let him know that the sound additions were indeed a very large and obvious addition to the mod. You're welcome to create the page at:

• http://wiki.teamfortress.com/wiki/VS_Saxton_Hale_Mode/Saxton_responses

Try and mimic the layout of pages like:

• http://wiki.teamfortress.com/wiki/Soldier_responses

Let me know if you need any help with the content. -- Benjamoose (talk | contribs) 20:53, 16 February 2011 (UTC)

Thanks good. Ill start then right now. Nope dont need help :] as admin of Main Hale server i have all i need, and also already done some responses pages for russian ppl :] Btw i already created question in discussion page but i repeat here: Ok main problem in our /ru responses pages that we didnt have alot of sounds in wiki base. There are divergences in transfers and official russian sounds. So my question is: Can i upload official missing(russian) sounds and then use them to re-edit pages? Rins (talk | contribs) 11:31, 17 February 2011 (UTC)

"INCOMIIIING!" or "Can WindBot defeat the dreaded AR-REDIRECTS? Find out on the next episode of Wind Bot Z."

The redirects are ready. The List Alsoodani 22:19, 16 February 2011 (UTC)

Hat Tab Concept

Greetings, Windy One. Do you remember that funky animated Class tab Navbox that was posted in the main discussion page on 27 January? Well, I was tinkering around with the same code (which I blatantly appropriated without permission) and basically cut it down to only include the headwear and Misc items for each class. It seems much more streamlined now, and I find the current Hat table to be rather unwieldy in some respects. Anyway, I still need to tweak the placement of some entries as I would prefer that they align (namely Dr's Dapper Topper and the Old Guadalajara), but you can view the concept here. As before, only the Scout, Soldier, Pyro and Demoman tabs are active. Any thoughts? Is this a project worth pursuing for any other reason than to practice my skills (if they can so be called)? Hmm, hopefully nobody else has already done this... Esquilax 00:54, 18 February 2011 (UTC)

You should synchronize yourself with Wintergreen in order to merge both. — Wind 01:34, 18 February 2011 (UTC)

Very well, I shall post a message on his/her Talk page. Esquilax 01:37, 18 February 2011 (UTC)

2du

• {{VerticalTabs}} show/hide thing.
• {{Item availability}} implementation – on hold pending consultation with everyone over the use of 'Unlock', 'Craft' distinctions everywhere on pages (concerns this template because of Unlock's ambiguity).

seb26 [talk] 05:49, 19 February 2011 (UTC)

VerticalTabs bug

It doesn't seem to play nice with child {{Navbox}}es.

A child Navbox places a at the beginning to close the blank div started by the list param inside the parent navbox.

Example:

hi

hai

And as stated, when used inside a parent Navbox, the parent will eat up the div and fit the whole thing inside nicely:

The trouble comes when you try to use this inside VerticalTabs:

The table is put inside eventually, but under the name of the next tab. A better example is at {{All class nav/sandbox}} which is where I discovered it; Scout content appears under Soldier, Soldier content appears under Heavy, etc.

I have an idea of how to fix this internally within {{Navbox}} and its siblings but I'm posting this here as well in case there's a solution that can be made at the script level.

seb26 [talk] 10:22, 19 February 2011 (UTC)

Implemented all show/hide thing and fixed height bug. As for the NavBox thing, no, I don't believe there's a solution at the script level. Having a template start by placing a closing </div> is pretty hacky if you ask me, so I think that even if there was a script-level fix, it shouldn't be done there D: — Wind 08:35, 22 February 2011 (UTC)

Ahem

Not that I'm one to point out the same thing twice, but you spelled "Wikichievement" wrong again on my talk page. "Wkikchievement" became "Wikchievement".

i-ghost hides

i-ghost 13:50, 19 February 2011 (UTC)

Uploading audio files in a language other than English 2: The Return of Sven

Hello again, WindPower. Remember me? The guy who flipped out in the IRC...? Uploaded a lot of Spanish audio files...? No...? Well... I'm back. Again. I see that the "Wanted Files" list is full of Russian this time, and I'd like permission to begin uploading them. We're talking around 800 files here, and I seriously doubt that I'm going to be the only one doing this (unless I am.. then I'd have nearly 1500 contribs), but I might as well get the ball rolling and start. So, permission granted, or should I wait? Sven 18:14, 19 February 2011 (UTC)

Just upload a zip file somewhere where I can directly download it and they'll all go POW — Wind 03:29, 20 February 2011 (UTC)

Most of the wanted files list were because of some old subpages of mine. I've deleted the two pages that were marking them as 'wanted' and the list has been reduced significantly. I filtered through it and made a list of wanted .wav files as well. Sorry. seb26 [talk] 04:01, 20 February 2011 (UTC)

A majority of the Russian library of sounds were on "old subpages?" Geez. Well, this saves me a lot of time, then. Sven 13:55, 20 February 2011 (UTC)

Question about Recent Changes

For some reason, on the Recent Changes, I've noticed some peoples names are colored #0066FF (light blue). Obviously those with green names are Admins, and I know Valve gets like a pinkish-purple colored name. But what's with the light blue? 404 User Not Found 06:54, 21 February 2011 (UTC)

They're "trusted editors" in that they've been around for a while and their edits have been of consistently good quality. It doesn't change their permission in any way, it just changes their names in the RC feed (and on the IRC channel feed). It's not for show, just for moderators to more easily prioritize their moderation — Wind 06:59, 21 February 2011 (UTC)

Weird because my name has showed up as light blue. I did check the CSS just now and noticed ".trusted .mw-userlink". I think the reason my name is showing up as light blue is because of "mw", or what I believe is "My Watchlist". Either that or I've somehow become a Trusted Editor. 404 User Not Found 07:05, 21 February 2011 (UTC)

Well, you're not a trusted editor (no offense) and I don't see you in light blue... I don't see light blue on the lines of edits to pages on my watchlist either, so I don't know. Might be your cache bugging out or your browser not interpreting the CSS right or something o_O Anyway, it's just a visual difference, nothing major — Wind 07:07, 21 February 2011 (UTC)

Well you might wanna see this, then. I agree, it's nothing major, but I think something about the ".trusted .mw-userlink" class in the CSS is screwing up and giving anyone who edits a page on my watchlist the trusted editor color on my Recent Changes. 404 User Not Found 07:12, 21 February 2011 (UTC)

Oh, you're using the improved JavaScript RC page, I see. The script actually looks at each line, sees if there's one of the trusted editors on the line, and if there is, it adds the .trusted class to the whole row. Since the "improved" JS page collapses multiple edits to the same page into one, then any line which has at least one user in the trusted/staff list has all its non-staff users in light blue (by the way, you should use the IRC feed~) — Wind 07:21, 21 February 2011 (UTC)

Indeed, it's a lot faster than a static webpage. GeminiViRiS Talk Contribs 07:25, 21 February 2011 (UTC)

Yeah I figured as much. And I can't be arsed to load up the IRC. It's like, nearly 2:30am, I'm dead-tired and I thought I was seeing things :P 404 User Not Found 07:26, 21 February 2011 (UTC)

SEE?!

Wikichievement	Awarded by	Reason
Bloody Merry Spread happiness on your journey throughout the Team Fortress Wiki.	OluapPlayer	Wikichievement unlocked! Iz fun and nice and homosex. WindPooter is credit to team!

SSSSSSSSSSSSSSSSS. -- OluapPlayer _(t) 23:10, 23 February 2011 (UTC)

FANK YOOO :3 — Wind 23:12, 23 February 2011 (UTC)

This

Can this discussion be finalized? It's been sitting for a while with no opposes and no response for implementation. Toomai Glittershine 03:38, 24 February 2011 (UTC)

There — Wind 03:49, 24 February 2011 (UTC)

Video Demonstration

Hi, can I put this video on the spanish article of halloween? Dio 14:26, 24 February 2011 (UTC)

Sorry mate, but the video (and audio)'s quality is just... no. :( — Wind 16:39, 24 February 2011 (UTC)

Ok, no problem Dio 18:22, 24 February 2011 (UTC)

2du II

• {{Navbar}} integration into VerticalTabs & script.
• Notes on {{All class nav}} deployment: User:Seb26/all_class_nav

seb26 [talk] 05:43, 25 February 2011 (UTC)

Hey Wind

Are you interested to have a userbox template made by me? The Noble Scout 12:48, 26 February 2011 (UTC)

What would that be? — Wind 16:17, 26 February 2011 (UTC)

This user is the almighty WindPower, the original Offensineer.

The Noble Scout 16:58, 26 February 2011 (UTC)

Already there, thanks~ — Wind 17:00, 26 February 2011 (UTC)

Dis writeup

As you've seen I made this spreadsheet and everything and it's really highlighted a few suspicions I had about a lot of things.

The large spikes are quite alarming really, {{all class nav}} raises performance levels from around ~3% to about 20-50% of the site limit. This raise will occur on every instance of the template and considering that it'll replace templates on 8,800 pages, that's 9 out of 10 pages on our wiki, is a huge problem. However, I don't attribute this huge cut in performance to the template itself; instead I believe the problem to be the way we store language strings in {{item name}}.

We really, really, need to find a new, more efficient way to store these strings. I don't think we can just pass this off as a minor issue, because the current system we have now can only expand and expand. Not only do we have more item names to add as time passes and the game is updated, but the use of #switches in a similar way is also increasing; at the moment there's a discussion ongoing at the moment about storing damage values within a switch as well and choosing which ones to display based on the page name. This really will be yet another performance hit for all weapon pages if implemented poorly like item names are. We can't continue to encourage this.

Although in a slightly different way, en.wikipedia has a similar sort of problem at the moment. Due to the widespread use of their string length templates on pages (that are written as well as they can be but are still implemented incredibly inefficiently), some pages take almost 30 seconds to render and display (before ResourceLoader anyway).

So instead of just coming to you with a problem and demanding a solution like I've done other times (:P) I thought I'd do a little research and tinkering around with things.

My basic idea of how a better system would work is similar to one that's already in place inside MediaWiki and is used to display interface messages. Their method is simple; all message strings are stored in a large array in a file and are called up by the software whenever they are needed (yes they appear as individual pages onwiki but I'm unclear about where custom changes are written to because they aren't written to the same script). They are also cached in a special way (the method of which I'm not too familiar with).

The main difference that this has with the current system is that the script simply fetches and prints the value of the given key, as opposed to the template parser system that we have going where, after a series of complicated #switches and #ifs, the decision which parameter input to display is made.

This method would be implemented through an extension. On one page, all language strings would be stored inside an array and the extension would (in no technical terms) simply fetch the value of the given key and display it. Obviously since this function would be run several times on a single page the values would need to be cached (but I'm not really clear about this, so it may also be the downfall to the plan).

If there are concerns about even having the extension implemented, I'm sure that, after the Portal 2 release, if we propose to Jeff & whatnot the serious benefits this would have over the current way of doing things and also present him a completed, stable release then it can really only seal the deal IMO.

/end megapost seb26 06:37, 1 March 2011

There are multiple ways to approach the problem. First, let me try and sum up the "slow points" of the current process:

• The item names are stored in a template, which involves parsing the template's code (slow)
• The item names are stored in a template, which involves doing the switch and stuff (slowish)
• The item names are stored in a template (again), which involves having to fetch it from the database (slow)

Those three "slow points" can each be addressed. However, each approach I can think of has its limitations. Here they are:

• Storing the string mapping in a database: This would be really, really fast (no need to parse anything, and no need to do a long search if we use an index on the table). This is the best solution and would be the one that would get implemented, if we had control over the server. However, it probably will not happen in our case.
• Storing the strings as a PHP array in a file on the web server's disk: This would also be quite fast, because instead of using MediaWiki's parser (which itself runs within PHP's parser), we would directly be using PHP's parser, which would make the parsing part much faster. However, this involves having access to the disk, or at least having a way to write a PHP array to the disk.
• Storing the strings as a PHP array in a "hidden" wiki page: This would also alleviate the need for running a parser-in-a-parser (same advantage as previous solution), but we would have to pay the roundtrip-to-database cost again (to fetch the template's code from the database). This is the closest solution to what is being used now, and it would be quite easy to update, as it'd simply involve changing a wiki page.

Now, TF2 gets updated constantly, and translations change over time; all of this is natural, I guess. Thus, no matter the solution, we not only have to consider the speed problem but also how can we maintain it. However, all of these solutions have a big problem when it comes to this.

• Storing the string mapping in a database: Updating this would obviously involve database access, which we are not likely to get
• Storing the strings as a PHP array in a "hidden" wiki page / Storing the strings as a PHP array in a "hidden" wiki page: The first oen involves disk access, but there is something much worse: both of these have the strings encoded as PHP code (not necessarily an array!). This means that, by simply editing the file (or the hidden wiki page), we can actually inject PHP code into the wiki. In the 3rd case, this even means that all mods would be able to inject PHP code. This is obviously a large flaw that Valve would never allow.

So what can we do? In each case, we need some way to access a "backing store" to put the strings in, and to keep access to that backing store. Since Valve won't give us unrestricted access to that backing store, we will have to access it in a manner that satisfies two conditions:

• We have to be able to access it at any time without requiring Valve to intervene
• Valve has to be in the peace of mind that we cannot do anything bad with this

This is where writing an extension would come in handy. The only way to satisfy both of these constraints at the same time is to write an extension that basically lets us enter and modify stuff on the wiki, and have these things sanitized and then pushed onto the backing store. This extension would have to be installed by Valve manually, but you can bet it's not going to take only one iteration to get it right, so it will take a long while until we can actually use it. Such an extension would be a large chunk of code, as it would need to both handle the data sanitization part (ensuring that the data we put in isn't bad), but also all the input part (making a pretty webpage for us to put stuff in), and the accessing part (letting wiki pages actually use the strings). From Valve's perspective, this is a significant piece of foreign code that would need to be verified and approved for each iteration of the extension. This would be a lengthy process, and I'm not even sure Valve would consider doing it in the first place.

tl;dr: While I get the idea behind all of this, see the need for it, and completely agree with it, I see little possibility in making it a reality. D: _{^{also wat is dat new sig}} — Wind 07:30, 1 March 2011 (UTC)

Delete Pages

Could you delete the following pages? http://wiki.teamfortress.com/wiki/File:User_Sonic_Nova_Killicon_deflect_flaming_holy_mackerel.png http://wiki.teamfortress.com/wiki/File:User_Sonic_Nova_Killicon_crit_gunslinger_bleed.png http://wiki.teamfortress.com/wiki/File:User_Sonic_Nova_Killicon_crit_flaming_gru.png I uploaded them for my account but I don't want them anymore and I'd rather not keep them on the wiki to clutter it up. Sonic Nova 22:22, 3 March 2011 (UTC)