foamyesque

Deleting records out of *.esps is bad practice in general and will lead to odd behaviour, so you shouldn't do it. That said: To actually full-up delete something, you have to remove them from the original .esps in order to see things go away. What you've done is make a copy of one of the esps with the references gone, but because the original esp is still adding them, they're still there. As far as that last esp is concerned the records you deleted out of it simply don't exist and so it never tries to modify them at all, just as it wouldn't try to modify anything that was never edited in the first place. (Which makes sense, or else the entire Skyrim world would vanish whenever someone made a mod adding a piece of armour somewhere.) If you want to revert things to vanilla, or make them go away in game, without modifying the esps that originally place them, what you want to do is edit them in your override patch, not delete. If it's new material, you can usually simply flag it as 'starts disabled'. If it's something whose enable state isn't always-on by default (e.g., a guard in a hold that changes allegiances or something), it is a bit trickier and will need to be worked out case-by-case. Another possibility for statics is to just shift them down a few hundred points on the vertical axis, which will generally stuff them safely underground, but the disabled flag's simpler and cleaner. If it's modifications to vanilla you want to revert, you'll need to copy over the original vanilla fields to your override esp for that record.

First question: Does the package itself ever fire? Packages stack by order of quest priority, for example, so even if the conditions of your package are met, if another package higher in the stack also has its conditions met, yours won't be chosen. And follower AI packages are quest-driven, so they could very easily be overriding.

I wouldn't use scripts at all for simply scaling the power of a spell. You can do that by putting multiple effects on the spell, with a condition for each on checking for the level range of the caster at which it is active.

How reliable is this if there is a duplicate item already in the container?

As described the issue sounds very much like the LeveledItem is set to only generate one (randomized) item. Make sure it's set up correctly, like @dylbill suggested.

For questions like this it would be helpful to see the actual script. Could be something that changes from the first call and the looped calls, e.g. the player stops being set as the activator.

Then I think you might be stuck. I think you're going to need to edit more than just your projectiles to get this to work, since the Dawnguard bolts have the same issue. I might do some poking about and see if I can kludge up an answer via the approach I described for the unlock setup, but I'm not certain if it can be easily extended to arbitrary NPCs. I might be able to use OnEquipped to maintain a registry of who is of interest, I guess.

Well, that's a bit annoying. Not super unexpected, though. One of the things about the game engine is that magic effects can only apply to actors. I guess dead ones don't count, and the actual physical projectile damage hits first. @Shadohz might be on to something with the damage reduction idea, though. Perks can null damage out. Whether or not you can be selective enough to completely disregard the damage if and only if the strike is coming from your crossbow bolts I don't know; I'd have to dig into the conditions and do some testing. Also not sure if how it would interact with any possible enchantments on the firing weapon, but if those enchantments are processing I suspect your bolts will be as well. Of course, if you do this, then the bolt doesn't do physical damage any more, which is a bit janky. Another possibility, which I used to hack together an Unlock spell, is to cheat a bit. Put the player in a quest alias. If they have your bolts equipped, listen for the drawing animation (or in my Unlock spell's case, the casting one). When it happens, run another quest to stuff potential targets into quest aliases that listen for an on-hit event. If the on-hit event happens, trigger the explosions and such as you do in the magic effect. If you can't listen for the drawing animation I *know* you can listen for the firing one, but if so there's the possibility that the bolt will strike someone before the aliases are filled, which will break the effect. Drawing gives the scripts more time to work with.

I'm not aware of a good way to do that dynamically. However, I wonder how the Dawnguard exploding bolts are done, and if they have the same issue. If not, you could perhaps borrow from that implementation.

Yes, you should be able to. In fact, I'm not sure you need to alter the mannequin script at all (though you may need to). I'd start by giving them a new SitAt AI package -- there's a few ways to do this, but the simplest would be to just place a conventional mannequin somewhere and then put it in a quest alias -- and seeing if that works. The other bits of setting up a mannequin -- the triggerbox for activation, for example -- would need to be designed around the chair as well, but that's quite possible. I think what this *should* result in the mannequin being placed in the chair by the AI package, and then its script disabling its AI, freezing it in position.

I actually looked it up! GOQ is a non-delayed native function and therefore the fastest possible kind in the game short of direct operations like addition and whatnot. List of them here: https://www.creationkit.com/index.php?title=Category:Non-delayed_Native_Function So there's no real reason to avoid using it. It's still good practice IMO to stuff it into a variable if you're going to be using it multiple times, to save your fingers if nothing else :)

There is actually a performance difference. However, in most cases, it's unlikely to be dramatic. Properties get baked into saves, but many of the Papyrus functions (and GOQ is one, I believe) are tied to the frame rate of the game. So, for a given thread of the script engine, frame-linked function calls will always take at least one frame to return their result (multiple threads can process at the same time). This means that for stuff where you need to do a *lot* of things, in sequence, in a very short time -- inventory manipulation, for example -- you want to cut them to the minimum possible. However, a single call to GOQ will only take 1 frame. You can then store that in a variable on initialization of your alias, or whatever. if you need to access it repeatedly, and the performance impact is minimal.

My approach is to have a dummy effect, as you do, that tracks the cooldown. The other piece is having a second spell, with a magic effect that has a script that will cast the first spell whenever the effect is triggered. Then you put whatever conditions you want on that magic effect at the spell level. I used this, for example, to simulate the once-a-day restriction on power usage when I was making a mod allowing NPCs to use the same racial powers as the player.

I have used the everywhere option, but not for something as common as a static barrel. It works but I don't know if I'd want to stress-test the CK with that many things at once :v

In the CK? You can't, as far as I know. You can rename an objectreference in the cell view pretty easily without altering its display name, which helps a fair bit, but for specifically finding everything you've touched in a given cell you probably want TESVEdit.