OnActivate is broken

Feedback on past, current, and future development.
davidcernat
Posts: 192
Joined: 19 Jul 2016, 01:02

Re: Recent Negativity Regarding OpenMW

Post by davidcernat » 27 Nov 2018, 05:15

i30817 wrote:
27 Nov 2018, 04:37
Sarcasm aside, i don't think TES3MP is any kind of solution right now, simply because design like 'run a serverside script' and for what, a mod feature to be harmonize to the multiplayer i don't care about? This is frankly hilarious, unless by serverside you actually mean 'the server you initiate transparently in singleplayer mode'.

That people are even suggesting 'use a fork for [complicated feature that requires always online]
You don't need to be online. You can connect to a local server and play in singleplayer. In that regard, it's like a huge number of games where playing in singleplayer technically connects you to a server where you're the only player.

I also don't see why you think it's far-fetched. If you've spent a lot of time with Minecraft, it's like suggesting to someone that they do something in a Bukkit/Spigot plugin instead of a Minecraft client mod.
i30817 wrote:
27 Nov 2018, 04:37
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'.
Well, there are significant reasons why the freeze is a good thing. It creates less deprecated stuff that needs to either stay maintained to some extent or get permanently broken, and it potentially allows for a solution that can solve a three-way scripting divide between OpenMW Lua, MWSE Lua and TES3MP Lua.
i30817 wrote:
27 Nov 2018, 04:37
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.
I don't think you can reasonably expect everyone present in a brief time window to know everything about a huge engine recreation. You're picking on a tiny detail, and the overly demanding attitude isn't helpful.
i30817 wrote:
27 Nov 2018, 04:37
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.
So you're criticizing the fact that the multiplayer isn't perfect yet? Can you find me better fanmade multiplayer for a Bethesda game?

Beyond that, there's nothing funny about using a client-server model.
i30817 wrote:
27 Nov 2018, 04:37
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.
There are always going to be limitations to what you can do in MWSE regarding stuff like AI and custom objects.
Last edited by davidcernat on 27 Nov 2018, 05:27, edited 1 time in total.

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

Re: Recent Negativity Regarding OpenMW

Post by i30817 » 27 Nov 2018, 05:24

Well, if as it is obvious you aren't going to move forward and simply implement a version of the function on MWScript even though it would take zero effort from you (same deal with Modstat and others) because of the fragmentation boogieman you're already suffering from and no one cares but you, what i really expect from this conversation is some guarantee that the broken functions will not be re-implemented the same without any thought in the LUA interface post-1.0.

At least add design document on your github that says 'we plan these functions to be different/added/missing on LUA' so interested people have a rallying point for thinking about this before it happens, if you won't even accept the very sensible step of iterating and adding aliases of the fixed functions on MWScript so 'actual porting' can be done with a minimum of pain later. Considering this will actually take years while devs screw around with shadows and shaders and you won't accept the (much superior) iterative development method, i at least expect deliberateness. And for gods sake don't freeze the new implementation right away. Wait for people to complain and break compatibility when they do and makes sense.

But with the attitude of thinking MWScript is a metaphorical leper and LUA will magically fix broken original stuff, i'm really thinking that you're just going forward and importing nearly every pain point of those functions into LUA when running as a 'local' script. Except the very famous cases like modstat.

BTW the 'we don't want fragmentation' attitude actually caused fragmentation, with one of my new mods only existing because the MWSE (runtime) version doesn't work. Or just ask the Natural Character Growth and Decay guy if he wanted to port galsiah Character development stuff (and not even get the good stuff working because of lack of sensible modstat). People are implementing worse versions of new mods just for openmw (though my own mod isn't worse, mostly because i adapt to and manipulate new npcs/objects/records by using a leveled list merger approach when i can, which is a alternative to runtime stuff that's good when it's possible because it exposes engine stuff that MWScript or the cs doesn't).
Though to be honest, it mostly causes people not to want to port stuff as probably intended.

davidcernat
Posts: 192
Joined: 19 Jul 2016, 01:02

Re: Recent Negativity Regarding OpenMW

Post by davidcernat » 27 Nov 2018, 07:34

