Talk:Community Scripts

From TF2 Wiki

Discussion of specific scripts here.

Please post your polite and tactful comments about whether or not certain scripts function, and how they might be improved.

Join_Class Command

Found a reference to this on some forum, and tried it out. It works perfectly. Basically join_class <classname> bypasses the changeclass menu. This allows us to quite easily script custom configuration selection scripts. I've made probably the most simple version and posted it on the site. I recommend that everyone update or delete their custom configuration scripts as needed (I nuked my "top row class selection" script already). Essobie 20:06, 12 November 2007 (CST)

• Klaymen 21:52, 12 November 2007 (CST)

There's already a script that uses this. I'm not sure how it affects a "top row class selection" script, unless your old script manually went through the change-class menu :P.

• Hah... sure enough. How did I not see that? Better yet, when did this command get added? Grr! My script did, in fact, go through the class selection menu. :( Essobie 23:16, 12 November 2007 (CST) I nuked my new one too, even though mine was a bit cleaner and better commented. Oh wells. Essobie 23:27, 12 November 2007 (CST)

Auto-Reload

Auto-Reload Script on WASD movement.

Posted by Apathy

This script will break Sticky Bomb Launcher, Syringe Gun, and all Pistols, unless you are able to disable this script when you select those specific weapons. If you wish to have an auto-reload script, you should just do class specific configurations (scout.cfg, soldier.cfg, etc.) and in each of those, do the following for weapon selection:

bind "1" "slot1; -reload"
bind "2" "slot2; +reload"
bind "3" "slot3; -reload"

In each of these slot selections, you dictate whether you want +reload on or off after you make the selection. So long as this is the only way you select weapons (weapnext/weapprev commands will not work with this) then the weapon you select turn it on or off accordingly.

Aside from all that, the term "bind-agnostic" has been mentioned on this scripting page, and I'm going to steal the crap out of that term here: this script requires players to use WASD for movement. It is possible to do the same things as this script by taking binds out of all aliases and replacing them with aliases, and then binding to those NEW aliases.

I'd help you out and rewrite your script the correct way, but the script itself is going to break things in game without baby-sitting, so you are better off just not using it in the first place.

I don't think it'd be kosher for me to just delete a script on here as this is not one of my scripting websites... I'm just contributing to it. But I would ask that you, Apathy, take it down or put in a warning on the script itself that it's going to break pistols and such. - Essobie

• I've added a link to this discussion from the auto-reload script. You make some good points and without conditional scripting there doesn't appear to be a way of using or rewriting this script in a way that won't break certain weapons. It would have to be rewritten differently for each class.--Greeze 16:25, 28 September 2007 (CST)

• Yeah, I know the script does break the medic gun and also pistols. That is why you can toggle it while playing another class. I also know about the wasd thing, (and I did state that it was only WASD) but instead of making the script more confusing, it can work with most people (assuming most people use the default). Btw, it doesn't break stickies, because I play demo all the time with this script, perfectly fine. Apathy

• Thanks for adding the warning to the script. One thing though is that I'm not sure that even having a warning is the best thing for the site since the script essentially shows people the wrong way to do things (even if it does work for you and the vast playerbase still playing with WASD for some crazy reason). Eh... it isn't like we are collaborating on technical documentation or anything. Essobie 10:03, 29 September 2007 (CST)

• I added a bind-agnostic version of this script because I was bored and needed some scripting practice. Enjoy. --Kwogger 01:13, 25 December 2007 (CST)

Auto-Reload after firing

Posted by Bono

I've posted a generic auto reload script that does not break demoman sticky bombs, hwguy gun, or the medic syringe gun on the article page. The trick is using the wait [x] command before the +reload. This does result in a very slight delay in reloading compared to scripts with no wait commands before the +reload, but I find it negligible. For rapid fire pistols (engy, scout, etc.), you can try increasing the number after the wait (ex. wait 100) to give you time to get off shots before it interrupts and starts reloading. Using wait 100 before the +reload, I was able to rapid fire the engy pistol until 3 or 4 rounds were left (out of 12) before it began reloading. Otherwise, as mentioned, your best best is to make class-specific configs and activiate +reload/-reload on a per-weapon basis. - Bono

• As I mentioned on the STEAM forums, I believe this will prevent any input from the user until the waits are done waiting... which in this particular game could be catastrophic. During testing, was this not the case? Typically what will happen when waits are going off is that additional movement will be ignored (such as strafing or jumping, etc.). Oh, and I fixed some formatting on this page as well as the other page so that your script shows up in the contents. - Essobie

• Essobie, From my testing, nothing "catastrophic" happened. Even when using wait 100 before the +reload, it still allowed movement, firing, jumping, etc. All it did was just cause a longer delay before the reload started up. The wait command, as far as I know, does not "freeze" you (although it may have in earlier games such as Quake). - Bono

• Well, color me surprised. I just did a test of a "wait 1000; play" command string, and was able to move around without issue during the few seconds before it went off. Good grief, you could use this for all sorts of nefarious stuff. Good stuff! Essobie

• Make something nefarious please :D --Party escort 10:09, 15 October 2007 (CDT)

• Is it only for me or does this script ruin the spy's pistol and the sniper's machinegun? If its my problem, how to fix it? --RedCore 13, January 2008

Any 'autoreload' script will cause issues with other weapons. The solution is to script each weapon separately (usually via individual class scripts). You will also find the same issue with the Medic's syringegun, Eningeer's pistol and probably several others. You could increase the wait time to compensate but it's not really a solution because each weapon's reload times ar different. The "Weapon specific auto reload" was posted to resolve this issue, however it isn't bind agnostic and does require individual class configs be setup. --Aurora 09:05, 14 January 2008 (CST)

• Ok already knew that but had a little problem doing the individual scripts. I succeded with the help of a fried of mine but thanks anyway. If our solution was easy, we'd straight out post it, but it needs a lot of customization on whatever your config looks like. I hope anyone will achieve doing a reload script themselves. (A little hint u should care about: Dont forget the -reload in your Anti-auto-reload script) RedCore 14, January 2008

You'r right, that's why a simple solution hasn't been posted. If anyone is contemplating doing scripts it is worth taking the time to setup seperate config files per class, by doing this it gives you increased flexibility and more control than just having an autoexec.cfg. Something else you may want to setup, you may not have come accross it yet but if you are using the +reload or +attack in scripts it is worth creating a new alias such as:

alias resetcmd "-reload;-attack;-attack2"

[Add any other -commands you use + for] And then bind it to a key you don't use such as:

bind KP_END "resetcmd"

The reason for doing this is that occasionally, when your in the heat of battle and die, the aliases become "stuck". When this happends press the key to reset the commands. --Aurora 10:37, 14 January 2008 (CST)

Echoing Text to Screen

• Greeze 01:14, 29 September 2007 (CST):

This isn't specific to any script, but affects all of them. I've noticed that the whole "developer 1; echo Some Text; developer 0" thing doesn't work the way it did in Half Life 1, at least not on my machine. What happens is that "developer 1" turns on the feedback, "echo Some Text" puts text on the screen, and then "developer 0" instantly hides the text. Has anyone figured out a way around this problem? Is there another way of displaying text on screen?

• Bowevil 05:36, 29 September 2007 (CST):

You could try this:

alias dev1 "developer 1;wait 60;bind x dev0" //Turn on-screen feedback ON - Use "echo" command to show text on screen. alias dev0 "developer 0;wait 60;bind x dev1" //Turn on-screen feedback OFF

bind x dev1

A toggle so you turn developer on/off

• Greeze 12:50, 30 September 2007 (CST):

This may work with text that's echoed as a result of a key or button-press. I haven't tried it. What I want to do is to have all of my configs announce when they've been loaded. For example, the last line of my globalKeys.cfg file:

dev1; echo Global settings loaded!; dev0

This file gets called by my autoexec.cfg, which also announces that it's been loaded. Unfortunately, if I put the wait 60 in those echo lines, TF2 freezes on startup. Does this happen for everyone?

I believe if you put a wait # command directly inside a configuration file, it causes a loop of some sort that locks the game. While attempting to add the words "blue" and "red" to the start of the new Spy Quick Disguise scripting I found that trying to put a wait pause between the color and the class name caused lockups if done in a certain way. Essobie

Rocket Jump

Posted by Icehawk

//Rocket Jump
alias +rocketjump "+jump;+duck;wait;+attack"
alias -rocketjump "-jump;-attack;wait;wait;wait;-duck"
bind mouse2 "+rocketjump"

In testing I was able to get the same performance out of the following version of this rocket jump script (which does not include any wait commands). Does anyone see any reason why all those waits would need to be present? Essobie

alias +rocketjump "+duck;+attack;+jump"
alias -rocketjump "-duck;-attack;-jump"
bind mouse2 "+rocketjump"

• Klaymen 22:13, 1 November 2007 (CDT)

This script (the Icehawk one) doesn't work for me. The +attack doesn't seem to get triggered properly. At first I thought this was on purpose and you were just supposed to fire manually and use this alias to do a "special jump" to aide the rocketjump. Does it work for anyone else?

• Klaymen 21:53, 12 November 2007 (CST)

It's working now, I might have done something silly before :)

• --Jetblack 20:17, 22 November 2007 (CST)

Is this totally automated ? I know there used to be the TF1 script of using look to point camera view to ground and using the jump from there ? Is there a X Y you can use for this?

• • No, all it does is jump, duck, and fires; as far as I can work out, it can no longer be automated. You are correct you used to be able do something like:-

cl_pitchdown 89; cl_pitchspeed 9999; +lookdown

However in their infinite wisdom Valve have decided that cl_pitchdown is a cheat and cannot be used unless sv_cheats is set to "1", also as far as I can tell they have removed all the +look commands, replacing them with xlook for use with 360 controllers (I could be wrong here because I don't have a 360 and cant seem to get the xlook to do anything). But basically unless anyone figures out differently I can't see how you could automate camera views through scripts now.--Aurora 03:30, 23 November 2007 (BST)

Simplified and corrected version of "Bind-Agnostic Version of Tiered Class Config Switcher"

Posted by 1 of 9.

• Greeze 13:08, 30 September 2007 (CST):

I like some of the changes that have been made to this, but what happens if I want to cancel and go back to the main menu?

• 1 of 9 13:52, 01 October 2007 (CST):

Are you sure that return to main menù is mandatory? Never annoying you to select another class instead the latest, just retype "v" to enter in the menu again and select the correct class. Class file config _must_ has

unbindall
exec config.cfg
exec autoexec.cfg

at start.

• Greeze 15:32, 1 October 2007 (CST)

I think I see what you're saying. (I think you mean to retype "z", not "v", right?) But that means I have to choose a class config that I don't want if I just want to reset the menu. I guess that's not so bad. I just like the idea of a cancel key :). Do we really need to exec config.cfg and autoexec.cfg in all our class files though? What about just:

CCS_rebind

at the beginning of every class config?

• 1 of 9 16:07, 8 October 2007 (CST)

Ok, but you need to unbindall manually before use a different class, instead if you put unbindall in all class config files, it automatically unbind previous config.

Engineer: All in one

Build and destroy sentry/disp/exit/entry with only four key

Posted by 1 of 9

• Greeze 17:17, 1 October 2007 (CST):

This is beautiful. I haven't tried it yet, but will this allow me to rotate my sentry while I hold down the key? If so, I couldn't think of a more perfect engie script.

• Just looking at it, it appears so. Nice job, 1 of 9. I've been surviving with just having 4 binds for building and one key to bring up the destroy menu... and two of those buttons are on my Mousewheel so "holding down" isn't possible. I may have to rethink my engineer configuration to do something like this though. The key is going to be putting the keys for Sentry and Teleporter Exit in such a place that I can hit my +attack2 button while holding them down (for rotation). Essobie

• Inspired by this script, I've added an example of using a "shift key" script... that in this case, actually uses the SHIFT key. It should prevent the accidental destruction of buildings, plus it still requires doing a manual +attack for actually building the object (for some reason I think it's super cool to run around with a giant toolbox out).

• Nice, but it seems a bit slow. In some cases I need to destroy and rebuild dispenser quickly... 1 of 9 15:58, 8 October 2007 (CST)

• Thanks =), but it is only a readjusted old tfc script. 1 of 9 15:58, 8 October 2007 (CST)

