In this thread: http://www.gamesas.com/topic/1349554-bethesda-please-i-will-only-ask-one-question-of-you-for-the-rest-of-my-life-adding-perks-to-actors-other-than-the-player/

we were talking about how to add perks to all actors without the need to manually attach them to every single actor using the CK. Unfortunately, I still haven't found a way to get that to work, but using a method discussed in that thread (thanks to kuertee for his ideas!) I DID manage to dynamically add Papyrus scripts to all actors near the player (and they'll be remove again when the actors are dead, but that can be prevented as well if necessary). This same procedure should also work for adding items, spells and factions because these fields are also available in quest aliases, but unfortunately there is no place in quest aliases to add perks.

<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>

- Requirements: 2 Quests, let's call them ''UpdateQuest'' and ''AliasesQuest''.
- First we create AliasesQuest, with a priority 99, Start Game Enabled (not necessary but probably best)
- For testing I added 3 Quest Aliases, but for a final version this should probably be changed to 10 or 15 or something, depending on how many actors you want to support your functionality for in your mod.
- The first Quest alias for my testing was PlayerAlias, with as Fill Type ''specific reference'' (and then go to (any cell) and pick PlayerRef) and a Papyrus Script attached (I wanted the player to have a different script from all other actors). (THIS IS A REFERENCE ALIAS, NOT A LOCATION ALIAS)
- Now we create our second Alias, (ALSO REFERENCE ALIAS) named CombatAliasNPC1. Fill type ''Find Matching Reference'' with ''In Loaded Area'' checked (because we don't need to attach our script to an NPC in solitude if the player is in whiterun), and ''Closest'' checked (because I'm making a combat mod, and therefore the closest NPCs are more important to actually get a script than NPCs further away).
Also (VERY IMPORTANT!) check the ''Optional'' flag. If this isn't checked, the quest will fail to update aliases when there are no living NPCs nearby. If scripts also need to be added to dead actors, check the ''Allow Dead'' flag, but I left it unchecked because this was unncessary for me.
We have one condition in ''Match Conditions'', which is ''IsActor == 1'' (running on Subject), because we don't want our script to be attached to for example a chair which happens to be nearby.
And finally, we attach a second Papyrus script (different from the player, because I WANT it to be different). For testing purposes, this is a very simple script:

Scriptname CombatAliasNPCScript extends ReferenceAlias  Event OnHit(ObjectReference akAggressor, Form akSource, Projectile akProjectile, bool abPowerAttack, bool abSneakAttack,  bool abBashAttack, bool abHitBlocked)    Debug.MessageBox("This actor is quest alias!")EndEvent

- Back in the quest aliases tab, right click the CombatAliasNPC1 and click ''Duplicate''. Change the name of this alias to CombatAliasNPC2 and leave the rest as it is. Even though both NPC aliases have the ''Closest'' flag checked (which means they are filled with the closest NPC), the quest will still fill TWO NPCs (as opposed to filling both aliases with the same, closest NPC) because neither alias has the ''Allow Reuse in Quest'' flag checked.

- Click ok in the Quest Editor, because this quest is finished now. And then create the second quest, which we'll name ''UpdateQuest''. Update Quest also has a priority of 99 and this one MUST have ''Start Game Enabled'' checked.
- In the Quest Stages tab, create a new quest stage (0), create a new Log Entry (leaving it empty). Tick the ''Start Up Stage'' flag for this quest and add one line to the Papyrus Fragment:

RegisterForUpdate(5)

-Don't forget to click compile after adding this line of code. The ''5'' is the amount of seconds it takes to update. A smaller amount of seconds means the game will attach scripts faster when entering new areas or when actors near the player get summoned, but it also means scripts have to run more often. So you need to make a decision here: Is it more important to update scripts as soon as possible (use a low number) or is it more important that this mod keeps game performance as high as possible (use a high number). Generally the performance impact shouldn't be noticeable because only a couple lines of code are executed on each update, but it's still something to take into consideration.

- Go to the Scripts tab in this quest and attach a new script. This is the code I used in this script for testing:

Scriptname UpdateQuestScript extends Quest  Quest property AliasesQuest autoEvent OnUpdate()    AliasesQuest.Stop()    Utility.Wait(0.5)    AliasesQuest.Start()EndEvent

