Contents — 6 sections
RicochetTanksの初期Buildで、Udon Program Assetを生成した直後にBuildへ進めた。
コードは生成できている。
Assetもある。
それでもBuildは止まった。
ログには、
outdated script version, wait until program assets have compiled
という内容。
問題はUdonのロジックではなく、Unity側のImport / Compileが終わる前に次へ進んでいたことだった。
ファイルが存在することと、Unityが使えることは別
自動化では、
- Fileを生成する
- 保存する
- 次のCommandへ進む
という流れにしやすい。
でもUnityは、その間に
- Asset import
- Script compile
- Udon Program Asset生成
- AssetDatabase更新
のような非同期寄りの処理を持つ。
File system上で完成していても、Unity内部ではまだReadyではないことがある。
「生成成功」の直後にBuildして失敗
初期の記録では、Udon生成後のBuildが
outdated script version
で止まった。
つまりBuild側から見ると、使おうとしているProgram Assetがまだ最新状態ではない。
そこで、Import完了を待つ処理を追加した。
その後のBuildでは先へ進めるようになった。
Automationは待ち時間を消すのではなく、条件待ちへ変える
人間がUnityを操作していると、
「Consoleが落ち着くまで少し待つ」
「Compiling表示が消えてから押す」
を無意識にやる。
自動化すると、その曖昧な待ちが消える。
すると今度は、
何をもってReadyとするか
を明示する必要が出る。
固定で5秒Sleepするより、
- import中ではない
- compile中ではない
- 必要Assetが最新
- 参照が解決している
といった条件を待つ方がいい。
高速化しすぎると、人間より早く壊す
Agentは人間より速くCommandを連打できる。
それ自体は利点。
でもUnityのようなStateful Toolでは、
前工程が内部的に終わる前に次工程へ行ける
という別のFailure Modeになる。
人間なら自然に入っていた数秒の間が、Automationではゼロになる。
Build Pipelineでは「Ready」を一段入れる
この件以降、考え方としては、
Generate
↓
Import / Compile
↓
READY
↓
Buildとする方が分かりやすい。
Generateの成功を、そのままBuild可能とみなさない。
中間状態を一つ置く。
いまの結論
今回のBuild失敗は、UdonコードのBugではなかった。
Unityがまだ仕事中なのに、Automationが次へ進んだ。
自動化すると待ち時間は減らせる。
でも、必要なのは「待たないこと」ではなく、
時間ではなく状態を待つこと。
UnityやVRChat SDKを自動化するとき、この区別はかなり効いた。
Signal / 観測記録
この記録への観測を送る
反証、