コミュニティQ&A

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

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

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

+2 支持
It looks like a recent version of the UE4 plugin code has made it so calling PostEvent on an actor where IsActorBeingDestroyed() returns true fails to post the event. This workflow worked in previous versions of the plugin, and has caused a lot of performance problems in our event workflow due to game objects not properly being cleaned up in WWise now due to the stop events not being posted. It seems like a common pattern to start a looping sound on BeginPlay and subsequently call a stop event on EndPlay. The inability to post events during destruction would require us to create an entire pre-destruction code path to call solely for audio events.

Is there a good reason for this behavior? As I said, we were doing it before and did not notice and side effects. But perhaps something changed in WWise to warrant this? But on the off chance this was just an over zealous engineer trying to be safe, I'd really like to see it reverted as it creates a lot of seemingly unnecessary work for users of the plugin with what feels like a common event workflow.
Matt F. (120 ポイント) General Discussion

Please sign-in or register to answer this question.

...