Introduction to the Synapse X Environment
Before we can go into the new scripting methodology offered by Synapse X, it is first important to know the differences between the Synapse X environment and the game script environment.
Script Identity
Synapse X scripts run at a higher identity than normal game scripts - while the
actual identity number(s) are mostly irrelevant to us (if you wish to know, as
of writing this documentation, Synapse X scripts run at identity 7
and normal
game scripts run at identity 2
), it is more important to know what extra
privileges this gives Synapse X scripts over normal game scripts.
Unlike game scripts, Synapse X scripts have mostly (see below for exceptions) full access to the full game APIs without limitations. This means you can use certain functions not normally possible to use from either game scripts or even the command bar.
Some examples of extended functionality introduced by higher identity include:
-
Ability to use protected services like
VirtualUserService
andCoreGui
. (abiet there are far better alternatives for both we will introduce later) -
Ability to modify the 'protected' instance tree and properties.
-
Ability to use protected functions like the
UserSettings
APIs orgame:GetObjects
, commonly used to load external instances by Synapse X scripts.
While Synapse X tries to provide the most access as possible to scripts executed by it, some functions are deemed off limits and are not allowed to be called by Synapse X scripts. These functions include:
-
Functions that allow stealing from the Synapse X user who executed the script, or access to private information of the Synapse X user that should not be accessible from scripts.
-
Functions that have known security issues. (Ex: a function that has a known memory corruption vulnerability that could lead to arbitrary code execution on the user executing the script)
-
Functions that provide unrestricted authenticated HTTP request access, which allows the 1st point to occur. Synapse X provides facilities to allow unauthenticated web requests.
Synapse X Additions
Along with script identity, Synapse X also introduces many custom functions that
allow for enhanced functionality and access by Synapse X scripts. We will
introduce many of these functions to you later in this guide, but we will start
with a commonly used (and simple) one for Synapse X scripts: getgenv
. Getgenv
allows you to get the 'global environment', a shared top-level environment
between Synapse X scripts. You can use this to set globals that will be used by
all Synapse X scripts. Do note that getgenv
is not shared to game scripts -
you can instead use getrenv
if you wish to do that.
An example is shown below for getgenv
:
getgenv().test = 123
print(test) --> 123
Then, from another Synapse X script:
print(test) --> 123
As you can see, the value will stay within the globals table between each Synapse X script. You can add as many of these globals as you like.
Miscellaneous Changes
There are also many miscellaneous changes between Synapse X scripts and game scripts. These changes are listed below:
-
Synapse X scripts are not attached to a
script
global. While Synapse X still provides ascript
global for each script, it is only provided for compatibility reasons and is deprecated for all future use. Setting theDisabled
property on the Synapse Xscript
global will do nothing due to the Synapse X script not being connected to it. You should never touch this global in scripts you make. -
shared
and_G
, two tables commonly used by game scripts are not connected to Synapse X scripts. Instead, Synapse X scripts have their ownshared
and_G
tables, likegetgenv
. If you wish to access the game scriptshared
and_G
tables, usegetrenv()._G
and vice versa. Please note the considerations in the Synapse X security model if you wish to do this. -
Synapse X provides many internal protections against implicit environment leaks to game scripts. Please see the Synapse X security model for more information.
Now that you have a general idea of the Synapse X Environment, we can now move on to the major programming concept behind Synapse X - supervisor-based programming.