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.
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,
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.
A think function can be set with the
thinkfunction KeyValue, 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 input
RunScriptCode function_name(argument, ...).
An Entity Script has a
self reference to their owning script handle, allowing the script easy access to control the entity through its class methods.
caller are also available, but always seem to reference the same thing as
The script can be reloaded with console command
ent_fire <name of entity> runscriptfile <relative vscript path>. This is useful for quick script reloading.
I/O system interaction
If available in the game API, scripts can use the
DoEntFire() functions to fire outputs to map entities.
If arguments for
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.
- Entity handle
- Also known as EHANDLE. Only used in a few places. To do: Looks like some sort of pointer reference to an entity.
- Script handle
- An entity instance with accessors and mutators to the C++ entity object. Also known as HScript.
- Script scope
- The table where the variables, functions and classes of a VScript are placed.