I have a follower that I need to know if they are resurrected. When they die, I stop OnUpdates(), so if they are resurrected, I need to know to start them again. Any suggestions?

OnDeath, set their scale to 1.001 or something detectable via a script, but not the eye. Or you could give them a Non-Playable ARMO token as an indicator they've already crossed the river Styx.

Thanks JustinOther. Good idea, unforuntaly my script isn't running any more to do the check.

Post it?

My script isn't running anymore because I stopped doing the updates when the NPC died...it's restarting the updates that I want to do when they are resurrected.

I don't think you can know after the event has occurred.

What you might be able to do is trap the actual resurrection event (on a follower) and then apply any external script-start functions?

http://www.creationkit.com/Bethesda_Tutorial_Papyrus_Events_and_Properties#Scripting_the_Resurrection

(going to depend on exactly how resurrection happens in your stuff, I think?)

Thanks, that was my original question. I just wanted to make sure I wasn't missing something.


That's the problem, I'm not doing the resurrection. It's a follower, so I'm *guessing* the player could resurrect the follower by whatever means the games offers. (I've actually never done it, so I don't know the details.)

What I'm doing is this: I have a standard OnUpdate() function. Before I call RegisterForSingleUpdate(), I check to make sure the follower isn't dead. If they're dead, I stop updating as it doesn't make much sense. The problem is, what if the player resurrects the follower? I was hoping there was an EVENT I could use to start my updates again. JustinOther's suggestion would be good if I had code running, but I've already stopped the updates so I don't have any code running to do the check. I could continue the OnUpdate() even if dead, but I don't like that idea for obvious reasons.

I hate to have to leave anything "up to the player" because we all know how that goes, but in this case, I have a dialog option that will restart the updates. I'm just going to have to let the player know if they resurrect the follower, they need to use it.

I hope that makse sense, and I REALLY appreciate the comments! The modding community really does make up for what Beth didn't give us.

From memory, Resurrection is a spell?

So you could edit the spell to check if the NPC-Target being resurrected is in the Current-Follower faction? If they are ... then you have a hook to continue your scripts ... Not going to be perfect thoiugh, I think.

(This would probably mean editting a Vanilla Spell ... Which may lead to incompatibility problems (or problems with vanilla)

Best of luck

Why not dial back the update loop to once every 10 minutes or something like that. You could say that

Alternatively,

• Have an invisible quest with a list of aliases.
  
• When a follower dies, force the dead follower ref into one of the alias slots.
  
• Give each idle slot an idle package of some sort so they perform that idle right after being raised.
  
• Give the idle a fragment that restarts the actors script when they perform the idle and then clear the actor's reference

Job done!

I don't want the script running at all if they die because of the of the problems the game has with running scripts not updating, save game bloat, etc.


I'm already using a quest alias so that's not a problem, but I'm not sure how I would I assign an idle when they are raised?

Assign the idle when they die. You can do it from the OnDeath handler. They won't do anything because they'll be dead. But if someone brings them back to life, they'll hopefully start performing the package. Then the script fragment fires and from there you can do as you like.

Great idea DocClox, and even better than it actually works!

So basically now, I have an event for when/if they are resurrected. Thank you!

This is how I implemented it, since I am already handling package complete events:
1. I made a new package for being dead. (I didn't even have to use an idle, I just have a "DoNothing for 1 second" procedure.)
2. When the follower dies, I change to the "dead" package. (No more updates firing!) Since they are dead, they can't complete the package. (You are correct!)
3. If they are resurrected, the package will complete in 1 second and fire the package end event.
4. Since I know they were dead, I know to restart the OnUpdates.

Works great!

Great! Glad it works.

The could be a useful technique generally: DoNothing packages as custom events.

It might not always be the most prompt of notifications, but we could use it to detect just about anything on an actor...

Yeah, I was thinking the same thing.

And there really is no appreciable delay, even with the 1 second "Do Nothing" delay.

Yeah. I was thinking more of cases where the actor was already doing something else. Then you'd have to wait for him to re-evaluate his package stack.

You could force it of course, but if you knew when to force the eval, you'd be able to test the condition directly.

When the follower dies, I change the package conditions and then force the package reevaluate - so that's almost instant. By the time the actor is on the ground, it has the new package. But like you said, the package can't be completed because they're dead. So when they are resurrected, they already have the package and it completes in a second. So it's all very responsive, and best thing, it's all automatic! No continuous running updates if dead and automatic restart if resurrected. How often does it work out so great?

Oh, I agree! I agree entirely.

i was still thinking about the general case for using packages as user defined events, and wondering about possible issues using the approach on non-dead actors.

For this particular problem it seems to be a perfect fit. Life you say, that doesn't happen very often

For the sake of anyone else who might stumble across this thread... here's my thoughts:

Obviously, using the package to raise an event is only for the scenario that they aren't polling, otherwise, they can already check the condition directly. So I think this is more of an awareness solution. Once they realize they can use a DoNothing package and check the condition when it finishes, that opens up scenarios that won't require constant polling. But they also don't have to be DoNothing packages - being notified of arrival using the travel package, etc. Again, people probably already know about the pieces, it's putting it together to offer new solutions that might be the new idea.