OnActivate is broken

Feedback on past, current, and future development.
NullCascade
Posts: 121
Joined: 16 Jan 2012, 07:58

Re: Recent Negativity Regarding OpenMW

Post by NullCascade »

AnyOldName3 wrote: 26 Nov 2018, 17:21A 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.
This isn't true. Where are you getting your information on MWSE development? The Lua interface wasn't about trying to migrate around previous issues to any significant degree, it was about moving away from the steaming pile of trash that is mwscript. It was far easier to bind a whole new language than it was to add objects, dll support, functions, coroutines, more variable types, etc. to mwscript.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Recent Negativity Regarding OpenMW

Post by AnyOldName3 »

NullCascade wrote: 26 Nov 2018, 18:49
AnyOldName3 wrote: 26 Nov 2018, 17:21A 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.
This isn't true. Where are you getting your information on MWSE development? The Lua interface wasn't about trying to migrate around previous issues to any significant degree, it was about moving away from the steaming pile of trash that is mwscript. It was far easier to bind a whole new language than it was to add objects, dll support, functions, coroutines, more variable types, etc. to mwscript.
I thought I'd read that somewhere (and assumed that it was you who'd written it). I'll go back and add a strikethrough if that isn't the case. Sorry.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Recent Negativity Regarding OpenMW

Post by Chris »

i30817 wrote: 26 Nov 2018, 18:38 And this is bad when the 'work' is something you'll have to implement later
Not necessarily. The whole point of an extended scripting language is to provide lower-level features. The devs may not have to implement a fixed OnActivate because a script written in Lua could avoid the issue altogether. But even if that isn't the case, you're still asking the devs to take on more work; rather than just implement the fixed OnActivate in Lua, you want to have it implemented now in MWScript, and have it implemented again in Lua (with further additional work of making a converter for the MWScript function to Lua).
NullCascade
Posts: 121
Joined: 16 Jan 2012, 07:58

Re: Recent Negativity Regarding OpenMW

Post by NullCascade »

AnyOldName3 wrote: 26 Nov 2018, 18:59
NullCascade wrote: 26 Nov 2018, 18:49
AnyOldName3 wrote: 26 Nov 2018, 17:21A 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.
This isn't true. Where are you getting your information on MWSE development? The Lua interface wasn't about trying to migrate around previous issues to any significant degree, it was about moving away from the steaming pile of trash that is mwscript. It was far easier to bind a whole new language than it was to add objects, dll support, functions, coroutines, more variable types, etc. to mwscript.
I thought I'd read that somewhere (and assumed that it was you who'd written it). I'll go back and add a strikethrough if that isn't the case. Sorry.
No worries. Heaven knows I get shit wrong all the damn time. I just wanted to make sure there wasn't some guy pretending to be me in the OpenMW Discord, like we had some guy pretend to be David in MMC.
i30817
Posts: 58
Joined: 07 Nov 2018, 05:56

Re: Recent Negativity Regarding OpenMW

Post by i30817 »

Chris wrote: 26 Nov 2018, 19:17
i30817 wrote: 26 Nov 2018, 18:38 And this is bad when the 'work' is something you'll have to implement later
Not necessarily. The whole point of an extended scripting language is to provide lower-level features. The devs may not have to implement a fixed OnActivate because a script written in Lua could avoid the issue altogether. But even if that isn't the case, you're still asking the devs to take on more work; rather than just implement the fixed OnActivate in Lua, you want to have it implemented now in MWScript, and have it implemented again in Lua (with further additional work of making a converter for the MWScript function to Lua).
Not only no but hell no. Did you even look the github links I provided. No 'morrowind engine' function is written in MWScript in openmw come on. The excuse that (simple!) things are not implemented 'because MWScript' is completely transparently false. MWScript is not selfhosting and all all of the bindings are implemented in C++ directly on that first interpreter bindings page i linked. Any non-broken 'function' implemented now would still be used on the lua binding.

