So, what is one supposed to use instead of cloaks?

It depends what you're trying to achieve. In many cases, a cloak is fine - they've just been demonized by people who have received wisdom about cloaks and repeat it without considering that cloaks are very dependent on the specific implementation.

If you treat cloak code the way I suggest you treat burstable events, chances are you'll never have a problem with your cloak.

But there are mods that do make bad use of cloaks, and mods that made seriously bad use of cloaks and created the bad reputation they have.

SLAR replaced SLA's cloak with a quest that populates aliases based on conditions.

The quest approach can only fill as many aliases as the quest has, so the work is always bounded.

A cloak could potentially generate a list of 50 NPCs, but SLA* only wants to process a small number of NPCs, so finding those extra NPCs is a bad outcome for SLA.

However, SLA* should theoretically be processing all those NPCs, it's just designed not to, to help performance.

If you can process the NPCs efficiently, maybe you do want to find them.

A lot of mods - and DF is currently one - find rapists by using a cloak and then picking the nearest NPCs. (Lozeak copied the cloak example from the CK site, and that example is the root cause of most bad cloaks you'll see; despite its warnings it demonstrates a bad pattern). I plan to remove the DF cloak once I have a solution I like in SLAX.

Simplistically, in the case DF had, it would have been better to use a quest, because you could directly fill the sex partner aliases.

SLD uses a cloak to do it, where the cloak script is very fast, but it's something I might revisit. In this case SLD wants to find an arbitrarily large number of participants. SLD will happily set up a massive chain-run on the PC, and will also re-scan for participants during an ongoing scene. Solving this with a quest probably wouldn't be practical or efficient.

How I intend to solve this problem for SLAX is something I've been thinking about a long time. The existing quest based approach has some problems. It takes a long time to start a quest, and it's actually quite a load-generating process. Probably, the load from spinning up a quest is more than from a cloak that finds the same number of people and uses the busy-state model to turn itself off once it's found them. Certainly, the latency for quest start is high.

I want a more responsive approach, and more continuity in the alias population. I want the aliases to update incrementally as the player moves, or NPCs move away, or closer. That can't be done with a quest.

For a single cell, it's possible to write C++ that walks the occupants and applies conditions purely in C++, which is extremely fast and responsive. So that would work for interiors, but outside, the player may be at a cell boundary. In that case, finding the adjacent cells can be hard. I looked at how DynDOLOD does it, and it has a big table that tells it what cells are adjacent to others, which is not a something I want to replicate due to the work involved. This means that a hybrid approach might be best.

It's an area where I need to do some experimentation.

But the short answer is that in many cases a cloak can be replaced with a quest, or a better made cloak, or if you just want one NPC, there's a built-in native function to find a random NPC within a specified radius.

If your goal really is to add a new script to every NPC (or worse, every ObjRef) in a radius, you might want to rethink that entire approach, because doing that is what is most likely to generate suspended stacks in Papyrus when using a cloak. But if you bounded the scripts that could be added using the busy pattern, it might be perfectly fine.

One approach you can use is the game.Find* functions. FindRandomActorFromRef will grab an actor inside a certain radius of the given reference. This is useful if you don't have too many condition on what sort of actor you want and you only want a small number. For example, the rapist case above could pick a random actor and throw away unsuitable actors and still find a candidate fairly  fast. The advantage here is twofold. Firstly, you're doing this without the event burst of a cloak or the stat up time of a quest, and secondly, you don't have to surrender control while the quest starts and you can keep your code all in one function. Downside is that if you have too many conditions on what sort of actor you need, you may spend too long testing and discarding actors. If that happens a quest is better.

Formlists are also potentially useful. They act as Sets, so if you don't need to worry about duplicates. So for the case where a cloak adds actors to a list for processing, a Formlist saves worrying about duplicates.

You can also use the FindRandom* functions with a formlist in some cases. Suppose you want a cloak-like function, but that it's not essential that you get all of them, or that they all happen right away.  You could have a timer loop that every second adds one or two actors into a formlist, Doesn't matter which ones because you'll get them all eventually.

8 hours ago, DocClox said:

One approach you can use is the game.Find* functions. FindRandomActorFromRef will grab an actor inside a certain radius of the given reference. This is useful if you don't have too many condition on what sort of actor you want and you only want a small number. For example, the rapist case above could pick a random actor and throw away unsuitable actors and still find a candidate fairly  fast. The advantage here is twofold. Firstly, you're doing this without the event burst of a cloak or the stat up time of a quest, and secondly, you don't have to surrender control while the quest starts and you can keep your code all in one function. Downside is that if you have too many conditions on what sort of actor you need, you may spend too long testing and discarding actors. If that happens a quest is better.

I did mention that approach if you want to identify low numbers of, or single NPCs.

I plan to experiment with it for the SLAX scanner, trying an incremental update approach, at least for outdoors. Indoors C++ cell scanning may be better, but outdoors you run into the cell boundary issue. I think I wrote about this somewhere else though so I'm repeating myself. 

The advantage of find - I think - is that you don't put any burst pressure on Papyrus, and it can just chug along single-threaded in its Papyrussy way, and Papyrus basically can't ever stress or overload your game with a single thread of execution. The find native functions may come at a cost though, and it may be more efficient to get more actors at once if scanning with C++. If I know how to get adjacent cells in C++ that would be a huge help.

Ah, it's like finding all the info about effects on the player. It's been done in C++, but there's no source, so you need to put in a lot of effort to figure out how it is done, and it might require decoding data that SKSE knows nothing about.

22 minutes ago, Lupine00 said:

I did mention that approach if you want to identify low numbers of, or single NPCs.

You did. My bad.

22 minutes ago, Lupine00 said:

Ah, it's like finding all the info about effects on the player. It's been done in C++, but there's no source, so you need to put in a lot of effort to figure out how it is done, and it might require decoding data that SKSE knows nothing about.

I'll be interested in your results. I have some custom detects that need to call a pap function to evaluate whether the actor shows up in the detect, (or what color they highlight) and that uses a lot of these techniques. The end result is performant enough , but it can take a couple of casts before new actors get fully updated. I'd be interested in anything that lets me improve on that.

I think the performance edge of cloaks may be under-rated; if used with the busy pattern, probably quite safe.

Given how you have to use them over a time-period, my suspicion is that cloaks are relying on data that build up spatial data as part of the render-prep phase, and that then allows highly efficient query of what actors are nearby, have LOS, etc.  So you're waiting for a while, then suddenly the data is there, because the render is in a separate thread. So, the cloak updates what is in range at that point, with latency.

But that's just a hunch based on the way that cloak results trickle in. They may not work anything like that. They may simply be iterating through all the actors in the cell, and then nearby cells if needed.

Either way, from a Papyrus viewpoint, the cloak is perfect for finding "all the things" in a radius around a target.

The problems come when it finds too many things, and also because it keeps on finding them, periodically - which I suspect is another feature that Beth tried to implement quite carefully, so cloak-based damage shields can work predictably.

This latter behavior may be what creates all the latency in cloaks, so they may not be connected to render at all. But as noted, this was Beth's best shot at using the engine to search for collections for actors in a radius. If only they'd exposed a way to do this once-only on demand.