Fallout New Vegas GECK & Scripting Help 101

[Guest]

 

the animation from the added/removed package keeps playing even after the package has been removed

if you are SURE that the package is removed (i.e. checked it via console), then it could be the animation is glitching. Animations are everything but perfect and they can mess your game quite easily. It's better making some reset after an idle, you can find a reset.kf inside Sexout too, you call it on the npc and it will hopefully stop the animations. If it doesn't work, he's probably playing a peculiar kind of animation (i.e. a clamped animation setted as loop), in that case you can reset if you playgroup equip for example.

 

 

Another animation-related question.
If certain conditions are not met, the PC is supposed to sit and wait. I restrain him with "DisablePlayerControls 1 1 1 0 0 0 0" and add a new idle with conditions "GetIsId NPC:Player == 1" AND "GetQuestVariable MyQuest.iStage > 50" AND "GetQuestVariable MyQuest.iStage < 200". It works mostly fine, but is not completely reliable, i.e. it sometimes takes a while for the animation to kick in, and the PC keeps to interrupt animation and stand up for a couple of seconds from time to time.

Yes that method requires some time to kick in, that time is variable (it's cyclic). And it's not reliable, if you want to force an animation you should use playidle. OR addscriptpackage, which removes you the need to restrain movements too.

[nkAlex]

if you are SURE that the package is removed (i.e. checked it via console), then it could be the animation is glitching. Animations are everything but perfect and they can mess your game quite easily. It's better making some reset after an idle, you can find a reset.kf inside Sexout too, you call it on the npc and it will hopefully stop the animations. If it doesn't work, he's probably playing a peculiar kind of animation (i.e. a clamped animation setted as loop), in that case you can reset if you playgroup equip for example.

I'm pretty sure it's the animation. Ok, thanks, I'll look into what you suggested.

 

 

Yes that method requires some time to kick in, that time is variable (it's cyclic). And it's not reliable, if you want to force an animation you should use playidle.

From what I've read on geck.bethsoft.com PlayIdle seems even less reliable and requires certain conditions when used on the Player. There is also a link to some workarounds, but it's dead...

 

 

OR addscriptpackage, which removes you the need to restrain movements too.

Can I actually use packages on the PC? I supposed they're only applicable to NPCs...

DisablePlayerControls is also somewhat bugged it seems, sometimes it interferes with an animation or something like that, and the PC gets stuck restrained in a funny pose and can't be unrestrained even with console commands, only reloading a save helps. For now I restrain Player when the scene starts -> unrestrain right before a Sexout RunFull call -> restrain again right after -> GoTo 1. But it gets the Player stuck from time to time any way.

[Guest]

 

From what I've read on geck.bethsoft.com PlayIdle seems even less reliable and requires certain conditions when used on the Player. There is also a link to some workarounds, but it's dead...

It's probably the most reliable method, and it's instantaneous. It requires to be called inside a spell casted on the player, or in general I guess it could work as object script attached to a ref too; it doesn't work as UDF, unless it's called by one of the previous methods.

 

That dead link was wrong anyway, I know what they're talking about and it's not true, so don't worry.

 

 

Can I actually use packages on the PC? I supposed they're only applicable to NPCs...

You can, but you won't have the expected result (= your character won't start roaming because you triggered a wander package )

The only effect you achieve with a package on the player is blocking him to do everything else, so it's like if you are restraining him, but in addiction you can trigger the animations specified inside the package itself.

[nkAlex]

It's probably the most reliable method, and it's instantaneous. It requires to be called inside a spell casted on the player, or in general I guess it could work as object script attached to a ref too; it doesn't work as UDF, unless it's called by one of the previous methods.

 

That dead link was wrong anyway, I know what they're talking about and it's not true, so don't worry.

Added a spell cast, looks like at least the animation kicks in faster now, thanks

 

You can, but you won't have the expected result (= your character won't start roaming because you triggered a wander package )

The only effect you achieve with a package on the player is blocking him to do everything else, so it's like if you are restraining him, but in addiction you can trigger the animations specified inside the package itself.

How do I restrain the PC with a package? With a zero radius? Will things like "Weapon unequipped" also work?

 

Still, the packages continue to give all kinds of issues. Using the reset.kf did the trick with releasing animation-stuck NPCs, I think. But sometimes a package is not removed by "RemovePackageAt" for some reason, i.e. it still shows in the console as the active one even after trying to remove it several times. Randomly trying stuff like EVP, ResetAI, RemovePackageAt consistently sometimes does the trick. As initiating a combat does.