• 1 of 9 15:58, 8 October 2007 (CST)

Today I fix the boring "one shot after" when releasing binded key too fast...

• I don't understand how this script works....Bobothebum 16:02, 5 February 2008 (CST)

What part don't you understand? --Aurora 03:18, 6 February 2008 (CST)

"Boomode" All in one

Written by Spoonguard

• This is a perfect example of me not testing my crap before posting it, and someone coming along and fixing my crap. Kudos to you, sir. My script will only let you press one of those selection keys... if you try to pick another one instead, it simply won't do anything. It's missing weapon selection. Unfortunately, using the Slot command for some reason requires the wait command to be used. But, if you use the "use" command, and have the specific weapon for the Engineer then you don't need the waits at all. That's ACTUALLY what I'm personally using... thing is, it is inside the bind.

To remedy this entire situation, I'm going to replace both of our scripts with one that looks like both of ours that actually works (as well as explains what the three weapons are that the player can choose from to). Essobie 19:03, 21 October 2007 (CDT)

Another big edit to this script was done following Valve's latest patch which fixes the problem with stalling a Build command when another build command has just been fired. I've replaced the script with one that is extremely simple. The wrench is selected after building something automatically. Essobie 00:03, 26 October 2007 (CDT)

Spy Quick Disguise with PLAY Command Intergration

