OnActivate is broken
Posted: 26 Nov 2018, 15:33
I have a new experience that caused me some 'openmw negativity'.
read this if you want the complete story (note that is not the original title, it was more like 'OnActivate is broken')
https://gitlab.com/OpenMW/openmw/issues/4735
tl;dr:
1. i'm modding (in this case i'm using a python script to merge a MWScript to other MWScripts in order to have a 'compatible no matter the mod order' mod, like levelled list mergers).
2. I notice OnActivate has extremely funky behavior in my usecase: basically it sets a hidden flag and expects you to call 'activate' to clear it. Problem: it sets this flag regardless if the player clicked or not - just calling it on a if ( OnActivate == 1 ) is enough to disable the engine type 'activation' - dragging objects in this case - in the else branch too . There is no other recourse to reset this flag but activate, which ofc is completely wrong in my case (books) on the 'else' branch.
3. I open the bug and after much back and forth to convince them it's a bug get told 'not a bug, morrowind has the same exact (buggy) behavior' and suggests a workaround (still broken, especially for my usecase because i have to show the messagebox several times) and when i suggest 'add a new function' get told 'wait for 1.0 and LUA' (lol) as if adding a new script MWScript functions that fixed inane buggy behavior killed babies and functions added to the MWScript couldn't be used later on LUA.
I get pissed off, the end.
Now reiterating whats on the link. Using 'LUA will save us from this' as a excuse to do nothing right now is completely insane. Adding and using functions is not backwards compatible right. BUT WHO THE FUCK CODES MORROWIND MODS IN OPENMW-CS? Do people complain that MWSE is 'not compatible' with plain morrowind? (only idiots). Openmw-cs even outputs a extension that morrowind doesn't recognize on purpose.
Openmw coders admit that they're going to rip out everything relating to scripting with LUA so the 'compatibility' will be out of the window and screaming them.
Hilariously, even if the LUA engine came down from heaven tomorrow, it still wouldn't help me. Remember, i'm patching *existing* scripts (for compatibility with the merge approach). And MWScripts can't run LUA. For that two work i'd need my (already closed) suggestion to run multiple scripts per object (my complaint about that closure in this thread was moved to 'feature suggestions').
Not only this but after my experience i find myself questioning the LUA fetishism that seems to be going around. So the engine will run both LUA and MWScript interperters... at the same time (because large backwards compatibility tail from original scripts). I dunno how you expect this to work out but i'm predicting a whole lot of confusion and code churn to two different interfaces having to work at the same time neutralizing the advantages of both. Or maybe there is going to be a 'magic' source code rewritter that runs at runtime, but i doubt it.
Just the mention of 'events' in the bug report filled me with dread because event driven programming is completely fucking insane on the scope of its runtime ordering bugs even for professional programmers, much less modders.
I'm sorta ambivalent. A 'register script for this event' type of mod would be much more compatible for multiple scripts running at the same time than a 'change the OnPCEquip flag, forget to reset it to the same value on the exit from the script to allow other scripts to run on the same object and react to the same events'.
However as long as current MWScript mods and *original* game behavior that sets and depends on those side effects exists to run (ie: forever) then the engine won't be able to run multiple mods without problems that need fixing on the mods and original code. If this has major advantages (like running multiple scripts or running threaded scripts) i predict there will be usage but many recommendations to 'not use LUA and MWScript mods at the same time' (because LUA event driven mods will be fundamentally more restricted than MWScript and might 'do nothing' when a MWScript mod decides to turn off OnPCEquip and never turn it on again until the next time it runs - too late for the event mods - for instance). Then again this is 'not worse' than right now. But when you *actually* want to change mechanics (like for instance have the first equiping of a item do something different, which is something i've done before) you won't be able to use events (dunno if the LUA engine is supposed to have a non-event interface - if it does, i suggest side effect functions like OnPCEquip to be errors in in the event interface).
read this if you want the complete story (note that is not the original title, it was more like 'OnActivate is broken')
https://gitlab.com/OpenMW/openmw/issues/4735
tl;dr:
1. i'm modding (in this case i'm using a python script to merge a MWScript to other MWScripts in order to have a 'compatible no matter the mod order' mod, like levelled list mergers).
2. I notice OnActivate has extremely funky behavior in my usecase: basically it sets a hidden flag and expects you to call 'activate' to clear it. Problem: it sets this flag regardless if the player clicked or not - just calling it on a if ( OnActivate == 1 ) is enough to disable the engine type 'activation' - dragging objects in this case - in the else branch too . There is no other recourse to reset this flag but activate, which ofc is completely wrong in my case (books) on the 'else' branch.
3. I open the bug and after much back and forth to convince them it's a bug get told 'not a bug, morrowind has the same exact (buggy) behavior' and suggests a workaround (still broken, especially for my usecase because i have to show the messagebox several times) and when i suggest 'add a new function' get told 'wait for 1.0 and LUA' (lol) as if adding a new script MWScript functions that fixed inane buggy behavior killed babies and functions added to the MWScript couldn't be used later on LUA.
I get pissed off, the end.
Now reiterating whats on the link. Using 'LUA will save us from this' as a excuse to do nothing right now is completely insane. Adding and using functions is not backwards compatible right. BUT WHO THE FUCK CODES MORROWIND MODS IN OPENMW-CS? Do people complain that MWSE is 'not compatible' with plain morrowind? (only idiots). Openmw-cs even outputs a extension that morrowind doesn't recognize on purpose.
Openmw coders admit that they're going to rip out everything relating to scripting with LUA so the 'compatibility' will be out of the window and screaming them.
Hilariously, even if the LUA engine came down from heaven tomorrow, it still wouldn't help me. Remember, i'm patching *existing* scripts (for compatibility with the merge approach). And MWScripts can't run LUA. For that two work i'd need my (already closed) suggestion to run multiple scripts per object (my complaint about that closure in this thread was moved to 'feature suggestions').
Not only this but after my experience i find myself questioning the LUA fetishism that seems to be going around. So the engine will run both LUA and MWScript interperters... at the same time (because large backwards compatibility tail from original scripts). I dunno how you expect this to work out but i'm predicting a whole lot of confusion and code churn to two different interfaces having to work at the same time neutralizing the advantages of both. Or maybe there is going to be a 'magic' source code rewritter that runs at runtime, but i doubt it.
Just the mention of 'events' in the bug report filled me with dread because event driven programming is completely fucking insane on the scope of its runtime ordering bugs even for professional programmers, much less modders.
I'm sorta ambivalent. A 'register script for this event' type of mod would be much more compatible for multiple scripts running at the same time than a 'change the OnPCEquip flag, forget to reset it to the same value on the exit from the script to allow other scripts to run on the same object and react to the same events'.
However as long as current MWScript mods and *original* game behavior that sets and depends on those side effects exists to run (ie: forever) then the engine won't be able to run multiple mods without problems that need fixing on the mods and original code. If this has major advantages (like running multiple scripts or running threaded scripts) i predict there will be usage but many recommendations to 'not use LUA and MWScript mods at the same time' (because LUA event driven mods will be fundamentally more restricted than MWScript and might 'do nothing' when a MWScript mod decides to turn off OnPCEquip and never turn it on again until the next time it runs - too late for the event mods - for instance). Then again this is 'not worse' than right now. But when you *actually* want to change mechanics (like for instance have the first equiping of a item do something different, which is something i've done before) you won't be able to use events (dunno if the LUA engine is supposed to have a non-event interface - if it does, i suggest side effect functions like OnPCEquip to be errors in in the event interface).