[Guest]

 

How do I restrain the PC with a package? With a zero radius? Will things like "Weapon unequipped" also work?

It doesn't really matter, any package will have that result. And yes the equipment flags should work. I remember I was removescriptpackage via console without passing any parameter and it was working to unrestrain me, so I believe it doesn't really care what package you're triggering.

 

 

 

Still, the packages continue to give all kinds of issues. Using the reset.kf did the trick with releasing animation-stuck NPCs, I think. But sometimes a package is not removed by "RemovePackageAt" for some reason, i.e. it still shows in the console as the active one even after trying to remove it several times. Randomly trying stuff like EVP, ResetAI, RemovePackageAt consistently sometimes does the trick. As initiating a combat does.

 

My opinion? I don't understand why using such a complicated UDF just to trigger a simple package.

[nkAlex]

It doesn't really matter, any package will have that result. And yes the equipment flags should work. I remember I was removescriptpackage via console without passing any parameter and it was working to unrestrain me, so I believe it doesn't really care what package you're triggering.

OK, maybe I'll try it later...

 

 

My opinion? I don't understand why using such a complicated UDF just to trigger a simple package.

Hmm, what UDF do you mean? I was mostly talking about stuff I tried via console in the previous posts, and the UDF posted before was to search for and remove a particular package, it's just a failsafe measure in case something went bad and a package had been added to an NPC multiple times.

The actual calling UDF which adds packages is quite simple and basically assigns a correct package to an NPC based on its scripted role.

Problem is, RemovePackageAt doesn't remove package for some rare NPCs (or maybe removes it with a very long lag?), and then a creepy dude clapping his hands starts following me all over the place.

I couldn't find any documentation on AddPackageAt/RemovePackageAt besides a list of argument, so if there are some caveats, I'm not aware.

The problematic NPC is just a random vanilla King from Freeside, and I believe it's the same one every time...

[nkAlex]

Regarding that question about packages.
Weird, but sometimes a package added with "AddPackageAt" can't be removed with "RemovePackageAt", although is removed by "RemoveScriptPackage" instead. So, executing a shortly delayed "second pass" with RemoveScriptPackage in case the package still exists (after a RemovePackageAt) does the trick, I think...


And now a portion of some new random questions

• The PC is being robbed of random items by some NPCs. But for the sake of not ruining quests and stuff like that, some items can't be taken. For now, I have the following checks:
  • if eval !(IsQuestItem rItemBaseForm) && !(IsScripted rItemBaseForm)
  • if it is not a pip-boy (i.e. GetEquipmentSlotsMask doesn't contain a 6 flag)
  • if Item name does not contain keywords "pip-boy", "key", "card" — so that various keys and keycards don't get stolen.
  Are there any other checks that should be probably performed?
• It's quite simple to make NPCs run towards some target, but is it possible to make it reverse? I want to simulate a situation where the PC sends his companions away, after which they should run away for some distance, spend some time "regrouping", and then return back and attack whoever I script them to. That should work on any random terrain or even in interiors (although in interiors it would be best if they could run away just until they can't be "seen" by the enemies)
  Is there any function that can tell whether an NPC can be spotted by another NPC?
  Is something like that even possible?
• Is there a better way of sorting out who is your enemy and who is your ally in a battle besides comparing GetCombatTarget references and faction relations (for now doing it with a multipass loop which marks any NPC fighting the PC or his companions as an enemy, and then adds everyone else from their factions to enemies either. But it is not failsafe in case an ally is fighting an enemy, and both are not faction related to any other NPCs — both will be marked as allies. Or when and ally and an enemy are related by a neutral to both faction — both will be counted as enemies).

[Odessa]

1) IsPlayable is a good one to check.

 

2) You could try GetDetected, or try GetHeadingAngle / GetVATSFront|BackTargetVisible. You can find a ref and use SetPackageTarget (or just move an XMarker) with a travel package. Got a feeling it won't be reliable.

 

3) An OnStartCombat event might be useful.

[nkAlex]

1) Will add that, thanks!

 

2) Hmm, I was also thinking about using a marker, it should be pretty easy to place it randomly "X units away from Player", but how to make sure it doesn't end up in an unreachable location (inside a building, a rock, behind a closed door, off the map, etc., especially in interiors)?

I could probably just place a marker in the very center of the world map and make them run to it until they're not "GetDetected" by specified actors, but... there is probably just so many ways it could go wrong %))