It's more 'oh boy i really don't want to be asked to implement string references or to override windowing!'

If you want to justify a bizarre and counter productive dogma just say the truth: a influential member of the project got into his head 'lets turn away modders because i don't like MWSE and don't want to be asked the more complicated functionality it has to our implementation that would require a interpreter overhaul'. If i was even more cynical I would say that the person responsible was thinking 'let them eat MWSE' when he was laying down the 'post 1.0' rule in the full cognizance that it took more than 10 years (!) to get to '0.45'.

To be clear: I don't know who this person is and i don't actually care. This idea to freeze everything is complete idiocy though. Just say yes or no case by case. Implementing references is too much? NO. Implementing a non broken OnActivate or ModStat or SetStat is 5 minutes on a interface you say is going to be replaced '''eventually'''? YES.

Meanwhile over the last year, the openmw devs added complicated C++ debug binding functions to MWScript like 'opcodeShowSceneGraph' and 'opcodeSetNavMeshNumberToRender' like it was no big deal. As i said, hypocrisy about a nonsensical rule being ignored when it's inconvenient.
Last edited by i30817 on 26 Nov 2018, 21:13, edited 3 times in total.
davidcernat
Posts: 256
Joined: 19 Jul 2016, 01:02

Re: Recent Negativity Regarding OpenMW

Post by davidcernat »

i30817 wrote: 26 Nov 2018, 20:40 Guess what, that's not what i'm asking and i can't use MWSE (cause it doesn't work on wine, or didn't for the several years i tried it)
I suppose you can try using TES3MP for the time being. It has serverside Lua with its own separate take on object activations.
AnyOldName3 wrote: 26 Nov 2018, 17:21 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.
It depends. If we use clientside Lua, sure, but that will create a de facto split between Lua scripts that work in OpenMW and Lua scripts that work in TES3MP. If we use serverside Lua, there's no interoperability with MWScript. If we include both clientside Lua and serverside Lua, it's tricky to get people to use the former only for stuff that doesn't require network replication.

I'd call it an unresolved matter.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Recent Negativity Regarding OpenMW

Post by Chris »

i30817 wrote: 26 Nov 2018, 20:40 No 'morrowind engine' function is written in MWScript in openmw come on.
I didn't say they were. MWScript functions are, however, implemented in (C++) code. When Lua is implemented, its functions need to be implemented in (C++) code. The (C++) code implementing MWScript functions will then be dropped, in favor of (C++) code that translates MWScript to the equivalent Lua.
Any non-broken 'function' implemented now would still be used on the lua binding.
That's not how game engines work. Lua is different from MWScript, so implementing a function for Lua will be different from implementing it for MWScript. It's unlikely that Lua will be a 1:1 match to MWScript, but even in cases where specific functions are a close match, while the behavior logic may be the same and certain lines can be copied over, it will require rewriting to make it fit the new script system. It's not like putting on a different coat of paint where it just looks different and everything underneath is identical, it's more like refactoring the chassis so that the foundation is different to provide more/better capabilities and refitting the engine into said chassis.
If you want to justify a bizarre and counter productive dogma just say the truth: a influential member of the project got into his head 'lets turn away modders because i don't like MWSE and don't want to be asked to add similar (complicated) functionality to our implementation that would require a interpreter overhaul'.
Can you point out specific posts and messages with who said this? One of the main goals of OpenMW is to enable modders to do more and not be stuck with the vanilla engine at its core. And the devs have agreed to have MWSE compatibility where it can be achieved.
i30817
Posts: 58
Joined: 07 Nov 2018, 05:56

Re: Recent Negativity Regarding OpenMW

Post by i30817 »

I feel like i'm on the matrix taking the red pill. What does a fork for netplay has to do with making mods for the single player game with fixed new functions?

'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, on a interace you intend to deprecate, to use lmao.
davidcernat
Posts: 256
Joined: 19 Jul 2016, 01:02

Re: Recent Negativity Regarding OpenMW

