buttonをfix=trueで使いたかったら[call]ではなく[jump]を使う

buttonはfix=trueにすることで常駐ボタンとしていつも表示させておくことができます。

シナリオは分岐などで*ラベルを行ったり来たりする構造になると思いますが、メインのシナリオ(*main)からサブのシナリオ（*sub）に行ったとき、そこで「新たに」常駐ボタンを表示させるには注意点があります。

サブのシナリオ（*sub）に移動するときには、[call]ではなく[jump]でやらなくてはいけません。

[call]でサブのシナリオ（*sub）に飛んで、そこで新たに常駐ボタンの定義[button fix=true]をすると、ボタンが働かなくなります。

これは[button]の仕様で「コール先からリターンするまで全てのボタンは有効にならない」というのが影響してると思われます。

[button]

注意→fixにtrueを指定した場合はコールスタックに残ります。コール先からリターンするまで全てのボタンは有効にならないのでご注意ください

つまり、サブのシナリオ(*sub）を呼び出した時[call]のコールスタックが残っているので、[return]するまではボタンが働かないということですね。

単なるcallだけならcall先でまたcallみたいな、コールスタックを多重にすることも大丈夫ですが、buttonの場合はコールスタックを多重に働かせることはできないように思われます。

おかしな感じもしますが、自分のスクリプトではこうなってしまいますので自分用の注意です。

まとめ

*mainで[button fix=true]を定義して、[call]で*subに飛んでも、ボタンは正常に働きます。

*mainで[button fix=true]を定義して、[call]で*subに飛んで、*subで新たに[button fix=true]を定義すると働かなくなります。

これを回避するには、

*mainで[button fix=true]を定義して、[jump]で*subに飛んで、*subで新たに[button fix=true]を定義する、という手順になります。

ティラノスクリプトはビルドすると速くなる

「ティラノスクリプト　重い」

で検索するとこの記事けっこう上に出てきたので、追記です。

ティラノはビルドすると速くなると思って書いた記事なのですが、訂正です。やっぱり重い。

ビルドで速くなるのは微々たるものです。

ティラノはパッケージングすると起動時に素材の解凍作業を一括で行うため、それがすごい重い感じがします。

ゲーム容量が大きくなればなるほど、解凍にも時間がかかります。

動画やら音楽やらをたくさん入れたゲームには向かなそうだと思いました。

以上は筆者の個人的な体感なので、要検証と言うことでよろしくお願いします。

--------------------------------------

以下は古い記事。

ティラノスクリプトで宮本県の移植＆続きの制作をしていました。

システムもc94版から変えて、試行錯誤しながらいい感じに仕上がってきました。

しかし、いったん落ち着いてよく見ると、どうにももっさりしてる感じがしました。

自分のスクリプトの組み方が悪いのかもしれませんが、常駐ボタンをたくさん置いたUIにして、選択肢やらemoアイコンやらいっぱい表示させてたら、ボタンを押したときにさくっと動いてくれないときがあります。

　fixレイヤーに10個のボタンと、前景レイヤに最大で16個の画像やアイコン（[chara]関連のタグを使用）　　選択肢を押すと選択肢が消去され、16個のパラメータ関連画像が一気に全部書き換わります。さすがにこれだけあると重い・・？（実はボタンも、一つのボタンにレイヤを3枚使ってます）

そこで思い出したのが、airnovelは、制作環境よりもビルドした方が速くなると言うこと。ティラノも同じかな？と思って試してみました。

ティラノビルダーによる制作環境から、windows用アプリへのパッケージングです。

結果。みごとに速くなりました。万歳。^o^

ちなみにパッケージングするときに気づいたのですが、

TyranoRider_win_v201で、tyranoscript_v472dで制作したゲームはパッケージングすることができませんでした。（うちの環境では）

ぐぐってみると、ライダーとスクリプトは最新の物にしないとパッケージングできないことがあるとのこと。

TyranoRider_win_v211がリリースされていたので、そちらを使うと一発でパッケージングすることができました。

また、本体の方もtyranoscript_v472eが出ていました。

このブログは、ここまでtyranoscript_v472dを使用して書いています。

うちの環境で発見した不安定な部分も書いてきたのですが、tyranoscript_v472eでは改善されているかもしれないですね。

tyranoscript.blogspot.comアップデートはティラノフォルダを上書きとのことです。

コンフィグの画面をいじったりして（コンフィグにフルスクリーンのボタンをつけるとか）ティラノフォルダ内のファイルを変更してる場合は、単純に上書きでは初期状態に戻ってしまうので注意ですね。

ゲームリリース後のアプデ手順

tyrano.jp簡単そうで助かります。

レイヤーの重なり順の謎

ティラノのレイヤーは以下のようになっています。

下

base：背景

layer0：

layer1：

layer2：

layer3：

layer4：

layer5：
message0：テキストウインドウ
message1：
message2：

fixレイヤー：glinkやbuttonに使われる。（ボタンより上に画像表示させたいときは、画像をボタンとして表示させることで対応。公式のサンプル10_fixbutton.ks）

上

背景が一番下にあり、画像用のレイヤーがその上、さらに上にテキスト用のレイヤ、そしてボタン用のレイヤという順です。

（ボタン用のfixレイヤーが最前面にあるため、その上に画像や文字を表示させることができない件と、その解決法は前回書きました）

テキストウインドウの上にキャラを表示させたい時などには、messageレイヤに画像を出せばいいとwikiで拝見しました。

そこから、単純にmessageレイヤはlayer5などの通常レイヤの上に来るレイヤなのかと思ったのですが、違ったようです。

たとえばlayer5にptextで文章を表示させ、その上にかぶるようにmessageレイヤの画像を表示させるとこんな感じになります

下にあるはずのlayer5の文章が、messageレイヤの画像の上に来てしまいます。

何が何だかわからなくて悩んだのですが、messageではなく、layer6を使ったら、layer5の文章の上にちゃんと画像が来てくれました。

そこから想像したのが、以下のようなレイヤの仕組み。

画像同士の重なり順は　layer0＜layer1＜layer2＜messageという順になっています

ところがptextで文章を表示させると

layer0の画像＜layer1の画像＜layer2の画像＜messageレイヤの画像＜layer0のテキスト

と、こんなふうになっているようです。

検証不十分なので、あくまで「こんな感じかなあ？」という想像で、

他に何か間違ってる可能性もあるのですが…。

個人的教訓として、

「ptextの文章の上に画像を表示させたければ、ptextに使ったレイヤーよりも数字の大きいレイヤーを使え。messageレイヤに画像を置いてはだめ」

ということが分かりました。

そもそも、messageレイヤはテキストウインドウの画像と文章を表示させる想定にしかなっていないのかもしれません。

 文字色の指定の謎

[font]で 0xRRGGBB 形式で文字色を指定することができる、とリファレンスにあります。

ところが、#RRGGBBでも指定することができます。

普通に表示されるので、自分は#RRGGBBを使っていました。ところが、たまたま0xRRGGBB で指定してみたところ、#RRGGBBと色が違うのです。

リファレンス的に正しいのは0xのほうなので、「#でも表示できるけど正しくない色になる」、ということでしょうか？

 #RRGGBB形式のnscripterからの移植なのでたまたま気が付いたのですが・・。

 #RRGGBB形式のスクリプトから移植するときには注意ですね。