Search found 492 matches
- 2025/04/27 08:26
- Forum: Bug Report
- Topic: ParallelSequencerとParallelSelectorについて
- Replies: 2
- Views: 21
Re: ParallelSequencerとParallelSelectorについて
ParallelSequencer の子ノードのうち一つが必ず失敗を返す場合に他の子ノードが実行されない。 または ParallelSelector の子ノードのうち一つが必ず成功を返す場合に他の子ノードが実行されない、ということでしょうか。 であればどちらも仕様通りの動作となります。 ParallelSequencerの仕様は以下の通りです。 すべての子ノードを並列に実行し、いずれかの子ノードが失敗した場合に親ノードに失敗を返して実行を終了する。 子ノードがすべて成功した場合は親ノードに成功を返す。 ParallelSelectorの仕様は以下の通りです。 すべての子ノードを並列に実行し、...
- 2024/12/23 04:46
- Forum: Question
- Topic: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
- Replies: 12
- Views: 7487
Re: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
アップデート時期についてはAsset Storeの審査の関係上正確な日付についてはお知らせできません。
また現在Asset Storeのセール対象になっており、以前セール中の更新によりAsset Store側で問題が起きた経験がありますので期間中の更新は止めております。
セール終了後にアップデート作業を行いますので早くても来月中旬ごろを予定しております。
また現在Asset Storeのセール対象になっており、以前セール中の更新によりAsset Store側で問題が起きた経験がありますので期間中の更新は止めております。
セール終了後にアップデート作業を行いますので早くても来月中旬ごろを予定しております。
- 2024/12/21 09:52
- Forum: Question
- Topic: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
- Replies: 12
- Views: 7487
Re: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
Arbor関連でGCの対象にならずにメモリーに残るかどうかの仕様についてもまとめましたので記載いたします。 残るのが仕様 ArborEditorを開いた場合など、エディタ関連で参照されているデータ全般 型情報や属性などのキャッシュデータ 破棄されていないArbor関連コンポーネントから参照(Parameterやデータフローでの受け渡し含む)されているインスタンス 残らないのが仕様 破棄されたArbor関連コンポーネントからのみ参照(Parameterやデータフローでの受け渡し含む)されていたインスタンス ※「インスタンス」はコンポーネントなどUnityオブジェクト以外の参照型のインスタンスもす...
- 2024/12/20 07:54
- Forum: Question
- Topic: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
- Replies: 12
- Views: 7487
Re: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
ご確認ありがとうございます。
EachFieldの各種Findメソッドでのキャッシュは他にもありますので、そちらも同様の対策が必要なようです。
ひとまずこちらの開発環境(InstantiateAsyncへの対策も行った環境)にて、一通りEachFieldへの対策を行い関連オブジェクトDestroy後にMemoryProfilerを確認したところAll Of MemoryタブのManaged/Managed ObjectsにArbor3関連のコンポーネントのインスタンスが残っていないことを確認いたしました。
次回の更新でこの対応を適用いたします。
EachFieldの各種Findメソッドでのキャッシュは他にもありますので、そちらも同様の対策が必要なようです。
ひとまずこちらの開発環境(InstantiateAsyncへの対策も行った環境)にて、一通りEachFieldへの対策を行い関連オブジェクトDestroy後にMemoryProfilerを確認したところAll Of MemoryタブのManaged/Managed ObjectsにArbor3関連のコンポーネントのインスタンスが残っていないことを確認いたしました。
次回の更新でこの対応を適用いたします。
- 2024/12/20 03:51
- Forum: Question
- Topic: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
- Replies: 12
- Views: 7487
Re: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
もともとのコードもあまり良い作りとは言えない点に加え、別件で報告がありましたInstantiateAsyncで動かない不具合も同じ箇所が関連していますのでここは次回更新であわせて修正いたします。
- 2024/12/20 03:44
- Forum: Question
- Topic: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
- Replies: 12
- Views: 7487
Re: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
再帰的に呼び出される可能性を失念しており内容が不十分でした。 正確には以下のようなコードにしてください。 public static void Find(object rootObj, System.Type type, IFindReceiver receiver, bool ignoreRoot) { var oldReceiver = s_FindReceiver.receiver; s_FindReceiver.receiver = receiver; s_FindReceiver.Find(rootObj, type, ignoreRoot); s_FindReceiver.rece...
- 2024/12/19 10:38
- Forum: Question
- Topic: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
- Replies: 12
- Views: 7487
Re: BehaviourTreeコンポーネントを破棄した後も意図せずメモリに残り続けているコンポーネントがある
まずコンポーネントがNodeBehaviour関連の場合についてです。 最初に考えられるのは、エディタ上でノードなどをコピーした場合です。 この場合はクリップボードのような内部データにコンポーネントそのものがコピーされていますのでコピー元が破棄されても残ります。 またNodeBehaviourのフィールドから参照しているコンポーネントもGCの対象から外れます。 こちらについては仕様であり、ランタイムへの影響もありませんのでそのままでも問題ないかと思います。 エディタ操作に関係なくビルドしたランタイムでも残る場合はArbor3の何らかのキャッシュの不具合の可能性が高いです。 ざっと調べてみたとこ...
- 2024/12/19 04:07
- Forum: Bug Report
- Topic: Object.InstantiateAsync時のエラー
- Replies: 1
- Views: 3328
Re: Object.InstantiateAsync時のエラー
ご報告ありがとうございます。 InstantiateAsyncなどによる非同期デシリアライズにはキャッシュなどのスレッドセーフ対応が必要となりますが、現在はまだ対応しておりません。 今後の更新で対応できるかを検討いたします。 暫定対処方法としては以下のようになります。 全ての箇所をここで網羅することは難しいため、一般的な対処方法を記載いたします。 お急ぎの場合は、内部コードを一時的に変更して対応していただければと思います。 以下のようなスクリプトを"Plugins/Arbor/Internal/Scripts/"に作成 namespace Arbor { public st...
- 2024/12/05 10:25
- Forum: Question
- Topic: arbor3以外のパッケージによるエディタ拡張を無視したい
- Replies: 1
- Views: 4950
Re: arbor3以外のパッケージによるエディタ拡張を無視したい
まずは、ドキュメントに記載しているARBOR_DISABLE_DEFAULT_EDITORについてですが。
これはNodeBehaviour用のデフォルトのCustomEditorを無効にする設定ですので、これを設定しなければ他アセットによるEditorの上書きは発生しなくなります。
今回はそれとは別の問題で、EditorGUILayout.PropertyFieldを介した場合のPropertyDrawerが他アセットに上書きされてしまう問題のようですので、Arbor側での回避方法はありません。
問題が他アセットにある場合はそのアセットの開発者へお問い合わせください。
これはNodeBehaviour用のデフォルトのCustomEditorを無効にする設定ですので、これを設定しなければ他アセットによるEditorの上書きは発生しなくなります。
今回はそれとは別の問題で、EditorGUILayout.PropertyFieldを介した場合のPropertyDrawerが他アセットに上書きされてしまう問題のようですので、Arbor側での回避方法はありません。
問題が他アセットにある場合はそのアセットの開発者へお問い合わせください。
- 2024/09/27 23:20
- Forum: Bug Report
- Topic: NavMeshSurfaceのBuildHeightMeshを使用した場合Waypointを巡回しない
- Replies: 3
- Views: 17097
Re: NavMeshSurfaceのBuildHeightMeshを使用した場合Waypointを巡回しない
解決したようで良かったです。 一応解説しておくと、Agent関連のStopping Distanceは移動先の位置と現在位置との間の距離がこの数値以下であれば移動先にたどり着いたと判定するプロパティになっています。 数値を0にした場合は、数ミリのズレも許容されずに判定することになるため移動先に到達したとなかなか判定できず、移動しようとするもののいつまでたっても完了しなくなります。 AgentMoveOnWaypointの仕様としては開始直後は最初のWaypointへ向かう仕様ですので、エージェントの出現場所が完全一致していないことで移動完了にならず次の地点に向かえなくなり、最初の位置から動かな...