What are these "GetVATS..." functions for exactly? The GECK documentation is completely blank on them. Aren't they supposed to only work on Player?

 

3) Sounds promising, but may probably end up with the same uncertainties. I'll look into it, thanks!

[Odessa]

SexAssault uses (/used?) the GetVATSTarget functions, combined with GetHeadingAngle and a few other tricks to calculate stalkers.

 

You can call them from the console, so I'd suggest playing around with them in game to get an idea of what they return.

 

For XMarkers, you could allow the player to mark spots, kind of like "if we get seperated, meet up here", and place a few default ones to start with. Perhaps you could even expand it to allow setting up ambushes a well.

[nkAlex]

SexAssault uses (/used?) the GetVATSTarget functions, combined with GetHeadingAngle and a few other tricks to calculate stalkers.

 

You can call them from the console, so I'd suggest playing around with them in game to get an idea of what they return.

All right, I'll look into it later, maybe will even take a peek at SexAssault's scripts   

 

 

For XMarkers, you could allow the player to mark spots, kind of like "if we get seperated, meet up here", and place a few default ones to start with. Perhaps you could even expand it to allow setting up ambushes a well.

That would be good for a companion manager, bot is not exactly suitable for the situation I want to simulate. I'm currently reworking tomm434's "Unethical Deeds" mod and wanted to implement an option for the "Player as victim" mode so that the PC could choose to "take one for the team" and send away the companions, but they would actually "regroup" and come back a bit later to attack the rapists mid-act

[Guest]

Regarding that question about packages.

Weird, but sometimes a package added with "AddPackageAt" can't be removed with "RemovePackageAt", although is removed by "RemoveScriptPackage" instead. So, executing a shortly delayed "second pass" with RemoveScriptPackage in case the package still exists (after a RemovePackageAt) does the trick, I think...

 

 

And now a portion of some new random questions

• The PC is being robbed of random items by some NPCs. But for the sake of not ruining quests and stuff like that, some items can't be taken. For now, I have the following checks:Are there any other checks that should be probably performed?
  • if eval !(IsQuestItem rItemBaseForm) && !(IsScripted rItemBaseForm)
  • if it is not a pip-boy (i.e. GetEquipmentSlotsMask doesn't contain a 6 flag)
  • if Item name does not contain keywords "pip-boy", "key", "card" — so that various keys and keycards don't get stolen.
• It's quite simple to make NPCs run towards some target, but is it possible to make it reverse? I want to simulate a situation where the PC sends his companions away, after which they should run away for some distance, spend some time "regrouping", and then return back and attack whoever I script them to. That should work on any random terrain or even in interiors (although in interiors it would be best if they could run away just until they can't be "seen" by the enemies)

  Is there any function that can tell whether an NPC can be spotted by another NPC?

  Is something like that even possible?

• Is there a better way of sorting out who is your enemy and who is your ally in a battle besides comparing GetCombatTarget references and faction relations (for now doing it with a multipass loop which marks any NPC fighting the PC or his companions as an enemy, and then adds everyone else from their factions to enemies either. But it is not failsafe in case an ally is fighting an enemy, and both are not faction related to any other NPCs — both will be marked as allies. Or when and ally and an enemy are related by a neutral to both faction — both will be counted as enemies).

 

1) if you are concerned about keys, GetType 46 should exclude them all. But if you have a list of excluded keywords... what about adding "wig" and "hair", too?

 

2) If you place your marker, being unreachable is a good risk, as you said. Not only it could be in a rock, but think for example if you are on the edge of a canyon, or hooverdam, or in the water, etc. there's plenty of cases to test. But I believe a combination of timers and getdistance should make the trick - you mainly want that the companion goes away from you, so you only care about its distance, so if after some time it is still too near then let's try again and see what happens. Or point as destination an existing vanilla header, picked by location, i.e. 1 header for edge of the map, if you are S then it will pick the N marker, etc. This implies playing in Mojave, not sure what could happen in other worldspaces but I believe the npc will still move away and this is what you want basically - you need to make them go away on their feet, or it will be a pain when it's time to regroup them.

 

By the way, there's a GetLOS function which maybe could help you, for npcs.

 

3) You create a lot of false positives if you use the faction relations. The most reliable method I know is picking all the "red ones", but I forgot right now how I did it

[nkAlex]

1) if you are concerned about keys, GetType 46 should exclude them all.