- Compile the script and don't forget to attach the AliasesQuest as a property to the script. I'm not entirely sure whether the ''Utility.Wait(0.5)'' line was necessary or not, didn't try without it, but it shouldn't hurt anyway. Now because of the Papyrus fragment in the startup stage this quest will update every 5 seconds, and every time it updates it will stop the AliasesQuest (clearing it's aliases and therefore removing all the scripts from actors again) and 0.5 seconds later start the quest again (allowing it to generate new Aliases in case the player is now in a different location or new actors have entered the scene through for example summons).

<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>
Now I went on to test the mod. My last saved game happened to be in a place where at least one dead enemy was near me and my companion was near me. Hitting the dead enemy didn't produce any messageboxes (so he didn't have the script on him) and hitting my companion did (so she did have the script). Killing my companion and then hitting her body showed that messageboxes no longer appeared (might have to wait up to 5 seconds for the updating though). Resurrecting the dead bandit using the console and hitting him produced messageboxes, so he had received the script after getting resurrected. As a last test I used the console to resurrect both my companion AND the bandit, and they both generated messageboxes after hitting them, so they both had the script attached correctly (more NPCs wouldn't have worked because I used 2 NPC aliases for testing).

Cool! Thanks Borgut!
I was gonna get to "finding actors" soon enough. Glad that you got it tested!
It helps heaps.

No thank you for launching the idea, it's gonna help my Deadly Combat mod loads I used to have just the player alias with a script with an OnHit block so I could make the player stagger when hit, have stagger chances vary based on whether it was a melee hit, bow, magic etc, and allow timed blocking. However, I couldn't get scripts on enemies so to have the player stagger enemies I used a perk with an Apply on Combat Hit spell. Now recently I figured out that the game only allows one perk per actor to actually use the spell on combat hit, so vanilla perks like bleeding etc all stopped working because of my mod.

Now I'll be able to put OnHit events on all actors and stagger them that way, so no longer need the perks and can more easily get more advanced reactions depending on lots of variables

Thanks to both of you for figuring this out. I had wanted to add a setting to my follower mod to have the follower only attack after the player has initiated an attack, and this will help a great deal.

As you know I have given up on the perks. So I will make scripts to replicate the perks I need. All the ones I need I already made in oblivion anyway, so I have a good idea how I may do so in skyrim.

How do I change your procedure to KEEP the script on the NPC forever? I do not want it to be removed because I do not want some variables to get set back to zero in their scripts.

Thanks!

Using quest aliases, you can't have a dynamic number of attached scripts. What you could do instead, though, is create an ability to apply to actors that has only a scripted effect. Scripts extending http://www.creationkit.com/ActiveMagicEffect_Script are sent updates from the http://www.creationkit.com/Actor_Script on which their effect is running, so it could function just like a script on the actor.

Cipscis

Ya i agree with Cipscis, could attach a Ability to the actors and make your own Keyword so you can detect if the actor is running the script or not, thss way it does not duplicate, i would take a look at http://www.creationkit.com/FindClosestActorFromRef_-_Game and http://www.creationkit.com/HasMagicEffectWithKeyword_-_Actor

Small example
The following code checks to see if the target is in combat, line of sight, not dead, and has our keyword (ActiveMagicEffect that has a Keyword that holds the script to apply). If you want the script to be a constant effect until it is dead or whatever, just place the ability rather than a spell, but if you want it to be a short duration just use a normal spell and place the duration effect onto it then the script will be applied until the effect wears off

How do you give other actor abilities from script? simple use http://www.creationkit.com/AddSpell

but...If I was going to do that why not just use tokens instead?

Or will token with scripts not work the same way they did in Oblivion? Is it not possible to get the ref of the actor that holds the token from inside a token script in skyrim?

Going back to spells seems antil progressive in that was how we did things originally in Oblivion and that was a big mess for even the best moders, tokens turned out to be far more reliable.

The nice thing about spells is that their scripts will be sent events from the actor on which they're running. So, for example, a spell could detect an OnHit event, whereas a token couldn't.

Tokens are entirely appropriate for some things, but there are a lot that will require spells.

Cipscis

ok, so tell me if I have this right:

Spells have functions that tokens do not (at least until SKSE can make them) such as onhit event detection.

Scripts on the actor using kuertee and Borgut's process also can detect onhit events .... no?
BUT I cannot keep scripts on the actors forever, I will have to attach them again and again because that ...er I did not really understand WHY they cannot stay on the actor forever. You said they cannot but not really why they cannot...


These temporary scripts and spells cannot have "memory" type variables in them, well that CAN but they will get wiped clean each time they are attached again to the actor.

So it looks like I will have to wait for SKSE to give me the functions I need for tokens.
In the mean time it seems that explosion scripts are the easiest way to attach temporary scripts to a cell full of actors, so why is kuertee and Borgut's process better than explosions? (I am assuming it is or they would just use explosions.)

Perhaps because some actors are immune to AOE spells? That was one of the issues in Oblivion with using AOE spells to attach scripts to actors.

So what you are saying is use kuertee and Borgut's process to attache abilities to the actors that have the script I need...right?
This what ALL the actors can get the scripts I want put on them, and they will stay on them forever?

The only thing I do not get is the Memory.....right?


wow...what a hassle all this is just to get each actor my script...I am really going to miss Token scripting.

Excuse me if i'm wrong but, isn't it possible to do all that with only one Quest ? Using ForceRefTo in a script, and others functions to return the Ref you want to use your Alias ?

Using this method you cannot keep scripts on actors forever. Actually I think using the method you tried previously but replacing ''AddPerk'' with ''AddSpell'' would work and permanently add spells to everyone. The reason I didn't do this is that I wasn't aware that ActiveMagicEffects scripts can use OnHit events.


Maybe, though then you'd have to loop through the location in a script to find all actors. Using my method the game automatically finds the actors itself.

This is a pretty nice method you have posted here, perhaps if you have free time you could put the guide on the wiki rather than it be lost to the depths of the forum. I think it would be better however if there were some way to purge the referenceAliases that are redundant (different cell (interior only), beyond certain distance etc...) rather than getting rid of everything and starting over.

Personally I use an AOE spell with magicEffect that has a script and reads in the OnHit events. You can set a condition on the magicEffect (not the spell!) to check if they already have the magic effect to stop them getting duplicate script. I set the duration to an hour and fire the AOE spell on the player every 2 seconds to pick up new targets. Helpful if you want the script to stay on a character to keep your variables and stuff and the magic effect is removed when they die.

Hmm yes that might be better... though yeah, I wasn't really aware that OnHit events could be used in an ActiveMagicEffect script. Although I'm not sure if it's possible for some actors to resist or be immune to such AoE spells?

Correct. Sort of. If a script is attached to a token, then that script will extend http://www.creationkit/ObjectReference_Script. This means that the game will call native events like http://www.creationkit.com/OnHit_-_ObjectReference on them when appropriate, but it won't do this when the http://www.creationkit.com/Actor_Script whose inventory they're in is hit.

In order to detect a hit on the Actor, you either need to attach a script directly to an actor, or you need to use a script that extends http://www.creationkit.com/ReferenceAlias_Script or http://www.creationkit.com/ActiveMagicEffect_Script.

A Quest can have a predetermined number of ReferenceAliases, each of which can point to one actor and have a script on the ReferenceAlias be sent events from the Actor to which it is pointing.

An ability (or other http://www.creationkit.com/Spell_Script, but abilities are permanent so more useful here) can have an effect with the "script" archetype that uses a script that extends ActiveMagicEffect. ActiveMagicEffects will receive events from the Actor to which they are attached, so when the game calls OnHit on your Actor, an ability would pick that up.

Of course, the third option is to simply attach a script to the Actor, but the inability to attach and detach scripts dynamically, as well as the compatibility issues, makes that inappropriate for what you want.

That method is great if you know beforehand that you'll only need to attach a script to N actors or fewer - just set up N ReferenceAliases in your quest and you won't run out. The problem is when you don't know, or you don't want to set up 100 ReferenceAliases just in case - that's where it starts being useful to use ActiveMagicEffects too.


You can use unscripted tokens as a great way to store data on an actor - just use them like an int variable that's persistent.

As far as I'm aware, any Spell applied by an explosion has to have a duration, so if you were going to use an explosion's effects to add an ability you'd have to use a scripted ActiveMagicEffect to add your ability that has another script of its own. Also, it sounds like this method is handled more directly by the game engine, which is generally a very good indicator that it's going to be much faster.

No idea about this bit, sorry.

If you know you'll never need to handle more actors than you have ReferenceAliases, then this method looks great. If you think an Actor may no longer have a ReferenceAlias pointing to it when it should do, and you don't want to add more ReferenceAliases to your quest, then you can use an ability to attach a script which gets sent events from the Actor on which it's running.


Token scripting is absolutely fine, if what you want to do doesn't require you to intercept events that are unique to the Actor. If that is what you want to do, then you'll want to use a ReferenceAlias or a Spell.

I hope that's a little more clear.

Cipscis

Thank you very much for sharing this!

Apparently abilities are removed before OnDeath can fire. how would you catch that one?
here's the script I tried, attached to an ability on the Draugr race:

Scriptname draugrreanimatescript extends ActiveMagicEffect  SPELL Property reanimateSpell AutoInt Property SecondsToWait Auto  Event OnDeath(Actor akKiller)  Debug.Notification("A Draugr has died.")  Utility.Wait(SecondsToWait)  reanimateSpell.cast(Self.GetTargetActor(), Self.GetTargetActor())EndEvent

The notification never fires

Ooh, I hadn't thought of that. Do you know if http://www.creationkit.com/OnDying_-_Actor would still work if it's caught in an ability?

Cipscis

http://www.creationkit.com/OnDying_-_Actor maybe?

Edit: Ninja'd by Cipscis again...

I've experienced this as well. OnDeath Events fire sometimes but not always when called from ActiveMagicEffect scripts.
edit: though it doesn't seem to be because the ability is removed. The script just stops running before the OnDeath Event can fire.
example:
I have this in a script attached to an ability...

Event OnDeath(akKiller);Actor SpellTarget- Actor ability is running on - referenced earlier in the script;Int CountNum - number of counters - referenced earlier in script  CountNum = SpellTarget.GetItemCount(MyCounter) ;MyCounter properly set up in script properties  SpellTarget.RemoveItem(MyCounter, CountNum)  Debug.Notification("Items Removed From Target")EndEvent

The Debug Notification never fires and calling ShowInventory on the actor after it dies shows there are still counters in its inventory. Calling Actor.HasSpell(Myability) in the console returns true even after the actor is dead. So Abilities aren't automatically removed on actor death.

Aha, ondying did indeed work. thanks!

My Deadly Combat most has been using the method described here, but an issue started popping up in the intro scene where the player gets stuck right before he's supposed to be executed. (everyone here has played the intro already right? No spoiler warnings needed? )

This issue seemed to be related specifically to the Player being a quest alias in my mod, so it wasn't related to the other 10 aliases I'm currently using. And more specifically, the issue seemed to pop up because SetPlayerAIDriven() is called by the intro quest's scripts to make the player walk automatically. Now this issue is not related to the method described above, but player alias specifically, but still... it seems quest aliases can have unexpected issues. So I'm thinking of switching to the abilities myself now that I know they can have OnHit events.

Hm... so it may be better to NOT have the alias quest start game enabled, and instead have it start off of a story manager event node or something...

Actually.. people have reported that they didn't have issues with versions 2.30 and earlier, this specific issue only showed up in versions 2.40 and 2.50. 2.40 is exactly the version where I started using this method, but BEFORE that I actually already had a start game enabled quest with just the player alias, so I figured the problem isn't really in that after all. The difference is that from version 2.40 I started stopping and restarting the quest in order to update all other aliases, and that seems to cause the problem.

So now I just made a quick fix not to update the quest until the main quest has progressed far enough that the player is no longer AI driven (and it also updates if that quest didn't start yet, in case users are using an alternate start mod) and that works.

I have been using the abilities (spell) method attached to the actors with a quest script using GetRandomActor command and that is working very well for me.

I take back some of what I said about hateing this new scripting system as well, I guess it is not so bad once you get into it.
Still there are some things I did religiously in Oblivion scripting that I cannot do now that will drive me crazy until I find a work around.