コミュニティQ&A

Audiokineticのコミュニティ主導のQ&Aフォーラムへようこそ。ここはWwiseとStrataのユーザのみなさまがお互いに協力し合う場です。弊社チームによる直接のサポートをご希望の場合はサポートチケットページをご利用ください。バグを報告するには、Audiokinetic LauncherのBug Reportオプションをご利用ください。(Q&AフォーラムではBug Reportを受け付けておりませんのでご注意ください。専用のBug Reportシステムをご利用いただくことで、バグの報告が適切な担当部門に届き、修正される可能性が高まります。)

最適な回答を迅速に得られるよう、ご質問を投稿される際は以下のヒントをご参考ください。

  • 具体的に示す:何を達成したいのか、またはどんな問題に直面しているのかを具体的に示してください。
  • 重要な詳細情報を含める:Wwiseとゲームエンジンのバージョンやご利用のOSなど詳細情報を記載してください。
  • 試したことを説明する:すでに試してみたトラブルシューティングの手順を教えてください。
  • 事実に焦点を当てる:問題の技術的な事実を記載してください。問題に焦点を当てることで、ほかのユーザのみなさまが解決策を迅速に見つけやすくなります。

+2 支持

Hello, we're using Wwise 2023.1.1.8417.2904 for UE 5.3.2 and we're encountering a failing check() when stopping PIE with multiple client players in AkAudioDevice.cpp line 3101: check(!m_defaultListeners.Contains(in_pComponent));

In this integration, they changed the typedef of UAkComponentSet to be a TSet of TWeakObjectPtrs as opposed to raw pointers, previously. This has a side effect of not being able to reliably find a matching entry in the TSet if the set contains any PendingKill objects (affects functions like Contains(), Find(), Remove(), etc). This is because the equality operator (used for the aforementioned functions) of TWeakObjectPtrs considers PendingKill objects both as nullptr, and therefore equal, even if the two weak ptrs were originally pointing to separate objects (this is because the equal op uses the de-ref op, which uses Get(bool bEvenIfPendingKill = false) for perf reasons).

In regards to Wwise's failing check(), where it worked previously because raw pointer addresses of PendingKill object were still distinct, it is now reasonable for the TSet that they're check()'ing against to contain multiple PendingKill ("null") listeners (due to stopping PIE multi-player), so the check() just doesn't make sense anymore - in fact, all of the usages of the TSet modification functions are now suspect because attempting to query/find/remove any PendingKill object will perform those actions with other PendingKill entries in the TSet even if the set didn't actually contain the object in question.

We're commenting-out the failing check() to stop the editor from closing for the team, but this change to use weak pointers as a drop-in replacement seems alarming to me - can someone from Wwise offer any insight?

Thanks

Kevin Mabie (120 ポイント) General Discussion

Hello! Thank you for your post, we have exactly the same issue as you: www.audiokinetic.com/qa/12674/crash-bug-in-fakaudiodevice-unregistercomponent

We have removed temporarily the check like you, but replacing the TWeakObjectPtr to a raw pointer as it was before also works.

Looking forward to hear from Wwise guys.

Hey, we've been seeing the same thing using 2023.1.4.8496.3012, and I've commented out the check for now too. I'm wary of changing the TWeakObjectPtr back to raw though! It seems there has been a bit of work in this area given the IsValid test, and CleanDefaultListeners function used in editor builds. I'm looking forward to a resolution too.

Please sign-in or register to answer this question.

...