Arbor

Unity 2019.1.2f1
arbor3.5.2

購入したばかりで使い方が間違っているかもしれないのですが質問させてください。
ArborFSM内に下記を追加したのですが、1つ目に接触したオブジェクトはDestroyできて2つ目以降のオブジェクトはDestroyできませんでした。

１、OnCollisionEnterTransition
２、Collision.GameObject
３、DestroyGameObject
４、GoToTransition(１へ戻る)

2つ目以降のオブジェクトがDestroyできない原因は何でしょうか？
サンプルのCoin PusherのSaucerオブジェクトと同じ構成のOnTriggerEnterTransitionからComponent.GetGameObject経由の場合と
単体のOnCollisionEnterDestroyを使った場合では正常にDestroyできることは確認しました。

それともう一つ別件ですが、ArborでFixedUpdateのタイミングでオブジェクトの移動などを制御したい場合はどのようにすれば良いでしょうか？

A_rosuko wrote: ↑2019/05/14 17:37 2つ目以降のオブジェクトがDestroyできない原因は何でしょうか？

遷移するタイミングがデフォルトでLateUpdateになっていますので、そのままではOnCollisionEnterのような1フレーム中に何度も呼ばれる場合に遷移漏れが発生してしまいます。
遷移タイミングをImmediateにすることで判定時に即遷移されるため、同フレーム中にOnCollisionEnterステートに一瞬で戻すことで回避できます。
遷移タイミングを変更するにはStateLinkの歯車アイコンをクリックし、TransitionTimingを設定してください。

ステートマシン#TransitionTiming | Arbor Documentation

また、もし同フレーム中にOnCollisionEnterステートに一瞬で戻せない（他にさせていることがある）場合は、常駐ステートを使用すると処理中のステートを無視して強制遷移させられます。

ステートマシン#常駐ステート | Arbor Documentation

A_rosuko wrote: ↑2019/05/14 17:37 それともう一つ別件ですが、ArborでFixedUpdateのタイミングでオブジェクトの移動などを制御したい場合はどのようにすれば良いでしょうか？

いくつかRigidbodyの移動関連のStateBehaviourが組み込まれていますので、参考にしてみてください。

• AddForceRigidbody
• AddVelocityRigidbody
• SetVelocityRigidbody
• TweenRigidbodyPosition

また、組み込みStateBehaviourだけでは実現できないような動作でしたら、StateBehaviourの自作をお勧めいたします。
自作したStateBehaviourにFixedUpdateメソッドを定義し、Rigidbody.MovePositionなどを行うことで移動できます。

StateBehaviour | Arbor Documentation

返信どうもありがとうございます。
いろいろ試していて返信遅くなってしまいました。

Destroyが出来ない原因についてはimmediateも設定してアイコンがカミナリマークになっていますし、オブジェクトも当たるタイミングもずらしています。
Coin Pusherのサンプルの方法ではDestroyできていますのでTransitionTimingの問題ではないようです。

FixedUpdateについてはStateBehaviourからプログラムを追いかけて、別の方向行ってしまった気がしますが下記の内容を追加してみました。
１、UpdateType.csにEveryFixedUpdateを追加。
２、Updatesettings.csにEveryFixedUpdateでTrueを返すcaseを追加。
３、arborFSMInternal.csにUpdate関数があったので下にFixedUpdate関数を作ってUpdateの中身をコピーして追加。
とりあえず、何か影響が出ないか慎重に確認しながら使ってみようと思います。
この方法でダメだったら提示頂いた方法も含めていろいろ試してみようと思います。
こちらは要望として出しておきますね。

A_rosuko wrote: ↑2019/05/15 06:21 Destroyが出来ない原因についてはimmediateも設定してアイコンがカミナリマークになっていますし、オブジェクトも当たるタイミングもずらしています。
Coin Pusherのサンプルの方法ではDestroyできていますのでTransitionTimingの問題ではないようです。

こちらで再現確認してみたところ、Collision.GameObjectが2回目以降再計算されない不具合を発見いたしました。

暫定対処方法

• Plugins/Arbor/BuiltInBehaviours/Scripts/Calculators/Collision/CollisionGameObjectCalculator.csをコードエディタで開く。
• 40行目あたりに以下のコードを追加。

  Code: Select all

  public override bool OnCheckDirty()
  {
  	return true;
  }
  

• 注：出力したGameObjectと接続している側で何度も受け取り呼び出しをすると、その回数分だけCollision.GameObject内の処理が行われるようになります。

また、他のCollisionやCollision2D関連のCalculatorも同様に2回目以降の再計算が行われない可能性もありますので、そちらも必要に応じて追加してください。

根本的な原因などの検証ののち修正いたします。
修正版更新までしばらくお待ちください。

A_rosuko wrote: ↑2019/05/15 06:21 FixedUpdateについてはStateBehaviourからプログラムを追いかけて、別の方向行ってしまった気がしますが下記の内容を追加してみました。
１、UpdateType.csにEveryFixedUpdateを追加。
２、Updatesettings.csにEveryFixedUpdateでTrueを返すcaseを追加。
３、arborFSMInternal.csにUpdate関数があったので下にFixedUpdate関数を作ってUpdateの中身をコピーして追加。
とりあえず、何か影響が出ないか慎重に確認しながら使ってみようと思います。
この方法でダメだったら提示頂いた方法も含めていろいろ試してみようと思います。
こちらは要望として出しておきますね。

こちらにつきましては要望フォーラムの方で返答いたしますね。

原因が特定できたので報告いたします。

• Unity 2018.3以降、Physics Settingsに「Reuse Collision Callbacks」が追加され、新規プロジェクトを作成時にデフォルトでチェックがつく。
• Arborは同じ値をデータ出力しようとした場合、演算ノードの再計算負荷を抑えるため変更フラグを立てず計算させないようになっている。
• OnCollisionEnterTransitionなどで送られてきたCollisionが「Reuse Collision Callbacks」のチェックに従って使いまわしされていると、出力したCollisionは以前と同じものであるとして、Collision.GameObjectが再計算されない。

ということでした。
なので、暫定対処としては一旦以下の方法を行ってみてください。
（暫定対処としてお知らせしたOnCheckDirtyの追加部分は削除してください）

• メニューより「Edit / Project Settings」を選択。
• 左側リストから「Physics」を選択。
• 「Reuse Collision Callbacks」のチェックを外す。
• (Phsycis2Dもお使いの場合は、Physics2Dの方の「Reuse Collision Callbacks」も外してください。)

修正版更新までしばらくお待ちください。

すごい、原因の特定早すぎです！！
早速、Reuse Collision Callbacksのチェックを外したら正常に動きました。
ありがとうございます。
これはさすがにツール制作者としてはUnityめ～って案件ですね・・・。
修正版お待ちしております。

Arbor側の対応についてですが、検討の結果以下のように決定いたしました。

• 該当スクリプトのドキュメントに「Reuse Collision Callbacks」のチェックを外す必要がある旨を追記。
• もし実行時に「Reuse Collision Callbacks」が有効の場合、正常に動作しない旨の警告をログに出力。

理由としましては、以下の3点です。

• Collisionクラスにコピー用メソッドがないこと。
• Reflectionなどで無理に対応すると今後のUnityバージョンの互換性対応コストが大きくなること。
• Collisionクラス相当の自作クラスに仕様変更するとすでに利用しているFSMの互換性が取れないこと。

ご不便おかけして申し訳ございませんがよろしくお願いいたします。