里々の内部処理

里々の内部処理 †

ここでは、里々がdll内部で行っている処理のうち、注意を要する場合があるものを取り上げています。
こうした処理は本来里々利用者の便宜を計るために行われているものですが、状況によっては思わぬ弊害となります。
また他のSHIORIの経験があるとかえってつまずきやすい部分でもあります。
里々を使っていて奇妙な不具合に遭遇した場合には、思い出してみてください。

里々の選択肢処理 †

本題の前に、里々利用者が見落としがちな基本的な原理について強調しておきます。 里々ではさくらスクリプトも使用できますが、捉え方としては「里々で作成したトークは自動的にさくらスクリプト主体の（ベースウェアが使用できる形式の）トークへと変換される」とした方が正確です。 以降、辞書のトークは自動的にさくらスクリプトに変換される事を念頭に置いてお読みください。

下例は、あるトークと、それを里々が自動的に変換した結果のさくらスクリプトです*1。

＊
：（７）じゃんけんするよー！
：いくでー。（１１）最初は……
＿グー
＿パー【タブ】アンブッシュ

\1\n[half]\0\_w[6]\s[7]じゃんけんするよー！\n\n[half]\1\_w[66]いくでー。\_w[30]\s[11]最初は
……\n\q[グー,グー
グー
1]\n\q[パー,アンブッシュ
パー
2]\e

選択肢である \q[グー,グー
グー
1] と、 \q[パー,アンブッシュ
パー
2] に注目して下さい。
明らかに記述した覚えの無い単語が、\qタグ内に勝手に記述されています。

実は、里々は選択肢に関連した情報取得変数を実装するために、選択肢について他の栞にはない独特な処理を行っています。
まず、里々の選択肢の記法は、以下のようなさくらスクリプトで変換・実現しています。

＿選択ラベル【タブ】選択ＩＤ

\q[選択ラベル,選択ＩＤ]

ここまでは基本的なさくらスクリプトですが、里々はさらに続く処理で、その\q[選択ラベル,選択ＩＤ]を含めた、トーク中の全ての\q[ラベル,ＩＤ]を、次のような独特な形式へと置換します（ベースウェア側でスクリプトログを確認してみて下さい*2）。

\q[選択ラベル,選択ＩＤ（バイト値、１）選択ラベル（バイト値、１）選択番号]

結果、選択肢が選ばれ、OnChoiceSelectイベントがベースウェアから通知されると、このreference0には
選択ＩＤ 選択ラベル 選択番号
が返却される事になります（半角スペースは1バイト文字）。
里々はこれをユーザーの目に触れる前に内部で分割し、それぞれの部分を選択肢に関連した情報取得変数にセットしてから、（Ｒ０）に改めてＩＤのみセットし直すといった手順を取ります。こうして里々の情報取得変数の（選択ＩＤ）（選択ラベル）（選択番号）が利用可能になっているというわけです。
※OnChoiceEnterでも選択ＩＤの再変換が行われるようです。

留意すべき点 †

しかしながら、上記の選択肢の仕様はさくらスクリプト構成のトークとしては特殊な使い方です。選択肢が記述者の思いがけない変形を受けていることが、思わぬトラブルの種になる場合もあるのです。

例えば、スクリプトログで確認できるように、MAKOTOやreplace_after.txt、OnTranslateで処理するトークの状態は
上記の変形を受けた段階のものという事になります。
OnTranslateを活用するケースでは、このイベントの性質からトーク全文を引数とする事が大半ですから、この時、関数の引数の区切り字に「バイト値１」を使用していた場合、引数の指定位置が狂ってしまい、思わぬ引数エラーが発生する可能性があるという事です。

SSPがいくつか独自に実装している、選択肢関係のSHIORI Eventにも注意が必要です。
例えば、SSPはOnChoiceSelectと同時にOnChoiceSelectExというイベントも通知します。
しかし、里々の上記処理はこれらSSP独自のイベントには対応していません。
従って、上記の戻し処理が行われないので、ＩＤ部分には上記のバイト値１区切りの文字列がそのまま入ってしまいます。

• \q → OnChoiceSelect
  加工処理が行われ、正しく分割される
• \q → OnChoiceSelectEx
  加工処理が行われるが、分割されないので本来ＩＤが入っているはずの（Ｒ１）がひどい事に

結論として、里々では\q選択肢タグでOnChoiceSelectExイベントを利用しない方が無難です。
（この動作仕様が把握できれば、処理を組んで稼動させる事はもちろん可能です）
ちなみに、SSPでは選択肢系のさくらスクリプトとして、

\__q[選択ＩＤ]選択ラベル\__q

というタグも用意されていますが、こちらは選択ＩＤが未加工である代わりに選択肢関係の情報取得変数も更新されません。

OnUpdateReadyのファイル数 †

SHIORI Event（参照：構造とイベントの流れのReference（イベントの関連情報）は、里々では情報取得変数の（R*）で取得出来ます。

どのイベントでどのようなReferenceが取得できるかは、通常SSPの公式リファレンスでもあるUKADOCなどで確認する事ができます。

ただしネットワーク更新において更新すべきファイルが見つかった場合に発生するイベント「OnUpdateReady」で（R0）を使う場合には少し注意が必要です。

UKADOCにもあるように、OnUpdateReadyのReference0には本来「更新を行うファイルの総数から1引かれたもの」が入っています。つまりreference0が「0」のとき、更新のあったファイル数は1個である事を意味します。

しかし里々の（R0）ではこの値は補正され、更新を行うファイル数が1個の場合には（R0）にも1が入っています。

これは例えば

＊OnUpdateReady
：ネットワーク更新を開始するよ。
：ファイルは全部で（R0）個あるみたいや。

といったトークを書く場合に（R0）を素直な序数として扱うのに役立ちます。

しかし一方で、同様に更新ファイル総数や現在更新中のファイルの番号をReferenceにもつOnUpdate.OnDownloadBeginなどでは、この補正がされない事に注意する必要があります。
もし

＃思ったように動かない例
＊OnUpdate.OnDownloadBegin
：今（R1）個目のファイルをダウンロード中だよ〜。

などといったトークを実現したい場合は、calc関数などを用いて

＃思ったように動く例
＊OnUpdate.OnDownloadBegin
：今（calc,（R1）+1）個目のファイルをダウンロード中だよ〜。

のようにする必要があります。