Talk:ScriptEffectFinish

Is the description really accurate?

It's the same as for ScriptEffectStart. Now, I changed ScriptEffectStart here to ScriptEffectFinish, but nothing else. --Stardaemon 05:35, 1 April 2006 (EST)

No, I have changed it to what I am 99% sure is the right description. It runs once the scripted spell effect has expired/ended (example a buff of 20seconds would mean that the block would run 20seconds after the start script). TaggeD 12:17, 1 April 2006 (EST)

Yeah, your new description looks more accurate:) Not that I've played with magic scripts, but it makes a lot of sense. --Stardaemon 05:04, 2 April 2006 (EDT)

---

I'm having issues with the ScriptEffectFinish block not running. While an actor is affected by a scripted spell, leaving the cell or using the wait menu seems to prevent the block from running, which leaves the actors permanently affected by the spell. I'm not sure there's a way to fix this, just wondered if anyone else has noticed this. Scruggs 18:18, 18 July 2006 (EDT)

Dragoon Wraith TALK 18:24, 18 July 2006 (EDT): Well, a work-around could hit actors in a cell with a new spell after Waiting (or entering the cell) that would check IsSpellTarget and if not, whether the effects were still on, and if so, then remove them like you would with ScriptEffectFinish.

Sure. The workaround I'm using is placing a scripted item in the inventory, which applies the effects and removes itself after a set duration. Seems to work. I still think it's worth mentioning the issue, despite any workarounds. Scruggs 18:30, 18 July 2006 (EDT)

Grr...I've been playing with this again, and I'm having no issues with the scriptEffectFinish block. I need to do some more testing, but for now I'll remove the notes I made. Might as well post the test script I'm using. This one works fine (the menuMode stuff also runs, which is nice):

scn testMagicSCR

; testing to see how magic effect scripts handle menu mode
; include a menu mode block
; in the update portion, include a check on menuMode
; if menuMode detected, print a message and add a token to player's inventory
; also make sure scriptEffectFinish is running while out of the cell/during menuMode
; add a different token on scriptEffectFinish

short started
short menuOn

begin scriptEffectStart
	if ( started == 0 )
		message "Script Effect Started!"
		set started to 1
	else
		message "Started == 1, start block running..."
	endif
end
; leave the cell, come back, see if script restarts

begin menuMode
	if ( menuOn == 0 )
		message "Menu Mode is Running!!!!"
		player.addItem testMenuToken 1
		set menuOn to 1
	endif
end

begin scriptEffectUpdate
	if ( menumode )
		if ( menuOn == 0 )
			message "Update block says menu mode is on."
			player.addItem testMenuToken 1
			set menuOn to 1
		endif
	elseif ( menuOn == 1 )
		message "Update block says menu mode now off..."
		set menuOn to 0
	endif
end

begin scriptEffectFinish
	message "Finish block running!"
	player.addItem testFinishToken 1
end

In that script, the start block never restarts after leaving the cell. The menuMode block and the menuMode check inside the Update block both run, but only after traveling or waiting, not in the inventory screen. The Finish block always runs regardless of where the player is or whether menus are open or not.

This is the one I had issues with before. Going back to test it and see what's wrong:

scriptName taFatiguePotionSCR

float fat

begin scriptEffectStart
	message "Starting"
	set fat to getAV fatigue
	set fat to ( fat + 1 )
	set fat to ( fat * -1 )
	modav fatigue fat
end

begin scriptEffectUpdate
end

begin scriptEffectFinish
	message "Finished."
	set fat to ( fat * -1 )
	modav fatigue fat
end

It could be an issue with modifying fatigue while in a different cell, but I don't recall ever seeing the "Finished" message while waiting or outside of the target's cell. I'm thinking it's more likely that leaving the Update block out caused the problem. Sorry for the confusion, hopefully I'll be able to post something more conclusive in a moment. Scruggs 20:19, 31 July 2006 (EDT)

