Trigger boxes on rare occasions seem unreliable - is there a trick to them?

[dafydd99]

Hi all,

I've had a couple of issues raised with trigger boxes on rare occasions not activating in my mods. Now I'm aware of these issues, so avoid them...

• don't have 'zero' rotations in player activated trigger boxes as there seems to be an occasional low level bug
• onTriggerEnter and onTriggerLeave events may not fire in order

However,  the two situations I've had reported issues from are with an 'onTriggerEnter' not firing as the player enters, and an 'onTriggerLeave' not firing as an object is removed from a pedestal. Both seem rare, and I haven't been able to duplicate, but they block quest progress, so of course ideally they'd totally bug free. Is there a 'best practice' use of them, eg perhaps doing something in 'onCellAttach' to maximise the chance of them working?

Thanks for any responses,

dafydd99

[IsharaMeradin]

If you cannot replicate the issue on your end with everything else being stock settings, objects, etc..., then the issue lies on the user's end. There are things that you could possibly do for certain scenarios but without the end user being more forthcoming with information, you will never be able to make a mod that is "bug free" in all situations.

You can make your trigger boxes bigger.  A larger box might be more accommodating to some modifications a user might make on their end.

OnCellAttach and OnCellDetach may not be best, these events will trigger when the player is not within the cell in question and possibly even further away from the cell than expected.

If the player is taking an object from a pedestal and that object is entering the player inventory, you can use a player alias script with an inventory event filter that uses the OnItemAdded event and triggers your stuff when the object gets picked up and then shunts the script into a state that uses a blank OnItemAdded event so that nothing gets triggered should the player try moving the item in and out of the inventory.

I"m sure others may have some thoughts on the matter, feel free to wait for other ideas.  Mine are not always the best in every scenario.

[dafydd99]

Thanks IsharaMeradin! That's all good stuff.

I suppose I'm a little worried when I get just a few people having difficulty, that's actually just the tip of the iceberg, and hundreds have had the problem but simply haven't got in touch about it and given up. I try generally to just use standard assets and scripts, plus my own, to minimise chances of clashes with incompatible mods - but I feel there's more I could do.

Yes I'm certainly a fan of the 'belt and braces' approach - eg in your example I could do both the onTriggerLeave event and the onItemAdded - first one triggered progresses the quest, second if triggered is just a backup. But at the same time it would be nice to understand in what situations a triggerbox hasn't worked.

Re OnCellAttach - yes for sure, just using that as an example. Eg perhaps someone has identified that disabling, then re-enabling a triggerbox in an onCellAttach event might avoid a problem, or maybe more than twenty in a cell could cause issues or some too close to each other etc.

Perhaps this is a part of a bigger question. I would love to find a document on 'skyrim bugs, gotchas and limitations' - simple things that you might do without realising there's an issue with the underlying engine that can cause problems when you least expect it, or that it was only ever designed to deal with eg 10 of something, and as soon as you go to 11 odd things start to happen.

Eg - three issues/bugs I've identified (after many hours of investigations!) are:

- using .kill() on an actor seems to cause a CTD when used frequently - often after around 50 actors or so have been killed. Whereas simply causing them a lot of damage (and thus killing them that way) via DamageActorValue avoids this problem completely.

- disabling a water object in an exterior cell can cause a CTD if it exists on the world map - if you need to, you should translate it to somewhere under the ground, rather than disable it.

- 'ambushes' sometimes silently don't set themselves up correctly because they're having a problem interpretting the navmesh. Even if the navmesh doesn't actually return any errors - and in fact is apparently 'fine'. By trial and error you can find the issue is with a triangle many rooms away that's part of the same navmesh.

Ah well, I can dream!

Edited January 9 by dafydd99