Vscript Fundamentals

This article aims to describe fundamental concepts and uses of VScript scripting.

Tables and Script Scopes

The scripting environment consists of associative arrays, or tables, nested inside each other.

When a script is loaded, it is placed inside a table called its script scope, and any code inside the script is executed. All variables, functions and classes in the script persist in the script scope after the code has finished executing.

Script Handles

Interaction with in-game entities is done through script handles, which are objects that reference a specific entity. The script handles contain accessor and and mutator methods to read and modify the entity properties. What methods are available depend on the game and entity type. See the scripting API reference for each game for more information.

All server-side entities currently in play can be searched and iterated through with the CEntities class object, Entities.

Entity Scripts

Main article Entity Scripts

A common VScript feature is to augment the features of entities using Entity Scripts.

Adding a script to the vscripts (Entity Scripts) KeyValue of a server-side entity loads the script as an Entity Script. The script is executed when the entity spawns, and loads into a script scope made up of an unique identifier followed by the entity name or class name; _<unique ID>_<entity name>, placed in the root table. If no script has been run on the entity, a script scope can be manually created by using the CBaseEntity::ValidateScriptScope() method.

Note: Source 2 has both public and private script scopes. Entity Scripts get loaded into the private script scope.

Additional scripts can be loaded by specifying multiple scripts in the vscripts keyvalue, or using the RunScriptFile Input. All scripts that are run on the same entity will load into the same script scope, overwriting any identical variables and functions. When multiple scripts are loaded from the vscripts keyvalue, the Precache() and OnPostSpawn() will be chained so that eventual versions present in either or both scripts are called.

A think function can be set with the thinkfunction KeyValue or by the AddThinkToEnt() function, the specified script function every 0.1 seconds. While it has the potential to become expensive, a programmer is able to limit the amount of code executed. Functions can also be manually called through the I/O system with the inputs RunScriptCode function_name(argument, ...) or RunScriptFunction function_name.

An Entity Script has a self (Source 1) or thisEntity (Source 2) reference to the script handle of the entity owning it, allowing the script easy access to control the entity through its class methods.

Predefined Hooks

Entities have the ability to call functions in their script scope from the C++ side. Common entity classes have predefined function calls programmed into them to occur at certain events, allowing scripts to execute code. For example, creating a function called Precache() in an entity script will call that function right after the entity spawns, allowing the script to precache any custom assets. These functions do not need to be registered, and are always called if if one with the right name exist. Please see the API documentation for your game to find out what hook functions are available for each class.

To do: Does Source 2 implement this?

I/O system interaction

Firing Outputs

If available in the game API, scripts can use the EntFire() and DoEntFire() functions to fire outputs to map entities. More functions may be available depending on game.

If arguments for activator and caller are available in the functions, they take a script handle and can be used to fire an output to an entity using the "!self" or "!activator" keyword, even without having to know its name, as long as the handle is available.

Arbitrary VScript code can be run from the I/O system, using the RunScriptCode input available in all entities. The code will run in the calling entities script scope.

Warning: Never use double-quotation marks in any Hammer input, as it will corrupt the VMF. This means that strings cannot be passed with RunScriptCode.

Tip: TeamSpen210's Hammer Addons include a workaround for this - backticks ( ` ) are swapped to quotes during compile, allowing strings to be passed.

Example Squirrel code:

// Sets the health of the entity owning the script scope to 500.
DoEntFire( "!self", "SetHealth", "500", 0, self, self )

Connecting Outputs

Using the CBaseEntity::ConnectOutput(string output, string function) method, an entity Output can be connected to a function in the script scope of the entity.

For the duration of the function call, the variables activator and caller are set to the handles of the activating and calling entities, allowing for example for an easy way to find which player triggered something.

Bug: In

, these variables are not set correctly.

Example Squirrel code:

// Lights a prop on fire when it's used by the player.
function IgniteSelf()
{
	DoEntFire( "!self", "Ignite", "", 0, self, self )
}

// Connects the OnPlayerUse output to the above function.
self.ConnectOutput( "OnPlayerUse", "IgniteSelf" )

Input Hooks

When an entity receives an input, the game code will attempt to call a script function of the format Input<Name of Input>() in the receiving Entity Script. If the function returns false, the input is prevented from firing.

Note: The input name is case sensitive, and uses the CamelCase format.

As with connected output functions, the variables activator and caller are set to the handles of the activating and calling entities.

Note: Unlike for output functions, these are set correctly in

.

Example Squirrel code:

// The script of a door or button. Intercepts the Unlock input, 
// and doesn't allow the door/button to unlock until 5 inputs have been received.

UnlockCounter <- 5 // Counter local to the entity script scope.

// Called when the Unlock input is received.
function InputUnlock()
{
	UnlockCounter--
	
	if( UnlockCounter <= 0 )
	{
		return true // Allows the unlock
	}
	
	return false // Discards the input
}

Glossary

Entity handle: An opaque entity reference passing a C++ EHANDLE. Can only be compared with other handles or passed to API functions expecting them. Only used rarely.
Script handle: An entity instance with accessors and mutators to the C++ entity object. Represented as a HSCRIPT typedef in C++ code.
Script scope: Execution context of a script. A table where the variables, functions and classes of a VScript are placed.