I had a longer post typed up, but due to power loss I guess I'm being forced to be brief
We compare not "script<->not scripts" but "2 scripts engine <-> 1 script engine". I add script exactly because of this reason you mentioned, but this can't be justification for another engine if one exists.
One of the biggest design tenants is that I do not want to replace or port any existing functionality so I do see yankesScript continuing for now. I'll maintain and expand the Lua API, and you can continue to focus on expanding yankesScript if you would like.
Another thing is demand for scripts in OXCE, right now I only one who push for new scripts (as my pet feature). Current interest is moderate (could be caused by limited scope of my scripts).
There's a huge demand from the modders I've spoken to on Discord.
Probably best benchmark for me would be custom bliting (altering pixel values on drawing surfaces).
Simply replace `ScriptWorkerBlit::executeBlit` with LUA call that will do same work without any slowdown.
Some thing like this: https://www.youtube.com/watch?v=FKzqCOg2DrQ (only units graphic, around 24 at once on screen).
Sounds like a good benchmark! I'll sneak that in as a "psychedelic" mod
And there is big difference, because my scripts do not allocate any memory only get buffer from C++ stack where they place variables. I simply traded speed for some limitations. If I would need allocate something then I would ask game code to create if for me.
The Lua context(which holds the memory for the Lua scripts) will initialise only with function pointers to allow the user to CRUD(create, read, update, delete) game objects. This means we can limited things to just "read only" if we want, but also means that no game state information will be held in the Lua context itself.
This object that script edit is pointer to `BattleUnit`. you can't have copy of unit because this will miss point of using game objects.
Another thing my scripts are static typed. This mean if you try modify const object then script will refuse to parse.
As mentioned above, we can limit access to read only since nothing will be stored in the Lua context.
If this is from current github repo then its need C++11, if it from some else it probably still use C++98 and boost.
Thanks! I'll pull the latest and compile from there instead of using Boost(that should cut compile time down a bit)
a) Have better capabilities that my scripts (easy to do).
Done
b) It do not have big overhead (probably harder).
Lua doesn't have a big overhead.
c) Can replace all current usage of my scripts.
Why is this a requirement? I'm not trying to replace yankesScript, at least, not initially. I'm only trying to provide a mod(der) friendly interface for other people to make what they want.
d) Do not disturb code base to much (e.g. you do not change multiple of functions signatures to pass some state).
Might need to define "too much"
I'll have to change the interface for loading/saving objects(almost everything in SaveGame, and most things that already take YAML node as a parameter) to include the lua context so that I can pass data to/from the game state.
e) If LUA have state it should be able to restore it after game save and load.
Yeah, still thinking on the best way to handle persistence. My current thoughts are to create a yaml node for game objects that stores the data per each mod, but some saves are already getting too large, so I might need to think about this some more.
f) Meridian is fine too to change script engine.
Cool!
g) mxe work without any hacks
I don't think this'll be an issue
h) Have "killer app" for people like Dioxine, Solarius Scorch, Hobbes or other big modders
"Hello World" isn't enough
I'm compiling a list of "example mods" as a way of specifying a Minimal Viable Product(MVP) milestone. So far, I have the following:
* add new field to the soldier for mana, and show how that can be used to implement new gameplay mechanics
* modify world zones and restrict missions in the zones to allow for diplomacy as a new mechanic
* implement "traitors" which are enemies that flip sides during battle and join your team
* open for more suggestions!
With all this I will happy kill my scripts and replace it with LUA
Like I said, the goal is not to kill yankesScript, but to supplement it initially. If there comes a point where the two collide, then yeah, we may want to revisit this strategy, but otherwise I don't see a problem with them co-existing
btw If your mod feature align with my or Meridian goals then is possible to include it to OXCE+ directly without need for script engine.
Yeah, but that simply continue the current process for writing custom logic in mods, which is to modify the engine in order to make something new. I would like to see what else the modders come up with given nearly full access to the internals of the engine