Talk:Activate

Rewrite

Is it just me, or is a lot of Kkuhlmann's information here wrong? Activate blocks are done when called, not later, correct?
Dragoon Wraith TALK 10:54, 13 July 2007 (EDT)

You can actually tell who's saying what??? Yeah, that information is incorrect on activating (not quite sure about onUnEquip, I'd say yes but I have one more thing to test). An activation runs the entire onActivate block (be it another object or that object) before the next line of code is processed. Not quite sure about "Atomic" and having multiple onActivate blocks in a script though (mainly because it hurts to think about why one would do that...). Also, this article is really confusing. Really, really, really confusing and since it doesn't mention that the reference is the object that's activated, it borders on useless. *sigh* I need to say more about it, but what's keeping me from rewriting the whole article - I don't want to turn it into a different structure/flow from other function articles, and I simply haven't read all of them. (I am more than happy to run tests, though - hence the nesting section)

--Haama 12:58, 13 July 2007 (EDT)

On the Wiki, correct information > consistent formatting. Feel free to fix this any way you like. If necessary, I can re-format what you write to make it consistent. I simply don't know enough about the intricacies of this function to write it myself. You might want to have a look at OnActivate, too.

Dragoon Wraith TALK 15:53, 13 July 2007 (EDT)

Wow, just wow... I'll start working on both of them. There are some things I just don't know, though - for instance, what will Activate SomeRandomNPC do? Does a simple Activate really assume the "Activator's 'current ActivatorID'" (rewritten as "Activator's ActionRef") or does it assume the player? Also, this is a unique case, as the ActivatorID is required if you use the RunOnActivateFlag, but optional if you don't (well, again, does it actually do anything for normal activation?)

--Haama 17:54, 13 July 2007 (EDT)

One part that's somewhat right - a foreign object does get flagged for 'onAdd' blocks, but I don't think the flag is on the object (because it won't run if you then move it to the player), but instead the flag is set on the cell (because the script will run once you enter that cell, even if the object is somewhere else)

--Haama 13:02, 13 July 2007 (EDT)

Would a good test be to 1st move that object to the player, then move the player to the cell where the object was? If that's true, then the object would have its onAdd block do the stuff (if not, then move the object back to the cell where you've moved the player - its originasl cell-, and see what happens)...?

--HawkFest 21:30, 16 April 2008 (EDT)

Syntax

Alright, so that's how it should look now? This is based on discussions on the Terminology Discussion thread on the Elder Scrolls Forums and Wrye's Modding Terminology paper. Some parts are pretty much finalized, some is still up in the air, so please continue the discussion in the Community Portal.
--Haama 20:20, 14 July 2007 (EDT)

Syntax Question

This page is unclear, does player.Activate doorID mean the player activates the door, or the door activates the player?

--Kkuhlmann 12:04, 6 April 2006 (EDT): What you wrote means the door is activating the player. If you want to simulate the player activating a door: DoorID.Activate player

Scripting Issues

--Mrflippy 12:59, 12 April 2006 (EDT) I've been having some issues with this command in scripts. Sometimes, "object.activate me, 1" just doesn't work. The OnActivate block in the script attached to object isn't run at all. Most of the activators I work with are dynamically created using PlaceAtMe. Is this the source of the problem?

--Tegid 13:37, 12 April 2006 (EDT) I too am having this problem. Is there some kind of time constraint on activation? What causes them to just not activate? If they are already inside their OnActivate block and someone calls Activate on them, what happens then?

--Kkuhlmann 14:01, 12 April 2006 (EDT): Some things to keep in mind which could be causing your issues:

