Most efficient way to scan all actors around the player?

[PAPVAFS11]

I would like to enhance how dynamic the music is in my mod by assessing all actors roughly near to the player. I have concepts in mind for the scripting and overall flow of it, but I'm unsure of the ideal method to do this. I know that going over every actor for keywords, values, and etc. is not going to be a very fast process for the game to handle. My experience with FindAllReferencesWithKeyword has so far been unpleasant, but I could be using it wrong.

So, what's the least painful way to inspect everything around the player?

[SKKmods]

Do not use script, you would be hoovering up untold cycles for searcheson ActorType* race keywords or lvlActor object types which is apalling design.

What you do is start a finder quest with a conditional fill RefCollectionAlias set to Initial count  0, In Loaded Area, IsObjectType == Actor, GetDead == 0, IsDisabled == 0. Of course this is so fast and efficient, rather than cause script lag you could cause overall game lag if you call it too often at high frequency, but one call every 1/2 uGridsToLoad is fine.

Then act on those results and stop the quest.

 

[DlinnyLag]

Would this finder quest cause overall game lag if it started/stopped too often?

[SKKmods]

There is no straight yes/no answer for that.

I have finder quests that start evey 5K of player movement, others that (less elegantly) start every 10 seconds with no reported issues.

BUT it totally depends how many objects/actors it is having to find/filter and how empty (wilderness) or busy (downtown) the game is and what else is loaded & etc & etc.

Read this whole page to learn more about object/actor counts.

[RaidersClamoring]

Another solution would be to always have a cloak/on contact magic effect going (in a spell, perk or enchantment), where the "magnitude" setting is dialed in carefully and the condition functions whittling down to only exactly the things you need. It will create an invisible aura around the player which will trigger an activemagiceffect script for every actor in range that fits the criteria. You should get a decent amount of good hits when googling "creation kit cloak spell" and "creation kit detect life" as this has been a trick often used since Skyrim or earlier. I used the files and forms involved in the power armor "detectlife" visor effect to learn about it. Magic effects used this way is so common in these games they should be reasonably well optimized for it. ActiveMagicEffect scripts tend to perform well.

[SKKmods]

The issue with finder cloaks is that they fire continiously every second which puts max load on the game.

Doing that downtown on an already stressed system (or xbox) is not great. 

Many of my solutions  offer the user a switch to help them manage that load load:

(7) Actor finder operating mode [ *High performance cloak | Timer | Low overhead player movement ] 
 

[RaidersClamoring]

Yeah, the quest approach has the benefit of dramatically reduced polling. My notion is that operations defined directly in the CK as opposed to setting up a polling/event loop by hand in a script,  get access to more/other resources than the game scripts which must all be dealt with from a superficial pool under the same budget customized for "quest designers who don't know how to code", i.e.  not geared for performance. For lower level code, polling once per second you are doing barely any work at all. It could easily be made imperceivable. But I don't know how they write their code.

[LarannKiar]

On 7/4/2024 at 11:13 AM, DlinnyLag said:

Would this finder quest cause overall game lag if it started/stopped too often?

It can, especially if it's started/stopped in less than 1 second. Actually, the engine evaluates conditions in the background all the time, they aren't necessarily the cause of the lag but the "filling" process. For example if you set up a quest with a RefColl with one fill type condition GetIsIbjectType "Static" == 1.00 (or any similar condition that allows filling many refs), the game may freeze for a second or so when starting the quest. If you add GetIsIbjectType "Static" == 1.00 AND GetIsIbjectType "Static" == 0.00 you won't experience the same lag. The difference is that upon filling, the game modifies all those thousands of Static refs. I.e. depending on the alias data, constructing / adding; new keywords, attaching a linked ref; or for Actor refs: adding override packages, setting an override voice type or name, etc. How fast are the embedded functions like SetDisplayName and the like is hard to tell.

14 hours ago, RaidersClamoring said:

Another solution would be to always have a cloak/on contact magic effect going (in a spell, perk or enchantment), where the "magnitude" setting is dialed in carefully and the condition functions whittling down to only exactly the things you need. It will create an invisible aura around the player which will trigger an activemagiceffect script for every actor in range that fits the criteria. You should get a decent amount of good hits when googling "creation kit cloak spell" and "creation kit detect life" as this has been a trick often used since Skyrim or earlier. I used the files and forms involved in the power armor "detectlife" visor effect to learn about it. Magic effects used this way is so common in these games they should be reasonably well optimized for it. ActiveMagicEffect scripts tend to perform well.

The MagicEffect Cloak effect is timer based which, if I'm remembering right, is defined in the INI setting fCloakEffectUpdateInterval:General (0.5 by default). The engine has to evaluate all conditions attached to the active effect source forms which results in a constant engine load. The code takes the actor process lists to iterate the actors. Cloak effects are not necessarily bad and for per Actor script processing ActiveMagicEffects are pretty handy but I personally wouldn't recommend using them for more than 30 actors and would also recommend checking fps and looking for micro stutters.

[RaidersClamoring]

53 minutes ago, LarannKiar said:

The MagicEffect Cloak effect is timer based which, if I'm remembering right, is defined in the INI setting fCloakEffectUpdateInterval:General (0.5 by default). The engine has to evaluate all conditions attached to the active effect source forms which results in a constant engine load

Well that is the job of the engine, to process loads of data. Starving threads is bad design. Of course you shouldn't be able to fry an egg on the cpu, but that is mostly due to communication between cpu and gpu. Iterating through a collection of 200 or so actors in their capacity of some script should take less than a microsecond. Are the hash-keys we know as RefIDs and FormIDs effectively random or do they contain any actual enum/flag-like information? If they are random then thats horrible design and could explain poor performance in these scenarios. When they keys don't "mean" anything, you have to look everywhere.  Alas, I am backseat driving. Which is fun.

[SKKmods]

Whilst we dont have much (well, any) info on CreationEngine, we do know that spherical object/collider searches or spherecasting are "expensive" in Unity and Unreal  (from building AI perception & awareness models)  so can make an inference.