Posted by Essobie inspired by Greeze's Downloads

Adds intergration to use some of Greeze's .wav files when a disguise is chosen. Prevents having to look down at the HUD to see what you will be disguising as. Note that you MUST have these .wav files installed correctly for this script to work. See Downloads page for details.

• Klaymen 22:39, 1 November 2007 (CDT)

Updated script to utilise the blue/team specific wavs in Greeze's wav pack

• Essobie 23:42, 12 November 2007 (CST)

I think it's better that if you feel that something new is truly needed to be added to someone else's script that you make a new version and keep the old one as is. I've reverted this script to its original form as I feel that having it say the color before the class is overly redundant and slow (especially with the robot voices I'm using!). I've moved your version that has these color specific waves below it and gave it a new name.

Spy Quick Disguise with F Keys

This script is a good example of why we shouldn't be putting bind commands inside aliases. It's also a good example of an extremely redundant script (everything that this script does is done cleaner in an existing script). Granted, many of those scripts were created by me, so I don't want to go all holier than thou and just nuke this script... but I don't really think this version is needed. It's also lacking in the writing style that most of the wiki adheres to (lots of me and I in the description, etc.). What's the protocol for just removing an unneeded script here? Essobie 10:06, 16 December 2007 (CST)

Also, the F1-F9 keys don't correspond (in Team Fortress 2 OR Team Fortress Classic) to classes in any recognizable fashion except for F2-F6. This may cause confusion amongst a user of this script that tries to disguise as a Scout but instead disguises as a Sniper. Pills 13:41, 27 December 2007 (CST)

