AISense_Hearing / ReportNoiseEvent never triggers OnTargetPerceptionUpdated (UE 5.8)

Hi everyone,

I’m running into what looks like a reproducible bug with the AI Perception Hearing sense in UE 5.8. AISense_Sight works perfectly, but AISense_Hearing never fires OnTargetPerceptionUpdated, even in a minimal, freshly-created test project.

Steps to reproduce:

  1. New ThirdPerson template project (UE 5.8).
  2. Created a simple AIController Blueprint with an AIPerceptionComponent.
  3. Senses Config: added AISense_Hearing (Hearing Range 900, Detect Enemies + Detect Neutrals = true, Max Age 5.0, Starts Enabled = true, LoSHearingRange 0.0).
  4. Created a simple Character/cube Blueprint, set as this AIController’s pawn (Auto Possess AI = Placed in World or Spawned), placed it in the level.
  5. On the ThirdPerson player character, bound a raw Input Key (T) directly to AISense_Hearing::ReportNoiseEvent, with Instigator = Self, NoiseLocation = GetActorLocation, Loudness = 1.0, MaxRange = 0.0 (no limit), Tag = None.
  6. Bound OnTargetPerceptionUpdated on the AIController to a Print String.

Result: Pressing T next to the test pawn (confirmed via a Print String right before ReportNoiseEvent, so the call is definitely executing) never triggers OnTargetPerceptionUpdated / the Print String. No warnings or errors appear in the Output Log.

As a sanity check, I added AISense_Sight to the same AIPerceptionComponent (Sight Radius 1000, Detect Enemies + Detect Neutrals = true), and walking into the pawn’s view cone correctly fires OnTargetPerceptionUpdated immediately. So the perception binding, the controller, and the pawn possession are all confirmed working — only Hearing fails to ever produce a stimulus.

I also tried:

  • Adding an AIPerceptionStimuliSourceComponent on the player with Auto Register as Source enabled and Hearing registered in “Register as Source for Senses”.
  • Manually calling Register Perception Stimuli Source (Sense = AISense_Hearing, Target = Self) on BeginPlay, confirmed via Return Value that registration succeeds.
  • Removing and re-adding the Hearing entry in Senses Config, recompiling/resaving in between.
  • Testing from multiple call contexts (Enhanced Input, raw Input Key, Custom Event via Set Timer by Event) — all produce the same negative result.

None of these changed the outcome. Has anyone else seen Hearing fail like this in 5.8? Is this a known regression? Happy to upload a minimal repro project if useful.

Thanks!

Hey @NikAMD98 Welcome to the community!

Well, I checked the bug tracker but didn’t see any reports about it recently. There can be a regression or maybe a simple setup problem from my perspective.

So obviously since you are triggering the noise event and there is a print we can clearly see that this is not an execution problem with inputs and similar so we can omit that.

Secondly just to be sure this is single player right? Cause noise event Client/Server setup can cause issue if the noise is not a Server event. Let me know. Sight can work since it can see the replicated movement of client so this can be an issue to double check and if this is a multiplayer game simply you can make an RPC call from C++ or from BP with CustomEvent(Replicated Server) then call the noise event.

Also, for testing, enable all affiliation checks temporarily: Enemies, Neutrals, and Friendlies. Once it works, you can remove whichever team category you don’t need.

Hey! Just wanted to follow up and say you nailed it — enabling Detect Friendlies on the Hearing sense config fixed it immediately. Confirmed single player/PIE standalone, so that wasn’t the issue, but the affiliation check absolutely was. Sight was working fine with only Enemies+Neutrals checked, but Hearing needed Friendlies too for some reason on my setup. Not sure exactly why the player ended up being read as Friendly for that sense specifically, but toggling that one box solved a debugging session that had been dragging on for way too long. Really appreciate you taking the time to help — thank you!

Glad that it’s solved!

Yeah the input wasn’t issue and multiplayer replication just a gut check. Affiliation detection requires team setup and can produce wrong results if not set.

If I remember correctly ** IGenericTeamAgentInterface** should be implemented for affiliation setup. Proper way is to use C++ and implement into the Pawn or Controller. Controller asks pawn the ID or Pawn can tell controller on posses. Think you can add it from blueprints too the generic one IGenericTeamAgentInterface | zomg's unreal engine notes or Affiliation and Team in Unreal Engine | apokrif6

There is an example implementation over here as well

Use FGenericTeamID to set IDs

As far as I remember you should be able to add interface from BP and you need to set GenericTeamID for controlled pawn. Think there is a wrapper in LEStandartLibrary plugin which is very handy in many things. You can install that and use wrapper node SetGenericTeamID/GetGenericTeamID to do bp pure.

Happy developing.