Is it at all possible for an indefinite number of standard, player-selected NPCs to persistently store "ref" variables? Magic Effect script variables reset when the subject NPC is loaded/unloaded...

You would probably need OBSE since it has more functions which can record information. The trick is to make that indefinite number more definable, or atleast limited. You can use quest scripts to store the IDs of NPCs, and store 20 or so using a sort of queuing system (after it stores in one slot, a varable is increased so that the next NPC targeted goes in the next slot.) You can then make a magic effect share information with that quest script to make sure that the variables remain constant. You can also use faction ranks (instead of variables) to store information perminantly by base NPC, or use dispositions toward a dummy NPC* to make them constant within that specific NPC (as long as the NPC doesn't respawn)

Alot of how this is done is a bit dependant on what NPCs you plan on using, and what you want them to be doing. Respawning NPCs typically don't work well with anything in this regard, and would need special adjustments made to them in the CS to get around those limitations.

*using dispositions is more difficult, and really only makes sense if you want cloned NPCs to behave differently without having to record each of their IDs anywhere.

Faction ranks and unplayable clothing are fine for numerical variables, not so much for refs... Actually, you know what? On the subject of unplayable clothing, I suppose that could be used to sneak an object script in, with the added bonus of being OBSE-free and dealing perfectly with respawning NPCs! Yay!

Well, the refs you would have to store on a quest script. The factions are really there to act as a persistant marker.

if <NPC>.getinfaction <faction>
<NPC>.Addspell <ability>

in the quest script, as part of a normal update routine paired with

set <variable> to self.getfactionrank <faction>

in the magic script. This would work as a means of storing those variables so that they can be re-registered by a local script. Then that local script can make changes based on that variable.

But again, doesn't work too well for respawning NPCs since all versions of that NPC will retain the same factions, and when they respawn they will be given a different ID.

Ah, okay. But an unplayable scripted clothing's variables would still remain unique and persistent, right?
This isn't necessary, but for the purpose of OnLoad blocks, do inventory items count as being loaded when their container is, or when they "enter the world"?

Scripts on inventory items will remain, however when the NPC respawns, they will probably be given a new copy of that item (unless you have a way of moving the item from the NPC before respawn to a holding container, then from that container to the new NPC after respawn). As far as onload, I believe it only runs when the item is placed in the world (not loaded by inventory, not worn, only dropped).

I'd be tempted to say that no scripting gets run if the item is just loaded within a container. The item needs to be picked up, used, or placed in world for any scripts to even register. I'm not even sure if gamemode blocks run when an item is worn. It's been awhile since I was last playing with scripted tokens, and admittedly, those never went very far due to the respawn issue (ended up using factions instead).

One option, if you're using OBSE, is to just disable the respawn of the NPC while they are alive and under your influence.
http://cs.elderscrolls.com/constwiki/index...etActorRespawns

Then you have one less issue to worry about. It may interfere with any clones of that NPC that aren't being controlled, but there aren't many instances of that.

Can be combined with
http://cs.elderscrolls.com/constwiki/index...LevelProcessing

to make fodder NPCs, like bandits, a bit more capable at moving around.

In this case it would be primarily using AddItem, so that wouldn't be a problem... Initial tests suggest that, while such an item doesn't have its OnLoad block run when in an inventory, its GameMode block runs every tick, whether worn or not. So it seems like it's all good.
And doesn't giving an NPC Low Level Processing force "Persistent Reference" status? That could be trouble...

No, when enabled low level processing is used to allow NPCs to move around when they aren't in the loaded cell. It "should" have the added side effect of keeping their data more current, and thus less likely to be purged.

The problem with using gamemode blocks on an item is that you still run into the issue of scripts on that item not retaining variables (the same reason why you didn't want to use magic effects). And has an added disadvantage since it can potentially lead to save game bloating depending on how many scripted items are created. This is because every time an item is added, it gets its own version of it's script, which doesn't get cleared when the owner is despawned. Although that scripting remains, it cannot be accessed by anything.

Tests suggest that a DoOnce variable on the item will, at the very least, retain its value after being unloaded/loaded. I don't really see anything that suggests Object scripts reset their variables like Magic Effect scripts... And I was just considering that, whenever I place an NPC with low level processing, the Persistent Reference tag is forced. It's togglable if the NPC doesn't have it.

I'm not sure if I'm following you here on save game-bloating... When you need multiples of a certain script, say two NPCs experiencing a scripted magic effect or with an object script, different versions of that script are created, except that Magic Effect scripts are cleaned up properly while, even if a scripted object in question ceases to exist via the owner vanishing or RemoveMe, the script remains? But that can't be right, can it? What about all the unlootable arena armor? And OOO added scripts to a lot of mundane objects... Every type of gem, for a start...

Dunno. I havn't actually done any of the benchmarking myself. But as far as the arena goes, only the blue/red armor has a script on it, and the quantity of those is limited, just like how there aren't many scripted items which appear on fodder characters in Vanilla. For everything else, I'm not sure, the issue maybe only related to scripts which record local variables, or more likely, those scripts need to be duplicated often enough, and be used for any significant change to be noticed.

As for the variable on the item... I'm a bit skeptical of that. You mean to say that a script with something like;



Technically, that script should only set rand once, and display rand every new day. If the NPC with that item is respawned, and a new instance of that item is generated, rand should not change, by your tests. However this doesn't make much sense to me since rand is reset for every instance of that item. If you have two seperate versions of that item in existance, they should have different numbers.

I never did anything with respawning. Just walking out of the cell, loading up the resulting autosave to make sure the cell needs to load again, and walking back in. That said, this project will work just fine with the variables reseting upon respawn. If respawning NPCs even end up working with this, which seems unlikely...
What about all the un-lootable Arena weapons aside from the raiments?