Is it possible (using OBSE or otherwise) to access local variables from a particular object's script?

Here is the scenario: I have a Quest Script that gives a Scripted Token Ring to nearby NPCs. Each Token Ring Script stores the NPCs name in a OBSE String Variable. Now, I want to be able to access that unique String Variable for each NPC from my Quest Script.

Any suggestions?

Create an array in the quest script and make the tokens add/remove the NPC names to that array?
This is how I do it.

Thanks QQuix. That's my backup plan. I am just afraid that the array will be HUGE since it will constantly be adding every NPC the player encounters throughout the game. Do you know if iterating a large array slows down performance? AFAIK a ForEach loop needs to be completed in a single frame so if I have a large array and iterate it using a ForEach, it may lag...

Just iterating thru large arrays (e.g. 1000 entries) every frame would not be noticeable in the frame rate, if you did, say, a couple of arithmetic calculations per loop (but is not a good practice, anyway). It may get heavy if you do a lot of things per loop
But I suppose you would not iterate over thousands of object scripts to get their variables, either.

ForEach loops are supposed to be used in a single frame, yes, but there are other ways to iterate thru an array. For example, you could keep an index in a var and check one entry per frame. Or 10 entries per frame, or 100, depending on how frequently you need to 'visit' an entry.

When do you need to access the variable? The array case applies when you need to have a list of ALL the affected characters, but if you're just needing the variables for a specific NPC you're already processing (e.g in a dialog result script), it's potentially simpler.

In this case I need to access the variable on the NPCs death or during conversation with him/her. I have never used a dialog script, but I don't think it will work since the variable is currently stored on the object's script in the NPCs inventory.

Anyway, I've taken QQuix's suggestion and just made it into an array.

I am curious about something else: Which of the following is a better scripting practice:

• Adding scripted tokens to every NPC, but only having the script use OnAdd and MenuMode blocks (AFAIK these scripts will only process when the NPC is in the same cell or surrounding cells as the player)
  
• Having a single quest script with a large array of NPCs constantly iterating

I'd suggest the first - That would remove the need for garbage collection, which would otherwise be tedious for dynamic refs. But ultimately, it depends on the script's intended scope.

shadeMe! I don't know if you remember me, but you basically taught me how to script a couple years back on the planetelderscrolls forums. Glad to see you're still around and thanks as always for the insight.

btw Construction Set Extended is awesome! It's making life so much easier.

The Syclonix who made BRAINS? Why, hello there :wave: Nice to see you around, mate!

..well, the one who failed to make BRAINS, but yes haha.

You know, I used to have so much trouble figuring out why my scripts wouldn't compile, how to properly iterate arrays, when to use let vs. set etc. etc. but thanks to CSE and the much better OBSE documentation, I think I'm getting the hang of it.

I haven't gone back to BRAINS or Finders Keepers, but I am working on a couple smaller mods that should be fun. Hopefully I'll release them next week

Agree that the first option is better, since you are running menumode only. Not sure if it were gamemode, considering that lots of NPC scripts still run when they are in mid or low level processing.

But, again, you may have other options.
For example, if you don't need to keep track of past encounters with the NPCs, you might just rebuild the array when the player changes cells (http://cs.elderscrolls.com/constwiki/index.php/GetCellChanged).
Otherwise, you may have a master array with all NPCs you have encountered and a small array with the nearby NPCs.
In both cases, the 'active' NPCs array will be very small (a dozen entries, maybe) to iterate frequently and this 'arquitecture' may change the tide toward option 2.