【ウディタ講座】緑帯との付き合い方~50万エラーはこわくない~

恐怖の象徴「緑帯」

ギャーーーー!!!!!

 

……はい、いきなり怖い画像をすみません。

知らない方へ説明しますと、ウディタがバグるとこのような緑色の警告が出るのです。
通称が「緑帯」

作者にとってはラスボスよりも強敵です。緑帯そのものはバグではなく、バグがあることを教えてくれるお助け機能なのですが、いかんせん緑帯が出るようなソースのミスは特定しにくく、いつしか緑帯そのものが恐怖の対象に……

場合によってはウディタがフリーズしますので、Alt+F4で強制終了しなくてはなりません。全画面モードにしていて右上の「×」が押せないときだと、地味に焦るものです。

緑帯の真相

緑帯にも種類があります。

表示が出たら、よくよくメッセージを読んでみてください。

多いのは呼び出そうとしたファイルが存在していない「名前の入力ミス」とか、ループ処理の終了指定を失敗した「無限ループ」のどちらかです。前者はわかりやすいですね。帯の中の文章を読めばだいたい解決するようになっています。

(なので、作者さんへのバグ報告で緑帯の内容が明記されていると、喜ばれそうですね)

無限ループなどで起こる後者が強敵です。

ループ機能を使うような処理は、やっぱり元から複雑ですから、作者自身、ソースコードを見てもなにがどうなっているのか把握しづらいことが大半です。

バグっていなくても緑帯が出ることだってあるのです。

なぜなら、ループによる緑帯は「1フレームあたりの処理行数が50万を超えた」という意味だから。いわゆる重たい処理をしている状態。瞬間瞬間の処理数が限界に近い時、ウディタが「自分、もうダメっす」と言い出すのが緑帯の一種、いわゆる「50万エラー」の正体です。

50万なんてまず行かない気がしますよね。

でも、SRPGの移動力計算などすると、バグっていなくても案外簡単に緑帯が出るのです。いわゆる「再帰処理」のような動きをするケースですね。

50万エラー対策コモン

複雑なループ処理になってしまって緑帯が不安なところには、こんなコモンを置いてみましょう。

■デバッグ文:【呼出元】\cself[5]
■条件分岐(変数): 【1】 Sys108:[読]現フレームのコマンド処理数 が 450000 以上
-◇分岐: 【1】 [ Sys108:[読]現フレームのコマンド処理数 が 450000 以上 ]の場合↓
|■ウェイト:1 フレーム
|■
◇分岐終了◇

引数のコモンセルフ5の文字列変数では、呼び出し元のイベント名を打ち込みます。

こうすると、このコモンがどの処理から呼び出されたのかがデバッグ文でわかります。そしてシステム変数を参照する分岐で「処理数が50万に近くなったら」ウェイトを挟みます

50万エラーは仕事が多すぎてウディタがあっぷあっぷしている状態ですから、一瞬でもよいので息継ぎの時間をあげることで、緑帯が回避できるのです。

1フレームは1/60秒。人間にはまず感じられない一瞬ですね。

ループのたびに入れるとモッサリしてくるのですが、処理負荷が高くなったときだけに挟むなら案外と体感はできない、そんな長さです。

呼び出し元はわかりやすく

どうして呼び出し元を書き込んでデバッグ文で表示するのか。

それは「どこのループ処理が重いのか」を特定するためです。

50万エラーのメッセージでも、実は問題のコモンやイベントのIDが書いてあります。どのイベントの何行目が変なのかが載っている。

これがあれば問題なさそうなものですが、実はそうでもないのです。

ループ処理で緑帯が出る場合、問題の「行数」にある処理そのものは問題ないことが多々あります。ウディタがギブアップした瞬間がそこというだけで、ウディタを追い込んだ処理は近くにある別のものという可能性もあるわけです。

また、SRPGの計算などでは、しばしばループが三重構造になったりします。おかしなコモンのIDがわかっても、「じゃあどのループの、どの行がおかしいの?」の特定は困難。

 

というわけで、デバッグ関係の手間は惜しまないようにしましょう。

あとでひどい遭に合わないために……(体験談)