OnActivate is broken

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

Re: Recent Negativity Regarding OpenMW

Post by i30817 » 27 Nov 2018, 13:39

wareya wrote:
27 Nov 2018, 13:35
i30817 wrote:
27 Nov 2018, 13:08
Ugh, please don't 'fix' #1751. I think it's the only reason Natural Character Growth and Decay even works on openmw. May be mistaken though.
To me it's literally the most important one though. It has the most impact on the experience of new players who barely understand how the game works. If there's some other reason why NCGD doesn't work, that has to get fixed instead. It's probably a good idea to make 1751 some kind of option, though I don't know what the developers think.
Thinking about it, the way i was thinking this was going to be 'fixed' is wrong (limiting fortification instead of making birthsigns 'special') so there should be a path for limiting birthsigns without breaking NCGD - which uses fortifications. Or maybe there isn't and making this a special case would break how NCGD uses the hacks around the unholy trinity of getstat, modstat and setstat to find the 'real' base number. I'd suggest asking the author if a proposed modification would break things or not.

Posts: 218
Joined: 19 Jul 2016, 01:02

Re: Recent Negativity Regarding OpenMW

Post by davidcernat » 27 Nov 2018, 18:51

i30817 wrote:
27 Nov 2018, 12:01
A good thought, but a bit lacking in specifics. Because i see no reflection on how each function is broken anywhere on openmw (github repository specificaly, forums in general), just a lot of 'MWScript sucks' and 'LUA won't'. Very little domain knowledge of why in specifics - I would have zero surprise that if i hadn't made this stink, OnActivate would just waltz on into the LUA interface with two distinct concerns (checking for activation and disabling normal activation, as if that is the same thing and you want the second on all paths of the first, which is completely inane).
You see few specifics on OpenMW's Lua because it's an unresolved matter. It will either be a clientside scripting system like MWSE's that splits it off from TES3MP and may have a handful of similarities to how MWScript does a few things, or it will mostly be a serverside scripting system like in Bukkit or Neverwinter Nights 1/2 where you can instantly assume that everything is completely different by necessity. As far as I know, the latter is now preferred, but all the time already spent on thinking about the former can cause hesitation.

Now, I can ultimately only speak for myself, but: if I'm implementing similar interactions from scratch in an entirely different scripting system, it doesn't matter what the fine details of the original flawed implementation are, because I'm not doing anything to imitate them. If someone encounters a problem with my scripting functions, I can adjust them so they work more intuitively.

MWScript is still run clientside in TES3MP, and it sends packets to the server when it needs to, but I regard it as a deprecated scripting system that's there to allow compatibility with existing Morrowind content and mods, with all new scripting preferably being done in Lua.
i30817 wrote:
27 Nov 2018, 12:01
This won't fly. Mods need some way to take complete control of object scripts because otherwise would imply that they could break the rules on the 'events', which would screw over others subsequent events almost arbitrarily . Not everything fits neatly on the rules of interaction of the engine, sometimes you want to disable movement (like i managed accidentally from that POS function). For such 'breaking the rules' it's much better if it happens - from a main script that runs before the others assuredly - *before* other objects run and catch the same event that the 'rule breaker mod' screwed with.
But you can easily take complete control of object scripts and make any of them override any others. You don't need local scripts that run every frame to do it; as far as I can tell, there's always a better way. Disabling movement is as simple as using one function, so you should give me another example.
i30817 wrote:
27 Nov 2018, 12:01
You probably can't notice because very few mods are marked 'compatible' (without compatibility patches) if they want to add to the same object/same script, but in a event driven script world this would be the norm and mitigation for these problems should be a priority (also a way to run things outside of the GUI event thread would be nice too. Maybe run the events outside the main graphics thread and make the functions the scripts can interact with enqueue their operations to a event thread, that is more 'transparent' than a swingworker-like helper).
Again, if we're talking about the packet-based scripting system I've already implemented and that may get merged into OpenMW, the GUI thread and graphics thread aren't relevant to it because they don't exist on the server where the scripts run, which is why I can't follow you through any of that.
i30817 wrote:
27 Nov 2018, 12:01
All the more reason that i think the idea of preventing fragmentation by forbidding needed extensions that fix broken morrowind functions is laughable. Are people seriously 'worried' about a OnActivatePure, or a 'SaneModStat' more over having their lunch stolen because their direct competitors are busy churning out mods where this crap doesn't suck or are going even more YOLO and introducing stuff like server side scripting and string references? I actually read the 'post 1.0 plan' document and while it's impressive in scope for the Scripting, it's also completely lacking in migration options - the underlying message seems to be 'we froze MWScript before we implemented non-broken original functions or MWSE (which is hacky but useful) and now you're waiting until post 1.0 which will literally take years, if not a decade, sucks to be you'.
If you really just want OnActivatePure or SaneModStat, there's nothing stopping you from doing your own fork with them. It should be pretty easy.

Anyway, I have a big problem with the suggestion that TES3MP is a competitor. If anything, TES3MP is the experimental branch that proves OpenMW's true potential to people who are too thick to see it otherwise, and is happy to follow OpenMW's wishes so it gets merged upstream. If it doesn't get merged, and that causes an extra de facto split between scripting systems, that's unfortunate; I definitely hope we can avoid that.

