Someone correct me if I'm wrong but If I use this mod along with EC, I'm assuming there will be plenty of scenarios where I'll both want to avoid spells and get hit by them depending on whether or not I want to regen magicka, that risk vs reward seems really appealing to me.
So I turned off my synthesis patch and tried out the newest version with skypatcher and the skypatcher version does not seem to cover friendly fire
More specifically my flame atronachs fire cloak, with the synthesis .kid file the friendly fire which is not doing health damage to my character is triggering spell absorb so I take no damage from my minion but gain mana as well as XP towards ligh
For now I've enabled the skypatcher and .kid file from synthesis and it's working as it was before which even then was a little odd, in combat my summons/followers with aoe spells will trigger spell absorb but out of combat they will not, however with only the skypatcher enabled and not the .kid file their aoe will behave this way out of combat too
Sorry for the wall of text, tried to explain this oddity as well as I could
I don't think it has anything to do with Skypatcher/Synthesis tbh. The interaction between allies' cloak spells and my mod's mechanics was just something that never crossed my mind until you mentioned it. I just changed the regen to not work if the source is an allies' cloak spell.
Fix is up now.
For any other weirdness, make sure you have the newest version of SkyPatcher (as SkyPatcher's recent update is the only reason this mod can work without Synth now).
That being said, if you choose to still use the Synthesis patcher, it'll still work. But it's entirely redundant now (provided SkyPatcher's update is truthful in doing what it say it does).
Thanks for the reply! I didn't realize skypatcher had an update so recently. The new version you uploaded works better than any other previous versions no .kid file needed and I no longer experience any friendly fire triggering the spell absorb, even in combat. You the real MVP! Thank you again
That's awesome! I love skypatcher! But that means we need to remove the patcher and redo the synthesis and delete the files related to synthesis spell absorption? I mean the file created after the synthesis patch is done, we need to remove it or it is removed automatic if we remove the patcher then rerun synthesis?
You technically don't need to do anything. There is no need to rerun anything.
If you want to clean up space you can delete the file made by the patcher, "SpellAbsorptionRework_AAA_SynthOut_KID.ini", and the actual patcher itself in the synthesis GUI. But if you don't delete them, it doesn't matter.
Well, i just did it. xD I simply disabled the patch in synthesis and reran it and deleted the ini file in data and all good. :) Good to know though thanks for the update too! :)
Do I need to run synthesis again for the 1.6 update or no need if i did it already? I know you told me already I don't need to rerun synthesis after updates but just want to be sure with your new 1.6 changelog.
For the issue you linked to, given from my experience with these types of po3-tweaks based mods, I'm 100% sure it has more to do with the perks themselves being distributed as opposed spid itself.
Spid/kid/whatever on their own don't cause latency. How they work is, when you first boot up the game (before the main menu), they distribute the perks dynamically. By the time you have loaded a save/are in-game, they aren't actively doing anything anymore and will not do anything further. From the game's perspective, it's the same as if the npc records themselves had always had those perks. It's like if spid itself created an esp and enabled it just before the main menu. (if that make sense).
What likely happened in your reddit post is that a perk(s) was added to npc that has scripts associated with it that are either themselves instesive or have functions that end up looping on themselves because they were never set up to be on that NPCs race/were meant only for the player. (Races have different headparts/attack data, so I could see a script trying to detect specific parts on a race it was never set to be on ending up with a ton a ton of latency.).
This isn't just conjecture. If you were to install all my mods simultaneously, you'll end up 200+ perks distributed to every NPC. To make sure this was a safe thing to do, in development I did a lot of stress testing, distributing literally thousands of perks to see if I could break the game. Besides making the initial game boot up milliseconds longer, there was no impact on performance/stability.
This is because of the reasons I listed earlier and the fact that none of my perks have scripts attached/associated with them, relying fully on native calls (which are infinitely faster than papyrus. I could only imagine native calls causing issues if you an ancient pc—like one that averages 10-20fps on unmodded Skyrim)
Now as for your question, adding those lines you suggest to the spid ini would make it so dragons would be unaffected by my changes and, beyond that, would also leave out all mod added NPCs that lack those keywords. I'd recommend leaving the inis as is or, if your really keen on limiting them, only adding exclusions.
I think your reddit post was in the right place, authors really should be careful distributing willy-nilly to everything in general, but it has more to do with what they are distributing.
Thanks for the thoughtful reply. In my testing over the last couple weeks I'm pretty sure that the perks were getting applied to NPCs when they are first spawned, not before. I determined this by putting debug.notification statements in all of the perk scripts that run when the perk is applied to the PC and to the NPC. When I loaded the game I got hundreds of notifications. After letting them scroll off, they would sporadically appear as NPCs got loaded into the game. When I went to whiterun (coc whiterunorigin) I got a flurry of notifications. After they scrolled off that pretty much stopped unless someone spawned into the game. In fact I saw an NPC spawn in front of me and that kicked off the notifications for that NPC. If the perks only get applied at game load and not dynamically, then none of the leveled list NPCs would ever get SPID perks because their refids are dynamically created in the FFxxxxxx range when they spawn (their refids are not in any plugin).
What you observed makes sense, perks don't do anything until they are attached to an NPC that is loaded in the world. If you attach a script to a perk/spell, then yes it won't fire until the npc its attached to is loaded in. Then the question becomes, (for those perks/spells that don't have scrips in the first place) is it the perks themselves causing latency or the debug notififcation? (This question kinda reminds of the double slit experiment lol, i.e. particles acting differently because you are observing them.)
As for distribution, I avoided getting into the weeds of it, but its a bit of both. See below from the SPID page:
When Distribution happens?
Distribution of forms is split into two steps:
Persistent static (not scaling with Player's level) NPCs are distributed to on Main Menu load.
Dynamic leveled NPCs are distributed to as they are loaded in the world (typically, on cell load).
Majority of NPCs in cites, what you said you tested on, fall into that persistent category, acting how I described earlier.
As for the others, here's what isn't mentioned. SPID actually makes a list of all the possible variants of leveled NPCs before you load into the game, and essentially creates an internal database of what perks/spells/keywords each of those npcs needs. Then, when you load near one, it applies them. Since the majority of the work for this process was done before you encounter the NPC, the addition of the perks/spells/keywords to NPCs on load has next to no performance impact as the functions already "know" what they need. It's very well optimized.
You can check out spid's source too if interested. I think if you go the route of debugging/trace notifications, you will need to do so through editing spid's source as opposed to papyrus. (that way papyrus' inherit latency can be taken out of the equation). I'd be very interested in seeing the result of that.
oh I see what you're saying now. So the perk is already applied, but the perk script doesn't get run until spawn time. That makes perfect sense because how can a script get run for an object that hasn't been instantiated yet. Sasnikol (SPID supporter) already pointed this out to me in Reddit but it didn't sink in until now. Thanks for your patience. :)
Also, that was a good idea about the debug.notification test itself adding stress. That probably happened during the debugging phase, but the stress was tanking my game before I did the debugging which is why I went looking.
Yeah no problem! Only reason I know this stuff is because I had to basically reverse engineer how perks in general work for one of my mods and then, for another, I had to dig through the SPID source directly to understand it. A lot of this stuff isn't really common knowledge/written anywhere.
Again, I think your reddit post still has a point. Like I mentioned on that PSA I did on KID keywords, modders are too eager to distribute things to all NPCs without fully understanding the consequences of doing so. In your case, it seems like a perk that has no right being on certain NPCs was distributed to them anyways, causing issues.
If we run the synthesis patcher to dynamically generate the new KID.ini file, do we still need these other 2 KID files from the install or can we delete them?
You can delete SpellAbsorptionRework_AA_PregeneratedExclusions_KID.ini . Leave the others ones. The patcher just adds the exclusion keyword to spells that need it. The other inis distribute mechanic related keywords to everything that doesn't have the exclusion keyword.
136 comments
More specifically my flame atronachs fire cloak, with the synthesis .kid file the friendly fire which is not doing health damage to my character is triggering spell absorb so I take no damage from my minion but gain mana as well as XP towards ligh
For now I've enabled the skypatcher and .kid file from synthesis and it's working as it was before which even then was a little odd, in combat my summons/followers with aoe spells will trigger spell absorb but out of combat they will not, however with only the skypatcher enabled and not the .kid file their aoe will behave this way out of combat too
Sorry for the wall of text, tried to explain this oddity as well as I could
I don't think it has anything to do with Skypatcher/Synthesis tbh. The interaction between allies' cloak spells and my mod's mechanics was just something that never crossed my mind until you mentioned it. I just changed the regen to not work if the source is an allies' cloak spell.
Fix is up now.
For any other weirdness, make sure you have the newest version of SkyPatcher (as SkyPatcher's recent update is the only reason this mod can work without Synth now).
That being said, if you choose to still use the Synthesis patcher, it'll still work. But it's entirely redundant now (provided SkyPatcher's update is truthful in doing what it say it does).
Thanks a lot!
I mean the file created after the synthesis patch is done, we need to remove it or it is removed automatic if we remove the patcher then rerun synthesis?
Oh and save to update midsave?
If you want to clean up space you can delete the file made by the patcher, "SpellAbsorptionRework_AAA_SynthOut_KID.ini", and the actual patcher itself in the synthesis GUI. But if you don't delete them, it doesn't matter.
I know you told me already I don't need to rerun synthesis after updates but just want to be sure with your new 1.6 changelog.
Thanks for the update! :)
Perk = 0x800~SpellAbsorptionRework.esp|ActorTypeNPC,ActorTypeUndead|NONE|NONE|NONE|NONE|NONE
Perk = 0x816~SpellAbsorptionRework.esp|ActorTypeNPC,ActorTypeUndead|NONE|NONE|NONE|NONE|NONE
Spell = 0x813~SpellAbsorptionRework.esp|ActorTypeNPC,ActorTypeUndead|NONE|NONE|NONE|NONE|NONE
Spell = 0x814~SpellAbsorptionRework.esp|ActorTypeNPC,ActorTypeUndead|NONE|NONE|NONE|NONE|NONE
I'm asking because I don't want to have this problem.
Spid/kid/whatever on their own don't cause latency. How they work is, when you first boot up the game (before the main menu), they distribute the perks dynamically. By the time you have loaded a save/are in-game, they aren't actively doing anything anymore and will not do anything further. From the game's perspective, it's the same as if the npc records themselves had always had those perks. It's like if spid itself created an esp and enabled it just before the main menu. (if that make sense).
What likely happened in your reddit post is that a perk(s) was added to npc that has scripts associated with it that are either themselves instesive or have functions that end up looping on themselves because they were never set up to be on that NPCs race/were meant only for the player. (Races have different headparts/attack data, so I could see a script trying to detect specific parts on a race it was never set to be on ending up with a ton a ton of latency.).
This isn't just conjecture. If you were to install all my mods simultaneously, you'll end up 200+ perks distributed to every NPC. To make sure this was a safe thing to do, in development I did a lot of stress testing, distributing literally thousands of perks to see if I could break the game. Besides making the initial game boot up milliseconds longer, there was no impact on performance/stability.
This is because of the reasons I listed earlier and the fact that none of my perks have scripts attached/associated with them, relying fully on native calls (which are infinitely faster than papyrus. I could only imagine native calls causing issues if you an ancient pc—like one that averages 10-20fps on unmodded Skyrim)
Now as for your question, adding those lines you suggest to the spid ini would make it so dragons would be unaffected by my changes and, beyond that, would also leave out all mod added NPCs that lack those keywords. I'd recommend leaving the inis as is or, if your really keen on limiting them, only adding exclusions.
I think your reddit post was in the right place, authors really should be careful distributing willy-nilly to everything in general, but it has more to do with what they are distributing.
As for distribution, I avoided getting into the weeds of it, but its a bit of both. See below from the SPID page:
Majority of NPCs in cites, what you said you tested on, fall into that persistent category, acting how I described earlier.
As for the others, here's what isn't mentioned. SPID actually makes a list of all the possible variants of leveled NPCs before you load into the game, and essentially creates an internal database of what perks/spells/keywords each of those npcs needs. Then, when you load near one, it applies them. Since the majority of the work for this process was done before you encounter the NPC, the addition of the perks/spells/keywords to NPCs on load has next to no performance impact as the functions already "know" what they need. It's very well optimized.
You can check out spid's source too if interested. I think if you go the route of debugging/trace notifications, you will need to do so through editing spid's source as opposed to papyrus. (that way papyrus' inherit latency can be taken out of the equation). I'd be very interested in seeing the result of that.
Also, that was a good idea about the debug.notification test itself adding stress. That probably happened during the debugging phase, but the stress was tanking my game before I did the debugging which is why I went looking.
Again, I think your reddit post still has a point. Like I mentioned on that PSA I did on KID keywords, modders are too eager to distribute things to all NPCs without fully understanding the consequences of doing so. In your case, it seems like a perk that has no right being on certain NPCs was distributed to them anyways, causing issues.
SpellAbsorptionRework_AA_PregeneratedExclusions_KID.ini
SpellAbsorptionRework_B_KID.ini
.
Leave the others ones. The patcher just adds the exclusion keyword to spells that need it. The other inis distribute mechanic related keywords to everything that doesn't have the exclusion keyword.