OnActivate is broken

[i30817]

'severside and clientside' scripts? I guess if you're going to completely break everything to be able to support several players interacting with the world at the same time, you'd need to break nearly all of the original scripts and then you wouldn't worry to excess about the 'backwards compatibility' of adding new functions for mods that never intend to go back to morrowind to use lmao.

That's a big disproven assumption. The last time I checked, very little was broken, and 99% of the game was completely playable in multiplayer.

I'm curious, how does this happen? You simply do not allow people to use mods obviously, but do you also not allow them to pick up objects? Duplicate objects given or picked up for quests to proceed? What about 'activator' functions that target the pc without bothering to check for distance (or if the 'pc' is more than one)?

[AnyOldName3]

Lots of the functions in MWScript likely either won't be available in Lua, or will only be available as part of some 'OpenMW Standard Lua Library' written in Lua. If we completely drop the concept of an OnActivate function, the original behaviour can be achieved using lower-level C++-to-Lua bindings and a few lines of Lua code. This then enables you to have your desired OnActivate function while other people can have the legacy OnActivate-but-actually-more-of-an-activation-filter function and doesn't require OpenMW to actually provide either. The replacement isn't necessarily the thing you've been suggesting, so implementing the thing you're suggesting, even without the maintenance costs, isn't necessarily a good idea. The maintenance costs are also bigger than you're considering. As well as actually implementing it, we also have to

