- 1 Summary
- 2 Scripting Languages
- 3 Item Handles
- 4 Item Existence & Item Properties
- 5 Signatures
- 6 Item Type Values
- 7 Validation
- 8 Other
The GTAC scripting interface aims to be enjoyable to use.
Goals include: clean, easy to use, minimal typing, consistent, no duplicate functionality, and wrappable.
Multiple scripting languages can be used in the same server/client instance, and even in the same resource.
Item handles are used to refer to items that are created, whether the item is created by a resource, a module, or by GTAC.
List of data types used for item handles in different scripting languages:
|Scripting Language||Data Type|
Item Existence & Item Properties
Item Creation & Item General Functionality
Global functions are used to create an item, and are also used for general functionality.
Global functions are used to destroy an item.
Item Setters and Getters
The majority of item attributes are applied and fetched via OOP properties. OOP methods are used too.
Either an OOP property or an OOP method is used per functionality, not both.
OOP properties are used when a single value can be applied or fetched for an item.
OOP methods are used when it is not appropriate to use an OOP property.
Lower camel case is used as the naming convention for all functionality provided, except event names which are case-insensitive.
This means that variable, function, property & method names start with a lowercase letter, and event names can be any case.
A global function or a method may use more than one signature.
Item Type Values
Radians are used as the angle measurement unit, not degrees.
Implicit modulo division occurs for angle input to functionality.
Vectors and Arrays
Arrays of size 2 can be used in place of vec2 for input to functionality.
Arrays of size 3 can be used in place of vec3 for input to functionality.
Global functions and methods provided have their input parameter count validated.
All functionality provided has input data type(s) validated. Integer and float are considered different in languages that natively differentiate them.
For scripting launch errors, the resource is not loaded.
For scripting callback errors, the resource continues as normal, and the callback invocation instance is aborted natively.
Provided functionality has no restrictions on wrapping.
However, events (observer pattern) should always be used instead when the applicable event is provided, to prevent resource conflictions.
Wrapping Example (Lua)
Backward compatibility is supported for all functionality, excluding when a confliction would occur.