i30817 wrote:
27 Nov 2018, 05:24
Well, if as it is obvious you aren't going to move forward and simply implement a version of the function on MWScript even though it would take zero effort from you (same deal with Modstat and others) because of the fragmentation boogieman you're already suffering from and no one cares but you, what i really expect from this conversation is some guarantee that 'the broken functions will not be re-implemented the same without any thought in the LUA interface post-1.0'.

At least add design document on your github that says 'we plan these functions to be different/missing on LUA' so interested people have a rallying point for thinking about this before it happens, considering you won't even accept the very sensible step of iterating and adding aliases of the fixed functions on MWScript so 'actual porting' can be done with a minimum of pain later. Considering this will actually take years while devs screw around with shadows and shaders and you won't accept the (much superior) iterative development method, i at least expect deliberateness. And for gods sake don't freeze the new implementation right away. Wait for people to complain and break compatibility when they do and makes sense.
I thought you were having a back-and-forth conversation with me. Now you're talking like I'm some imaginary OpenMW hivemind instead.

Look, I see no reason whatsoever why the Lua functions would replicate any of the strangeness of the MWScript functions. I can only personally speak for the ones in TES3MP, which have completely separate and unrelated implementations of everything.

Regardless, you keep talking like someone way more demanding and dismissive than you should be. Perhaps you should do your own fork where you add an OnActivateSane just for your own pleasure and leave it at that. At least appreciate the fact that you have that option and it doesn't require much effort from you.

Even in a scenario where TES3MP doesn't get merged into OpenMW, I'll always have the deepest admiration and respect for the neverending mountains of work they put into it that allowed TES3MP to exist in the first place. Maybe you should try some of that yourself instead of invalidating their efforts in your mind just because they wanted to stick to a plan with consistent principles instead of bowing to every random demand from everyone.
i30817 wrote:
27 Nov 2018, 05:24
But with the attitude of thinking MWScript is a metaphorical leper and LUA will magically fix broken original stuff, i'm really thinking that you're just going forward and importing nearly every pain point of those functions into LUA when running as a 'local' script. Except again, the very famous cases like modstat.
I don't actually believe in having "local" scripts that run every frame in Lua, which is why there aren't any in TES3MP's take on it. I find events and customizable timers to be much more elegant.
i30817 wrote:
27 Nov 2018, 05:24
BTW the 'we don't want fragmentation' attitude actually caused fragmentation, with one of my new mods only existing because the MWSE (runtime) version doesn't work. Or just ask the Natural Character Growth and Decay guy if he wanted to port galsiah Character development stuff (and not even get the good stuff working because of lack of sensible modstat). People are implementing worse versions of new mods just for openmw (though my own mod isn't worse, mostly because i adapt to and manipulate new npcs/objects/records by using a leveled list merger approach when i can, which is a alternative to runtime stuff that's good when it's possible because it exposes engine stuff that MWScript doesn't).
It's hard to solve fragmentation when you have three different projects with entirely different ideas and angles on how to add Lua scripting. OpenMW and MWSE have a singleplayer-oriented understanding of the matter that is very different from TES3MP's serverside requirement, OpenMW and TES3MP share an open source foundation that prevents the need for much of the workaroundism in MWSE, and – finally – MWSE and TES3MP have some very unilateral experimentation going on that isn't congruent with OpenMW's plan-ahead approach.

In fact, I'd say that OpenMW has the least of the blame. All it wanted to do was recreate Morrowind's engine in peace, and now it needs to play catch-up with a lot of haphazard stuff.

User avatar
Ravenwing
Posts: 321
Joined: 02 Jan 2016, 02:51

Re: Recent Negativity Regarding OpenMW

Post by Ravenwing » 27 Nov 2018, 08:22

Every single post where someone rudely complains about lack of their pet feature or general progress is actively ignoring one or both of the following items, without exception:
  • hobbies
  • feature creep
They also seem to have a proclivity towards bitching about how OpenMW hasn't reached 1.0, and in the same breath, demand that the devs drop all they're doing to work on this one all important feature. Hint: the more time spent on things outside of the 1.0 scope, the longer it will take! (This is basically the definition of feature creep btw)

The thing is, reality isn't something you can argue out of. And the reality is that people don't have unlimited free time, they get to spend it how they want to, and time spent on one thing takes time away from others. You can scream and shout all you want, but the only thing you're likely to do by that is lower the amount of free time they're willing to spend helping you.

