Yes, it's me again. I may have found a way to have a script track the player character's perks - this script serves as a cache/mirror for fast access to player character perk data instead of waiting for object locks with the HasPerk function.

It uses RegisterForMenu on the StatsMenu with GetPerkPoints to determine when the player has added new perks. whenever it detects that perks have been added (if there are fewer perk points on menu close than on menu open), the script will refresh its perk data.

My next question: Is there a technical limitation or an other issues with large numbers of properties on one script. I will likely need at least a property for every perk I would like to support caching for, and then additional booleans for caching actual perk status. If this would result in too many variables, I can use arrays of booleans and assign each perk an arbitrary number/array index.

I have used several hundred properties and variables before without any issues. I don't believe there's a limit on how many you can have in a script.

Yeh, like egocarib, I've used a huge amount of properties before when I was experimenting with my PokeDov idea (link in my signature contains the script if you want to have a peak at that monstrosity). It still ran as smooth as butter, in fact it was too quick. Had to slow it down with a bunch of Utility.Wait()'s

- Hypno

i think for property count it's more about memory than speed, if it's, like, 500 properties to object ref's, it'll make them all persistent