Shift + number class config switcher and loader

Link to the script, because it's long: http://404notfound.googlepages.com/nonumpad.txt

I was using the class config switcher and loader for a while, but since I'm getting a laptop-size keyboard soon that lacks a numpad, I modified it to work by using shift + the number keys on top to switch classes; I also made a minor change to how the script operates. I prefer it like this because I still use the number keys to switch weapons, but I know that a few scripts on the page just use them solely for scripted actions.

The change I made to the functionality of the script itself is the inclusion of an "exec clean.cfg" statement, since various class configs may have conflicting bindings and it's easier to just "reset" it every time to a default state. There's also an extra bind to execute just the clean.cfg by itself, in case something goes wrong.

But anyway--I'm mentioning my script here because there's a slight issue with it that I think may prevent it from being a viable community script (as well as the fact that there are already plenty of config switchers): using it basically requires that any other scripts that rebind the number keys be modified to instead re-alias the things in my script (i.e., instead of 'bind 1 blah' you would need 'alias num1a blah').

Personally, I think that scripts should be self-contained (apart from outright conflicts with other scripts, like using the same key), so this requirement to change elements of other scripts in order to be compatible isn't very good. I also use the automedigun script, and I had to fiddle with it a bit to make it work with this.

Bottom line: it could be handy for players on laptops who want to preserve the usage of the number keys, but at the same time it is somewhat incompatible with certain other scripts. Is it okay to add it? 404notfound 21:21, 30 October 2007 (CDT)

Splitting the page