The only semi-reasonable complaint one could have about OpenMW's development right now is that most development time should be spent on OpenMW-CS and less on the engine. But once again, reality dictates that the devs are only able to work on what they are actually capable of doing, and what they're willing to spend their spare time on. I do not consider myself a dev in any sense of the word, but since I am incapable of helping in other ways, I occasionally drudge up the motivation to help with documentation. Thing is, it's boring, and most of the time I end up playing other games. The devs don't complain, because it's none of their business, and I don't complain when they're not working round the clock because obviously I understand they may want to do something else with their spare time as well. When I do criticize, I try to do so politely and constructively.

Now for some specifics:
i30817 wrote:
27 Nov 2018, 05:24
Considering this will actually take years while devs screw around with shadows and shaders
See above. Also, as more people have complained about the lack of pretty graphical features than the lack of coding minutiae, guess which would logically be worked on first. Lucky for everyone, post-1.0 both will be actively worked on.
i30817 wrote:
27 Nov 2018, 05:24
iterative development method
As has already been explained in a similar thread (maybe even to you), this is exactly what happens on the devs' forks. Users tend to get grumpy if experiments break their games, so only the (hopefully) stable product of these iterations gets merged. Just because you aren't seeing it doesn't mean it isn't happening.


On the topic of these threads to the moderators. I am perfectly comfortable with you being more aggressive at moving or deleting posts that don't remain on topic. This thread should have ended on page 5. As i30817 already has a thread on his specific issue, he should have kept it there. Nnatinet may have made a post about his specific issue, and if he did, he should have kept his complaints there. Neither of them (nor many others on this thread) were discussing in good faith, but I suspect if topics were kept more specific, these obnoxious megathreads wouldn't be as common or so disjointed. No one is getting anything out of them (apart from a few masochists) past a few pages unless it's actually very important (e.g. direction of scripting language). And even the scripting language thread got capped.

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

Re: Recent Negativity Regarding OpenMW

Post by i30817 » 27 Nov 2018, 12:01

davidcernat wrote:
27 Nov 2018, 07:34
Look, I see no reason whatsoever why the Lua functions would replicate any of the strangeness of the MWScript functions. I can only personally speak for the ones in TES3MP, which have completely separate and unrelated implementations of everything.
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).
I don't actually believe in having "local" scripts that run every frame in Lua, which is why there aren't any in TES3MP's take on it. I find events and customizable timers to be much more elegant.
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.

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).

Also, please make sure that MessageBoxes with buttons (or their substitute) can be used if 2 or more mods open one. This is often a problem in 'plugins' and even GUI frameworks often don't handle this degenerate case gracefully (bugs and more bugs).
It's hard to solve fragmentation when you have three different projects with entirely different ideas and angles on how to add Lua scripting. OpenMW and MWSE have a singleplayer-oriented understanding of the matter that is very different from TES3MP's serverside requirement, OpenMW and TES3MP share an open source foundation that prevents the need for much of the workaroundism in MWSE, and – finally – MWSE and TES3MP have some very unilateral experimentation going on that isn't congruent with OpenMW's plan-ahead approach.
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'.

And presenting this as a measure to prevent 'fragmentation'!

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.
In fact, I'd say that OpenMW has the least of the blame. All it wanted to do was recreate Morrowind's engine in peace, and now it needs to play catch-up with a lot of haphazard stuff.
Haphazard stuff like the original function from the morrowind engine that triggered me in the first place?
Last edited by i30817 on 27 Nov 2018, 13:48, edited 4 times in total.

User avatar
wareya
Posts: 335
Joined: 09 May 2015, 13:07

Re: Recent Negativity Regarding OpenMW

Post by wareya » 27 Nov 2018, 12:34

OpenMW literally just is not ready for this kind of pressure. It barely functions as a replacement for Morrowind's engine, despite being better in certain ways. There are too many bugs to fix and there's too much missing functionality to add. Just look at my signature.
paying attention to #1751 #2473 #3609 #3862/#3929 #3807 #4297 #4623

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

Re: Recent Negativity Regarding OpenMW

Post by i30817 » 27 Nov 2018, 12:46

Maybe now that MWSE has a LUA interface itself, it may end up deprecating those ugly setreference / getreference functions, so that's probably something of a bullet dodged, not that i was ever asking for that.

