Scripting Extension

From OpenMW Wiki
Revision as of 16:57, 7 January 2015 by Maqifrnswa (talk | contribs) (Created page with "These are notes on the scripting extension work, see: First described for python (SWIG): https://forum.openmw.org/viewtopic.php?f=6&t=617&start=60#p29966 LUA implementation:...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

These are notes on the scripting extension work, see: First described for python (SWIG): https://forum.openmw.org/viewtopic.php?f=6&t=617&start=60#p29966

LUA implementation: https://forum.openmw.org/viewtopic.php?f=6&t=617&start=70#p30090 https://forum.openmw.org/viewtopic.php?f=6&t=617&start=70#p30093

current ideas: I think a post-1.0 goal, of mine at least, will still be to see if I can get an easy generic scripting interface.

Overview: [*] It will be a seperate fork from openmw, as I think a unified scripting language and zini's enhancements to the existing implementation would be best for the community. It's generally better to improve one implementation rather than create several new ones. If, in the future, such extension of scripting is found desireable, then there is no problem incorporating it into openmw. [*] There are some things that python/other languages can do better and can be implemented faster than writing a new scripting engine from scratch. For example, you can use all of python's existing modules and capabillities that could enable things like dynamic web content/interaction in games. Some people are already used to lua and python scripting, they could potentially write more complicated scripts or more easily integrate scripts. [*] Existing scripting IDEs can be used, most scripting language already has built-in verbose debugging. It's possible to generate embedded consoles for testing scripts on the fly. Scripts can be edited and recompiled on the fly, in game. [*] Security will be an issue (running untrusted scripts), but it something people already deal with in the modding community: http://wiki.blender.org/index.php/Doc:2 ... n/Security Concerns can be addressed at a minimum by making users opt in to using python, and can be extended to only allow running scripts signed by a trusted certificate/key.

Implementation: [*] Create a new opcode and scripting command for "StartExternalScript". This will be a subclass of OpCode1 with an execute() function that take a runtime with the name of a script file, create an embedded interpretter for whatever language, and run the script. Users can then create normal morrowind scripts such as:

StartExternalScript, "somepythonscript.py" or target->StartExternalScript, "somepythonscript.py"

. (for discussion on python versus lua, I found this very helpful:http://lua-users.org/wiki/LuaVersusPython -- I think both could be usefull in different cases)

[*] The scripting language will have access to all the MWScript functions via binding functions. Binding functions can be generated programatically but calling "Compiler:registerExtensions (extension)" and generating c++ code from the resulting information on each function and instruction. A new tool can be made that links against libcomponents.a and generates binding functions and headers.

[*] Binding functions will be made to know the opcode, configure a runtime object using the script manager's current context, and push the variables passed to it in order on to the runtime stack. It will then run the appropriate opcode execute function. The function will be overloaded to allow for both explicit and implicit as well has have default values for optional parameters.

player->SomeCommand, 10, "somestring" would be somecommand("player", 10, "somestring")

SomeCommand, 10, "somestring" would be somecommand(10, "somestring")

function returns will be generated programatically as well based on in encoding


[*] Some mapping will need to be writting to map comands to the "call(COMMAND, ...)" in each scripting langauge. Probably can be done programatically.

Outstanding questions: [*] How to handle saving variables? Between frames, variables can be saved by saving the environment. That also allows us to possibly think of creating each running script as a seperate object in python and make the interpretter environment persistent. Then add the variables to save upon exist (and load upon initiation) through a second binding function. Or we can create multiple independent environments. [*] How fast will this be? i'm guessing slower than the MWScript system, but will it be prohibitively slower?