Please allow objects to run more than one script

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

Please allow objects to run more than one script

Post by i30817 »

I honestly couldn't care less about shadows or general 'ultra' graphics quality.

What gets me is when requests like this, which i made right now are closed with no effort and no discussion because it's either 'post-1.0' (ie: never for at least 2 years) or because it's 'not original morrowind behaviour' as if that should be emulated when the whole point of the request is to allow modders to avoid stupid merge bugs by making openmw versions of mods that don't interfere with eachother with a much better way than 'oh i'll mush both scripts in a buggy compatibility patch'.

Meanwhile i'm right now hacking around this in a post-install merge mod by parsing the script out of books, chopping off the begin and end and prepending my own non terminating script to the existing one automatically, which is a horrific hack but hopefully it 'works'.

edit: it didn't work (or rather it would work but then break other scripts) because i need OnActivate and can't reset it to the previous value or shadow it with a local var so my check for OnActivate would disable further checks later as usual behavior for these weird morrowind callbacks.

So to enumerate:

1. Morrowind system callbacks 'reset' themselves once read.
2. You can't shadow the callback value on a local var of the same name (this is probably fair because if so it wouldn't have the same 'reset behavior')
3. 1 and 2 means that you can't merge scripts programmatically if your merged script needs to use a morrowind callback

Conclusion: the only way to merge scripts programmatically in general is with special support to make these callback values operate per script (they writing to hidden script variables) and to run multiple scripts, which is the exact RFE that was closed.
User avatar
psi29a
Posts: 5356
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: Please allow objects to run more than one script

Post by psi29a »

Splitting this out to its own topic because that is what was requested to do in the ticket. Let's get this thread started discussing the issue first. We can always revisit the ticket with any new insights. With such a change it is better to discuss first in the forums, the point of the 'feature requests and suggestions' .
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Please allow objects to run more than one script

Post by AnyOldName3 »

There are two main hurdles for something like this:
  • It breaks compatibility with normal Morrowind. This means that once you add a second script to something, you can't ever load the mod with the original engine or CS and can only use our CS. Our CS is far from finished and there are a bunch of things you can't do with it, so if, fairly early in the process of making a mod, you add a second script to something and then go to do something else that still requires the original CS, you're stuck.
  • MWScript is disgusting and every small change brings a high probability of breaking other things to the point of us deciding it's probably going to be better to add Lua support to OpenMW and then never have to touch MWScript again. Once that happens, this kind of change should be quick and easy, but we need a fully working MWScript implementation before we convert it to Lua, so it makes most sense to hold off until we've had the thorough testing we're going to have around the 1.0 release.
i30817
Posts: 58
Joined: 07 Nov 2018, 05:56

Re: Please allow objects to run more than one script

Post by i30817 »

1. Simply don't add the functionality to the CS until it's ready.

I for example am not using the cs, and instead i'm manually parsing and writing the records in python. Having a MERG record that could make a object run two scripts would be a god send to make even more compatible merge mods. While big mods like bookrotate and containers animated are likely to never follow this 'merge' strategy because they make allowances for specific objects and that is easier on cs (containers animated) or simply can't get the info required for all their hardcoding (bookrotate) other mods that would like to affect the same things but not override the main mod could merge with them.

For instance, right now i'm working on a replacement for 'Save Skill Books' that is supposed to work regardless of the book script already there, which is a a task that doesn't use object specific data. This would be much easier with a MERG record.

2. The script format has nothing to do with the feature. At most, the 'multiplexing' of the 'system' callbacks is what would cause trouble for the MWScript interface, but that really has to occur anyway for the feature to work, MWScript or no MWScript. Indeed you're likely to want to run both types of scripts on the same object.

I know this suggestion is a lot of work and trouble, but i might as well throw it there: if you have trouble with MWScript regressions i suggest some form of integration GUI testing. You'd need a way to 'drive' user input from another program, get 'object properties from running openmw (to verify the behavior) then load a 'test' omwaddon, preferably with a null renderer and drive a series of tests. ie:

load game, interact with object with script testing feature Y, verify runtime object/take picture and compare to see if everything is the same/ok, repeat.


And currently there isn't a good experience running scripts in python or lua, since they require a MWScript trampoline shebang and since there are numerous functions that you have to call as string constructs. It'll maybe be worth it when you can save variables references/strings and save them on the savegame, but ofc, you actually can't get runtime references to strings from objects, even on other script languages (except by the abhorrent method of a chain of ifs) so it's pointless right now. The only other thing i'm thinking is fixing the broken functions like modstat on that interface since it would have no 'legacy'. Arguably those should already be there from copying the MWSE functions, though i hear that MWSE getStat still has the problem of not counting racial fortifications.
Post Reply