Difference between revisions of "Talk:ScriptEffectUpdate"
imported>ShadowDancer (Return doesnt really end a script) |
imported>ShadowDancer m (formatting) |
||
Line 161: | Line 161: | ||
:::--[[User:Haama|Haama]] 09:05, 25 August 2007 (EDT) | :::--[[User:Haama|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 | ::::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. | ||
::::--[[User:ShadowDancer|ShadowDancer]] 20:08, 25 August 2007 (EDT) | ::::--[[User:ShadowDancer|ShadowDancer]] 20:08, 25 August 2007 (EDT) |
Revision as of 19:13, 25 August 2007
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 effect "updates". In other words, after the effect is done running through a cycle (cycles consist of ramp up, birth time, and ramp down apparently). Running a spell script that runs an effectshader with a 0 duration produces 3 cycles, 1 duration produced 11 cycles, 2 duration produces 21 cycles, and 3 duration produces 28 cycles consistently. If there is no finish to the script effect, then it should fire every time that a cycle is complete. My test script shows a multi-layer effect if you try to run the effect shader again in the ScriptEffectUpdate block but it only builds so far and then stops (or else the slow down is so great that it only seems to stop), which makes some sense with it functioning like this rather than on every frame.
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.
- --ShadowDancer 20:08, 25 August 2007 (EDT)