MoveTo in OnDeath blocks

[Khettienna]

Alright, since Willie offered, here's what I've come across. Using MoveTo on the player in an OnDeath block seems to be looping. MoveTo is supposed to function as a Return by itself when called on the player, but I added in a Return first thing when I saw it was looping, and that didn't change anything.

Here is how to reproduce what I see:

-Duplicate CreatureRat with a new ID and drop one in the TestingHall.

-Also place an XMarker in the TestingHall, away from the rat. Give it a persistent ref ID.

-Add this script to the rat:

ScriptName YourScriptNameGoesHere


Begin OnDeath Player  ;--because we only want this to happen if the player kills the rat


Player.MoveTo YourXMarkerRefIDGoesHere

Return  ;--redundant, in theory


End[/codebox]

Save, activate plugin, load game, kill rat. You will be teleported over and over again to the marker you placed. It may happen so fast that it appears you simply can't move. I know MoveTo has its share of "features", but I've never seen this one listed elsewhere; so I don't know if there's some great secret I've not been told or I'm just missing something reasonably obvious.

For the record, none of these loop:

[codebox]ScriptName aaTestRatLockpickScript

Begin OnDeath Player

Player.AddItem Lockpick 1
Return

End

ScriptName aaTestRatMessageBoxScript


Begin OnDeath Player


	MessageBox "You killed a rat!  Meanie!"

	Return


End[/codebox]

[codebox]ScriptName aaTestRatMessageScript

Begin OnDeath Player

Message "You killed a rat! Meanie!"
Return

End

And here is a test plugin, in the case you want to check behind me, or for your amusement: Clicky for download.

[WillieSea]

Hmm, I can only suspect that the 'forced return' in the script from the Player.MoveTo is causing the script to report that it has not finished.

And it must be different from a 'return' because those work fine.

My suggestion in this case is to use a variable:

ScriptName aaTestRatMoveToScript

short doOnce


Begin OnDeath Player

	if doOnce == 0

		set doOnce to 1

		Player.MoveTo aaTestXMH

	endif

End[/code]

[Khettienna]

I've tried it with and without the return, and with and without a DoOnce, and it makes no difference. I've tried just having the OnDeath script set a variable to trigger the moveto in another script attached to a quest or activator, and a few variants of that. Heck, I even tried spells. Whatever I tell the OnDeath script to do, it keeps doing if that action results in a "player.MoveTo".

The only thing I've seen work is using the OnDeath script to setstage on a quest, and having the MoveTo in the results script for that stage. Which doesn't mean the script isn't looping, it's just that setstage is hardcoded to only work once on a stage.

[WillieSea]

I tested the above script and it worked fine. It moved me once and that was it.

I will check it again.

[Khettienna]

Shouldn't need to, I would think. I'll set it up that way on mine.

[WillieSea]

Yeah, works fine wtih the doOnce the way I have it set above.

Perhaps you were setting the doOnce variable 'after' the MoveTo so it was never getting set?

[Khettienna]

Ahh, you set the DoOnce before calling the MoveTo, and that is the difference.

Though, and I'm just asking for the sake of academics, why does that make such a difference? And why does the moveto script need a variable, and the others don't, to only run once when called from an OnDeath block? I've never seen the same issue when using moveto in magic effect scripts or in OnActivate blocks.

[WillieSea]

As I noted before, its probably a bug with OnDeath blocks since there would have been no reason to even test such a thing. (as in, why would you perform a moveto on the player when a creature dies)

The other block types would have been tested and made sure they work. You would have to ask bethsoft since I have no idea how they coded the block types.

The reason why you have to set the variable BEFORE you perform the MoveTo is because the MoveTo acts as a 'return' and the variable will never get set.

[QQuix]

For the record and for the sake of future readers.

I've had a similar problem in the past and investigated it quite thoroughly.

My conclusion was that the "MoveTo acts as a Return" thing is actually a bug in the game engine that crashes the script for that frame. But the engine is smart enough to detect the crash, so it tries to run the script again next frame . . . and it crashes again . . . and it tries again . . . so the conclusion that it is in loop (which it is, but for a different reason).

This conclusion of mine if confirmed here once more, as there would be no reason for the OnDeath block to run over and over again.

The DoOnce works because on the second run, there is no MoveTo, therefore no crash, therefore no additional run of the script. Any other script condition that prevented the script to run the MoveTo two frames in a row would also work, e.g. a flip-flop switch or a timer.

By the same token, if the XMarker were in a different cell, the problem would not occur, because, as the player is moved to another cell, the rat would go off-scope and the script would not re-run.

And, again, by the same token, you can consistently recreate the scenario without the OnDeath block. I remember I used a TriggerZone that moved the player to a XMarker in the same cell, but outside the TZ, leading to exactly the same effect.

You also will have the same problem if the script that moves the player (even to a different cell) is in an item in the player's inventory. As the item goes along, its script continues running and crashing and running and crashing . . .

My 'crashing' conclusion may not be correct, but the game behavior is certainly consistent with this theory.

[Khettienna]

My conclusion was that the "MoveTo acts as a Return" thing is actually a bug in the game engine that crashes the script for that frame. But the engine is smart enough to detect the crash, so it tries to run the script again next frame . . . and it crashes again . . . and it tries again . . . so the conclusion that it is in loop (which it is, but for a different reason).

This was actually the point I was whittling away to prove, and I'm glad I'm not the only one. A long time (and many scripts) later, I find this bug to be 100% reliable.