Stopping non-hostile cloak spells from triggering the invisibility is a good idea in principle, however it has the potential to create a different problem. Because the seeker will stay invisible it will continue to receive these OnHit events, and if there are multiple seekers and multiple cloaks on the player these can start to rack up. This is an image from the vanilla scripting enhancements mod page. link The OnHit in the vanilla MQ304AlduinScript is probably heavier than the OnHit in this seeker script though.
The cloak spells triggering the invisibility isn't really your problem to fix either. If a mod has such an invisible cloak, at a 99 % probability it should be setup to not trigger hit events anyway.
So what you're saying is, if I want the best of both worlds, I'll need to go the Vanilla Scripting Enhancements route and use OnHitEx, but that would increase complexity and add an additional requirement to the script, which I don't want.
The OnHit in this script is very basic and I doubt it will ever cause such issues though, especially when it's only firing in the waiting state which shouldn't ever last long enough for that to become a concern anyway. That being said I don't want to completely ignore your advice, just unsure how to proceed with this.
Because the seeker will stay invisible it will continue to receive these OnHit events
Yesn't. The Seeker will eventually become visible again, which will stop the OnHit events from being triggered because the state changes. Generally speaking, it is very easy to prevent OnHit from being a massive pain in the rear by either a bool filter or a state filter, with the possibility of even locking up the script if things get out of control.
While not perfect, you can also look at Molag's Will for how to "lock a thread" and prevent other events from being processed while you are doing something with OnHit/something that shouldn't happen multiple times (the MWT_UtilityScript).
1. The update value is too conservative for the speedmult. Given how few the instructions are, you can probably safely set it to something like 0.1. 2. Optimizing the script by introducing hardcoded values instead of properties instantly makes it incompatible with any mod that uses the script, but changes the values and the performance gain probably cannot be measured. I highly suggest reverting that. 3. I haven't toyed with the script before, but I am a bit weary of the OnHit event. I know it is vanilla, but my concern is that it may be triggered by non-hostile cloak spells. Basically... please add a hostile check, I'd like that improvement a lot lol
Thanks for the feedback. The values are hidden properties, so they can't be changed by mods, but I get where you're coming from - will revert that and change the property types instead. As for the OnHit, you mean to only call the GoToState if akSource is a hostile spell, right? Will do.
Shekhinaga in a simple script that contains a non-latent function with a passed int when it expects a float it is around a 10% difference in speed(this example isn't waiting for syncronization delays so it has the largest difference).
If you look through the Vanilla (Micro) Script Optimization posts you can find Subhumans tests on this issue he got 12% difference but that will shift a bit. He used RegisterForSingleUpdate(1) -> RegisterForSingleUpdate(1.0).
Basically you would be surprised how big the differences is.
I adore that hot file modders on this Nexus specifically always seem to interact with eachother this way. It's so wholesome and funny at the same time (remember the hot file snake? That was awesome)
Give Feedback
136 comments
Noice
The cloak spells triggering the invisibility isn't really your problem to fix either. If a mod has such an invisible cloak, at a 99 % probability it should be setup to not trigger hit events anyway.
The OnHit in this script is very basic and I doubt it will ever cause such issues though, especially when it's only firing in the waiting state which shouldn't ever last long enough for that to become a concern anyway. That being said I don't want to completely ignore your advice, just unsure how to proceed with this.
Yesn't. The Seeker will eventually become visible again, which will stop the OnHit events from being triggered because the state changes. Generally speaking, it is very easy to prevent OnHit from being a massive pain in the rear by either a bool filter or a state filter, with the possibility of even locking up the script if things get out of control.
While not perfect, you can also look at Molag's Will for how to "lock a thread" and prevent other events from being processed while you are doing something with OnHit/something that shouldn't happen multiple times (the MWT_UtilityScript).
1. The update value is too conservative for the speedmult. Given how few the instructions are, you can probably safely set it to something like 0.1.
2. Optimizing the script by introducing hardcoded values instead of properties instantly makes it incompatible with any mod that uses the script, but changes the values and the performance gain probably cannot be measured. I highly suggest reverting that.
3. I haven't toyed with the script before, but I am a bit weary of the OnHit event. I know it is vanilla, but my concern is that it may be triggered by non-hostile cloak spells. Basically... please add a hostile check, I'd like that improvement a lot lol
If you look through the Vanilla (Micro) Script Optimization posts you can find Subhumans tests on this issue he got 12% difference but that will shift a bit. He used RegisterForSingleUpdate(1) -> RegisterForSingleUpdate(1.0).
Basically you would be surprised how big the differences is.
https://www.nexusmods.com/skyrimspecialedition/mods/89500/?tab=posts
Didn't post it here because didn't want to put adult content to this section too.