No Low Level Processing glitch?

[Belthan]

GECK wiki says this about actors with No Low Level Processing flag set:

The NPC does not update its AI unless the player is in the same cell as it.

True, but it also makes any REFs of that NPC non-persistent by default. When you call GetSelf in an effect script or result script operating on that REF, for example:

REF TheModel
set TheModel to GetSelf

it returns a valid REF just like it would if you called it on any other non-persistent REF. Subsequently calling

TheModel.<function>

always works if the player is in the same cell as the model. But... if the player is in a different cell, sometimes it works and sometimes it doesn't. If it was operating under the same constraint as the AI processing (only works when player is in the same cell), then I would expect it to fail every time. Any idea why doesn't it fail (or work) consistently? Am I missing something?

[rickerhk]

If you place an actor in the world with the Geck and mark that REF as persistent - then they are persistent regardless of the LLP setting. They can always be referenced by a script. As to whether the LLP setting affects the ability to run various functions reliably - I don't know. There might also be a difference if the esm flag is set in the plugin. When you were testing and the times where it worked, did you happen to leave the cell where the actor was (and so it was probably still in memory)? Or did you load a save where you had not been in that cell with the actor before?

[Belthan]

You hit the nail on the head about the inconsistent function behavior, thanks! If the player and NPC are in different cells, but both cells were recently visited by the player, reference functions work. As soon as the player (or the NPC) moves into a cell that has not been visited recently (or ever), reference functions stop working.

 

Unfortunately, these are vanilla NPCs with no LLP and no persistent flag. Which you might expect for generic background fluff NPCs, but these are named NPCs with unique dialog (e.g. Private Ortega & Morgan Blake). Makes it difficult to alter their behavior without violating my prime directive (never directly modify vanilla resources), because neither tokens, spell effects, nor quest scripts work reliably unless the player is in the same cell.

[rickerhk]

Well you could argue that since they aren't persistent then they aren't very important in the grand scheme of things, except perhaps to appearance mods. But appearance mods change the base object so there would still be no conflict if you set the persistent flag and gave them a REFiD name :)

[jazzisparis]

It behaves differently, depending on whether the object is persistent or not, and on whether the object is at an interior cell or at an exterior:

Persistent at an interior: All functions should always work reliably.

Persistent at an exterior: If the cell is currently buffered - all functions should always work reliably. Otherwise, some functions will fail (example: GetParentCell).

Non-persistent at either an interior or an exterior: If the cell is currently buffered - all functions should always work reliably. Otherwise, all functions will always fail.

Would you consider setting references, via script, to be persistent, a violation of the prime directive?

[Belthan]

I didn't know a non-persistent reference could be set to persistent at runtime. I don't think that would violate the "prime directive" (my slightly tongue in cheek term for giving a high priority to compatibility and conflict avoidance).

[jazzisparis]

In that case, if you are interested, I published an NVSE plugin yesterday, which adds this function (SetPersistent).

 

(my slightly tongue in cheek term for giving a high priority to compatibility and conflict avoidance)

:wink:

[rickerhk]

 

In that case, if you are interested, I published an NVSE plugin yesterday, which adds this function (SetPersistent).

 

(my slightly tongue in cheek term for giving a high priority to compatibility and conflict avoidance)

:wink:

 

Ah - I was looking for something like SetPersistent the other day :) I wasn't sure if had been done yet.

[hlp]

I thought I did a long time ago with SetPermanent, but it was stupid of me to apply it to baseform and not reference :( In the end SetPermanent is a useless alias to SetQuestItem