yeah, not only linked refs, but also targeted refs in ai packages, run on reference in condition functions, enable parents, activate parents, etc

luckily though, the majority of the time when you assign one of these it usually is already a persistent ref (like an xmarker), but the link refs, activate parents, and package targets are something to watch out for.



IME getclosestref works fine and always gets the right target 100% of the time if you use a base object query in which it has no choice to select otherwise. in the case with the bookshelf dummies, i made 30+ separate dummy base objects and have the container in proximity so that it can only select the marker in the shelf and not the shelf next to it. if you set your search leash just small enough (preview the target range by using test radius in the ref editor's 3d data tab) the math calculation is fairly quick, but overall using findref would obviously be slower inside a lengthy while loop than calling a persistent reference directly.

its not an ideal or efficient method and its ugly, but the way i see it, you will have to tell papyrus to crunch math on each item no matter what, if you are going to avoid using persistent refs. any system that doesnt call refs directly will always run slower and i would rather have a slightly slower running script momentarily per-single-activation than have multiple persistent refs lasting forever (even if the individual price of those persistent refs is really miniscule), especially when you consider how many bookshelves you plan on using and the number of persistent refs in total as a result

scratch that idea about the dummy markers doubling as auto-populate books from level lists. apparently when you use a level item to spawn a book, it replaces the marker with the spawned book (that makes sense now that i think about it). oh well