OnActivate is broken

Feedback on past, current, and future development.
i30817
Posts: 58
Joined: 07 Nov 2018, 05:56

OnActivate is broken

Post by i30817 »

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).
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Recent Negativity Regarding OpenMW

Post by AnyOldName3 »

The plan is to translate/compile MWScript into Lua, so provided our Lua implementation offers a way of doing everything MWScript can, there shouldn't be any backwards compatibility or interoperability issues between the two languages. This technology isn't magic. It's exactly how you're able to run Python code even though your computer only supports x86 machine code.

The reason we're not adding extra script functions every time someone wants them is that if we do, people will start using them, and then we can't replace them with something saner later on. It's fairly likely that the unintuitive OnActivate behaviour of the vanilla engine came about specifically because someone in the scripting team at Bethesda asked the engine team for a function that did one specific job, and then it got implemented as described without any thought about whether it was actually the best thing to do. A big part of the reason why MWSE 2.0 had a from-scratch Lua interface was that MWSE had a bunch of stuff that was added because it seemed like a good idea at the time, but actually wasn't the best solution for whatever problem it was supposed to solve.

The original official plan was to do more or less exactly what you're asking, and OpenMW received heavy criticism for it, even from active developers. A large debate was had, and eventually, it was decided that the current direction was better. Many of the points you're bringing up now were brought up then, but on reflection, they just weren't considered as scary as you're finding them, but other things that you're not concerned about were deemed to be actual real dangers. One such example is extending scripting pre-1.0 - if we'd started that already, even if the debate had decided Lua was better in every possible way, it would have been much harder to switch to it.
Last edited by AnyOldName3 on 26 Nov 2018, 19:06, edited 1 time in total.
i30817
Posts: 58
Joined: 07 Nov 2018, 05:56

Re: Recent Negativity Regarding OpenMW

Post by i30817 »

Yeah that's a insane excuse.

Riddle me this; how is a request for a new version of a function with side effects without side effects intuitive or 'insane' (same thing for the buggy modstat functions etc)

No. This is pure dogmatism. Hilariously you'll *still* need something like MWScript in the LUA 'interface' because much of script code in morrowind expects and manipulates side effects (turn off equipping once for instance). Expecially if you plan to 'convert' MWScript code, less so if you plan to reserve LUA to event driven scripts (though of course you still need non-event - every frame - type of scripts with full access to the side effect functions for flexibility).

I'll give that if you restrict some code to events and forbid using side effects on that code you could potentially run it at the same time (or threaded), along with a 'main' script that manipulates things as it will (probably this one will have to run first, then the others threaded). A big if that would need a big openmw-cs refactoring.
Last edited by i30817 on 26 Nov 2018, 17:33, edited 3 times in total.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Recent Negativity Regarding OpenMW

Post by Chris »

i30817 wrote: 26 Nov 2018, 15:33 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.
However, there are very many issues like this. Quite a few issues turn up where people suggest to just add a function to MWScript, and (mostly) everyone thinks their suggestion is the one important thing to make an exception for. But if the devs keep doing that everytime someone suggests it, where does it stop? At that point, they'd just be making an extended MWScript like they don't want to do. Every new function the devs add to MWScript needs to be designed and fleshed out (so they can say exactly what the function is supposed to do, and know what needs fixing if it begins to show misbehavior) and be maintained indefinitely, even after Lua is implemented. It's one thing if a non-vanilla function is added to improve compatibility with existing MWSE mods people use, but if it's an all new thing that only OpenMW supports (and thus only OpenMW mods use), it would be a short-term gain for more long-term work.
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.
All the more reason to not worry about fixing it in MWScript. If it has to be done in OpenMW-CS, and won't be compatible with vanilla Morrowind, why tack it on to vanilla Morrowind's scripting language? Better to let it get fixed properly with Lua scripting, than to add more hacks to MWScript.
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.
"Rip out everything" code-wise. That means rather than maintaining separate MWScript and Lua scripting engines, the current MWScript engine will be replaced with something that transforms MWScript code to Lua scripts. All user-created content files will remain compatible.
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Recent Negativity Regarding OpenMW

Post by psi29a »

