[Mattie]

Mattie's EventScripts
Download: http://mattie.info/cs.
Platforms: Windows, Linux
Beta Test Server: 207.36.209.213:27015.
Description: EventScripts is a Counter-Strike: Source add-on that will automatically execute a server config file whenever a game event occurs. For example, you can create a "round_end.cfg" file in your cstrike/cfg directory and it will execute when the round is over. For a full list of possible events, check your server's *.res files. EventScripts also supports in-line event variable expansion, extended event variables, server variables, user variables, message logging, player message broadcasting, simple file manipulation, and conditional expressions.


UPDATE:
Documentation has moved to my new forums:

• Docs: http://www.mattie.info/cs/forums/viewtopic.php?t=29
  Forums: http://mattie.info/cs/forums/

[Mattie]

To Do List:

1. Take a break and play some CSS ;) 2. Publish newest source code for EventScripts. 3. Finish configuring forum. Statusone.

Requested Features:

1. Allow for locating the config scripts in a different directory than cfg. Status: Available in v0.3.0. 2. Server variable expansion Status: Available in v0.5.0. 3. User variable creation and expansion Status: Available in v0.5.5. 4. es_log for logging strings to log file. Status: Available in v0.5.0. 5. Additional event triggers for events Valve doesn't track but community wants (Got any ideas?) 6. Convince other plugin writers to fire game events when their plugin does something (e.g. kicks, teleports, team balances, etc). This will allow administrators to perform custom steps (like logging, announce, etc) when these events fire. 7. es_attackerteam, es_userteam Status: Available in v0.4.0. 8. functions for changing health, money, etc. 9. Possibly some form of visual script syntax creator. For example, a calculator style interface that allows you to click buttons with normal english to create eventscripts, For example, if you pressed "If Headshot", "Tell everyone" then a textbox, it would then create a .cfg automatically. This is for the slightly less experianced, obviously, but i feel it might help them out. I could help you making this, if you think it's a good idea. It wouldnt be hard to code and well within you're skill, im sure. 10. "EventScripts based on map ie (map)_(event).cfg" 11. Allow players to register special script subdirectories which contain scripts towards a specific function (e.g. cfg/events/kingofthehill/round_start.cfg)

Reported Bugs:

. Some statements execute delayed because of variable expansion, this makes command ordering very difficult at times. Status: Under active investigation. . es_steamid isn't working quite right in conditional statements. Status: Fixed 2005.03.23 . Crashes occur if a player disconnects during event handling. Status: Fixed 0.5.5

[Mattie]

This isn't a dramatic release, but it has some recently requested features which I hope you'll find handy! Comments welcome, as always, in the forum.

New in this release:

• eventscripts_subdirectory ""
  Allows users to change the directory where you store your event scripts. It must be a subdirectory of your cstrike/cfg directory. I recommend "cfg/events", though it defaults to your "cfg" directory as before. You'll want to set this early in your autoexec.cfg.
  
  Added support for es_username extended event variable. Anytime an event is received that provies "userid", EventScripts will also set es_username to the player's name. It's accessible like normal event variables as such: event_var(es_username).
  
  Added support for es_steamid extended event variable. Anytime an event is received that provides "userid", EventScripts will also set es_steamid to the player's Steam ID. It's accessible like normal event variables as such: event_var(es_steamid).
  
  Added support for es_attackername extended event variable. Anytime an event is received that provides "attacker", EventScripts will also set es_attackername to the attacking player's name. It's accessible like normal event variables as such: event_var(es_attackername).
  
  Updated four example scripts to demonstrate usage of the above new variables. Available on the download site and in the forums.

[Mattie]

New in v0.4.0 release:

• 1. Reworked event handling to use the IGameEvent interface-- as a result, will be less prone to breakage by Valve updates.
  2. Now strip the quotation marks when a message is sent via es_xmsg or es_xtell. This prevents seeing messages that look too quotey:

  "[BOT] Wesley" killed you!

  3. Added es_userteam - Anytime an event is received that provides "userid", EventScripts will also set es_userteam to the player's team number. It's accessible like normal event variables as such: event_var(es_userteam).
  4. Added es_attackerteam - Anytime an event is received that provides "attacker", EventScripts will also set es_attackerteam to the attacking player's team number. It's accessible like normal event variables as such: event_var(es_userteam).

