Talk:ScriptEffectUpdate

From what I've tested, this effect appears to work similar to gamemode. While the spell is active ScriptEffectUpdate loops until the spell ends. Can someone else confirm this though before changing the description (which is definately wrong either way). TaggeD 12:24, 1 April 2006 (EST)

Dragoon Wraith TALK 11:13, 13 June 2006 (EDT): Regarding the "doesn't work on Enchantments" thing that JOG (rightly) removed, I've had some issues with Enchantment scripted effects, too. Sometimes works, sometimes not. I think perhaps some testing ought to be done here - but I don't know what.

i'd like to see an example of an enchantment that this works on. what i've tried is to add a script effect to an enchantment and all the script does is prints a message on update. then add the enchantment to an item. you'd expect that equiping the item causes the update block to fire every frame for a constant effect, but that is not the case. I don't think any of the other scripteffect blocks work for this either, but they're not important as an equip block in a script could accomplish the same thing. maybe i should have specified that this is only the case for constant effects? i believe strike (for weapons and staffs) works as expected.--Snake 17:47, 19 June 2006 (EDT)

Dragoon Wraith TALK 17:39, 30 June 2006 (EDT): Really? That's not what I would expect at all. I thought it was quite clear that the enchantment's script would run on the target of the enchantment. In the case of armor, that's the person equipping it, but in the case of a weapon, that's the person hit by it. I don't really think that the script you have there is relevant, but if enough people are confused, I guess it can stay.

as for my script example not being relevant to the update block, that's somewhat accurate. however, i don't know where else to put it. i'll try to separate it from the main part of the page more. but really, they should fix the game or the cs to make the apparel enchants work as expected.--Snake 15:02, 1 July 2006 (EDT)

Dragoon Wraith TALK 15:48, 1 July 2006 (EDT): Better formatting on it, but I still don't see what relevance it has in this article. It doesn't even use ScriptEffectStart.