If their engine hacking gets more effective they may end up getting rid of the (horrible) io functions and get some kind of savegame access instead, if they haven't it already (not really up to date).

It would be .... good... if both projects collaborated on something acceptable to all parties for that, though honestly it's probably going to end up something like a python dict that is saved on the savegame, like several other games.

NullCascade
Posts: 120
Joined: 16 Jan 2012, 07:58

Re: Recent Negativity Regarding OpenMW

Post by NullCascade » 27 Nov 2018, 13:06

i30817 wrote:
27 Nov 2018, 12:46
Maybe now that MWSE has a LUA interface itself, it may end up deprecating those ugly setreference / getreference functions, so that's probably something of a bullet dodged, not that i was ever asking for that.

If their engine hacking gets more effective they may end up getting rid of the (horrible) io functions and get some kind of savegame access instead, if they haven't it already (not really up to date).

It would be .... good... if both projects collaborated on something acceptable to all parties for that, though honestly it's probably going to end up something like a python dict that is saved on the savegame, like several other games.
MWSE discussion isn't really on-topic, but we're happy to help you along in the #MWSE channel in the Morrowind Modding Community Discord if you want to talk about any of that.

Though that's only if you want to actually make mods -- I'll bend over backwards to add new engine functionality for you for that. If you just want to complain, you will find about as much there as you are here.
MWSE 2.x lead.

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

Re: Recent Negativity Regarding OpenMW

Post by i30817 » 27 Nov 2018, 13:08

wareya wrote:
27 Nov 2018, 12:34
OpenMW literally just is not ready for this kind of pressure. It barely functions as a replacement for Morrowind's engine, despite being better in certain ways. There are too many bugs to fix and there's too much missing functionality to add. Just look at my signature.
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.
NullCascade wrote:
27 Nov 2018, 13:06
i30817 wrote:
27 Nov 2018, 12:46
Maybe now that MWSE has a LUA interface itself, it may end up deprecating those ugly setreference / getreference functions, so that's probably something of a bullet dodged, not that i was ever asking for that.

If their engine hacking gets more effective they may end up getting rid of the (horrible) io functions and get some kind of savegame access instead, if they haven't it already (not really up to date).

It would be .... good... if both projects collaborated on something acceptable to all parties for that, though honestly it's probably going to end up something like a python dict that is saved on the savegame, like several other games.
MWSE discussion isn't really on-topic, but we're happy to help you along in the #MWSE channel in the Morrowind Modding Community Discord if you want to talk about any of that.

Though that's only if you want to actually make mods -- I'll bend over backwards to add new engine functionality for you for that. If you just want to complain, you will find about as much there as you are here.
I can't actually use MWSE because it doesn't attach to morrowind in wine last time i tried (but that was some two years ago). More importantly i can't use Morrowind usefully since it's far too slow on this pos computer. I'll probably never mod 'specifically' for Morrowind because i'm doing record manipulation to try to make 'more compatible' version of some mods and the morrowind engine is much less friendly to chucking in non-compiled script code into a record from my understanding.

The one i found the 'OnActivate' problem was this: http://mw.modhistory.com/download-87-14029

which i was trying to make work without 'specifically' editing all the skillbooks and work with the book rotate script (by ataching the script code before the bookrotate / others ) scripts could run. The original mod also has the problem (without calling Activate on all paths right after OnActivate, which of course is wrong when you didn't actually activate - thus the book is immovable until you accept the window at best, forever at worst).

I previously had success with this approach adapting this:
http://mw.modhistory.com/download-46-9738
and this:
http://download.fliggerty.com/download--8

into this: https://github.com/i30817/raremagic4openmw

which works regardless of the scrolls or npcs added and doesn't require MWSE unlike the original no spells for sale. Granted, on those mods i didn't need to 'merge' script source code like the save skill books code, mostly because scrolls tend not to have scripts, and those few that did i just wrote on them to say you 'couldn't learn it'.

User avatar
wareya
Posts: 335
Joined: 09 May 2015, 13:07

Re: Recent Negativity Regarding OpenMW

Post by wareya » 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.
paying attention to #1751 #2473 #3609 #3862/#3929 #3807 #4297 #4623

Post Reply