[過去ﾛｸﾞ] 【ゲームエンジン】Unityなんでも質問スレpart15 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
380: 2024/12/19(木)00:11 ID:YOs+C3Gu(1) AAS
カニンガムの法則
カニンガムの法則は、「インターネット上で正しい答えを得る最良の方法は
質問することではなく、間違った答えを書くことである」という法則である。
381: 2024/12/19(木)00:27 ID:4W5d87yv(1) AAS
頻繁に止めたり複数動く可能性があったりするのものはコルーチンじゃないほうがいいね
382: 2024/12/19(木)00:36 ID:YOzF/vgV(1) AAS
莫迦が好きな3大法則！m9⎛´･ω･`⎞ドーン！
・ダニング＝クルーガー効果
・カリギュラ効果
・カニンガムの法則
・ジャネーの法則
・アムダールの法則
・グスタフソンの法則
383: 2024/12/19(木)00:54 ID:fsk2zKLN(1) AAS
プログラムは作った人間の書いた通りにしか動かないからなー
作った人間がバカだとつける薬がないおバカなプログラムが出来上がる
384: 2024/12/19(木)07:21 ID:UV4dTBTc(1/3) AAS
>>378
コルーチン末尾に
yield return new WaitForFixedUpdate();
でフレーム描画とシンクロさせていますが
中断の StopCoroutine は FixedUpdate のなかに書けばよいのでしょうか
385: 2024/12/19(木)09:07 ID:UV4dTBTc(2/3) AAS
昨日からコルーチンでのLerpの質問していた者ですが
根本的な原因をみつけました
lerpの第3引数0〜1遷移する変数を1に書き換えてゴールまでスキップしようとしても無視されて現在位置で止まってしまう
これは変数を1にして次のlerpが処理される前にdeltaTimeが加算され1を超えるのでlerpが実行されていない、ということでした
お騒がせしました
386: 2024/12/19(木)12:24 ID:0hoLGzS7(2/2) AAS
お前はまず硬式サンプルを3ヶ月やれ
387: 2024/12/19(木)12:29 ID:3DuFQrd4(1) AAS
まず軟式から始めないと怪我するよ
388: 2024/12/19(木)12:52 ID:0JsmdRFY(1) AAS
世界よこれが忍者のスペックだ
389: 2024/12/19(木)13:01 ID:UV4dTBTc(3/3) AAS
ケッ
390: 2024/12/19(木)13:18 ID:DPi5FS2B(1) AAS
だいたいコルーチン使う奴を優秀だと思ったことがない。
まぁ俺も使ったことあるけど。
391: 2024/12/19(木)13:18 ID:mI23ljpa(1) AAS
このスレ勢いどんどん上がってて草
392: 2024/12/19(木)14:53 ID:0eZh9dRK(1) AAS
コルーチンょりINVOKEのほうが簡潔に書けるから好き
393: 2024/12/19(木)17:23 ID:Xk37TfxT(1) AAS
コルーチンはゲームオブジェクトと生死を簡単に共にできるから楽したくて、投げっぱなし処理させる時に使ったりするな
394: 2024/12/19(木)18:55 ID:hPmkSD8X(1) AAS
UniTask 入れて async/await じゃいかんのですか？
395: 2024/12/20(金)22:06 ID:Y8hb47dI(1) AAS
LerpってA地点とB地点の割合を変化させるよりも、割合を固定したうえで現在地と目的地をUpdateで動かす方がいいんだな
この使い方を知って利用頻度が5倍くらい増えた
396: 2024/12/20(金)22:21 ID:g5OTfHAG(1) AAS
それラグあった時にワープしねえ？
397(1): 2024/12/20(金)23:19 ID:lt0FxcC+(1) AAS
非同期のマルチタスクと違いシングルタスクだから
実行したコルーチンはほぼUpdate2でしかない ただのゴミ
398: 2024/12/21(土)07:01 ID:XZ0eYDtA(1) AAS
>>397
それで十分なケースは多いんだから有用だと思うけどな
逆に非同期マルチタスクって必要？
399: 2024/12/21(土)08:36 ID:GJroyFr8(1) AAS
コルーチン使うなって言ってんじゃないの、仕様知らずに使うなって言ってんの
400: 2024/12/21(土)09:13 ID:Fwktxi0Q(1/4) AAS
whileでループしてる時点でほぼハングアップと同じ
401: 2024/12/21(土)09:46 ID:Fwktxi0Q(2/4) AAS
トグルスイッチについて質問があります
チェックボックスがありON/OFFできるとします
そいつにcallback関数を紐づけてあり、状態が変わるとcallbackが走ります
チェックONのときに押すとcallbackによってOFFになります
するとcallbackが走ってONに戻ります
異常よろしくお願いします
402(1): 2024/12/21(土)09:51 ID:GMjhbTKC(1) AAS
チェックボックスに関連するトグルスイッチで、状態が変わったときにコールバック関数が実行される場合に、チェックオンからオフ、またはその逆になる際にコールバックが意図しない動作を引き起こすことがあります。
この現象を簡単に説明すると、チェックボックスが「ON」から「OFF」に切り替わるときに、コールバック関数内で再度状態を変更する処理が走ることで、再帰的な状態遷移が発生している可能性があります。具体的には、以下のようなケースです。
説明
初期状態: チェックボックスがON。
ユーザーがチェックボックスをクリックし、状態を「OFF」に変更。
チェックボックスの状態変更に伴い、コールバック関数が実行される。
コールバック関数内で再度チェックボックスを「ON」に変更（状態を元に戻す）し、もう一度コールバックが実行される。
これが繰り返されると、状態の変更がループしてしまい、予期しない動作を引き起こすことがあります。
解決方法
状態変更の条件をチェック: コールバック関数内で状態変更を行う前に、現在の状態が変更前と異なる場合にのみ変更を行うようにする。これにより、同じ状態を繰り返さないようにできます。
javascript
コードをコピーする
// 例：チェックボックスの状態が変わったときにコールバックを実行
function handleCheckboxChange(event) {
const checkbox = event.target;
// チェックボックスがONからOFF、またはOFFからONに変更された場合のみ処理を実行
if (checkbox.checked !== checkbox.defaultChecked) {
checkbox.defaultChecked = checkbox.checked;
// コールバック関数
// 状態変更処理をここに記述
}
}
状態管理フラグを使う: 状態の変更がすでに行われたかどうかを追跡するためにフラグを使用し、状態が変わったときのみコールバックを実行する。
イベントリスナーの適切な設定: change イベントを使って状態変更時にコールバックを実行し、トグルが重複して発生しないようにする方法もあります。
状態の変更を制御する方法によって、予期しない再帰的なコールバックを防ぐことができます。
403: 2024/12/21(土)10:06 ID:Fwktxi0Q(3/4) AAS
>>402
つまりどういうことけ
404: 2024/12/21(土)12:51 ID:ZbZHB27q(1) AAS
自分でそういう命令出してるのでセーフ
405: 2024/12/21(土)14:42 ID:RyNjSfKm(1) AAS
無限に押せて楽しそう
画像ﾘﾝｸ
406(1): 2024/12/21(土)16:52 ID:OHMbuwnQ(1/2) AAS
俺も電子工作にシフトしようかなあ…
デジタル時代は現物のほうが強いよね…
407(1): 2024/12/21(土)17:04 ID:/MoWDuAo(1) AAS
>>406
ゲームと全然別物じゃね？
ピンボールでも作るのか？
408: 2024/12/21(土)18:53 ID:TYYjfflb(1) AAS
コインプッシャーで
409: 2024/12/21(土)19:29 ID:OHMbuwnQ(2/2) AAS
>>407
もちろん細かい点は違うけど、電子工作もゲームも基本は一緒やで
ゲームオブジェクトを操作してるか、回路上のシリアルピンを操作してるかの違いだけだ
上下前次1-新書関写板覧索設栞歴
あと 593 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.014s