ShadowDancer 08:19, 6 July 2006 (EDT): I have a script that uses the ScriptEffectUpdate and it is a "yes and no" thing with it firing every time like in GameMode. If the effect is killed by some other process, it does fail to execute (like when moving into a new cell that is far enough away for some reason -- probably due to length of load?? I don't really know...). You can see it in the ETHEREAL HORSES mod where the effectshader stops working after moving far enough. I encountered the same problem while working on mine and created a sort-of workaround. While it is running, however, it does seem to run multiple times and is useful in some circumstances. This is the script that I have running an effectshader (actually, its both a membrane shader and a particle shader) on a horse.

ScriptName NightmareFlameEffect
Ref DoOnce
Float GSP

Begin ScriptEffectStart
   SummonedNightmare.PlayMagicShaderVisuals effectNightmareFlame
End

Begin ScriptEffectUpdate   ;fires actor dismount after "loading..." menu
   If MenuMode == 17 && DoOnce == 0 && Player.GetSitting == 13
      Set DoOnce to 1
      Set GSP to 0
      If Player.GetInWorldSpace Tamriel == 1   ;to prevent crash when going into city
         Activate Player 1
      EndIf
   EndIf
End

Begin GameMode
   Set GSP to GSP + GetSecondsPassed
   If GSP > 3   ;time delay required so game doesnt freeze after dismount and remount
      If DoOnce == 1 && Player.GetInWorldSpace Tamriel == 1   ;fires effect after dismount
         If Player.GetSitting == 0
            SummonedNightmare.PlayMagicShaderVisuals effectNightmareFlame
            Set DoOnce to 0
            Activate Player 1
         EndIf
      ElseIf Player.GetInWorldSpace Tamriel != 1   ;removes automount in city when leaving
         Set DoOnce to 0
      EndIf
   EndIf
End

ShadowDancer 16:55, 7 July 2006 (EDT): Additional Info: This block fires each time the script "updates". In other words, when the script is running through a cycle. Cycles are ScriptEffectStart, ScriptEffectUpdate, and ScriptEffectFinish - ScriptEffectUpdate occurs every frame like GameMode for duration of the spell (minimum of 3 cycles when included in the script in most cases). Running a spell script with a 0 duration produces 3 cycles, 1 duration produced 11 cycles, 2 duration produces 21 cycles, and 3 duration produces 28 cycles consistently. [Edited to correct info by ShadowDancer 17:04, 28 August 2007 (EDT)]

Test Script:

Script TrialEffect

Begin ScriptEffectStart
   Player.PlayMagicShaderVisuals effectAtronachFlame
End

Begin ScriptEffectUpdate
   Set Count to Count + 1
End

Begin ScriptEffectFinish
   Player.StopMagicShaderVisuals effectAtronachFlame
End

---

Does the ScriptEffectUpdate block run before ScriptEffectFinish even if the Finish block comes before the Update block in the script?

Haama 16:33, 24 August 2007 (EDT)

No, if the ScriptEffectFinish block is placed before the ScriptEffectUpdate block (which does not cause any problems that I can see), it will find the ScriptEffectFinish block before it finds the ScriptEffectUpdate block and finish the spell without running the ScriptEffectUpdate block first. If block order is altered, it will run the blocks in the order written in the script so this can be used to get around the Return command firing in a ScriptEffectUpdate block (although in my experience, most of the time a constantly active Return command isn't necessary in a ScriptEffectUpdate block). For instance in the following spell script:

ScriptName SCAlterWeather

Short WeatherButton

Begin ScriptEffectStart

  MessageBox "What weather would you like?", "Clear", "Cloudy", "Fog", "Overcast", "Rain", "Snow", "Thunderstorm"

End

Begin ScriptEffectUpdate

  Set WeatherButton to GetButtonPressed
  If WeatherButton == 0
    ForceWeather Clear 1
  ElseIf WeatherButton == 1
    ForceWeather Cloudy 1
  ElseIf WeatherButton == 2
    ForceWeather Fog 1
  ElseIf WeatherButton == 3
    ForceWeather Overcast 1
  ElseIf WeatherButton == 4
    ForceWeather Rain 1
  ElseIf WeatherButton == 5
    ForceWeather Snow 1
  ElseIf WeatherButton == 6
    ForceWeather Thunderstorm 1
  EndIf
End

Begin ScriptEffectFinish

  ReleaseWeatherOverride
  ForceWeather DefaultWeather

End

As this isn't a complicated script, it won't make much difference whether it has a Return statement unless you are running many instances of scripts like this. So there is no need to include this:

  If WeatherButton == -1
    Return

--ShadowDancer 22:48, 24 August 2007 (EDT)

After some more testing, I found out that the ScriptEffectUpdate block does actually run even after the ScriptEffectFinish block runs with the blocks reversed. I am adding this since I assume that some possible interesting effects could be created intentionally (or unintentionally) by setting a variable in the ScriptEffectFinish block. I used this script if anyone wants to try to replicate this:

ScriptName SCAlterWeather

Short WeatherButton
Short ScriptVariable

Begin ScriptEffectStart

	MessageBox "What weather would you like?", "Clear", "Cloudy", "Fog", "Overcast", "Rain", "Snow", "Thunderstorm"

End

Begin ScriptEffectFinish

	ReleaseWeatherOverride
	ForceWeather DefaultWeather
	Set ScriptVariable to 1

End

Begin ScriptEffectUpdate

	Set WeatherButton to GetButtonPressed
	If WeatherButton == 0
		ForceWeather Clear 1
	ElseIf WeatherButton == 1
		ForceWeather Cloudy 1
	ElseIf WeatherButton == 2
		ForceWeather Fog 1
	ElseIf WeatherButton == 3
		ForceWeather Overcast 1
	ElseIf WeatherButton == 4
		ForceWeather Rain 1
	ElseIf WeatherButton == 5
		ForceWeather Snow 1
	ElseIf WeatherButton == 6
		ForceWeather Thunderstorm 1
	EndIf
	If ScriptVariable == 1
		MessageBox "ScriptEffectUpdate fired after ScriptEffectFinish block"
	EndIf
End

--ShadowDancer 02:15, 25 August 2007 (EDT)

That makes a whole lot more sense. Back to the point, a return acts the same in SEU as any other block, so I'm going to change some of the wording around.

--Haama 09:05, 25 August 2007 (EDT)

Umm, I am not sure that the change to the Note: on the ScriptEffectUpdate page accurately reflects how Return works or should be used? Since Return doesn't really end the script, it could confuse people. Shouldn't it be more like:

Note:

• A ScriptEffectUpdate block with an active Return statement placed before a ScriptEffectFinish block in a Magic Effect script will prevent the ScriptEffectFinish block from running when the Magic Effect script ends.

--ShadowDancer 20:08, 25 August 2007 (EDT)

That looks good too. You're right about the 'end' thing, that wasn't quite the right word. I changed it to the wording in the Return function, but whichever works. The original sounded like it worked differently from other scripts and Return functions, which was the thinking at the time, so :shrug:.

--Haama 22:30, 25 August 2007 (EDT)

I would say use the above version of the note since it explains more about what is happening. The Return page might actually need a little updating as well to better explain how it works when used.

--ShadowDancer 00:32, 26 August 2007 (EDT)

The return discussion should be moved to the return page, then. What needs to be updated?

--Haama 00:52, 26 August 2007 (EDT)

I actually already did an update to the Return page to better clarify how it works. The wording on a bunch of it was either vague or outright wrong like the part where it said "...it terminates the script for the rest of the frame. The script will be run again the next frame." I think that the return discussion here was more focused on how it interacts with the ScriptEffectUpdate and should probably stay here.

--ShadowDancer 01:20, 26 August 2007 (EDT)