-Mattie

[Mattie]

More information is listed above, but here's what I added in this release:

• 1.Fixed server crash on player disconnect - This required a major rework of the event engine. Valve really didn't like when players disconnected in the middle of events, so EventScripts now delays its script running slightly. Be on the lookout for weird behavior just in case the new model causes any new problems.
  
  2. es_log and es_xlog were added to allow you to write messages to the event log.

In addition, I added the following two items to the documentation above, as they're now supported in v0.5.0:

Server Variable Expansion As of EventScripts v0.5.0, EventScripts can perform in-line expansion for server variables as well. To accomplish this, you'd use the server_var(variable) text wherever you want the server variable expanded. For example, you could place the following in player_jump.cfg: // EventScripts v0.5.0 es_tell event_var(userid) You're jumping around and the gravity is server_var(sv_gravity)! and the server would send you this message whenever you jumped: You're jumping around and the gravity is 800 ! You can use server variables in conditions and in scripts just as you would event variables. In addition, since these don't require an event to run, you could even expand the variables by typing directly into the console if you ever wished to do so. User Variable Expansion As of EventScripts v0.5.0, EventScripts can perform in-line expansion for user variables. Source/Valve treats these pretty much like server variables, and so does EventScripts. To accomplish this, you'd use the server_var(variable) text wherever you want the user variable expanded. User variables have to be created via Valve's 'setinfo' command, but they support handy things like incrementing (via the 'incrementvar' command) and decremating ('decrementvar'). For example, if you had previously run "setinfo deaths 0" in your autoexec.cfg, you could place the following in player_death.cfg to count server deaths since last restart: // EventScripts v0.5.0 incrementvar deaths 0 99999 1 es_msg There have been server_var(deaths) player deaths since the server was last booted. The server in this case would output something along these lines whenever someone died, where 23 is the number of deaths that day: There have been 23 player deaths since the server was last booted. You can use user variables in conditions and in scripts just as you would event and server variables. In addition, since these don't require an event to run, you could even expand the variables by typing directly into the console if you ever wished to do so.

I really hope you guys enjoy this release since it's been a great deal of work getting this release out. Thanks for your patience with the problems and let me know if you see any new ones.

Special thanks to 'shro' who helped in brainstorming and troubleshooting this release.

[Mattie]

I just made another update. Primarily this update addresses one issue, but more details are below. The main issue was that I heard that Valve did not provide the "setinfo" console command on Linux. I got very frustratingly terse/incorrect answers from Valve so I decided to code it myself. So, I've now implemented it for them in an almost identical manner as how it behaves on Windows.

If you're not using Linux, you may want to skip this update, but read the items below and decide:

• * Cleaned-up my source code to remove bot commands that were not needed and/or crashed.
  * After you use incrementvar for a variable, look-ups via server_var() tended to return a float/decimal value (e.g. something that was really 2 would print "2.000000"). Now we force the string to be an integer representation (e.g. 4) most of the time so you don't get all the trailing zeroes.
  * Updated plugin_print to show the version for the plugin, too.
  * Implemented Valve's setinfo for Linux dedicated servers since Valve wasn't nice enough to provide access on Linux. (On Linux, "setinfo" is now just another way to call my "es_xsetinfo" which works on Windows, too.)
  * Also providing es_setinfo for both platforms which will mimic setinfo yet will expand any EventScripts variables it finds on the line.

Hope this helps, let me know if you have any questions or problems with v0.5.5.

Thanks,
-Mattie

Special thanks to 'shro' who spent many hours working on this with me yesterday.

[Mattie]

Changes in this version as reflected in the documentation above:

