Asynchronous Simulation

Spring Multithreaded Lua Compatibility

In order to make your Lua code compatible with the multithreaded engine, you need to follow certain rules. The rules apply to any code run by a rendering thread, which means all DrawXXX call-ins plus the Update call-in. Many UI call-ins (mouse/keyboard etc) are also run by the rendering thread.

All versions

Lua code must be designed so that it works even if objects are deleted (and possibly replaced by another object with same ID) in between any rendering call-ins. This means it is not recommended to store lists of e.g. units in global variables, and if you still want to do that, each one must be re-checked for validity before use. Keep in mind that if an object has been replaced, the operation that you intended to perform may no longer be valid for the new object.

0.82.X

Unfortunately, Spring MT has very limited Lua rendering support in this engine version, and it carries a huge negative performance impact. Especially time-consuming rendering such as looping through a set of units and drawing something for each one, must be avoided.

Only the rendering thread may use Lua OpenGL stuff, so you must be careful not to create e.g. display lists in the wrong call-ins.

There are also numerous related bugs in this version, that could turn your coding job into a trial-and-error nightmare. Deadlocks and crashes can be expected.

0.83.X

(Preliminary information, not released yet)

Rendering in a gadget can negatively affect the performance, although the performance penalty is less severe compared to in the previous engine version. Avoid writing any time-consuming rendering code in a gadget. The easy way out is to let a widget do the rendering instead. The gadget can send a message to the widget by calling Script.LuaUI.XXX(), but the value returned from this call is undefined in MT Spring.