Continue(s)

Twitter:@dn0t_ GitHub:@ogrew

【Unity】子オブジェクトとしてInstantiateしたり、子オブジェクトまとめてDestroyしたり。

あるオブジェクト(親)に対してInstantiateで子オブジェクトを任意の数生成したり、あるいはそのオブジェクトの子オブジェクトをまとめて消したりしたいケースは多い。

[ContextMenu("XXXX")]コンテキストメニューに"XXXX"の名前で新たに項目が追加されて自由にメソッドを実行できます。よく使います。

子オブジェクト量産する

    void GenerateChildren()
    {
        for (int i = 0; i < _num; i++)
        {
            var parent = this.transform;
            var instance = Instantiate(_prefab, spawnPos(), Quaternion.identity, parent);
        }
    }

Instantiateの4つ目の引数にparentObj.transformを与えるとそれが親になります。 あるいはSetParent()を使った書き方もあります。どちらが一般的なのでしょうか?ぐぐったら、一応そのパフォーマンスを測った記事があったので載せておきます。

qiita.com

ちなみに余談ですが、今日定時後にまさにこんな感じのスクリプトを書いてPR作ろうとしたら動作確認で不審な動きをして「ど、どうなってるんだあああああ!」って1時間くらい悩んでいたら、なんてことはないinstance.setData 的な処理をやろうとして _prefab.setData とやってしまっていました。凡ミスですが、沼りました。助けてくれた先輩に感謝です。

子オブジェクト一括削除する

    void DestroyAllChildren()
    {
        for(int i = 0; i < transform.childCount; i++)
        {
            Destroy(transform.GetChild(i).gameObject);
        }
        transform.DetachChildren();
    }

ここではDestroyを使っていますが、実を言うとコンテキストメニューからのコマンド実行を最初から考えており、その際にedit mode(not play mode)でなんの気なしに実行したらエラーが出てしまい、読むと「edit modeでオブジェクトを削除したいんだったらDestroyImmediateを使って!」的なエラーメッセージが。

ということでそれにならってDestroyImmediateで書いてレビューお願いしたら先輩に「(今回みたいなケースならまあ使いたいのもわかるけど)非推奨だよ!」と教わったという経緯があります。

ヒエラルキー内のオブジェクトの操作をしたいときはplay modeで動作を確認する、これを肝に銘じます。

ちなみにDestroyはゲーム画面からオブジェクトを消去してくれますが実は裏では完全に削除されておらず、そのフレームの最後?あるいは次のフレームの頭?の処理で綺麗サッパリ消えるようです。(このあたりはUnity内のフローによるところなのでもう少し勉強が必要そうです。)

とはいえ、それがわかるとedit modeだと変な挙動を示す理由もわかります。

transform.DetachChildren();のところに関しては以下の記事の説明が簡潔でわかりやすいです。

cosmocleaner.hatenablog.com

f:id:taiga006:20200118010359g:plain

コンテキストメニューから操作しているので何のエビデンスにもならない動作確認GIFです。

【Unity】"XXXX.app" requires a provisioning profile. に頭を抱える.

unityアプリの自動iosビルド化に頭をかかえる日々。 そういった頭痛の種の中でも先週一番大きかったのがerror: exportArchive: "XXXX.app" requires a provisioning profile.

...つまり「お前が指定したplistにはProvisioning Profileに関する項目がないぞ!」というやつ。

このエラーはすでにほとんどの開発ケースではぶつからないはず。

というのも今は認証周りはAutomatic manage signingさせておけば大抵のケースでうまくいく。 (今回は古いビルドマシンを使って作業をして、SigningをAutoではなくManualで設定する羽目になった。)

Provisioning Profileに関してはUnityで書いたビルドスクリプトでIDを正しく指定しているし、なんならそこから吐き出されたxcodeファイルを開いてSigningの項目を見てもちゃんとできているんだけれどいざコマンドラインから実行しようとすると上のようなエラーが出てしまう、、、しょぼーん。

どうしたものかと頭を抱えていると、とても参考になるQiitaの記事を発見。

UnityのiOSビルドを自動化させたい人はひとまずこれを見るのが2020年1月時点では一番良さそう。

そこでProvisioning ProfileのUUIDというのがあってそれをアーカイブ化、ipa化させるときにそれぞれコマンドラインから指定できることがわかった。

さて、本題はその調べ方。基本的には.mobileprovision形式のファイルは中身を見ることができない。 Xcodeから調べる方法もあるみたいだけど、もっと簡単な方法がある。


① 作ったProvisioning Profileをダウンロード
② mobileprovisionファイルに対して以下のコマンドを叩く

security cms -D -i sampleapp.mobileprovision | grep UUID -A 1

③ xcodebuildのオプションにPROVISIONING_PROFILE=XXX-XXXX-XXXX-XXXXXXXのような形式で追加


これでうまく行ってそんな馬鹿なってなった。 -exportProvisioningProfileってオプションはもう使えないよ、って情報を早々に見つけてしまったのが敗因。

それからmacのsecurityコマンドってのがよくわからん。このへんが公式のドキュメント?