____

Sorry to be filling this page up. I'm still getting conflicting results. Here's the modified script I'm testing with:

scriptName taFatiguePotionSCR

float fat

begin scriptEffectStart
	message "Starting"
	set fat to getAV fatigue
	set fat to ( fat + 1 )
	set fat to ( fat * -1 )
	modav fatigue fat
end

begin scriptEffectUpdate
	if ( fat == 0 ) ; this should never run
		message "Fat == 0"
	endif
end

begin scriptEffectFinish
	message "Finished."
	set fat to ( fat * -1 )
	modav fatigue fat
end

As long as I remain in the cell with the affected NPC, the Finish block runs and the fatigue is restored, even if I use the wait menu. But if I leave the cell, then when the duration is over I get the "Fat == 0" message, and no "Finished." The NPC remains unconscious. I'm thinking at some point the variable is getting reset? I'm not really understanding this, but I'm thinking the only workaround may be to run a timer inside the script instead of relying on the Finish block. But I'm a little worried about variables (including the timer variable) becoming reset. :sigh: Makes no sense for the first script to work, and not the second. Back to testing... Scruggs 20:51, 31 July 2006 (EDT)

____

I'm posting my latest results and then I think I've had enough of trying to figure this out. Input is welcome. Here's a test script that does nothing but report the number of seconds elapsed at the point when the variable becomes uninitialized:

scriptName taFatiguePotionSCR

float fat
float timer

begin scriptEffectStart
	message "Starting"
	set fat to 1
end

begin scriptEffectUpdate
	set timer to ( timer + scriptEffectElapsedSeconds )
	if ( fat == 0 ) ; this should never run
		message "Fat == 0 at %.2f seconds" timer
	endif
end

begin scriptEffectFinish
	message "Finished."
end

This spell has a 20-second duration. To test, I cast the spell on an NPC, leave the cell, and wait for the spell to wear off. In all cases, I get the message "Fat == 0 at xx seconds", with the timer being around 15.2 to 17.84. In about half of the tests, the first message is followed by "Fat == 0 at 0.00 seconds", which suggests that both variables are becoming uninitialized at some point before the script stops running. On a few occassions, both messages were followed by the "Finished" message, but generally not.

I would like to think that giving the spell a long duration and using a timer inside the script to terminate the spell will provide a reliable workaround. But I'm more than a little confused as to why this doesn't seem to be an issue with other spell scripts. Scruggs 22:54, 31 July 2006 (EDT)

Blocktype Behaviour

It would seem that this blocktype fires immediately upon the death of the target. In my instance what I am doing is creating fullactorcopy's and dueling them to the death, upon my success (said copies also have a token to achieve various other things) an activator casts a spell at them preventing the looting of their corpses and removing the token I gave them (calling DeleteFullActorCopy inside the token caused a CTD, using another activator should get around it). The spell has a duration of 2 seconds giving plenty of time for the corpse to hit the ground/ragdoll before being destroyed. My problem is that destruction of the copy is specified inside the ScriptEffectFinish block, which seems to fire immediately upon death.
Anyone got any solutions for this?
--Antares 22:01, 15 October 2008 (EDT)

I have resolved my specific issue but the problem still remains if someone wanted to have a ScriptEffectFinish Block run properly after the death of the spell target.

--Antares 22:47, 15 October 2008 (EDT)

Run a timer in this bock, until you want the death handling to kick in. Should do the trick. Or use a getTimeDead function. -- shademe 03:54, 16 October 2008 (EDT)

I think there could be more to it than that, my spell had a duration of 2 seconds, the whole point of using one in that way was so that the spell acted as the timer. I'm pretty sure the spell terminates when the target dies and the block is processed no matter what. Having a timer in there would only serve to make sure that the block couldn't be processed as the criteria could never be met. That's my theory at least, more extensive testing would be required before any solid conclusions could be drawn.

--Antares 05:05, 16 October 2008 (EDT)