• Write up documentation explaining what it does (and why you'd prefer it to the original) as we can't rely on existing Morrowind documentation.
• Answer a bunch of forum questions whenever anyone gets confused about it.
• Probably translate the documentation to other languages, and this gets messy, as mostly we've been avoiding doing that because lots of stuff might end up changing and it's better to have up-to-date documentation in one language than incorrect documentation in a bunch of languages which can lull people into a false sense of security.
• Fix any bugs that might come up (which is unlikely in this case, but if we implement your proposed policy of judging things on a case-by-case basis, there are going to be bugs that get in).
• If we do switch to considering implementing every function anyone comes up with on a case-by-case basis, we're going to end up spending a lot of time doing the considering that could otherwise be spent implementing things which the original engine actually does have that we don't do yet.

[davidcernat]

I'm curious, how does this happen? You simply do not allow people to use mods obviously, but do you also not allow them to pick up objects? Duplicate objects given or picked up?

The vast majority of mods work fine. Players who join a server are required to have the mods and load order set for that particular server. As long as they don't use really complicated singleplayer-focused MWScript, mods don't cause any trouble. In the nearby future, I'll allow servers to completely override the smallish number of MWScript scripts that are buggy in multiplayer with serverside Lua equivalents, potentially making everything work fine in multiplayer.

Players can pick up items without any problems. I assume you're asking specifically about how quest items are handled. By default, if you're playing on a coop-oriented server and your coop buddy picks up a quest item and then never returns, that means you can't finish that quest (hence why you should play with a reliable coop buddy). However, it's very easy to reset any given quest or cell so you can get a quest item again, and the serverside scripts also allow you to make certain items obtainable once by every player, which is how public servers get around the problem.

You're welcome to watch one of the many videos of multiplayer in action on YouTube to see that it works quite well.

What about 'activator' functions that target the pc without bothering to check for distance (or if the 'pc' is more than one)?

Initially, I also assumed those would cause problems, but they are so few and unimportant that I can't remember a single quest that is broken due to the singleplayer logic used there.

[i30817]

I see that list and can only think 'but completely broken mods with (real case) books that only allow themselves to moved after they're read is completely fine, or at least for the other 2 to 10 years that it will take to reach 1.0'...

So apparently getting questions asked about fucking MWScript functions that are just 'the same thing, but fixed so xyz doesn't happen' is 'too much' and 'would cause trouble for translators and we'd have to think about the functions' (non english reading morrowind modders.... that's like if a japanese company bothered to translate their modding guide). Thanks for all the fish and so long.

I can now say i COMPLETELY understand the negativity. If you don't want to add new functionality at the minimum fix what's broken on morrowind scripting already so people don't think 'openmw? Pointless when i can get so much less broken mods in morrowind' then no wonder people are negative.

(the 'better mods' ship has sailed with the no MWSE until 1.0 and 'no new functionality until then policy', which i don't believe will actually happen btw).

Here is to another 10 years of farfing around with Snell's windows and shaders. Maybe the critical component of real time shadows is next? Oh boy, so many things to distract away from 1.0. Why just the other day some dude was asking about MGE long distance rendering. Clearly 1.0 material, much more relevant than the fact openmw is 2nd class for modders (behind MWSE2.1+ and even MGE) and players subsequently. Who knows, maybe your own multiplayer fork will overtake you in player popularity and add implementations of MWSE before you in MWScript. One can only hope, because it would be much needed kick on the pants.

[davidcernat]

I see that list and can only think 'but completely broken mods with (real case) books that only allow themselves to moved after they're read is completely fine, or at least for the other 2 to 10 years that it will take to reach 1.0'...

So apparently getting question asked about fucking MWScript functions that are just 'the same thing, but fixed so xyz does't happen' is 'too much' and 'would cause trouble for translators and we'd have to think about the functions'. Thanks for all the fish and so long.

I can now say i COMPLETELY understand the negativity. If you don't want to add new functionality at the minimum fix what's broken on morrowind scripting already so people don't think 'openmw? Pointless when i can get so much less broken mods in morrowind' (the 'better mods' ship has sailed with the no MWSE until 1.0 and 'no new functionality until then policy', which i don't believe will actually happen btw).

I think negativity is completely unwarranted. These folks have done a phenomenal job in recreating a really complicated engine in an incredibly detailed and accurate way. When you look at other similar projects that have failed, such as Project Aedra and The Crystal Scrolls, you can see that they failed precisely because they were not as focused and as adept at prioritization as OpenMW was.

Now, as far as additional scripting possibilities are concerned, I can sympathize with modders' frustration in not having better scripting possibilities for so long. However, if the plan is to use Lua as a greatly superior scripting language, that means making MWScript additions or changes today that are exclusive to OpenMW only creates an extra list of quickly deprecated mods called "OpenMW mods that only work with OpenMW's MWScript." This is an extra headache when you consider that there's a chance we're already going to have "Morrowind mods that work in both Morrowind and OpenMW" and "OpenMW-exclusive mods that use Lua" and "MWSE-exclusive mods that use Lua" and "TES3MP-exclusive mods that use Lua."

My hope is that we can reduce the number of headaches by using the same serverside scripting system for both OpenMW and TES3MP, and that we can try to also add a compatibility layer for MWSE mods, so that no one's work is wasted. This means that OpenMW's current lack of additional scripting possibilities is a blessing in disguise from my perspective because, at the very least, there's a good chance we can avoid splitting the scripting community between OpenMW and TES3MP.

Here is to another 10 years of farfing around with Snell's windows and shaders. Maybe the critical component of real time shadows is next? Oh boy, so many things to distract away from 1.0. Why just the other day some dude was asking about MGE long distance rendering. Clearly 1.0 material, much more relevant than the fact openmw is 2nd class for modders (behind MWSE2.1+ and even MGE) and players subsequently.

It doesn't need to be "another 10 years." There's a perfectly fine Lua scripting system for OpenMW that you can use right now, and it even works in multiplayer. According to the lead MWSE developer, it's pretty good. If it gets cleaned up a bit and merged into OpenMW, that skips your imagined 10 year wait.

[i30817]

It doesn't need to be "another 10 years." There's a perfectly fine Lua scripting system for OpenMW that you can use right now, and it even works in multiplayer. According to the lead MWSE developer, it's pretty good. If it gets cleaned up a bit and merged into OpenMW, that skips your imagined 10 year wait.

Again, riddle me this: what's the point of using a entirely new scripting system if i want to patch at post-modlist setup (like omwllf) a MWScript function (my original problem when i found the inane OnActivate behaviour).

Even assuming i'm disregarding the 'i want to patch old morrowind mods using morrowind scripting' niggle, what's the point of using LUA... if the function i need is not there?

Well, i'm assuming that the slot system talked about in the design document is not already done; that could, or could not simplify this mod by obviating the need to care about other mods scripts. I find it weird that you go to the trouble of specifying 'slots' (ie : events) and don't specify a way for multiple mods to register on a 'slot', which is basically 'the point' of a listener pattern besides performance. And tears. Many tears when loosely related events of unclear sequence 'have' to be coordinated.

I'm also wondering if the 'local' slot (ie the frame by frame equivalent) will be able to turn off the events automatically as it does stupid things to get new mechanics (turns off equipping the first time etc). It should be possible if this one is run first. I suggest that this is made possible to avoid the tears above and attempting to write settings that affect mechanics or the engine on the 'event slots' be forbidden (reacting differently is fine, just not 'and now i turn off drag and drop').

Even worse, If listener slots start wanting to bypass the event queue that is driving them things get messy quick
ie : in a multiple listener sequence running in order (not in parallel)

A - B - C, if A executes a push for some property, and expects immediate results before B and C see the value, but A-B-C is actually on the same thread than the GUI/property it wanted to affect, things work, but if the work being done by A is long, you need something like a swingworker (if you ever did java) that pushes that work to another thread, continues executing and when 'done' a mysterious event 'G' happens in the GUI sequence
C-D-E-F-G (it's not a listener obviously but if you smooshed the execution order, it would run on the same GUI thread but much after than B and C).

So when i think of 'LUA will be much better' i'm already thinking 'get ready for long pauses because people are blocking the gui thread doing inane stuff like 'searching all containers for loot and solving the travelling salesman problem on the GUI thread' and people are not even thinking about this'. People already complain about 'microstutters' that are probably misbehaving scripts.

[davidcernat]

Again, riddle me this: what's the point of using a entirely new scripting system if i want to patch at post-modlist setup (like omwllf) a MWScript function (my original problem when i found the inane OnActivate behaviour).

Even assuming i'm disregarding the 'i want to patch old morrowind mods using morrowind scripting' niggle, what's the point of using LUA... if the function i need is not there?

You should be able to use the OnObjectActivate event in the serverside Lua to do what you want, without the bug you encountered in MWScript. Other functions you may end up wanting can be suggested and added.

Of course, by using TES3MP, you'll run into the very small part of the game that still causes trouble in an adjusted-for-multiplayer context, but you can always use the console or small serverside script adjustments to get through any issues until they are properly fixed.

If we assume that TES3MP will get merged into OpenMW – which is currently the plan, unless everyone decides that's too much trouble – then one could argue that using it is not too dissimilar from trying out an early version of OpenMW's Lua scripting system.

Well, i'm assuming that the slot system talked about in the design document is not already done; that could, or could not simplify this mod by obviating the need to care about other mods scripts. I find it weird that you go to the trouble of specifying 'slots' (ie : events) and don't specify a way for multiple mods to register on a 'slot', which is basically 'the point' of a listener pattern besides performance. And tears. Many tears when loosely related events of unclear sequence 'have' to be coordinated.

I'm also wondering if the 'local' slot (ie the frame by frame equivalent) will be able to turn off the events automatically as it does stupid things to get new mechanics (turns off equipping the first time etc). It should be possible if this one is run first. I suggest that this is made possible to avoid the tears above instead of attempting to write settings that affect mechanics on listeners (reacting differently is fine, just not 'and now i turn off drag and drop').

The TES3MP scripting system was done in isolation from the OpenMW post-1.0 design document, and most of it was in place before the design document was made public. Additionally, the design document outlined future improvements to MWScript; since then, intentions have changed towards using Lua. That means it's unclear which parts of the design will be retained as described, especially if the merger with TES3MP goes through.

Right now, in TES3MP, you can have multiple script hooks for the same event on the same item. For example, I can implement a custom magical potion that, when drunk, runs a script specifically for that one potion that makes it shrink you, runs a separate script used for all potions that makes it lower your thirst, and runs a separate script used for all drinkable items that makes you need to pee. (With the latter two being separate because alcohol, for instance, should make you pee but shouldn't lower your thirst.)

Even worse, If listener slots start wanting to bypass the event queue that is driving them things get messy quick
ie : in a multiple listener sequence running in order (not in parallel)

A - B - C, if A executes a push for some property, and expects immediate results before B and C see the value, but A-B-C is actually on the same thread than the GUI/property it wanted to affect, things work, but if the work being done by A is long, you need something like a swingworker (if you ever did java) that pushes that work to another thread, continues executing and when 'done' a mysterious event 'G' happens in the GUI sequence
C-D-E-F-G (it's not a listener obviously but if you smooshed the execution order, it would run on the same GUI thread but much after than B and C).

So when i think of 'LUA will be much better' i'm already thinking 'get ready for long pauses because people are blocking the gui thread doing inane stuff like 'searching all containers for loot and solving the travelling salesman problem on the GUI thread' and people are not even thinking about this'. People already complain about 'microstutters' that are probably misbehaving scripts.

It's an event-based serverside scripting system, so I can't really follow you through those problems. Perhaps you can give me an example of something you want to be able to do and I can tell you how I'd implement it.

(Of course, the microstutters may well be there. When doing an action, clients send a packet to the server, an event gets run in the serverside scripts, and the server sends back packets with the desired results of the action.)

[AnyOldName3]

With the latter two being separate because alcohol, for instance, should make you pee but shouldn't lower your thirst.

That's not right - a beer will make you pee, but for about half an hour it will make you less thirsty. It increases the rate of urine production but has an instantaneous-ish effect on thirst. This would be better simulated with a script that added hydration to the player and another which decreased the player's anti-diuretic hormone secretion rate, then periodically, based on the ADH secretion rate, the ADH level should be adjusted (with a constant removal rate) and based on ADH level, hydration should be converted to bladder fullness. Other factors could adjust the ADH secretion rate, such as increasing it when hydration is low, and decreasing it when the player's blood sugar is high.

Implementing fully accurate player homeostasis should be a pre-1.0 goal. This is now our top priority.

Because I'm not spending this much time on the forum in one day without suggesting we do something really silly and convoluted to achieve something no one cares about.

[davidcernat]

That's not right - a beer will make you pee, but for about half an hour it will make you less thirsty. It increases the rate of urine production but has an instantaneous-ish effect on thirst. This would be better simulated with a script that added hydration to the player and another which decreased the player's anti-diuretic hormone secretion rate, then periodically, based on the ADH secretion rate, the ADH level should be adjusted (with a constant removal rate) and based on ADH level, hydration should be converted to bladder fullness. Other factors could adjust the ADH secretion rate, such as increasing it when hydration is low, and decreasing it when the player's blood sugar is high.

Implementing fully accurate player homeostasis should be a pre-1.0 goal. This is now our top priority.

I was trying to keep it really dumb and simple, but yes, you can definitely implement it in the way you described.

[i30817]

Sarcasm aside, i don't think TES3MP is any kind of solution right now.
That people are even suggesting 'use a fork for [complicated feature that requires always online] because we froze the script system essentially forever and can't be bothered to patch to full (or partial) compatibility with existing MWSE it even if we're going to deprecate it for new scripts' is very telling.

(though now that i'm looking at it, i don't think existing MWSE would fix this because i searched for 'OnActivate MWSE' the only thing i saw was 'this function wraps the original...')

I also find it funny that before i suggested there was a 'problem' with the normal use of onactivate/activate there wasn't even a whisper of a awareness that the function was broken. I mean you implemented the vanilla behavior all right, but when asked 'how does this function side effects make sense' no one could give a satisfactory answer.

That there isn't actually a living document for these original function drawbacks on your project really makes me wary that what you're going to deliver post 1.0 is going to be fatally flawed (again).

Yes your 'OnActivate' slot is (probably) going to be fixed (by accident). What about the actual function called from a 'local script?' Probably NOT if i hadn't complained. You need to think about these things before you deliver, if you're going to have the same hardliner attitude to 'backwards compatibility' (more like 'i don't want fragmentation' like finally someone said on the previous page) you've displayed about MWSE with LUA. What about all the other stuff lurking there? Are you even going to try to ask modders about the drawbacks of each function or look at your own implementation and ask 'does this make sense and is the smallest unit of behavior' or are you just going to pretend 'new LUA system, every binding ported, we have fixed versions of the functions everyone complains about (modstat for example) 'everything is fine', time to freeze again'.

About the fragmentation argument. Openmw is the upstream, TES3MP is the downstream. If you don't want 'fragmentation' on the scripting system, have one of them PR into the other, but in my view, that ship has sailed long and far by now. I mean when scripts are 'only mildly broken' and 'quests work fine if you use the console' are real things, not to mention 'serverside scripts' lmao. And again, that ship has sailed for MWSE2.1+, considering it has its own LUA system that is completely different again and is much much more popular for new mods.