WSE/LUA uses a modified version of LuaJIT 2.0.4, which is based on and ABI compatible to Lua 5.1
LUA will run on top of module system code. That means you can add features to modules even if you don't have the source code.
This guide is solely a documentation of the provided WSE/Game API, to learn Lua itself there exist many tutorials online.
There is some example code at the end of this file that can help you to get started.
The game table is a predefined global table that allows you access to the game from lua.
To call operations, use game.operation_name(arg1, arg2, ...)
Example: game.display_message("test string")
String and pos arguments are passed to the game via the games registers (overwritting them), starting from reg[128] and counting downwards.
Notice that the argument type matters. For example, if an operation expects an integer, you cannot pass a string that contains a number.
Return values are:
boolDidNotFail, intError
intResult, intError
boolDidNotFail, intResult, intError
intError
= game.cf_operation(arg1, arg2, ...) for can_fail operations
= game.lhs_operation(lhs_arg, arg1, arg2, ...) for lhs operations
= game.cf_lhs_operation(lhs_arg, arg1, arg2, ...) for operations which are both can_fail and lhs
= game.operation(arg1, arg2, ...) for all other operations
While most Lhs operations don't require an actual value for lhs_arg (in those cases it's strictly a return variable, for example player_get_gold), some (for example val_add) do, so you have to specify it anyway.
Real-world lhs_operation example:
Note that in Lua, you don't have to assign all return values. For example, if you don't care about the error code, just omit the corresponding lhs var.
I'm not sure what the error code signalizes, however it should be 0 if there was no error.
To access registers, use game.reg[n] , game.sreg[n] and game.preg[n]
Example:
As of the current version, registers are copied by value instead of by reference. So doing things like:
Does not change the actual game register. This is likely going to be improved in a future version. What you have to do instead for now is:
For every header_[name].py or ID_[name].py file you copied to your "msfiles" folder (except header_operations.py), a new table will be generated: game.const.[name]
This table will be filled with all the constants from that file.
As of the current version, only lines that match one of the two following regexes (regular expressions) will be accepted:
This probably looks intimidating to you, but really all it says is that your constant must either be a number, a hex number, or another constant (from the same file, currently).
In other words: constant = num|hexNum|otherConstant
If the match fails, the line will be ignored and a warning message will be triggered which you can safely ignore.
You can omit the [name] part in game.const.[name].[constant], in which case all tables in game.const will be searched for your constant and the first result will be used.
So let's say you want to add a deathmatch trigger for ti_on_agent_hit. Instead of this:
You could copy header_triggers.py to your msfiles folder and do:
To add mission template triggers, use intTriggerNo = game.addTrigger(strTemplateId, numCheckTime, numDelayTime, numRearmTime, funcConditionsCallback, [funcConsequencesCallback])
These work exactly like module system triggers. Times can be float values or values from header_triggers.py (the numbers, string names are not supported yet), just like you would do it in the MS. If conditionsCallback returns false, consequencesCallback will not be executed. If it returns true or nothing, consequencesCallback will be executed.
This function is fairly expensive, as it involves copying the entire array of triggers and then adding the new one.
Example:
addTrigger returns an integer that is the index of the added trigger.
You can also remove triggers by using game.removeTrigger(strTemplateId, intTriggerIndex). If intTriggerIndex is negative, the trigger with (numTriggers + intTriggerIndex) gets removed (e.g. to remove the last trigger, use -1).
You can also add item triggers with intTriggerNo = game.addItemTrigger(strItemID|intItemNo, numTriggerInterval, funcCallback)
Example:
To use iterators (try_for_agents, try_for_players, ...), use the provided iterator functions game.partiesI, game.agentsI, game.propInstI, game.playersI
These work exactly like module system iterators and take the same arguments.
Example:
To work with positions, the following "classes" are provided: game.rotation, game.pos and vector3 (see under miscellaneous)
Keep in mind that these don't need the fixed point multiplier that the module system requires you to use.
The MS multiplier is essentially a way of specifying the current unit of length.
MS Example:
Consider the lua counterpart to "always have a fixed point multiplier of 1".
game.rotation
game.rotation.new([obj]) - constructor. obj can be used to specify initial values.
game.rotation.prototype
game.pos
game.pos.new([obj]) - constructor. obj can be used to specify initial values.
game.pos.prototype
Example:
You can add presentations using game.addPrsnt(tablePrsnt)
tablePrsnt must have the following format
}
[flags] can be omited and defaults to no flags at all. If you copied header_presentation.py to your msfiles folder, you can use the flags defined there.
[mesh] can be omited and defaults to 0. If you copied ID_meshes.py to your msfiles folder, you can use the mesh nos defined there.
triggers must have at least one element, the key being a number and the value being a function. If you copied header_triggers.py to your msfiles folder, you can use the trigger values defined there.
Basic example:
You can hook module operations using game.hookOperation(operation, funcCallback).
This means whenever the module system uses the operation, your callback will be executed first.
operation must be either the operation name as a string or an opcode.
The return values of funcCallback control further behaviour.
If it returns nothing or true, the module operation will be executed as usual.
If the first return value is false, the module operation will not be executed.
If the second return value is a bool, the module system will think it is executing a cf operation (so if the bool is false, it will break execution, like e.g. (eq, 1, 0),).
If the second return value is a number, the module system will think it is executing a lhs operation and try to set the return value
If the callback returns three values, the module system will think it is executing a cf/lhs operation. The 2nd return value must be the cf value and the 3rd the lhs value
In short, the variants are:
The hook will not be triggered when calling operations from lua. However, this task can be achieved by overwritting the game metatable, which is defined as:
One could, for example, do (NOT FINISHED YET):
You could even go one step further and create a wrapper for game.hookOperation that automates this process for you.
game.getScriptNo(script_name), use in conjunction with game.call_script(scriptNo, ...)
Example:
game.getCurTemplateId(), returns the id/name of the current mission template. Note that no template will be loaded at the time main.lua is executed.
game.OnRglLogWrite(str), this function, if it exists, gets called when something gets written to rgl_log.txt. It receives the log message as its parameter.\n A bad idea is to use game.display_message in this function, as it will easily cause an infinite loop. You can however use print().\n Any error (which would normally trigger the event again, which would trigger the error, ...) caused by this function will be catched and logged safely.
game.fail(), when used during a lua_call operation it will make the MS code fail, like any other cf operation can do.
Example:
game.OnChatMessageReceived(intPlayerNo, boolIsTeamChat, strMsg), this function, if it exists, gets called when a chat message is received (both client and server). It will be called after the corresponding module system script. If it returns a string the message will be overwritten, if it returns true the message will be supressed. Returning something will overwrite any action the module script may have taken.
Other WSE LUA API functions - these could be useful for advanced users, but you should get along fine without ever using them.
game.execOperation(strOperationName, arg1, arg2, ....) - see operations
game.getReg(intTypeId, intIndex) typeIds are: 0 = int, 1 = str, 2 = pos
game.setReg(intTypeId, intIndex, val)
vector3.prototype
vector3.new([obj]) - constructor. obj; can be used to specify initial values.
vector3 operators + - * ==
Example:
Changes include:
Disabled package.loadlib, package.cpath, io.popen. os.execute, os.getenv, os.tmpname, ffi library, loading bytecode (can be exploited)
Restrict dofile, loadfile and all IO operations to the lua directory
disable_game_const_warnings - disables all warnings during msfiles\ game constants scanning
The Lua/C stack (used to pass parameters and return values from modsys to lua and back) is automatically cleared when it reaches a size of 100. This is to prevent stack overflows.
This function spawns agents in a square at the specified position.
You could call it like: