The Script Entity - Content Creation Docs

Content Creation

From weapon paints to maps, find everything you need to know about creating content for Lambda Networks.

Home

Learning

Intro to Lambda vScript JavaScript Basics The Script Entity Scripting Cookbook

Reference

Scripting: In-Depth

API Reference

Instance API Core API CS API Entity Methods Player Methods Value Classes Enums

Scripting

The Script Entity

The lambda_point_script point entity is the bridge between your map and your JavaScript. This page covers everything it can do on the Hammer side.

Prerequisite

Install the Lambda Generic FGD via Content Authoring Tools. It contains the lambda_point_script entity.

Placing the entity

Place a lambda_point_script anywhere in your map; its position doesn't matter. Give it a targetname so your buttons and triggers can send it inputs, and set ScriptFile to your script's path.

Each entity creates its own independent script instance. Two entities can even run the same file, and each gets its own separate variables and callbacks. Removing the entity destroys its instance.

Keyvalues

Keyvalue	Type	Default	Description
`targetname`	string	none	Name used when targeting this entity through map I/O.
`ScriptFile`	string	`scripts/vscripts/test.js`	JavaScript file to execute. A missing `scripts/vscripts/` prefix is added automatically.
`AutoRun`	choice	Yes	Loads the script when the entity initializes, provided it is enabled.
`StartDisabled`	choice	No	Starts with map-to-script input forwarding disabled.

For most maps: set the script file, leave AutoRun on Yes, and you're done.

Inputs

Input	Parameter	Description
`Enable`	none	Enables script input forwarding. If `AutoRun` is enabled and the script is not loaded, it also loads the script.
`Disable`	none	Disables script input forwarding. Existing think, event, and hook callbacks remain registered.
`ReloadScript`	none	Reloads `ScriptFile` and runs the script reload lifecycle.
`RunScriptInput`	string	Invokes a registered script input. Format: `InputName optional value`.
Any custom input	string	Forwards directly to an `Instance.OnScriptInput` callback with the same name.

Custom inputs

Any input name your script registers with Instance.OnScriptInput can be sent straight to the entity. This Hammer output:

OnPressed  →  map_script  →  OpenDoor  →  red_keycard

invokes:

Instance.OnScriptInput("OpenDoor", (value) => {
	Instance.Msg(value); // "red_keycard"
});

Hammer can't discover JavaScript callback names automatically, so custom inputs won't appear in the output dropdown. Type the name in manually. The supplied FGD declares ExampleInput as an example; you can add your project's inputs to your own copy of the FGD if you want autocomplete.

Names are case-sensitive

OpenDoor and opendoor are different inputs once they reach the script. If your input seems to do nothing, check the capitalisation first.

RunScriptInput

RunScriptInput does the same job, but takes the input name as part of its parameter. This is useful when the name needs to come from the I/O chain itself:

RunScriptInput    OpenDoor red_keycard

This invokes OpenDoor with the value "red_keycard". Everything after the first space becomes the value.

Outputs

Output	Value	Description
`OnScriptLoaded`	script path	Fired after `ScriptFile` executes successfully.
`OnScriptError`	path or error description	Fired when script loading or script-input invocation fails. Detailed JavaScript exceptions are printed to the server console.
`OnScriptInput`	input name	Fired after a registered JavaScript input is invoked successfully.

These let your map react to the script itself. For example, fire OnScriptError at a game_text while developing so you notice failures without watching the console.

A typical setup

Place a lambda_point_script and name it map_script.
Set ScriptFile to scripts/vscripts/security_door.js.
Keep AutoRun set to Yes.
In the script, register an input: Instance.OnScriptInput("OpenDoor", ...).
On your button, add the output OnPressed → map_script → OpenDoor.
Use OnScriptLoaded, OnScriptError, and OnScriptInput to continue the map's I/O chain if needed.

One script or many?

Both approaches work; pick whichever keeps you organised:

One entity, one big script is simplest to manage. All your state lives in one place.
Several entities with focused scripts, e.g. one for doors and one for the round logic. Each has isolated variables, so they can't interfere with each other. To communicate between them, fire script inputs at each other with Instance.EntFireAtName.

Where do script files go?

During development, place files under:

garrysmod/scripts/vscripts/

When you ship your map, you can pack scripts inside the BSP itself so players and servers need no extra downloads. See shipping your scripts for the packing rules.