Arbor

「開いているグラフのどのノードか」については以下の方法で検索できます。

• サイドパネルのノードリストタブを開く
• 検索したい型名を検索欄に入力する
• 検索したノードを選択する
• グラフビューを中ボタン押下などでフォーカス
• Fキー押下で選択ノードへ移動

ご利用ありがとうございます。

ActionやDecoratorなどの使用箇所を探す機能はArborにはありません。
ArborのスクリプトはMonoBehaviourを継承しており、内部的にはGameObjectに追加される一般的なコンポーネントと同じ形式です。
Arbor専用の処理は不要なはずですので、一般的なUnityでのコンポーネント検索方法を調べてみてください。

ご報告ありがとうございます。 確認したところ再現できましたが根本原因がUnity側の不具合の可能性が高く、またUnity 6.1はLTSではないためUnity内部の動作も高頻度で変わってしまうかもしれません。 そのため対応を行うかどうかはひとまず様子見とさせてください。 対処方法は、Unity 6.0(LTS)をご利用いただくか、以下の暫定対処方法をお試しください。 ただしこの暫定対処方法によって別の問題が発生しても対応はできません。あらかじめご了承ください。 暫定対処方法 主に接続線をマウスオーバーをした際に前面に移動されなくする対応を行います。 Assets/Plugins/Arbor/I...

ParallelSequencer の子ノードのうち一つが必ず失敗を返す場合に他の子ノードが実行されない。 または ParallelSelector の子ノードのうち一つが必ず成功を返す場合に他の子ノードが実行されない、ということでしょうか。 であればどちらも仕様通りの動作となります。 ParallelSequencerの仕様は以下の通りです。 すべての子ノードを並列に実行し、いずれかの子ノードが失敗した場合に親ノードに失敗を返して実行を終了する。 子ノードがすべて成功した場合は親ノードに成功を返す。 ParallelSelectorの仕様は以下の通りです。 すべての子ノードを並列に実行し、...

アップデート時期についてはAsset Storeの審査の関係上正確な日付についてはお知らせできません。
また現在Asset Storeのセール対象になっており、以前セール中の更新によりAsset Store側で問題が起きた経験がありますので期間中の更新は止めております。
セール終了後にアップデート作業を行いますので早くても来月中旬ごろを予定しております。

Arbor関連でGCの対象にならずにメモリーに残るかどうかの仕様についてもまとめましたので記載いたします。 残るのが仕様 ArborEditorを開いた場合など、エディタ関連で参照されているデータ全般 型情報や属性などのキャッシュデータ 破棄されていないArbor関連コンポーネントから参照(Parameterやデータフローでの受け渡し含む)されているインスタンス 残らないのが仕様 破棄されたArbor関連コンポーネントからのみ参照(Parameterやデータフローでの受け渡し含む)されていたインスタンス ※「インスタンス」はコンポーネントなどUnityオブジェクト以外の参照型のインスタンスもす...

ご確認ありがとうございます。

EachFieldの各種Findメソッドでのキャッシュは他にもありますので、そちらも同様の対策が必要なようです。
ひとまずこちらの開発環境(InstantiateAsyncへの対策も行った環境)にて、一通りEachFieldへの対策を行い関連オブジェクトDestroy後にMemoryProfilerを確認したところAll Of MemoryタブのManaged/Managed ObjectsにArbor3関連のコンポーネントのインスタンスが残っていないことを確認いたしました。
次回の更新でこの対応を適用いたします。

もともとのコードもあまり良い作りとは言えない点に加え、別件で報告がありましたInstantiateAsyncで動かない不具合も同じ箇所が関連していますのでここは次回更新であわせて修正いたします。

再帰的に呼び出される可能性を失念しており内容が不十分でした。 正確には以下のようなコードにしてください。 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...

まずコンポーネントがNodeBehaviour関連の場合についてです。 最初に考えられるのは、エディタ上でノードなどをコピーした場合です。 この場合はクリップボードのような内部データにコンポーネントそのものがコピーされていますのでコピー元が破棄されても残ります。 またNodeBehaviourのフィールドから参照しているコンポーネントもGCの対象から外れます。 こちらについては仕様であり、ランタイムへの影響もありませんのでそのままでも問題ないかと思います。 エディタ操作に関係なくビルドしたランタイムでも残る場合はArbor3の何らかのキャッシュの不具合の可能性が高いです。 ざっと調べてみたとこ...