GetCombatVisualDetection and PlayerVisualDetection

[d4em]

These 2 can be set as conditions on magic effects, but they don't have a wiki entry at all

GetCombatAudioDetection as well

Ran some initial tests but they didn't appear to do anything

Anyone know how these work?

[pepperman35]

Never used them myself but I would hazard a guess and say they are related to the detection-based mechanics.  Are these used in any vanilla scripts?  I took a quick look and it appears GetCombatVisualDetection and PlayerVisualDetection are not in any of the Papyrus scripts. 

If they are valid condition functions in the Creation Kit (i.e., you can use them in the Conditions tab of a magic effect, spell, perk, etc.), but are not callable in scripts (i.e., you can’t log or display the exact float values in-game via script), not sure how one goes about setting up debugging to test its functionality.

[d4em]

Make a bunch of perks with the conditions set in all different shapes and forms and try to trigger them I guess

[LarannKiar]

GetCombatVisualDetection/GetCombatAudioDetection return the visibility/sound level of the combat target of the console subject ref (i.e. how much the subject ref sees/hears their target).

PlayerVisualDetection does the same as GetCombatVisualDetection but instead of combat target, it always takes the PlayerRef as target so you can use it outside of combat.

GetCombatVisualDetection < 0.00 means the target is not detected as far as I remember.

I added Condition runner and logger to Garden of Eden SE a few versions ago: you can evaluate condition items and condition fields from Papyrus scripts and if needed, log the float return values and measure the runtimes in milliseconds.

[hereami]

On 5/3/2025 at 2:59 AM, LarannKiar said:

Condition runner and logger

Curious. Probably you're very familiar with internals already, could maybe clarify some things how records' Conditions processing is designed in game? It's said that all conditions in a block are evaluated no matter the intermediate results, is that really true? For example, when topmost AND evaluates to False there is no reason to continue.

Another case in regard to automated alias fill by search, not exactly same. If one of conditions naturally blocks alias fill regarldess of subject properties, e.g. Global != Global etc., would it be recognized and prevent farther alias processing or still would iterate on every object? Mainly just pointless, though ground, theoretical matters.

[LarannKiar]

23 hours ago, hereami said:

Curious. Probably you're very familiar with internals already, could maybe clarify some things how records' Conditions processing is designed in game? It's said that all conditions in a block are evaluated no matter the intermediate results, is that really true?

As far as I remember no, the vanilla function returns after the first False condition item unless its operator is OR:

So WornHasKeyword would only be processed if the GetGlobalValue's operator is OR.

Run on: PiperRef   IsActor == 1   AND

Run on: Subject    GetGlobalValue "TrueGlobal" == 0   AND

Run on: PlayerRef   WornHasKeyword "ActorTypePower" == 1   AND

23 hours ago, hereami said:

Another case in regard to automated alias fill by search, not exactly same. If one of conditions naturally blocks alias fill regarldess of subject properties, e.g. Global != Global etc., would it be recognized and prevent farther alias processing or still would iterate on every object? Mainly just pointless, though ground, theoretical matters.

Even though one can specify a Subject ref for all conditions in the editor, for certain condition functions (e.g. GetGlobalValue) it doesn't matter because the function that the condition item invokes may not process it. It's similar to some of the console commands which don't require a reference to be called on.

I don't know right now but I highly doubt that after a non Optional Quest Alias couldn't be filled the Aliases with a greater Alias Index are processed. You can enable EnableConditionRunnerLogging(True) for Garden of Eden and call GetConditionResults() to see which conditions are actually evaluated.

[hereami]

On 5/15/2025 at 11:00 PM, LarannKiar said:

As far as I remember no, the vanilla function returns after the first False condition item unless its operator is OR:

Thanks. Possibly i've misinterpreted something. Maybe it was mentioned for OR blocks specifically, though still would be nice if first True quits the block.

Meant different thing for alias fill. If any Condition which is irrelevant to Subject itself and evaluates to False would stop this alias processing at first iteration or not. Because it's highly likely to stay False regardless of iterations number (i.e. amount of objects processed). Although in case of GetRandomPercent() it becomes ambiguous.

All this detection conditions (as topic, plus GetDetected) seem be fully impractical for player. Can we actually distinguish Caution from Danger by any simple means? I've failed to find a way, possibly missed something obvious.

[DieFeM]

8 hours ago, hereami said:

Can we actually distinguish Caution from Danger by any simple means?

https://falloutck.uesp.net/wiki/GetCombatState_-_Actor

Although the link is for the script function, the values to which you would compare the condition function are surely the same.

Quote

The actor's current combat state, which is one of the following values:

0: Not in combat

1: In combat

2: Searching

So if you want the condition to be true only on caution then use GetCombatState == 2

Edited yesterday at 06:25 AM by DieFeM

[d4em]

Doesn't work, the player goes into combat mode when [caution] is active. I assume this function is intended for use on NPCs.

I actually used this function in no combat pipboy which got roughly the endorsements it deserved since the pipboy is also disabled during caution (still fun to play with tho, makes you plan ahead)

Edited yesterday at 08:33 AM by d4em

[DieFeM]

Probably it is still bugged, in the CK wiki for Skyrim, there's an actual entry for the condition: https://ck.uesp.net/wiki/GetCombatState

There's a Bug entry, at the bottom, it says the following:

Quote

Bug
This condition is unreliable the first time it is called after a certain amount of time has passed. If this condition is used in a place where it is frequently checked (for instance, as a spell condition on an ability, checking every second) it will probably be correct after the first iteration. But if it is used in a single shot spell, it may not be. Try adding multiple magic effects to your spell, each checking for this condition, and only making the last one actually do something.