openmw.org

There is a recent feature request on the bugtracker.
It is a pretty bad described, but the main idea which makes since: there are a couple of must-have mods, such as Animated Containers and herbalism mods, which attach scripts to every container. It is a good source of conflicts with other plugins, especially with massive landmass mods or total conversions.

There are two possibilities for us here:
1. Such things should be handled via event-based scripting to make them more configurable.
2. Such things should be baked to the engine itself (as in later TES games) to make sure they work properly without any additional programming by content developers.

I am fine with either options, both have pros and cons, and both of them will allow to get rid of a batch of copy-pasted scripts, attached to every object.
But which option is preferred and how should we handle such feature requests?

Well, that is post-1.0 stuff. So tag it as such and forget about for now. Feel free to improve the description.

Everything else depends on how post-1.0 scripting will work which is a discussion I really meant to get back to but just haven't got around to it. But off the cuff I would suggest to go with both the options you suggested. Build-in option for easy of use and simplicity with the ability to use a scripting solution in case the default solution isn't sufficient.

Since i opened the bug i'm clearly on the side of 'this should be engine stuff'.

Currently, certain - but not all - of the mods that target a 'class' of objects to attach scripts are a very common source incompatibilities. In the case of animated containers, because it targets all containers, it interferes with all quests that have the idea of attaching a script to the container to check for some item or generate some functionality.

Examples: Uvirith's Legacy, quest tweaks and alternatives, probably library portable, probably some herbalist mods etc. This manifests as needing to put in Animated Containers before some quest and some utility mods (as long as mlox recognizes the problem, which it doesn't for 'quest tweaks and alternatives' for instance).

Worse, since animations are very much a 'object by object' replacement mod, making a 'post install' alternative that simply doesn't attach a script if a script is already attached would be merely replicating the original mod enumeration of nif-and-script-replacements except for that detail.

A engine animation scheme on the other hand would be consistent, and even if another mod or quest added a script, the container would behave the same as the others and would (probably) be taken in consideration for meshes replacements.


There are other problem flashpoints (book rotate is another hard one, that should be added to every book but needs a complicated script and compatibility patches for other mods - bookrotate can almost be a generic script, if it hadn't some constants per book mesh and alternates for 'open' book meshes - to the point it needs a alternate esp for jacket replacements), but i think it would be a unequivocal good to add this for animated containers so that scripting has no influence on this and the (basically cosmetic) mod doesn't interfere with quests and can be folded in the mesh replacement hierarchy without problems.

Then again, it would also be a unequivocal good to add a version of OnActivate which isn't stupid but that ain't happening.

A big part of the decision with this kind of thing is planning for the mystical post-1.0 dimension. When that happens, it'll be much easier to attach multiple scripts to the same object (as not offering that possibility causes the mod incompatibilities you mentioned, and we don't want that). That means that if we haven't implemented native animated containers by the time the script system is revamped, a lot of people won't care any more as there'll be another way of doing things.

That makes the main arguments in favour of a native system basically:

• Akortunov can (probably) start work on it right away.
• It'll probably be faster (although potentially not enough to measure - Lua's supposed to be really fast).
• It's not an either-or - modders who aren't happy with the native system can make a scripted one that behaves exactly as they want once that's possible.
• Anything else I've not thought of.

I'm very much of the opinion we should use the "both, and" method. Even if post-1.0 we can attach multiple scripts, I still think a native option is necessary. The benefits of ease of use cannot be overstated. Attaching scripts to several objects gets incredibly tedious and just increases the likelihood of errors, which increases the likelihood of bugs. Moreoever, many modders would prefer to not have to deal with scripts. A model/texture artist is not necessarily going to be keen to also write code, and it would be a shame to limit the artistic potential of mods because of it.

I for one was super excited when Oblivion introduced all the buttons and animated traps/secret doors/etc that were easy to link together. No reason to have to dick around with scripting for something so simple. I imagine we could come up with a more elegant system than they had, but a built in system still opens up doors for a lot of more modders.

Animated containers and graphic herbalism are great examples of the types of mods that always get made if they aren't natively supported along with survival, cooking, stationary alchemy, secret doors, glowing windows, mounts/vehicles, followers, mannequins, book/object placement, etc. I think for things that have relatively little variation in possible or effective implementation, we should definitely offer in-engine support, e.g animated containers, glowing windows, alchemy, graphic herbalism. For things that have a bit more variation, it would be nice to have a hybrid where certain aspects are made simple with easy extensiblity via scripting, e.g buttons, mounts/vehicles, object placement. I believe this is what Skyrim did so that it was easier to allow both single use and timed buttons for gates/secret passages while still providing relatively easy use. For things where implementation can vary widely, it makes the most sense to maybe have some features built-in, but leave most of the implementation to scripting, e.g. survival, followers. Not saying these are the ideal categories for some of these types, but this is the breakdown that makes sense to me.

Since animated containers now in master, I uploaded used files to Nexus.

Also there is a prototype of graphics herbalism.
The main idea is to mark some nodes in a container mesh (or the root node in the simpliest case) as "harvestable" via NiStringExtraData with "HBN" value.
If the container has model with such node, OpenMW places its content to player's inventory on activation without opening the container and hides "harvestable" nodes.
In this case there is no need to modify container records, spawn new objects via scripts or provide separate meshes for looted containers.
Not sure if it should be baked into the engine, though.
Also I wonder how this feature is implemented in Skyrim.

0.46 is not released... 0.45 also isn't released.

Won't this be a problem for end users/players who want to use the mod?

I mean, I think this is great work, but I don't want people thinking that 0.46 is already out.

psi29a wrote: ↑19 Dec 2018, 14:59 0.46 is not released... 0.45 also isn't released.
Won't this be a problem for end users/players who want to use the mod?

Previously we increased OpenMW version only after release, but now master branch already has the 0.46 version, so I do not know what to do here.