I also investigated this issue today using Unreal 5.3 and Wwise 2023.1.1.8417, it still exists and is a problem on the code side from AudioKinetic in the respective Unreal plugin.
First and foremost: Deleting log prints is never a solution @Chirag M.!
Let's get to the solution.
Setup:
- A Character blueprint with one or multiple AkComponents that are bound to sockets of the mesh
- An animation (sequence) that includes one or many AnimNotify_AkEvent which have their "Attach Name" property set to the socket names where the wanted AkComponent is bound to
Issue:
- The AkComponent can not be found when running the animation and a new AkComponent is created by the system on which the AkEvent is then posted
Reason:
- Open the AnimNotify_AkEvent blueprint and check out the "GetAkComponent" function. This function calls the C++ function of AkGameplayStatics::GetAkComponent with a standard location of (0,0,0)
- The AkGameplayStatics::GetAkComponent function passes this location, which never is null, as a reference to the AkAudioDevice->GetAkComponent(..., &Location, ...). This is a huge error, as that function actually takes a pointer to an FVector and intends for this pointer to also be a nullptr sometimes. However, AkGameplayStatics::GetAkComponent always enters a valid FVector.
AkAudioDevice::GetAkComponent:
...
// If a location is requested, try to match location.
if ( Location )
{
if (LocationType == EAttachLocation::KeepWorldPosition)
{
AttachRules = FAttachmentTransformRules::KeepWorldTransform;
if ( !FVector::PointsAreSame(*Location, pCompI->GetComponentLocation()) )
continue;
}
else
{
AttachRules = FAttachmentTransformRules::KeepRelativeTransform;
auto RelLoc = pCompI->GetRelativeLocation();
if ( !FVector::PointsAreSame(*Location, RelLoc) )
continue;
}
}
- Location here will thus never be a nullptr and you always run into a comparison in the end, if your location (in our case (0,0,0)) matches the location of your AkComponent pCompI->GetRelativeLocation() as @KoKuu has correctly pointed out.
- If our AkComponent on the Character does not sit at (0,0,0), which is very likely for footstep components or other stuff, the code will just continue and not choose that component.
Solution:
- Don't ever use AkGameplayStatics::GetAkComponent.
- Let your programmers copy the code from the function and make a helper function that can call AkAudioDevice::GetComponent also with a nullptr for the location
- In the AnimNotify_AkEvent blueprint, replace the call to AkGameplayStatics::GetAkComponent with your helper function
I have filed a bug report for this, let's see if something happens.
Cheers