Arbor

質問内容としては、そのグラフをフリーズしないようにする方法についてでしょうか？ 申し訳ありませんが、自作されているグラフの内容についてはプロジェクトを丸ごと見せていただかないと正確なサポートもできないため、基本的には自力での解決をお願いいたします。 (Arbor外スクリプトとのタイミングの問題などもあるかと思いますので) 図４については、条件合致後アクションがないので即失敗を返してノード③へ行くも割り込み条件が合致したままなため再度ノード②に戻るのを繰り返しているのかと思います。 Priorityが自分よりも低い場合に割り込むデコレータ、失敗を返した場合に次のノードを実行するSelector、...

ご質問ありがとうございます。 現在の仕様についてですが、ノードのアクティブ化と処理の流れは以下の通りとなっています。 ノードがアクティブになる このタイミングでActionBehaviourやDecorator、ServiceのOnAwakeとOnStartが呼び出される。 SubStateMachine関連では、このOnStartのタイミングでPlay開始しているため、必ず子グラフが実行開始されるようになっている。 割り込み判定を行う。 実行可能かのデコレータ判定を行う(アクティブ化後の1回のみ)。 条件に合致するならOnExecuteを呼び出す。 まず、なぜアクティブの時に必ずOnStar...

ご確認ありがとうございます。 MyOutputSlotでやりたかったことができそうです。 できそうとのことでよかったです。 上のFSMでいうところのDynamicParamaterContainerCalculatorやDynamicCalcParamaterのようなもののことです。 パラメータ名を文字列で指定しての取得や設定するCalculatorやStateBehaviourについてですね。 Parameterを文字列化して型の違いに１クッション置く話かと勘違いしてしまいました。 パラメータ名を文字列で指定しての取得や設定に関しても現在ありません。 CalcParameterなどでのPar...

ご要望ありがとうございます。
OnStateEndで遷移先State参照ですね。
対応を検討いたします。

ご報告ありがとうございます。

ノードのコピー扱いになっているようですね。
確認して修正いたします。

ご質問ありがとうございます。 要約すると、 ParameterContainerのパラメータ値を出力するCalculatorを作ろうとしている。 どのParameterContainerのなんてパラメータかは実行時までわからない。 実行時に判明した型別にそれぞれOutputSlot用意するのはなんか微妙。 ということですね。 Ⅰ、どんなInputSlotにでも接続できるOutputSlot こちらについてですが、ご希望に添えるSlotは現在ありません。 OutputSlotAnyという似たようなクラスはありますが、型が実行時までわからない場合はInputSlotAnyとしか接続できません。 こ...

ご報告ありがとうございます。

Unity 2018.1からEditorGUILayout.ColorField(GUIContent, Color, bool, bool, bool, ColorPickerHDRConfig, params GUILayoutOption[])がObsoleteになっていますね、確認不足でした。
修正いたします。

暫定対処の方法は、ご指摘の通り最後のnullを削除していただければ問題なさそうです。

The big difference between Arbor 2 and 3 is the addition of BehaviourTree and hierarchy of graph. BehaviourTree BehaviourTree is a graph that makes it easier to organize complicated AIs that are difficult to manage in FSM. It becomes a graph editor like Behavior Designer. Manual : BehaviourTree Hier...

今後の拡張性も考え、遷移時処理用スクリプトをStateLinkに持たせられるようにする （そこにCalcParameterと同等のスクリプトも組み込みで提供） ということであれば最大限の便利さを提供できそうですが、 そうではなく、単にStateLinkにパラメータを設定できるだけの機能があるとCalcParameter追加する手間が省けて便利 （逆に言うと遷移時スクリプト機能はいらない） という話であれば、申し訳ありませんが、現状の方法での対応をお願いいたします。 また、処理＋遷移用スクリプトを作成し、遷移前にパラメータを設定するようにするのはいかがでしょうか。 処理ごとにスクリプトを書く手間...

お返事ありがとうございます。

最終的には、便利かどうかは設定方法によるかと思いますが、
結局のところ、「どのパラメータにどんな値をどう設定するか」という課題がまずありますので、
現在のCalcParameterと設定機能的には同じとなり、単純に設定用にCalcParameterを追加しないといけないのが面倒、という話にも思えます。

ひとまず設定できる機能があるという点、スクリプトを自由にカスタマイズできる点を考慮すると、
StateLinkにまでパラメータ設定の固有の機能までは必要ないと思いますがどうでしょうか？