QQuix

It is kind of well known (I hope) that using MoveTo prevents any further script from running in that frame. My theory is that MoveTo is bugged and, somehow, silently crashes the script execution part of the engine, without cleaning up whatever has to be cleaned. The next frame the engine, somehow, detects the failure and attempts to re-execute the same script again. This is my theory and it fits what you describe and my previous experience with MoveTo. It has nothing to do, particularly, with the TriggerBoxes or On<whatever>. If you use Player.MoveTo from a token in the player inventory, the effect is the same: loop! If you use Player.MoveTo from an item that is moved with the player, the effect is the same: loop! But (if memory serves), if you use Player.MoveTo from an item that stays behind, it works, because the next frame, the item is 'out-of-scope', so its script does not get executed anymore. The solution is what syscrusher mentioned: use a variable to make sure MoveTo does not run in two consecutive frames.

Moving lights is tricky, because lights don't behave like other objects when moved. Disable and enable do not solve it, I am afraid. I once did a lot of tests to answer a question on the Beth forums and found a perfect solution. Problem is: the thread is gone and I don't remember the details. I must have the answer in a text file somewhere in my PC, but I cant look for it today. If you are interested, I will find it tomorrow and post the solution.

I don't think you need to complicate things. The objective is quite straightforward and the solution must be simple (as the one in your first post). I suppose your script is different by now, but all items/trees running the one you posted will disable themselves whenever the player attacks an object named XXX with a weapon named ZZZ. For your objective, an additional "if TargetRef == rCrosshairs" will limit the disabling to the tree being attacked.

"Set Var to 1" and "Let var := 1" are equivalent. Set is vanilla. Let is OBSE. Let must be used when dealing with OBSE added concepts, like arrays and strings. As for the script, what is NewObject? The way it is set up. If you have 10 objects with that script in a cell, all 10 will be disabled at once when the conditions are met.

Yes, I know what you mean. As for the switch, do you expect the activator-light pair to change over time? Cant you do the detection just once? Then it does not really matters if you do it on the OnLoad or the OnActivate block (and I agree that the OnActivate option is better).

If it still helps: As WillieSea said, you can set GameDaysPassed to GameDaysPassed + 7. Problem is that you also need to Set GameDay to GameDay + 7, but then you have to adjust for going over to the next month and to the next year. Not that hard, but will need some coding. Most info for this may be found here: Special variables

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.

(a little late, but . . . ) Your approach sounds sound. One question: do you run the detection every time the cell is loaded? Do you need to? I ask because, under some conditions, the OnLoad block does not trigger. Can't remember the condition, I am afraid.

Hi, all Thanks for the warm welcome. I already had a hard time sorting out two similar dragon icons at the BGS forum. Now, here, I thought everybody had a dragon icon. Fortunately, you three guys came along to prove me wrong. Lol. (Just kidding. The dragon is beautiful)

First of all, I would like to congratulate you all for the site and the invaluable services you provide. I am a scripter that knows a lot about a very narrow area of modding (mostly moving things around). I am an active member of BGS Oblivion forums and TESNexus forums and I can see many familiar names around here. I mostly work on proof of concepts, most of them as building blocks towards my main long term project: The Evolving Society (an empty island that the player has to 'raise' to a thriving community with a large city and a several villages). Which leads me to the reason I joined: I've just finished a mod and I am interested in the beta testing 'services' you provide. The mod is called "QQuix - Construction Suit" which I will describe at the BTA forum. Take care! (oh . . .the ShoutBox . . . not sure I understand it . . . from a newcomer point of view it seems like just a lot of unrelated, encrypted phrases)