MWSE has very different goals from OpenMW, which is why I wouldn't call it a competitor either. As far as I can tell, OpenMW doesn't have any competition in the "complete cross-platform engine recreation with optional multiplayer, infinite potential for improvement, and the future ability to load up assets from all the other Bethesda games that use Gamebryo/Creation Engine" department.
i30817 wrote:
27 Nov 2018, 12:01
And presenting this as a measure to prevent 'fragmentation'!
In practice, you can generally safely assume that Morrowind mods will work in both Morrowind and OpenMW, and that may well be preferable to having yet another layer of confusion for the sake of temporary workarounds.
i30817 wrote:
27 Nov 2018, 12:01
That some of these functions (replacements for the original morrowind buggy functions) are going to be needed and used later on the LUA interface and if they were to be added to MWScript could just be renamed in LUA to their original incarnations after getting stress tested, screams dogmatism and excessive concern with churn and not the good kind. Meanwhile of course, we have the graphic concerns taking all the dev mindshare while modders just back away from openmw.
I personally doubt they will be reused at all. That being said, if you really want to try out some new scripting possibilities and you can't use MWSE, you can try out TES3MP, unless you think a scripting system that works in both singleplayer and multiplayer with up to dozens of players is somehow inferior to a scripting system that works only in singleplayer.
i30817 wrote:
27 Nov 2018, 12:01
Haphazard stuff like the original function from the morrowind engine that triggered me in the first place?
Perhaps you should write a tersely worded letter to the original programmers instead of complaining about an engine whose main goal has always been to recreate that system closely.

Posts: 58
Joined: 07 Nov 2018, 05:56

Re: OnActivate is broken

Post by i30817 » 28 Nov 2018, 06:10

And here comes the sarcasm. It's quite clear what's happening here 'we won't do anything because we're going to change everything (in 2 to 10 years).

About your idea to 'abandon' the (i hope) misleadingly named 'local' scripts, that only make me sure i'll never mod for TES3MP.

Any mod that opens a Messagebox for user input is by definition going to jump outside of the 'event' framework, and will have at a minimum to let the event processing continue to not block the event queue.

There are two methods in programming to do this
1. The more 'elegant' continuation method. Pretends that GetButtonPressed is 'waiting' for input, and makes it special in that it checks if the user pressed the button and if not *returns* outside the listener and continues. Next time the listener is run it starts from GetButtonPressed instead of the top, making the listener look like completely linear code.
2. The more 'explicit' callback method. Adds a piece of code, usually a closure that will run once the user presses a button to the messagebox. GetButtonPressed doesn't exist.

(I hope for your sake LUA supports 1, though even that method is still usally quite explicit in code and i never saw a programming language that had 'continuation functions' just keywords so you might not be able to pretend GetButtonPressed is just a 'normal function')

(One of) the problems with 1, is that 'resuming listeners' doesn't work, because events only run once in response to a single stimulus. 'suspending' a listener is nonsense without very special handling in the event queue (ie the listener would temporarily turn into a 'run every frame' script when 'suspended by continuation' - no clue if the LUA bindings allow that).

But even supposing you handle that, what happens in both 1 and 2 if a later mod listener decides for whatever reason 'now i turn off all open windows'? Will the continuation or callback stay as a 'soft leak' and the purpose that mod 1 want to fulfill half completed with maybe half-broken variables starting other broken behavior? (answer: it depends). Same deal for if another mod decides to push another messagebox (though this can be handled well enough that messagebox can be made 'safe for multiple mods' i think) etc.

It's not only that other mods can turn off 'events' but that multiple scripts per object can't run as a 'single uninterrupted unit of linear code' and that they share resources and using them and then continuing means there is going to be contention or conflicts. And these 'resources' can be nearly everything system related. I'm not saying 'don't run multiple scripts', i'm saying 'don't allow multiple scripts running to get write access to system resources at the same time'.

This is much easier if you make these 'impure' functions exclusives the the 'local' script. I don't know if this contention can be reliably avoided otherwise. at least for listeners using 'continuation/callback' functions that need to allow the processing to continue (examples: GetButtonPress, Timer, probably more i can't think of now) or mods that expect to install multiple listeners to multiple events (there is one or more implicit and unpredictable 'intervals' there where another mod can do whatever it wants).

You'll soon get into deadlocks if you try 'mutex queues' over multiple resources to try to square the circle i think.

Not to mention that the original code is expecting frame by frame, and transpilers aren't magic. If you convert MWScript code to LUA, even if you keep 'separate but hidden' functions with the same behavior as MWScript just for those converted scripts, they can't run as Listeners and can't be modified by hand and distributed (Because that is copyright infringement). You can pretend you don't have a 'frame by frame' slot, but you'll have it anyway, with the corresponding code bloat, unless you want to let your project live or die at the whim of whoever owns Bethesda.
Hell, you'll have more than one, because of that messagebox continuation/callback problem above (though those will hopefully be 'invisible' to the modder).

Which is one of the reasons i think (not writing about TES3MP, but openmw now) the 'we're getting rid of all MWScript' mentality in display is unrealistic and a bad excuse not to do anything now - the revolution will not free you from maintaining the MWScript functions on their C++ side or their 'hidden requirements' like the stupid hidden state side effect on OnActivate and Activate. Not to mention the revolution will take a loooong while with this list of requirements, all while morrowind modding itself is getting more and more divergent. Eh 'doing nothing prevents fragmentation' right.
Last edited by i30817 on 28 Nov 2018, 17:31, edited 2 times in total.

User avatar
Posts: 4718
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/

Re: OnActivate is broken

Post by psi29a » 28 Nov 2018, 11:09

I split this thread out because it is worth in its own right as a feature request. I view this as an example of a healthy technical discussion.

Please, carry on. :)

Post Reply