[過去ﾛｸﾞ] 【3Dゲームエンジン】Unity総合スレッド31 [無断転載禁止]©2ch.net (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
640(2): 2017/12/15(金)14:22 ID:bO73tzHJ(1/3) AAS
>>631
気まぐれというよりは見落としがちな仕様の1つって感じかな？
他の不親切な開発環境だと、マニュアルの車運転んしてるみたいに最初からその辺り注意して作るが
Unityは変に親切設計でオートマ車みたいな感じなのもあり
意識しないで作れるようになってるから俺には落とし穴だった。
その割には詳しく説明してるサイトは少ない気がした。
>>634
漠然とは明記されてたようだよｗ漠然とね >>637
説明みてても初心者向きではないわなｗ
>>637
サンクス！
この説明分に俺なりの補足いれると
こうなる
↓
実際のオブジェクト破壊は瞬時には行われません。
Destoryを記述した同一フレームのUpdateの最期に実行されます。
この動きはinstantiateも同じです。
よってFindでオブジェクトを検索する時は注意してください。
Findは同一フレームのUpdateの最初に実行されます。
Start()でinstantiateした場合Findを使用しても検索できない事になります。
645: 2017/12/15(金)16:40 ID:bO73tzHJ(2/3) AAS
>>641
まさにおっしゃりとおり
ちなみに
＞そもそもGameObject.Find()に依存した作りはお勧めしない
これも当然承知の上で物は使い様でケースバイケースで使ってる
例えば俺の場合ステージ移管の時の初期化はFindが多い。
Updateみたいに毎フレーム呼び出すような頻繁にやるものではないため処理速度を要求していないのと
変数に格納してメモリー圧迫したくないという点からFindの方が向いてるわけよ。
その場限りの使い捨てみたいな感じの場所でFindは重宝してる。
俺の場合ね。
646(2): 2017/12/15(金)16:52 ID:bO73tzHJ(3/3) AAS
>>642
そうそうまさに初心者の定義は人によるから何とも言い難いところだわな。
フラグ立てて非同期っぽく遅延処理かけるやり方は結構制御に気をつかうので
中級者レベルかな〜と勝手に思ってる。
なんとなくネットワークプログラムのタイムアウト処理とか
外部ファイルの非同期読み込み処理に似てるものがあるしね。
初心者には結構難しい所だとおもうわけよ。
俺が最初そうだったからさｗあくまで俺基準だけどなｗ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.031s