Hmm, good tip, there even may be other types I'd like to exclude. Still, will fail for some mods where the keys might be just misc items.

 

But if you have a list of excluded keywords... what about adding "wig" and "hair", too?

There are wearable wigs and hair? O_o Wasn't even aware of that ))

I suppose I should also include "[", "]" and ":", since various mod configurators often have their names enclosed in those.

 

2) If you place your marker, being unreachable is a good risk, as you said. Not only it could be in a rock, but think for example if you are on the edge of a canyon, or hooverdam, or in the water, etc. there's plenty of cases to test. But I believe a combination of timers and getdistance should make the trick - you mainly want that the companion goes away from you, so you only care about its distance, so if after some time it is still too near then let's try again and see what happens. Or point as destination an existing vanilla header, picked by location, i.e. 1 header for edge of the map, if you are S then it will pick the N marker, etc. This implies playing in Mojave, not sure what could happen in other worldspaces but I believe the npc will still move away and this is what you want basically - you need to make them go away on their feet, or it will be a pain when it's time to regroup them.

 

By the way, there's a GetLOS function which maybe could help you, for npcs.

I guess I'll have to dig up some info on all this. Aren't there any functions that just return current map limits as coordinates? This is just getting more and more complicated by the minute %))

 

3) You create a lot of false positives if you use the faction relations.

Yeah, that's what I was trying to say... I think? Still, better than no filtering at all

 

The most reliable method I know is picking all the "red ones", but I forgot right now how I did it