If you wanted OldScript+ (extending MWScript) then you should have been there to argue with NullCascade who was pushing Lua (newscript). I'm affraid that boat has sailed. MWScript is officially petrified and we made the decision to go to newscript.
i30817
Posts: 58
Joined: 07 Nov 2018, 05:56

Re: Recent Negativity Regarding OpenMW

Post by i30817 »

Chris wrote: 26 Nov 2018, 17:28 However, there are very many issues like this. Quite a few issues turn up where people suggest to just add a function to MWScript, and (mostly) everyone thinks their suggestion is the one important thing to make an exception for. But if the devs keep doing that everytime someone suggests it, where does it stop?
When people stop complaining about not being able to do mods because of shitty original functions and monomania about keeping shitty original behaviour in amber and not adding new fixed functions. It's not even 'i want a new feature', it's 'this fucking function is broken add a fixed one'.
Chris wrote: 26 Nov 2018, 17:28 At that point, they'd just be making an extended MWScript like they don't want to do,
Yes. Because it's the sane thing to do and doesn't actually affect the 'LUA interface' if you don't want it to. You're already (i'm assuming if you're not completely insane) to extend or worse modify the problematic functions in LUA
Chris wrote: 26 Nov 2018, 17:28 Every new function the devs add to MWScript needs to be designed and fleshed out (so they can say exactly what the function is supposed to do, and know what needs fixing if it begins to show misbehavior) and be maintained indefinitely, even after Lua is implemented. It's one thing if a non-vanilla function is added to improve compatibility with existing MWSE mods people use, but if it's an all new thing that only OpenMW supports (and thus only OpenMW mods use), it would be a short-term gain for more long-term work.
Have you thought about asking what is broken? Ask gaisah how much trouble did Modstat give him. Or just read the bug report i opened right now about OnActivate insanity (OnActivate should really be called 'desactivate native activate')
Chris wrote: 26 Nov 2018, 17:28
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.
All the more reason to not worry about fixing it in MWScript. If it has to be done in OpenMW-CS, and won't be compatible with vanilla Morrowind, why tack it on to vanilla Morrowind's scripting language? Better to let it get fixed properly with Lua scripting, than to add more hacks to MWScript.
more insanity. What's this idea fixe that LUA will have anything to do with mwscript extensions? Just because LUA will be saner doesn't excuse refusing to deal with insanity now. In fact even if the LUA interface is entirely event driven you'll still need at least a 'master' script that runs every frame both for compatibility and because that's the only way to create some mods that affect mechanics deeply. It should be possible to run things on a setup with 1 frame by frame mod (for the side effects) and 0 to many event driven mods (if the event driven mods can't use the functions with side effects).
Last edited by i30817 on 26 Nov 2018, 17:53, edited 1 time in total.
User avatar
silentthief
Posts: 456
Joined: 18 Apr 2013, 01:20
Location: Currently traversing the Ascadian Isles

Re: Recent Negativity Regarding OpenMW

Post by silentthief »

Since the goals are outlined for the development up until 1.0 (which is not yet reached due to the CS being the primary reason), doing this before would simply become https://en.wikipedia.org/wiki/Feature_creep which could cause issues.

The project was stated to mirror the original (flawed) design to not make vanilla mods incompatible. Once Lua is in place (as in, in the CS) then the ability to try to remedy this can be addressed. The devs have stated that they want to make it so relying on bethesda's CS or 3rd party tools such as MWedit or other creation tools is not necessary, but also they stated that until the CS is developed, there may be issues with making mods/designs using the CS as is (not to mention that again - the original was not optimal). For this particular issue, you may have to wait. Its not that you personally are being told to wait - but that there are many issues/feature requests that are on hold until the development has gotten to the proper level.

ST the creep
i30817
Posts: 58
Joined: 07 Nov 2018, 05:56

Re: Recent Negativity Regarding OpenMW

Post by i30817 »

Feature creep my ass. You're having feature creep right now when people waste dozens of man hours agonizing about 'snell's windows' on their physics accurate water shader (i honestly deleted my rant about it on github, because, hey not my business how someone wants to spend hours coding for free).

This is a request for: this original behavior is insane, spend 5 minutes to copy the OnActivate code from onactivate here https://github.com/OpenMW/openmw/blob/m ... efdata.cpp and from here https://github.com/OpenMW/openmw/blob/m ... nsions.cpp to give modders a version of that function without the side effect if you don't want to fix the original because of backwards compatibility (fixing the original would involve either splitting it into two - disablesystemactivate and onactivate or making onactivate only setting the disable flag when the player pressed the actual activate (ie OnActivate would return 1) which is not compatible).

This request does nothing to mandate how the LUA script engine will be coded (except if you do the sane thing and make the new function the 'new' OnActivate on LUA, which only means you had more testing and feedback - same deal for modstat).

The hilarious parts is that you're still adding debug MWScript functions (last was something for the detour behavior i think).
Spoiler: Show
Talk about double standards. 'If it's useful to us and only takes 5 minutes to code, it doesn't matter, if it's useful for mods or players, no way'.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Recent Negativity Regarding OpenMW

Post by Chris »

i30817 wrote: 26 Nov 2018, 17:49 When people stop complaining
You haven't been on the internet long, have you? People will always find something to complain about. And taking time to continue adding to MWScript will just give people more time to find things to complain about, creating even more work.
It's not even 'i want a new feature', it's 'this fucking function is broken add a fixed one'.
Which in this context is the same thing. Vanilla MW behaves a certain way with OnActivate. OpenMW replicate that behavior. To make something that works as you want, while also maintaining compatibility with current OnActivate behavior mods rely on, would be a new feature.
Have you thought about asking what is broken? Ask gaisah how much trouble did Modstat give him. Or just read the bug report i opened right now about OnActivate insanity (OnActivate should really be called 'desactivate native activate')
We're quite aware of how asinine vanilla Morrowind's behavior can be. However, short of breaking peoples' mods, OpenMW needs to replicate that behavior where it can. The alternative is to make existing mods incompatible and give people less reason to care about OpenMW.
more insanity. What's this idea fixe that LUA will have anything to do with mwscript extensions? Just because LUA will be saner doesn't excuse refusing to deal with insanity now.
As I said, everything added to mwscript now needs to be maintained indefinitely. And when Lua is implemented, it's more things in mwscript that need conversion. The devs don't have infinite time and resources, so it's a matter of picking the necessary battles. Taking on more work than necessary will ensure overall slower project development, even if there may be short-term gains.
i30817
Posts: 58
Joined: 07 Nov 2018, 05:56

Re: Recent Negativity Regarding OpenMW

Post by i30817 »

Chris wrote: 26 Nov 2018, 18:27
more insanity. What's this idea fixe that LUA will have anything to do with mwscript extensions? Just because LUA will be saner doesn't excuse refusing to deal with insanity now.
As I said, everything added to mwscript now needs to be maintained indefinitely. And when Lua is implemented, it's more things in mwscript that need conversion. The devs don't have infinite time and resources, so it's a matter of picking the necessary battles. Taking on more work than necessary will ensure overall slower project development, even if there may be short-term gains.
And this is bad when the 'work' is something you'll have to implement later (because it's broken original behavior and you want things not to be broken in LUA) and can be implemented in 5 minutes to 10 minutes? 'More work than necessary' in making a copy of a 3 lines function that doesn't set a flag and turns into a 1 line function that i'll want anyway in the nebulous mythical 'post 1.0' age that will probably take at least 2 years?

I'd like not to have a significantly increased chance of death before a 2 lines function that you admit you'll need is implemented just because MWScript is icky or a similar sentiment that inspired the 'freeze everything script related for literal years to decades' dogma.

I'll admit i have no fucking clue how you expect to 'convert' MWScript to LUA' as one of you indicated on the previous page, considering how many functions have their semantics broken, you'd expect you'd welcome a clean break. If you don't, you'll really have the disadvantages of maintaining double versions of the same function (if you don't decide you don't actually care about fixing those functions, which is a possibility that i'm fearing more and more). Maybe there is a trick to redirect code from one source to different versions of the function, that's your 'overengineering' problem.

But since you literally will have fixed versions 'later', you could have them 'now' without affecting what those functions 'later' will be called. Hell, since you don't care about the future of MWScript, it would be a good platform to ask for feeback from modders, so it would limit churn later in the LUA interface (within its limitations, asking about naming is ok, about 'should this use a closure' is not).
Last edited by i30817 on 26 Nov 2018, 18:56, edited 3 times in total.
Post Reply