• All "action" block types (OnActivate, OnEquip, OnAdd, etc.) work by setting a flag on the script when the action occurs. The next time the script runs, if the appropriate block flag is set, that block is executed, and the flag is reset (so it doesn't run it more than once for a single action).
• Object scripts only run if the object is in the currently loaded area -- where the player is. So calling Activate on something that isn't loaded will set the flag for that action, but won't actually trigger the script (it will trigger the next time the object's script is run). NPC scripts (on persistent NPCs) do run when they're not loaded, but only when their AI is updated, which can happen as infrequently as every 15 game minutes.

--Tegid 15:13, 12 April 2006 (EDT) So three questions.

• That reset happens when the OnActivate block starts or stops? (So if I send another activate before it is finished with its block, will it be cleared when its block ends and therefore never happen?)

  --Kkuhlmann 08:49, 14 April 2006 (EDT): Reset happens when the script is finished processing. So calling Activate on an object from within its own script won't work.

I don't understand what you mean: what "reset" are you referring to? Cell reset? Fact is that MANY objects actually can have an Activate command within their own onActivate script, and more over MUST have one so as to activate themselves, especially those objects involving a GUI presented to the player in menu mode (like beds, containers and such)!... But of course, this Activate command will NOT "reactivate" a second pass of the onActivate script, it will instead render the default activation behavior of the object.

--HawkFest 21:39, 16 April 2008 (EDT)

Don't know about the reset, but I believe they're referring to an item activating itself with the onActivate flag. Yes, this can be done, but no, it shouldn't be done (just copy the code for each) and can lead to CTDs if not done carefully.--Haama 00:47, 17 April 2008 (EDT)

• As long as I've used PlaceAtMe to create this object, the second section shouldn't apply correct?

  --Kkuhlmann 08:49, 14 April 2006 (EDT): Rephrase the question to be more specific. I don't understand what you're asking.

  --Tegid 09:32, 14 April 2006 (EDT):Since I'm using PlaceAtMe, the object will always be in my cell and therefore will always run it's activate script.

• Are script blocks atomic?

  --Kkuhlmann 08:49, 14 April 2006 (EDT): I don't know that I understand what you're asking. You CAN have more than one script block of the same type in a script -- since the flags are cleared at the end of the script, any number of blocks of the same type can exist in the script just fine. Why you'd want to do this, I don't know. But you could. If that's what you were asking.

• --Tegid 09:27, 14 April 2006 (EDT): By Atomic I mean, does the entire script block (or script) execute without interruption by another script, or can it be interrupted by another script mid-run and then come back and finish later?

Nesting

--Tegid 00:40, 26 April 2006 (EDT) With MrFlippy's help, I believe I have found an issue with chained activations. If I have more than four objects which pass a single Reference down an activate chain, after the fourth pass, my reference is normally != to what it was when it started down the chain. (It does SOMETIMES make it to the 5th object). As an example.

scn Object1Script
ref incoming

begin OnActivate
  set incoming to GetActionRef
  if (incoming == SomePresetReferenceInAPersistentObject)
    Message "I am doing something cool in Object 1",1
  endif
  Object2Ref.Activate incoming 1
end

if Object2Ref has a script that is similar but activates Object3Ref like so

scn Object2Script 
ref incoming

begin OnActivate
  set incoming to GetActionRef
  if (incoming == SomePresetReferenceInAPersistentObject)
    Message "I am doing something cool in Object 2", 1
  endif
  Object3Ref.Activate incoming 1
end

And so on down to Object5, object 5 will NOT execute the code inside its if statement. That equality will evaluate to false. Am I missing something, or is this a bug based on something you couldn't imagine us wanting to do?

I've posted a test showing that you can, normally, have 5 called nested scripts running at once (6 including the original, calling script). It also shows you can't avoid the limitation by using a result script to call the activator.--Haama 05:28, 30 July 2008 (EDT)

Fake "Nesting"

• At the bottom of the article, "Nesting" section, it is written:

You can only nest 5-6 activations at a time. At a time is a little hard to define here, since OnActivate blocks run instantly and before the next line of code is processed. This really means that if 4 other scripts are still being processed and an activation is made during the 5th script, that last activation will be ignored (the script skips the line). This applies to any activation, even if they're different objects or different scripts.

Maybe that you problem is due to some limit imposed by the engine over piling (or stacking) onActivate processes : since the onActivate block executes fully before going on to the next line of code, a stack is taking place here, as would do a recursive method... As such using the GameMode block that executes every frame would be more appropriate imho, given the provision of some conditional control to recreate what you want to do. Be aware to put any onActivate control block before the GameMode block for any reference involved in the chain, and which could serve as some "State observer" setting variables controling its GameMode block - and thus a chain of events that could involve multiple object references/path/scenario/story lines/effects/whatever... I'd try this using tokens instead of the actual objects needed to be manipulated during the chain of events (the scripting of these object staying thus independent from the FX or the wanted "chain reaction" in itself, making them consequently and independently reusable for some other stuff you could want them to do or behave in another stage or scenario). Note that I am not talking about an "instantaneously chained" multiple events triggered via onActive blocks - at most 4 to 5 considering what you said (which would be "normal" in regards to the "fps factor" during game playing)-, but about a chain reaction happening frame-by-frame (you could mix both methods btw). Although the later is only based over logical assumptions in regards to all the info provided around, maybe I'll try this some other time in a mod, as a "proof of concept"... --HawkFest 23:54, 11 September 2007 (EDT)

I've done it. A hint to the simplest way, not only to do it, but also to manage it: from a quest script or another object's script, use/set object variables that are triggering your stuff, exactly when you want it... set refObjectID.localVar to 1, where a conditional block on localVar, within the refObjectID's GameMode block script, would trigger whatever stuff you wish for it to render. Like a "Master script" that is managing the cascading events from one single object's script that is NOT involved into that chain reaction (which object can be hidden in the player's cell, or that would have no other use than showing itself as well as doing this "orchestration" silently). --HawkFest 21:54, 16 April 2008 (EDT)

True, this can be done, but it's not really nesting. Nesting means everything runs before the next line of code runs - this avoids a good chunk of timing issues ("orchestration") and would be much prefered.--Haama 05:28, 30 July 2008 (EDT)

I was thinking about this, and I was wondering what situations would really call for nesting 5-6 levels deep? I think generally better practice would be to have most activator scripts do something and then return, rather than call another activator mid-script. Most things that can be done via deep nesting can also be done relatively painlessly via simple nesting. So again, I'd be interested to see examples of where deep nesting would be used and for what.

--quetzilla 06:13, 10 August 2008 (EDT)

RunOnActivateBlock Flag

This flag seems to determine more than whether to run the onActivate block or not; it appears to be more of a DoNormalActivation flag (which includes running the script if it's present), than simply a RunOnActivateBlock flag.

Example: Steal an unscripted item, and drop it. If you pick it up again, your stolen item misc count will NOT increase (since you already stole it once). Now, take the same item, and instead of picking it up, target it in the console and do "activate player". The stolen item misc count increases. If you use "activate player 1", the stolen item misc count will NOT increase. Since the item is unscripted, you wouldn't expect the RunOnActivateBlock flag to actually do anything. --Waruddar 15:24, 1 February 2008 (EST)

Well, that's bizarre. Good find... I have no idea why that would be.

Dragoon Wraith TALK 16:15, 1 February 2008 (EST)

My best guess would be that the absence of the flag is actually telling the engine not to parse the ExtraData (stolen status, scripts, item health, etc) on the item. If it doesn't read that data, then the engine doesn't know to run any scripts or that you already stole the item. Then again, in order to erroneously increment the theft count, it has to read some part of that data to know that it was stolen at all. --Waruddar 18:00, 1 February 2008 (EST)

But then the engine wouldn't know that the item was stolen in the first place, since that's also ExtraData, no?

Dragoon Wraith TALK 18:17, 1 February 2008 (EST)

Yeah, that's the kink in that theory. If the theory is true, then the fact that it checks the stolen status is a bug (likely an overlooked check in a sub function). If the theory is false, then I have absolutely no idea. Regardless, there's little chance of proving any of this. Waruddar 19:45, 1 February 2008 (EST)

Well actually it makes perfect sense in regards to your theory... Unless: have you tried picking up the item before doing it in-game for the 1st time (from the console and without the flag)? Logically it should not increment the theft count if your theory is correct. --HawkFest 03:37, 5 February 2008 (EST)

Can't activate while on a horse

Seems that actors on horseback won't activate anything and can't be used for the ActivatorID--Haama 01:23, 3 April 2008 (EDT)

Belated confirmation - I believe you can get around it by placing an actor in a Remote cell, leave it Enabled, and use that actor's reference editorID instead of player.