That one sounds really promising (and pretty much exactly what I'm trying to do), maybe you know any mods that use this method? Because I have no idea right now how it can be done, Google is not much help either.

Just thought about using the OnStartCombat event to pick NPCs' targets, but it's still not fail-proof in case an enemy chooses to attack an ally who's not directly affiliated to the PC...

[Guest]

Hmm, good tip, there even may be other types I'd like to exclude. Still, will fail for some mods where the keys might be just misc items.

Personally I wouldn't be much preoccupied. If they're not marked as Quest Item, then probably they are common clutter, and if they are not, then I would have another modder to blame *just kidding*

 

 

Aren't there any functions that just return current map limits as coordinates

mmmh I don't think it would be very useful, probably I explained bad what I was meaning. Your main concern is that they don't finish inside a rock or in places like that, I guess. But I just thought to a solution right now that I'm writing:

- If it's on exteriors, you don't care too much, you just track down their distance, you only need that they go far away enough. To achieve a destination, you can move your marker in some random spot. If you are afraid to put it behind the edges, you could use a gamemode scanner that looks for a random reference of a certain type which is surely inside the edges of the map, i.e. a marker (there's a marker type), but it could be even an actor, better if not enemy, and use that reference as temporary destination for your followers' package; while you will have to not use a static, as destination, since it's full outside the edges. not sure about activators, but for example I placed some activators outside the edges in a mod of mine, shame on me...

The scanner could cause stutter due to its depth, based by how much depth you will use, in these cases I use a gamemode scanner which walks <some references> per frame, but well it depends by the kind of reference you're tracking down. A marker would be a good idea in my opinion, since there are not so many to check with GetDistance (>>> it is considered a slow function, I tend to use it less than I can)

- If it's interiors, you can track down the door marker (you know, the yellow prism), hlp ported some door functions from OBSE recently and they work very fine, I already used them. So they can simply go to the yellow prism and then you teleport them on a temporary cell, just to teleport them back to the yellow prism when they come back.

 

These are the first 2 solutions I could think about

 

maybe you know any mods that use this method?

I have an old mod on my computer which uses that, but I'm away from GECK these days.

Or if you don't mind digging, probably Gribbleshnibit's "Radar mod" uses a similar check to achieve the enemy targets in the radar.

 

EDIT: edited the second paragraph, I forgot interiors

[nkAlex]

Personally I wouldn't be much preoccupied. If they're not marked as Quest Item, then probably they are common clutter, and if they are not, then I would have another modder to blame *just kidding*

I think some of the quest mods I have do that... so it's just better to be safe

 

 

mmmh I don't think it would be very useful, probably I explained bad what I was meaning. Your main concern is that they don't finish inside a rock or in places like that, I guess. But I just thought to a solution right now that I'm writing:

- If it's on exteriors, you don't care too much, you just track down their distance, you only need that they go far away enough. To achieve a destination, you can move your marker in some random spot. If you are afraid to put it behind the edges, you could use a gamemode scanner that looks for a random reference of a certain type which is surely inside the edges of the map, i.e. a marker (there's a marker type), but it could be even an actor, better if not enemy, and use that reference as temporary destination for your followers' package; while you will have to not use a static, as destination, since it's full outside the edges. not sure about activators, but for example I placed some activators outside the edges in a mod of mine, shame on me...

The scanner could cause stutter due to its depth, based by how much depth you will use, in these cases I use a gamemode scanner which walks <some references> per frame, but well it depends by the kind of reference you're tracking down. A marker would be a good idea in my opinion, since there are not so many to check with GetDistance (>>> it is considered a slow function, I tend to use it less than I can)

- If it's interiors, you can track down the door marker (you know, the yellow prism), hlp ported some door functions from OBSE recently and they work very fine, I already used them. So they can simply go to the yellow prism and then you teleport them on a temporary cell, just to teleport them back to the yellow prism when they come back.

 

These are the first 2 solutions I could think about

Thanks! I'm storing all of the suggestions for future reference, but I think I should really finish stuff I know how to do, otherwise I'm just risking starting everything at once and not finishing anything

 

 

I have an old mod on my computer which uses that, but I'm away from GECK these days.

Or if you don't mind digging, probably Gribbleshnibit's "Radar mod" uses a similar check to achieve the enemy targets in the radar.

Looked into that (nice mod, by the way!), it uses these conditions to sort friends, enemies and neutrals:

...
if eval (rActor.HasFriendDisposition) && !(rActor.GetShouldAttack Player) ;; Friend
elseif eval (rActor.GetShouldAttack Player) ;; Enemy
else ;; Neutral
...

GECK Wiki is completely blank on the "GetShouldAttack" function, while TES Wiki says that this function has its own logic and is generally unreliable and suggests this check instead:

if eval (rActor.GetAV Aggression > 5)
  if eval (rActor.GetDisposition Player < rActor.GetAV Aggression)
    ;; Enemy
  endif
endif

So, I think I could just use all of the methods above, plus GetCombatTarget on Player and companions, instead of factions checks?

[Guest]

GetShouldAttack! Right! Disposition, as factions, causes false positives

[nkAlex]

GetShouldAttack! Right! Disposition, as factions, causes false positives

Yeah, just went to the Mojave to punch some random people  and confirm that it looks like the most reliable way to filter enemies. And "Aggression" happens to be a completely different thing compared to TES version. So, ended up with this UDF:

 

 

scn alxUDActorFnGetHasEnemy
;;; Returns true if rActor is an enemy of GetSelf.

; Args
ref rActor

; Local vars
ref rMyself


begin Function {rActor}
  SetFunctionValue 0
  let rMyself := GetSelf
  if eval !(GetType rMyself) || !(IsFormValid rMyself) || !(GetType rActor) || !(IsFormValid rActor)
    return
  endif
  if eval !(rMyself.IsActor) || !(rActor.IsActor)
    return
  endif
  if eval rActor.GetFactionRelation rMyself == 1
    SetFunctionValue 1
    return
  elseif eval rActor.GetShouldAttack rMyself
    SetFunctionValue 1
    return
  elseif eval rActor.GetCombatTarget == rMyself
    ; May return false-positives?
    SetFunctionValue 1
    return
  endif
end

 

Pretty sure the GetCombatTarget check is redundant, will leave it for now to monitor debug output.

[Guest]

 

Yeah, just went to the Mojave to punch some random people  and confirm that it looks like the most reliable way to filter enemies. And "Aggression" happens to be a completely different thing compared to TES version. So, ended up with this UDF:

 

If you want to test, here's a couple of false positives I had:

- coyotes (mum + puppies, those which are red but won't attack until you get in the aggro radius)

- certain military near the tents in Primm, I think it was Mc.Gee, but I'm not so sure, I'd test them all

[nkAlex]

A.J., thanks! I may look into it, but since those characters are marked red on the radar and the "GetShouldAttack" function basically checks for that it may not be an error actually? Taking aggro radiuses into consideration probably means walking through NPC's packages, getting their aggro radiuses and comparing them to distance to Player... doable, I guess, but sounds a bit of an overkill right now %)

All of those checks are probably slow. Maybe aggression and other stats are somehow taken into consideration either... Gah, why couldn't they just make a function like rActor.IsEnemy? ))

[Guest]

Well... when I was testing, those were a couple of false positives I remember. I for sure remember that faction and disposition didn't help with them, but what I don't remember is if GetShouldAttack solved them all. I think so, I think GetShouldAttack was the answer to every problem, however a small in game test will confirm you

By the way, I've just seen this:

if eval (rActor.GetAV Aggression > 5)
   if eval (rActor.GetDisposition Player < rActor.GetAV Aggression)
      ;; Enemy
   endif
endif

and I wanted to add you this just for curiosity:

- you don't need to eval everything, that usually is used for new NVSE 4+ things like arrays

- Aggression goes from 0 to 3. 0 is the only pacifist, 1 is someone who can fight, 2-3 are almost the same, they both are frenzy and attack whatever they see, it has not to be used on rational actors

 

[nkAlex]

Well... when I was testing, those were a couple of false positives I remember. I for sure remember that faction and disposition didn't help with them, but what I don't remember is if GetShouldAttack solved them all. I think so, I think GetShouldAttack was the answer to every problem, however a small in game test will confirm you

Well, works fine for now, but mostly tested on humans

 

By the way, I've just seen this:

- Aggression goes from 0 to 3. 0 is the only pacifist, 1 is someone who can fight, 2-3 are almost the same, they both are frenzy and attack whatever they see, it has not to be used on rational actors

Yeah, that was a suggested working solution for TES which is not applicable to Fallout, it's not included in the final UDF.

 

- you don't need to eval everything, that usually is used for new NVSE 4+ things like arrays

Yeah, I know, I just like it this way Also, eval is more likely to produce an error report into console upon failure. Unless it crashes and eats up the error, which unfortunately happens regularly. There are some conditions that always crash it without any report...

[ZuTheSkunk]

Hi. I have a quite complex problem that I really hope can be resolved somehow.

 

I have two scripts that seem to be causing CTDs. One is applied to a Protectron, and another is applied to an activator placed in the same cell as the Protectron.

 

This is the Protectron script: pastebin . com / raw . php?i=HddZpefP

 

What this script is supposed to do: At first, the Protectron is in an inactive state, locked safely inside a pod. Once he becomes activated, he starts a patrol across a specific, predetermined path. He's supposed to move between points marked with XMarkers, and always stop on each one for a random amount of time. If it happens that the XMarker is already occupied by another robot, or that a door between him and the marker is closed, the Protectron will continue standing on his current point until the path to the next one is clear. In the event that he starts combat with the player, he will just attack him as normal. However, if the Protectron enters searching state, is in he's looking for the player but doesn't know where he is, after 5 seconds he will cease combat and then teleport to a random point that is neither seen by player nor anywhere near him. He will then resume his patrol.

 

This is the activator script: pastebin . com / raw . php?i=xGB4iK7f

 

When the player enters the location, the activator is supposed to start a countdown before the "night" begins. At certain points, it's supposed to show messages how much time is left (for some reason it doesn't), and when the clock reaches zero, the night begins and the Protectron is moved onto his "spawn point". If his intended spawn point is currently seen by the player, he'll simply spawn on a different one.

 

For some reason, when the Protectron becomes active, the game crashes. I'm not sure, but I think he even gets moved rapidly between locations; I wasn't able to test out this theory though.

 

Any idea what's going on here?

 

EDIT: Nevermind... turns out, this whole time the game had a problem with a custom model, rather than the scripts.

 

I still don't know why the time messages don't show up though.

Edited August 30, 2015 by ZuTheSkunk

[nkAlex]

I'm trying to detect if the PC is fast-traveling from a Quest script, and nothing seems to work, I'm at a loss...

 

MenuMode 1007 never fires (i.e. those blocks never work):

begin MenuMode
  if (MenuMode 1007)
    ; never fires
  else
    ; works fine
  endif
end

;; or
begin MenuMode 1007
  ; never fires
end

Those methods don't work as well:

begin MenuMode
  if IsPlayerMovingIntoNewSpace == 1
    ; never fires
  endif

  if IsTimePassing == 1
    ; only fires from wait/sleep menu and never from loading screen
  endif
end

The Quest is running with a high frequency (0.1...0.25). Am I doing it wrong?

[Halstrom]

The only thing I can suggetst is record their position and look for a change in location or cell by more than x amount.

[nkAlex]

The only thing I can suggetst is record their position and look for a change in location or cell by more than x amount.

Thought abut that, but that would be a pretty ugly solution...

Aren't any of the functions above supposed to work somehow?

Or is there maybe at least an easy way to get neighboring cells for a cell? Couldn't find any function for that at http://www.gribbleshnibit.com/projects/NVSEDocs/