This page is now getting extremely long (nearly 90k), what do you guys reckon to splitting it up into separate pages? We could maybe have Weapon scripts, Class specific scripts, General scripts, System scripts, and Script Packs (for multiple scripts like Grim's)? --Aurora 17:52, 28 November 2007 (CST)

Agreed, but I don't have enough scripting knowledge to take it on (wouldn't know what sections to put things in, as I don't script :P) -- WanderingFox 14:51, 29 November 2007 (CST)

Yup, its definitely getting a bit cumbersome. As WanderingFox said, I'm not familiar enough with scripting to get too much into it, but the page could definitely use some splitting up. Nos 14:51, 3 December 2007 (CST)

Marked for cleanup, and removed open review. I think we're all in agreement that this page is far too big.

Not exactly sure what "removed open review" means, but there's a number of formatting issues on this page that are all over the place for sure. I haven't contributed all that much in the last couple of months, but there's been a whole lot of little annoying practices that a number of contributors have been adding. If we are going to split this page up into subsections, we should probably come up with a solidified standard that all scripts will be posted under, and stick to it. Essobie 07:37, 13 December 2007 (CST)

The open review was removed because a decision that the page was far too big was reached. It was then moved to the 'clean up' category, which essentially says "we've acknowledged there's a problem with this article, and it needs to be fixed, and split up into smaller articles" The reason as to why nothing has been done about it yet, would be the fact that I simply do not have the background knowledge in Source scripting to do it, and Aurora (who I believe does) is too busy with everything else. If you feel like you want to fix the article yourself, then go for it. This is a wiki after all. -- WanderingFox (Talk • Contribs) 07:47, 13 December 2007 (CST)

I looked at doing it yesterday and have decided on the way to orginise it, but I realised we will need a new template for each of the entries. The problem I ran into, and you might be able to help me on this Fox, is how to contain a pre tag within a table and have a horizontal scrollbar incase the line is too big (pre's keep the original text formatting and don't wrap, intentionally as you probably know). There is a css style called overflow: which should do it, but I couldn't get it to work correctly in IE6 which I'm using here at work. Haven't tried it in FF or any other browser yet because it was work's xmas party last night and I got slaughtered :p Anyway, I am working on it as top priority and it will be done soon so please don't split it yet. --Aurora 08:15, 13 December 2007 (CST)

Overflow would work as such:

    * Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
    * Phasellus nec enim vel leo ultrices volutpat.
    * Pellentesque tempor aliquam tortor.
    * Nunc quis odio sit amet pede condimentum commodo.
    * Aliquam sit amet arcu in orci nonummy laoreet.
    * Donec malesuada sollicitudin mauris.
    * Quisque consequat libero eget elit.
    * Ut sit amet odio in urna rutrum tincidunt.

    * Maecenas id massa a nunc dignissim luctus.
    * Sed dapibus commodo velit.
    * Nulla iaculis mi in nunc.
    * Proin et purus vitae mauris mattis egestas.
    * Fusce quis erat et mauris pharetra blandit.
    * Praesent elementum ipsum et libero.

The above should render in IE6 fine, but I've only ever really used it with IE7/FF/Opera. -- WanderingFox (Talk • Contribs) 08:21, 13 December 2007 (CST)

Just checked, and it functions just fine in IETab here. Care to check on your end? -- WanderingFox (Talk • Contribs) 08:23, 13 December 2007 (CST)

Also worth noting, if it's set to 'auto' it should default to 'visible' if all of the contents fit in the defined height/width, and then scroll when they do not. -- WanderingFox (Talk • Contribs) 08:27, 13 December 2007 (CST)

Yeah it works fine if specifying fixed widths but the problem arises when you use percentages and containing tables. I'll carry on trying to find a suitable solution. Until I figure this out for the template I'll split the pages as they are. --Aurora 11:03, 13 December 2007 (CST)

    * Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
    * Phasellus nec enim vel leo ultrices volutpat.
    * Pellentesque tempor aliquam tortor.
    * Nunc quis odio sit amet pede condimentum commodo.
    * Aliquam sit amet arcu in orci nonummy laoreet.
    * Donec malesuada sollicitudin mauris.
    * Quisque consequat libero eget elit.
    * Ut sit amet odio in urna rutrum tincidunt.

    * Maecenas id massa a nunc dignissim luctus.
    * Sed dapibus commodo velit.
    * Nulla iaculis mi in nunc.
    * Proin et purus vitae mauris mattis egestas.
    * Fusce quis erat et mauris pharetra blandit.
    * Praesent elementum ipsum et libero.

Relative widths seem to work fine in FF. Checking the above in IE now. -- WanderingFox (Talk • Contribs) 11:15, 13 December 2007 (CST)

The above renders fine in IE6, at least it does for me anyway. What exactly are you having a problem with? -- WanderingFox (Talk • Contribs) 11:17, 13 December 2007 (CST)

Look at the Template:Script in both FF and IE6 to see what I mean --Aurora 13:15, 13 December 2007 (CST)

That's really friggin odd... It appears that IE6 doesn't play with overflow properly, and even if the pre tag is overflowed, the table's width is set to the full width of the text. It may just be simpler to pick a decent width, and hard code it -- WanderingFox (Talk • Contribs) 14:08, 13 December 2007 (CST)