• * es_format <variable> <format-string> [token1] [token2] [token3] [...] [token9]
  Formats a string according to the format-string and stores it into the variable command. EventScripts will expand any variables it finds. (Equivalent to running "es es_xformat".)
  * es_xformat <variable> <format-string> [token1] [token2] [token3] [...] [token9]
  Formats a string according to the format-string and stores it into the variable command. No variables are expanded as it is assumed everything is already perfect.
  * es_math <variable> <operator> <value>
  Performs the math operator (+, -, /, *,add, subtract, multiply, or divide) on variable and value and stores the result in variable. EventScripts will expand any variables it finds. (Equivalent to running "es es_xformat".)
  * es_xmath <variable> <operator> <value>
  Performs the math operator (=, +, -, /, *, set, add, subtract, multiply, or divide) on variable and value and stores the result in variable. No variables are expanded as it is assumed everything is already perfect.

Special thanks to Cr3V3TTE who provided the es_math functionality (and more things you'll see in the next release)!

I'm a big fan of these new methods-- they can help solve a lot of little problems (e.g userid-based variable name building, logfile formatting for stat programs, etc).

Yet, these functions really make clear the issues with command sequencing. I'll be looking into a good remedy for that as soon as I can squeeze it into a release.

-Mattie

[Mattie]

I've provided a major update to EventScripts. This was a great deal of work. Please read this entire message before upgrading.

The release contains the following new commands coded primarily by Cr3V3TT3. For examples, see the updated documentation at the top of this thread.

• es_token <variable> <string> <token#> [seperator-character]
  Sets a variable to the part of the string corresponding with "token#". It splits up the string according to the seperator character which defaults to space. EventScripts will expand any variables it finds. (Equivalent to running "es es_xtoken".)
  es_xtoken <variable> <string> <token#> [seperator-character]
  Sets a variable to the part of the string corresponding with "token#". It splits up the string according to the seperator character which defaults to space. No variables are expanded as it is assumed everything is already perfect.

In addition, this release should resolve the command execution order problem. This comes after about 7 discarded attempts to handle the issue and I've finally found a fix that works on Win32 and Linux (no thanks to Valve, though).

Important Note: The 'fix' for this problem required a major change to the way EventScripts works under the covers. It is now a little more fragile when it comes to Valve updates and there's a possibility it doesn't work wonderfully on some flavors of Linux. I've tested on Slackware 10, Windows XP, and Windows 2k3. If EventScripts v0.7.0 doesn't work for you please post a message ASAP indicating the problem. The good news is that if your server comes up, it's probably going to work 100% of the time.

There's a chance that if your scripts were taking advantage of the bad command ordering in the old ES, they'll behave a little oddly now. Your scripts were likely wrong before to make up for ES's shortcomings. If you have problems getting your old script adapted to v0.7.0, post them in the forums and I'll work with you to fix them.

If you run into problems, set the eventscripts_sigscan server variable to 0 (via your srcds command-line or autoexec.cfg file) and you should revert back to how the old ES behaved-- I don't recommend this unless you're seeing major problems. If it makes you feel better, backup your old EventScripts version just in case.

For those interested, here's the well-ordered output from my ordering tests which failed so badly before v0.7.0:

L 04/13/2005 - 00:06:40: test1 L 04/13/2005 - 00:06:40: test2 L 04/13/2005 - 00:06:40: test3 L 04/13/2005 - 00:06:40: test4 L 04/13/2005 - 00:06:40: test5 L 04/13/2005 - 00:06:40: test6 L 04/13/2005 - 00:06:40: test7 L 04/13/2005 - 00:06:40: test8 L 04/13/2005 - 00:06:40: test9 L 04/13/2005 - 00:06:40: test10 L 04/13/2005 - 00:06:40: test11 L 04/13/2005 - 00:06:40: test12 L 04/13/2005 - 00:06:40: test13 L 04/13/2005 - 00:06:40: test14 L 04/13/2005 - 00:06:40: test15 L 04/13/2005 - 00:06:40: test16 L 04/13/2005 - 00:06:40: test17 L 04/13/2005 - 00:06:40: test18 L 04/13/2005 - 00:06:40: test19 L 04/13/2005 - 00:06:40: test20 L 04/13/2005 - 00:06:40: test21 L 04/13/2005 - 00:06:40: test22 L 04/13/2005 - 00:06:40: test23 L 04/13/2005 - 00:06:40: test24 L 04/13/2005 - 00:06:40: test25 L 04/13/2005 - 00:06:40: test25 L 04/13/2005 - 00:06:40: test26 L 04/13/2005 - 00:06:40: test27 L 04/13/2005 - 00:06:40: test28 L 04/13/2005 - 00:06:40: test29

Thanks, and speak up if you have problems,
-Mattie

[Mattie]

This was a lot of work. I hope you guys can figure out some good things to surprise me with this functionality. Let me know if you run into problems:

Summary list of changes:

• * Revised the command execution handler for Linux -- might work better on certain platforms. Try eventscripts_sigscan 1 to give it a whirl. Disable with eventscripts_sigscan 0.
  * Added carriage return to es_xmsg and es_tell so they should appear properly in the console.
  * Added many new commands (see below)
  * Added many new extended event variables for userid/attacker (see below)
  * Introduced 'script packs' to make it easier for people to drop-in/enable/disable script sets that people write. (e.g. King of the Hill, FireBug)
  * Going to release my FireBug scripts for people to try.

Details (excerpts from the update doc at the beginning of this thread):

New Extended Event Variables: es_userweapon - Anytime an event is received that provides "userid", EventScripts will also set this to the internal name for the weapon (e.g. "weapon_usp"). es_userarmor - Anytime an event is received that provides "userid", EventScripts will also set this to the user's armor value. es_userhealth - Anytime an event is received that provides "userid", EventScripts will also set this to the user's health value. es_userdeaths - Anytime an event is received that provides "userid", EventScripts will also set this to the user's death count. es_userkills - Anytime an event is received that provides "userid", EventScripts will also set this to the user's kill count. es_userdead - Anytime an event is received that provides "userid", EventScripts will also set this to 0 if the user is alive and 1 if the user is dead. es_attackerweapon - Anytime an event is received that provides "attacker", EventScripts will also set this to the attacking player's internal weapon name (e.g. weapon_usp). es_attackerarmor - Anytime an event is received that provides "attacker", EventScripts will also set this to the attacking player's armor value. es_attackerhealth - Anytime an event is received that provides "attacker", EventScripts will also set this to the attacking player's health. es_attackerdeaths - Anytime an event is received that provides "attacker", EventScripts will also set this to the attacking player's death count. es_attackerkills - Anytime an event is received that provides "attacker", EventScripts will also set this to the attacking player's kill count. es_attackerdead - Anytime an event is received that provides "attacker", EventScripts will also set this to 0 if the user is alive and 1 if the user is dead. [/list] New Variables: * eventscripts_sigoffset 1856 Warning: Do not change this value unless instructed to do so. It is used for Linux dedicated servers to track down internal Valve commands to help command order execution. New Commands: * eventscripts_register [subdirectory] Allows you to register a subdirectory underneath your eventscripts_subdirectory that contains a pack of scripts to be handled as a group. If you do not provide a one-word directory name, calling this function will list all active script packs. * eventscripts_unregister [subdirectory] Allows you to unregister a subdirectory underneath your eventscripts_subdirectory that contains a pack of scripts to be handled as a group. If you do not provide a one-word directory name, calling this function will list all active script packs. This effectively 'disables' a script pack until you run eventscripts_register again. * es_delayed <seconds> <command-string> Will execute the command-string seconds later. All scheduled es_delayed commands are reset at the beginning of each map. Special thanks to Cr3V3TT3 for this one. EventScripts will expand any variables it finds. * es_xdelayed <seconds> <command-string> Will execute the command-string seconds later. All scheduled es_delayed commands are reset at the beginning of each map. No variables are expanded as it is assumed everything is already perfect. * es_gettime <variable> Stores the current seconds since January 1, 1970 in variable. Always growing value. EventScripts will expand any variables it finds. * es_xgettime <variable> Stores the current seconds since January 1, 1970 in variable. Always growing value. No variables are expanded as it is assumed everything is already perfect. * es_copy <variable1> <variable2> Copies the value of variable2 into variable1. This is handy to help you indirectly access variables. (E.g.: "es_copy myvar sv_gravity" might write 800 into the myvar console variable). EventScripts will expand any variables it finds. * es_xcopy <variable1> <variable2> Copies the value of variable2 into variable1. This is handy to help you indirectly access variables. (E.g.: "es_xcopy myvar sv_gravity" might write 800 into the myvar console variable). No variables are expanded as it is assumed everything is already perfect. * es_getuserid <variable> <identifying info> This follows an algorithm similar to Mani's commands. Allows you to lookup a user's userid by providing a userid, steamid, full username, or partial username. Only returns the first match. EventScripts will expand any variables it finds. * es_xgetuserid <variable> <identifying info> This follows an algorithm similar to Mani's commands. Allows you to lookup a user's userid by providing a userid, steamid, full username, or partial username. Only returns the first match. No variables are expanded as it is assumed everything is already perfect. * es_rand <variable> <min> <max> Courtesy of Cr3V3TT3. Generates a random integer within the min and max range and stores it into the variable. EventScripts will expand any variables it finds. * es_xrand <variable> <min> <max> Generates a random integer within the min and max range and stores it into the variable. No variables are expanded as it is assumed everything is already perfect. Variable Copying: In EventScripts v0.7.5, support was added to copy one variable to another without necessarily requiring the use of "server_var" commands. For example: // EventScripts v0.7.5 es_setinfo myvar 0 es_xcopy myvar sv_gravity would store the server's gravity value into your new variable "myvar". The above was already achievable before v0.7.5 using server_var(). What this command is really handy for is for indirect access to variables. In lieu of nested variables, you could do the following: // EventScripts v0.7.5 es_xsetinfo myvar 0 es_xsetinfo varname sv_gravity es_copy myvar server_var(varname) This allows you to build-up console variable names with things like es_format and then copy their information into another variable. ... Random Numbers: In v0.7.5, EventScripts added support for random number generation. For example, you can use es_rand to generate a random number between 1 and 6 in myvar: // EventScripts v0.7.5 // initialize es_setinfo myvar 0 es_rand myvar 1 6 es_msg The die rolled a server_var(myvar) might broadcast something like this: The die rolled a 4 Lookup Functions In EventScripts v0.7.5, support was added to lookup certain values provided by the server. Other commands like this will probably be added over time. For starters, es_gettime was created. This is a simple function that will let you store the current system time (in the form of seconds since midnight January 1, 1970) into a variable of your choice. This is primarily useful if you wish to construct a unique value for that time period. In addition, es_getuserid was added to allow lookup of a particular userid. It works a lot like commands provided in Mani's Admin Plugin. I.e., it will try to lookup the information you provide in different ways to see if it can find a good userid. For example, suppose you typed: // EventScripts v0.7.5 es_setinfo myvar 0 es_getuserid myvar Mat If "Mattie!" happened to be on the server, myvar would return his userid. es_getuserid return the first userid where a match is found. It performs the lookup in this order: userid, steamid, full username, and then partial username. If no appropriate user is found, it will return a 0 userid into the variable. You should check for this if it is important for how you wish to use the userid. Delayed Command Execution One of the most interesting features in EventScripts v0.7.5 is the ability to schedule a command to occur at some point in the future. There are almost always better ways to handle things, but there are a lot of interesting uses. For example, I thought I'd give players on my server a warning before freezetime ended. In round_start.cfg: // EventScripts v0.7.5 es_delayed 4 es_msg Get ready. es_delayed 5 es_msg Get set. es_delayed 6 es_msg Go! Since my mp_freezetime is 6 seconds, this would schedule "Get ready.", "Get set.", and "Go!" within a second of each other ending when freezetime does. Script Packs EventScripts v0.7.5 introduced the concept of 'script packs' that can be enabled and disabled at will. Basically a script pack developer can specify the following things when he provides a group of related event scripts: 1. A command that activates the script pack for you to place in autoexec.cfg (or to type in when you want). This is typically of the form of eventscripts_register scriptpackname. For example, "eventscripts_register firebug". 2. A command that de-activates the script pack. This is typically of the form of eventscripts_unregister scriptpackname. For example, "eventscripts_unregister firebug". 3. The subdirectory under eventscripts_subdirectory where you must place these. This must be the name of the script pack you use when you call eventscripts_register. For example, I could create a group of scripts that provide "FireBug" functionality. I'd provide a zipfile of the scripts and any users who wanted to use it would extract those into their (e.g.) cfg/events/firebug directory. In order to turn on the scripts, they'd just issue "eventscripts_register firebug" from the console. To disable them for the next map, they'd issue "eventscripts_unregister firebug". In addition to typical event cfg files (e.g. round_start.cfg), script pack developers might include extra functionality in traditional .cfg files. Whenever a script pack is registered, a server variable is created that provides the directory to the script pack to use with the 'exec' command. It's of the form "scriptpackname_dir". Script pack developers can also provide their own 'server.cfg' file that exists in the script pack subdirectory. This will be executed whenever a new map is loaded since there aren't a lot of good events for this sort of thing.

[Mattie]

This version added support for center-screen messages, and color-coded es_tell's and es_msg's. In addition, bug fixes were made to prevent es_delayed crashes, and support was added to automatically set eventscripts_sigscan to 0 on processors that are not supported.

Please post a message in the primary forums if you have any problems with this release. Below is the updated documentation regarding broadcast messaging:

Broadcasting Messages Since you don't want the Console speaking for you all the time via 'say', I've created the some generic/useful message commands. If you have Mattie's EventScripts installed, you can run these from a console. They also work in scripts/config files: es_msg [color] <text/variable message> Sends a message to all players. If a color is specified, it must be "#green" or "#lightgreen". EventScripts will expand any variables it finds. (Equivalent to running "es es_xmsg MyMessage".) es_xmsg [color] <text-only message> Sends a message to all players. If a color is specified, it must be "#green" or "#lightgreen".No variables are expanded as it is assumed everything is already perfect. es_tell <userid> [color] <text/variable message> Sends a message to a single player by userid. If a color is specified, it must be "#green" or "#lightgreen". EventScripts will expand any variables it finds. (Equivalent to running "es es_xtell userid MyMessage".) es_xtell <userid> [color] <text-only message> Sends a message to a single player by userid. If a color is specified, it must be "#green" or "#lightgreen".No variables are expanded as it is assumed everything is already perfect. With these, a lot of possibilities open, but here's a simple one I put in player_jump.cfg: // EventScripts v0.2.0 Example // The server gets mad at players who jump, for some reason. es_tell event_var(userid) Why are you jumping? Stop rocking the server! Version 0.7.6.1 of EventScripts added basic support for optional coloring of es_msg and es_tell messages. At this time, the only supported color codes are "#green" and "#lightgreen". For example, the above player_jump.cfg example might look like this instead: // EventScripts v0.7.6.1 Example // The server gets mad at players who jump, for some reason. es_tell event_var(userid) #lightgreen "Why are you jumping? Stop rocking the server!" Note: Due to the special nature of color-coded messages, the broadcast text cannot be as long as a message that does not specify a color (i.e. that uses the default coloring for messages with no "#green" or "#lightgreen"). If you choose to color-code your message double-check to be sure it does not get truncated when sent to the clients. Also provided in EventScripts v0.7.6.1 is the ability to print messages to the center of all player's screens. Those commands are as follows: * es_centermsg <text/variable message> Displays a white message in the center of the screen for all players. EventScripts will expand any variables it finds. (Equivalent to running "es es_xmsg MyMessage".) * es_xcentermsg <text-only message> Displays a white message in the center of the screen for all players. No variables are expanded as it is assumed everything is already perfect This broadcast command has a short duration and cannot be displayed in a color other than white. If you need to extend the message duration, try using es_delayed to send a duplicate message again to all clients.

Enjoy,
-Mattie