Post by davidcernat »

i30817 wrote: 26 Nov 2018, 21:26 I feel like i'm on the matrix taking the red pill. What does a fork for netplay has to do with making mods for the single player game with fixed new functions?
The multiplayer fork has a fairly advanced Lua scripting system. It can also be played in singleplayer.
i30817 wrote: 26 Nov 2018, 21:26 '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.
i30817
Posts: 58
Joined: 07 Nov 2018, 05:56

Re: Recent Negativity Regarding OpenMW

Post by i30817 »

Chris wrote: 26 Nov 2018, 21:16
i30817 wrote: 26 Nov 2018, 20:40 No 'morrowind engine' function is written in MWScript in openmw come on.
I didn't say they were. MWScript functions are, however, implemented in (C++) code. When Lua is implemented, its functions need to be implemented in (C++) code. The (C++) code implementing MWScript functions will then be dropped, in favor of (C++) code that translates MWScript to the equivalent Lua.
You're living in complete denial if you think you can alter the semantics of the existing scripts (mods OR the original) to the point that the C++ functions will be 'different' to the point you'll 'delete the MWScript code'.
At most you'll add several new functions that only work in LUA (registering interest in events is one) or deny some functions there because they'd break the idea (the example i keep thinking of is that having a event handler 'decide' to set PCOnDrop to zero for everyone is completely bonkers while for a 'frame by frame' script it's very sensible for new semantics, but the same could be said of using the current OnActivate or the current ModStat on a new script engine... which only makes implementing their replacements now sensible.

'The (C++) code implementing MWScript functions will then be dropped' is pure science fiction fantasy you have here. At most you're change the binding FFI.

Even if you manage to transpile the MWScript code to LUA... so what, it'll still be calling functions with the same broken semantics and you'll STILL need at least 2 versions of those broken functions (one for the transpiled code, the other for the 'new and shiny' lua scripts).

This response only proves my point to myself. You are not being reasonable if you think adding 2 lines of binding a function (that you'll reuse) and whatever i didn't read on the compiler to recognize the keyword is a 'arduous maintenance burden'.

Any non-broken 'function' implemented now would still be used on the lua binding.
That's not how game engines work. Lua is different from MWScript, so implementing a function for Lua will be different from implementing it for MWScript. It's unlikely that Lua will be a 1:1 match to MWScript, but even in cases where specific functions are a close match, while the behavior logic may be the same and certain lines can be copied over, it will require rewriting to make it fit the new script system. It's not like putting on a different coat of paint where it just looks different and everything underneath is identical, it's more like refactoring the chassis so that the foundation is different to provide more/better capabilities and refitting the engine into said chassis.
This is true but is disingenuous again. You *already* implemented all the machinery to bind a c++ function to MWScript. No wonder because it's basically returning ints (or bools) and passing strings. Adding the C++ function that you'll reuse on the LUA binding (which is what i obviously meant, not the 'machinery' around it) is not a huge effort. In fact that you wasted the brainpower on that paragraph instead of copy pasting
this:
https://github.com/OpenMW/openmw/blob/m ... a.cpp#L266

removing the
mFlags |= Flag_SuppressActivate;
mFlags &= (~Flag_OnActivate);

lines, calling the copy OnActivatePure (or something)

and going here: https://github.com/OpenMW/openmw/blob/m ... .cpp#L1469

and adding two lines,
and here: https://github.com/OpenMW/openmw/blob/m ... s.cpp#L135
and copy pasting again

only shows the dogma (i probably forgot something on openmw-cs or the compiler, for the keyword recognition).

Mod stat is more complicated (because modstat is actually 26 functions or so) but sure enough, there is a cheat sheet here of the broken method that uses the magic of hidden arguments to deduplicate the common stuff: https://github.com/OpenMW/openmw/blob/m ... s.cpp#L131
Last edited by i30817 on 26 Nov 2018, 22:17, edited 2 times in total.
Post Reply