So why Lua vs Yankes scripts? Well it's pretty clear adoption has not been great, modders would rather bug programmers than deal with it, and the only programmers that deal with it are... Yankes. And I think a big factor is because modders aren't programmers. You can give them all the code and potential in the world, if they don't know how to use it, it's useless. So will they code Lua? Probably not. The draw of scripting isn't to the modders who can't code, but to the programmers who can't code C++ but can deal with something simpler like Lua, which in turn help the modders. I doubt they're itching to learn a whole new bespoke scripting language.
And ohartenstein23
Even if I myself would use this scripts it still would be useful as way to write features that I do not like or do not wan't to hardcode.
I'm aware that my script engine is not perfect but adding another script engine on top of this will not fix it but even worse that.
This is why I agree to include Lua but only when it completely replace my engine without loose of most of functionality.
As for performance... honestly, you could do a lot worse than Lua. It's the most common lightweight scripting language around, designed for embedded, runs on every platform on the planet. It'll never beat native, it's a bytecode VM, but for anything outside a tight game loop it should be fine. After all, OpenXcom struggles on anything under a 2Ghz and does all its graphical operations on the CPU, so I don't think we're winning any awards for performance either.
This depend on usage, in most cases this not matter but if it allocate memory per pixel drawn? This is one of my script usages and some mods use this.
I can only guess how Lua will behave and what will be performance. If Whispers will show it work fine, then is not problem to drop my scripts but if otherwise it will be problematic.
My whole point is that can be only one script engine in code base (Lua or my) other wise will be one big maintaining mess.
Hmm, not really easily done with the way I have started implementing the API. I do have a container class I quickly wrote which maps user objects to their respective class pointers, so maybe in that container class I could write some access rights management, but there will be HUNDREDS of hooks. On<Whatever Event I Put A Hook For> would then set the access rights to object classes, but that seams extreme. Can you point to a situation where one thing can be read, but not written during a single event, yet can be read/written on other events?
only read when you draw unit or calculate fire reaction, both should not change any thing because it could break code.
on event wen unit is hit you can alter unit (kill it, change damage values, change some custom property).
Another important thing is random seed, when you would access it on unit draw this would make that bugs become ultra hard to debug.
This why in my scripts access to random is only allowed in moments when other data is changed.
Overall it could be simplify to two global states, one is allowed to modify thins other is not.
The hooks will need to be implemented in the logic classes so I do imagine it touching most logic classes
For number of changes/modifications to source code, look how I manage my scripts. If your solution is comparable then is fine.
In my case most "mess" is in save game objects `.cpp` files where I define all bindings and scripts api:
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/BattleUnit.cpp#L3882And "links" visible publicly:
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Savegame/BattleUnit.h#L148or
https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Mod/RuleItem.h#L183If your changes are similarly localized and do not leak every other place then is fine.
I get that. I'm actually saying I will maintain the Lua stuff and you could continue to maintain the existing script stuff.
And after year you get bored and stop updating it or opposite I get bored and stop contributing to OXCE. In both cases will stay big blob of code that nobody want to touch. Right now I not interested in changing script engine or maintain another one but if you fulify my condition then I will accept it and take responsibility of maintaining it further.