[LE] How to delay activation of chest upon... activation.

[corrado33]

I want to be able to run a script between the point when the player activates something (say, a chest that's attached to a quest alias) and when the object activates.

 

So essentially....

Scriptname AliasScript extends ReferenceAlias  

Event OnActivate()
     ;Do stuff I want here before the alias is activated
     ;Wait an unspecified amount of time here
     .
     .
     .
     ;Actually activate the alias (chest) here.
     self.getref().activate(Game.GetPlayer())
endevent

If I run the following

event OnActivate()
        debug.messagebox("Before Wait")
	utility.wait(5)
	debug.messagebox("After Wait")
	self.getref().activate(Game.Getplayer())
endevent

The chest will activate, then wait 5 seconds, then activate again. I want to... get rid of the first activate.

 

Believe it or not, I did try to figure this one out. I opened a script from another mod that essentially does the same thing, and they used "GoToState", which I tried, but still failed.

 

 

EDIT: So I figured out how to do this, and I'll post it in a bit... but I'm not continuing this line of programming anyway. I found a mod that does essentially what I was programming. (Auto stash of loot into a dynamic container.) Called "Quick Stash."

Edited October 1, 2018 by corrado33

[IsharaMeradin]

You can use a Perk Entry Point of the Activate variety. There is an option to 'run immediately' which does not show a menu box but rather runs what you want and then runs the normal activation sequence. Care needs to be taken as their can be only one such type Perk Entry Point of this Activate method. There can be as many of the menu variety as you want, however.

 

A hotkey dedicated to your mod could be used to bypass default activation behavior, do what you want and then activate the object so that it may process its normal activation sequence. You could couple that with a GetCurrentCrosshairRef() check so that you can do different things based upon what the player is pointing the crosshair at when they press the key. (I have a mod that does this but that version isn't released yet.)

 

What you found in that mod, may yet be another option. I have not looked at it to see what it does. Would be interested in seeing what you have come up with.

[corrado33]

You can use a Perk Entry Point of the Activate variety. There is an option to 'run immediately' which does not show a menu box but rather runs what you want and then runs the normal activation sequence. Care needs to be taken as their can be only one such type Perk Entry Point of this Activate method. There can be as many of the menu variety as you want, however.

 

A hotkey dedicated to your mod could be used to bypass default activation behavior, do what you want and then activate the object so that it may process its normal activation sequence. You could couple that with a GetCurrentCrosshairRef() check so that you can do different things based upon what the player is pointing the crosshair at when they press the key. (I have a mod that does this but that version isn't released yet.)

 

What you found in that mod, may yet be another option. I have not looked at it to see what it does. Would be interested in seeing what you have come up with.

 

Oh my goodness. Ok that mod was an absolute shitshow, please excuse my language. It just had me freaking out for the last hour that my mod was bugged and randomly taking my items that I would craft. That's..... probably why it didn't have many downloads.

 

The way I did it was to place an load a container into a quest alias. In that script immediately "DisableActivation" of that chest. (I used OnItemContainerChanged. Alternatively, you could do it "OnLoad". Then in the quest alias script in "OnActivate" I immediately have an if statement (if activator is player) then if yes, call a new state (GoToState). I'm not... entirely sure this is necessary, but it works. In that state I do whatever I want, then return, and at the end of that state I call "Activate(containerref, true). The "True" bypasses the "disableActivation" from before. Basically, the entire reason I did this was so I could "double click" a chest to set the formlist of what the player has equipped. I'll post it later, I'm playing now. :smile:

 

EDIT: And I'm well aware this is very similar to your script. I'm stubborn and don't like using other people's code unless I'm absolutely stumped or if replicating it would take way... way too much time. (Libraries, for example.)

Edited October 2, 2018 by corrado33

[IsharaMeradin]

BlockActivation is the "bad" way if done directly on the object. It prevents the normal processing sequence unless a scripted Activate has that one parameter set to true. A mod which blocks activation directly on an object will permanently block that object if the mod is removed mid-game. Personally, because of this, I try to avoid using it. Especially, since I did have a mod that used it (I used scripts from a resource mod) and then users that complained about my mod breaking their workstations after uninstalling.

 

Anyway, good luck in your efforts.

[foamyesque]

Yeah, in general, BlockActivation should only be used on stuff your mod personally controls. The Perk Entry Point via Activate is a much more elegant method, though setting up the targeting conditions can be interesting.

[corrado33]

BlockActivation is the "bad" way if done directly on the object. It prevents the normal processing sequence unless a scripted Activate has that one parameter set to true. A mod which blocks activation directly on an object will permanently block that object if the mod is removed mid-game. Personally, because of this, I try to avoid using it. Especially, since I did have a mod that used it (I used scripts from a resource mod) and then users that complained about my mod breaking their workstations after uninstalling.

 

Anyway, good luck in your efforts.

Ah, sad day. However, if it was scripted to "OnLoad" then it would only block activation if the person was currently IN that cell when they removed the mod, right?

 

EDIT: Obviously I'm going to try to use the perk entry point method, however creation kit is... once again... not being useful. Literally no useful links on that page you linked.

 

Ah ok. So what you're saying is that I could give the player a perk that would let them access a menu when they activate a "special" chest if I set up the conditions right. Ok... I'll try that.

Edited October 2, 2018 by corrado33

[IsharaMeradin]

If you are using an alias on a quest, you'll have to test to see if proper behavior is restored after removing the mod mid-game.

 

All I can tell you is that if BlockActivation is directly on an object, every instance of that object that had ever been loaded (or ran the event that called BlockActivation) would be unable to be properly activated after the mod was removed mid-game. That said, it *could* have been possible to wait over 30+ days in an unaffected cell so that the affected cells could reset which *should* clear the affected objects and have them use the original script (if any). But if any of those objects were persistent through other means, waiting for reset wouldn't work.

[corrado33]

If you are using an alias on a quest, you'll have to test to see if proper behavior is restored after removing the mod mid-game.

 

All I can tell you is that if BlockActivation is directly on an object, every instance of that object that had ever been loaded (or ran the event that called BlockActivation) would be unable to be properly activated after the mod was removed mid-game. That said, it *could* have been possible to wait over 30+ days in an unaffected cell so that the affected cells could reset which *should* clear the affected objects and have them use the original script (if any). But if any of those objects were persistent through other means, waiting for reset wouldn't work.

 

Ahhhhhh that sounds awful. Yeah I'm definitely going to look into the perk method. Although it seems... unfriendly. :wink: I'll probably make another dozen posts about it before I understand it. :smile:

 

Thanks again for the help.

 

EDIT: For the record, my idea with the "onLoad" above didn't work. Even if I wasn't in the cell when I disabled the mod, the chest still wouldn't activate. (Although other identical chests (I used a wardrobe) still worked fine. For reference, I used one of the wardrobes on the sides of the entry door in Hjerim. The one with the script attached wouldn't activate, but the other one worked fine.) If I could find a way to disable the... disabling when leaving the cell, I think it'd be fine. I'll look into it if I can't figure out the perk stuff.

 

EDIT2: However, the "OnCellAttach" and "OnCellDetach" seem to work fine. I can use OnCellDetach to run a getref().disableactivation(false) to return the ref to normal activation. Then the player simply has to leave the cell that contains that chest then uninstall. I'd still prefer a perk though.

 

EDIT3: Ok, I got the perk method to work, so long as there is a specific item IN the chest. I'm looking through the conditions now to see if I can remove that. I'd like a condition that says "IsQuestRef" but those don't seem to work right. I can see the "IsQuestVariable" but it doesn't... work.

 

EDIT4: Yeah I can't find a working condition. There are a few conditions that deal with quest aliases and variables, but none of them let me select my quest... just an empty pull down menu.

Edited October 2, 2018 by corrado33

[IsharaMeradin]

You might want GetIsAliasRef

[corrado33]

You might want GetIsAliasRef

Yeah I tried that one.

 

It just leads me to an empty drop down list. I tried adding it then exiting the entry type screen, all of the way back to the perk, but nothing. Nothing in the drop down list. I tried "Use Aliases" as well. :sad:

 

It just says "Quest alias: " "INVALID ALIAS" with absolutely nothing in the drop down list.

 

It seems that one is only valid when the condition is on something owned by a quest. Since this is a perk... it's not owned by a quest.

Edited October 2, 2018 by corrado33