A few suggestions concerning containers for the ESX format:
Animations and Sounds:
Basically, it would be super if you could add animations and sounds when you activate a container. If a container has an animation and/or sound set in its properties box, then they would play when you click the container, and when they finished, the container window would open. This would basically allieviate all the scripting hacks that you have to go through to do something similar like in the "Morrowind Containers Animated" mod.
Alternative models: In addition to the above animation and sound possibilities, it would also be great to be able to simplify "Graphical Herbalism" mods. Their basic premise is that once you empty a container (usually plants) the model of the container is replaced or removed; if its contents respawn (like in plants and guild chests), then the original model is replaced. The basic premise for this part of the suggestion would be to give containers a check box in their preferences that allows you to enter another mesh that replaces the original when the container is empty (or just removes the container for the duration if no alternate model is entered).
Lastly, to complement the above suggestion, my final container improvement would be to give a check box in the container preferences that allow one click gathering so that items such as plants (or whatever the mod maker wished) could be emptied into the player's inventory with a single click.
I believe these improvements would go a long way to improving the moddability of containers.
Container improvements
Re: Container improvements
Might be easier to just let container models have an animation with a specific name, which is automatically run when activated, and when the animation is finished it pops up the container UI. When the container UI closes, another specifically-named animation is run. The animation info contains the keys used to invoke sounds already. This could be done for general activators too, e.g. teleport doors.Greendogo wrote:Animations and Sounds:
Basically, it would be super if you could add animations and sounds when you activate a container. If a container has an animation and/or sound set in its properties box, then they would play when you click the container, and when they finished, the container window would open. This would basically allieviate all the scripting hacks that you have to go through to do something similar like in the "Morrowind Containers Animated" mod.
This way, there wouldn't be any need for extra ESX data.
IIRC, plants and stuff already have a special flag that prevents you from placing anything in it. Would that be good enough to detect "auto-transfer" containers? The visual change could probably also be handled by an animation that's run when activated. Or maybe toggling visibility on specific nodes in the model.Alternative models: In addition to the above animation and sound possibilities, it would also be great to be able to simplify "Graphical Herbalism" mods. Their basic premise is that once you empty a container (usually plants) the model of the container is replaced or removed; if its contents respawn (like in plants and guild chests), then the original model is replaced. The basic premise for this part of the suggestion would be to give containers a check box in their preferences that allows you to enter another mesh that replaces the original when the container is empty (or just removes the container for the duration if no alternate model is entered).
Lastly, to complement the above suggestion, my final container improvement would be to give a check box in the container preferences that allow one click gathering so that items such as plants (or whatever the mod maker wished) could be emptied into the player's inventory with a single click.
Re: Container improvements
Great, sounds good to me!Chris wrote:Might be easier to just let container models have an animation with a specific name, which is automatically run when activated, and when the animation is finished it pops up the container UI. When the container UI closes, another specifically-named animation is run. The animation info contains the keys used to invoke sounds already. This could be done for general activators too, e.g. teleport doors.
This way, there wouldn't be any need for extra ESX data.
That's a good point. OpenMW could just offer the option to automatically "Take-All" for containers tagged as "organic". You don't really need the inventory menu for organics, since you're not going to be transferring anything back into them, and you usually aren't going to be picking and choosing only specific items to put into your inventory.Chris wrote:IIRC, plants and stuff already have a special flag that prevents you from placing anything in it. Would that be good enough to detect "auto-transfer" containers? The visual change could probably also be handled by an animation that's run when activated. Or maybe toggling visibility on specific nodes in the model.
The visibility thing could definitely be handled by an animation, just like the first case. However, it might conflict if you ever wanted to have a container play an activating animation, and then have an empty animation when you empty it, and then it would need to play another animation for closing.
But that's probably OK. If I'm understanding your ideas correctly, you seem to have figured out a good way to make these container improvements work without an additional ESP, with just a few tweaks to the engine. Nicely done!
Re: Container improvements
That seems like the most logical way of doing it. Would work pretty much the same as in TESV, however, it would be much nicer if the menu appeared instantly instead of waiting for an animation to play. The animation can play while a menu is open i imagine.Chris wrote: Might be easier to just let container models have an animation with a specific name, which is automatically run when activated, and when the animation is finished it pops up the container UI. When the container UI closes, another specifically-named animation is run. The animation info contains the keys used to invoke sounds already. This could be done for general activators too, e.g. teleport doors.
It probably sounds silly but one of the most tedious things about TESV is having to wait for a book to finish playing a lengthy animation every time you try and open it. Same goes for containers.
Re: Container improvements
I agree with this person.SGMonkey wrote:That seems like the most logical way of doing it. Would work pretty much the same as in TESV, however, it would be much nicer if the menu appeared instantly instead of waiting for an animation to play. The animation can play while a menu is open i imagine.Chris wrote: Might be easier to just let container models have an animation with a specific name, which is automatically run when activated, and when the animation is finished it pops up the container UI. When the container UI closes, another specifically-named animation is run. The animation info contains the keys used to invoke sounds already. This could be done for general activators too, e.g. teleport doors.
It probably sounds silly but one of the most tedious things about TESV is having to wait for a book to finish playing a lengthy animation every time you try and open it. Same goes for containers.