里々ログビューア「れしば」の使用方法解説。
バグへの対処や、動作を実験するのに便利なツールです。




れしばとは?

[ポストと狛犬]にも同梱されている、里々用の補助ツールです。
ゴーストがよく分からない動作をした場合に、里々はどんな処理をしたのかが見ることが出来ます。
必要に応じて使うことで、ゴースト作成が楽になるでしょう。

れしばは何をするもの?

基本的な使い方

ログには何が書かれてるの?

SHIORI Eventごとに記録される以下三つの情報のセットが基本です。
※SHIORI Eventについては以下を参照してください。簡単にいえばゴーストがしゃべるタイミングの事です。
参照:栞としての里々ukadoc

--- Request --- 
GET SHIORI/3.0 
BaseID: OnMouseDown
ID: OnMouseDoubleClick
Reference0: 100 
Reference1: 206 
Reference2: 0 
Reference3: 0 
Reference4: Face 
Reference5: 0 
Reference6: mouse 
--- Operation --- 
*OnMouseDoubleClick
  
(R3)→0
  
(R4)→Face

*0Faceつつかれ
  
return: \1\0メニューです。\n\n\q[喋り頻度,喋り頻度]\n
\q[話して,話して]\n\n\q[なんでもありません,なんでもありません]\n\e
status code : 200 
--- Response ---
Value=\0\s[0]\1\s[10]\0メニューです。\n\n\q[喋り頻度,喋り頻度喋り頻度4]\n
\q[話して,話して話して6]\n\q[なんでもありません,なんでもありませんなんでもありません8]\e

その他、里々のload、unload時(≒ゴースト起動時・終了時)の処理もログに記載されます。

Request

--- Request --- 
GET SHIORI/3.0 
BaseID: OnMouseDown
ID: OnMouseDoubleClick
Reference0: 100 
Reference1: 206 
Reference2: 0 
Reference3: 0 
Reference4: Face 
Reference5: 0 
Reference6: mouse 

ベースウェアからのイベントの通知内容。
ゴースト作者にとって特に大事なのはIDとReference。
Event IDとReferenceの中身についてはukadoc/SHIORI Eventを参考にしてください。
案外Referenceを見るだけでバグの原因となる異常に気づくことも。
例:当り判定名誤字ってるじゃねーか!

Operation

--- Operation --- 
*OnMouseDoubleClick
  
(R3)→0
  
(R4)→Face

*0Faceつつかれ
  
return: \1\0メニューです。\n\n\q[喋り頻度,喋り頻度]\n\q[話して,話して]\n
\q[なんでもありません,なんでもありません]\n\e
status code : 200 

ベースウェアからのイベント通知を受けて、里々が行った処理の痕跡です。
たぶん一番よく見る事になる箇所。ログビューアの本領発揮。
書いてある詳しい内容は以下のほか、「実例」も参考に。

(○○)→

(変数や関数)→中身

()によって対象(変数・トーク・単語群)が展開・実行され、結果が得られたことを意味します。
ヒント

*トーク名

里々のシステムからの直接の呼び出しや、によるジャンプなどで、あるトークの処理が始まった事を意味します。

*計算結果が0だったため、続行します。

によるジャンプで、ジャンプ側の条件式が偽(0)になったので、ジャンプせず次の行の評価に移った事を意味します。
条件を満たすジャンプ先のトークが存在しない場合は、次のnot matchedになります。

not matched.

*トーク名 not matched.

によるジャンプなどで、条件を満たすトークが存在しないことを意味します。
採用条件問わずジャンプ先自体が存在しない場合も含みます。
>によるジャンプ先以外では、里々の起動・終了時などに自動的に検索されるトーク名などについても、発見できない場合こう書かれます。

not found.

(変数) not found.
>ジャンプ先 not found.

()による展開・実行や、によるジャンプの対象(変数・トーク・単語群)が見つからなかったことを意味します。
()の場合はφ(○○φ)という文字列に置き換えられて表示されたり、>の場合は次の行が読まれたりします。
ヒント

written.

$変数=1/written.

新たに変数が作成され、初期値が書きこまれたことを意味します。
【タブ】、=、あるいはset関数いずれによるものでも区別されません。

overwritten.

$変数=0/overwritten.

既存の変数に、新たな値が上書きされたことを意味します。
【タブ】、=、あるいはset関数いずれによるものでも区別されません。

cleared.

$変数/cleared.

変数が削除された(変数に「空」が代入された)ことを意味します。
【タブ】、=、あるいはset関数いずれによるものでも区別されません。
ヒント

return:

return: \1\0メニューです。\n\n\q[喋り頻度,喋り頻度]\n\q[話して,話して]
\n\q[なんでもありません,なんでもありません]\n

Operationのブロックの最後あたりに一度だけあらわれる。
里々が辞書の内容に基づいて得た、今回のSHIORI Eventに返信するさくらスクリプト。
いうなれば、里々記法で書かれたトークを、ベースウェアが理解できる形に翻訳した姿。
この後さらに里々が色々と内部的な処理を行ってから、ベースウェアに返信される。

Response

--- Response ---
Value=\0\s[0]\1\s[10]\0メニューです。\n\n\q[喋り頻度,喋り頻度喋り頻度4]\n
\q[話して,話して話して6]\n\q[なんでもありません,なんでもありませんなんでもありません8]\e

ベースウェアに対して里々が返す「今回のイベントでは、こういうスクリプトでしゃべって(動いて)くれ」という返事の内容です。
限られたケースでバグの原因特定に繋がることがあります。
里々の辞書の記述がベースウェアに送られる時にはこんなわけの分からない記号の集まりになっているんだなあと感慨を深くするだけでも意味はあるかもしれません。

Value

ベースウェアに返信される直前のスクリプト。
Operationのreturnから、さらに里々が内部的な処理を行ったあとの状態のもの。
※なお、Operationのreturnから、Valueの間に行われる処理は例えば以下のようなもの。

Reference

Reference0=さくら
Reference1=JPRadish

$Value*によるコミュニケート送信時にその内容が表示される。
Value0はReference0、Value1はReference1、以後それぞれ対応。

実例

ここでは、れしばを用いたデバッグの簡単な例をあげていきます。

なんか計算がうまく動いてないっぽい

いきなりバグの症状設定があいまいですが、れしばが真価を発揮するのは、むしろこういったぱっと見で原因が(または症状さえも)はっきりわからないというようなバグの解析においてです。
以下のようなトークを書いたとしましょう。(ユーザ年齢)は

*日本酒入手
$ユーザ年齢【タブ】(現在年)-(ユーザ誕生年)
:いい日本酒が手に入ったんだけど……
>ユーザお酒飲めない【タブ】(ユーザ年齢)<20
>ユーザお酒飲める

*ユーザお酒飲めない
:(ユーザ名)もウーロンで乾杯しよう!
:あと(calc,20-(ユーザ年齢))年たったら一緒に飲めるな。

*ユーザお酒飲める
:(ユーザ名)も一緒に飲まない?
:俺の分は?
:ないよ。
:……。

というように、ユーザの年齢をその場で計算してトークを分岐します。
この時ユーザが未成年なら、calc関数を使ってあと何年で二十歳になるのかも計算したいと考えたとします。
しかし実は上例の場合、calcの結果は思ったようになりません(満年齢じゃなくて数え年になる点は考えないとしても)。ユーザが何歳だろうと常に「ユーザお酒飲めない」が選ばれますし、「あと○○年たったら」の部分も滅茶苦茶な数字になるでしょう。
一見するとその理由は分かりにくいですが(※)、こういう時こそれしばの出番です。
早速ログを覗いて見ます。
※ある程度里々に慣れていると一目で分かるかもしれませんが、疲れているかなんかで注意力散漫だったと思ってください。実際そんな時はよくあります。

--- Operation ---
*日本酒入手
  
(現在年)→2014
 
(ユーザ誕生年)→1990
  
$ユーザ年齢=2014-1990/written.
  
(ユーザ年齢)→2014-1990
  
*ユーザお酒飲めない
  
(ユーザ名)→ユーザ
  
(ユーザ年齢テスト)→2014-1990
  
(calc,20-2014-1990)→-3984
  
return: \0いい日本酒が手に入ったんだけど……\n\1\n[half]
\0ユーザもウーロンで乾杯しよう!\n\n[half]\1あと-3984年たったら
一緒に飲めるな。\n

ログを一行一行、(現在年)は想定通り、(ユーザ誕生年)にも妥当な値が入っている、と確認していくと、次の行がおかしな事に気づくはずです。

$ユーザ年齢=2014-1990/written.

本当はここで、2014-1990が計算されて、

$ユーザ年齢=24/written.

となっていてほしいはずです。そのことで、結局

(calc,20-2014-1990)→-3984

と、本来は「20-14」を計算してほしい場面でとんでもない事になっています。
そう思って辞書を見返すと、どうやら

$ユーザ年齢【タブ】(現在年)-(ユーザ誕生年)

と言う行が思った通りに動いていないようです。
そこで里々wikiで変数の代入について見直して見ると、どうやらこの場合は

$ユーザ年齢=(現在年)-(ユーザ誕生年)

と書かなければならないと分かります。

ちなみに上例の=と【タブ】を間違える誤りの他に、例えば、

などの場合も、上例のトークは思い通りに動かなくなるでしょう。
いずれの場合でも、れしばでログを覗けば、どこがどうおかしくなっているかが分かるので、その異常の原因を推測する材料にできます。

実際に表示がおかしいのにれしばのログでは正常に見える

*
:僕っ子とボクっ子とぼくっ子は別属性っていってるだろ!!!
:おちつけ!

といったトークで、れしばで見ると最終的なスクリプト

Value=\0僕っ子とボクっ子とぼくっ子は別属性っていってるだろ!!!\n\n[half]\1おちつけ!\e

と、別段おかしい様子がないのに、実際のバルーンへの表示がなぜか「僕っ子」ではなく「私っ子」になっている!
と言うような場面に出くわすかもしれません。

この場合、れしばのログから異常が読み取れないことが、かえってヒントになります。
何故なら、SHIORI(ここでは里々)による処理の後で、スクリプトの内容に干渉できる仕組みは多くないからです。

結局先の例の場合、辞書を探すとこんな事を書いていました。

*OnTranslate
$引数区切りの追加【タブ】(バイト値、2)
$一時変数【タブ】(R0)
$一時変数【タブ】(replace(バイト値、2)(一時変数)(バイト値、2)僕(バイト値、2)私)
(一時変数)
$一時変数【タブ】

SHIORI EventのOnTranslateまたはMAKOTOによるスクリプトへの置換処理は、通常のSHIORIの処理のあとに行われます。
そのため、れしばのログに記録されないスクリプトの変化を引き起こす理由となりえます。
里々wikiにもOnTranslateを使った処理がいくつか書かれていますが、そうした物を使っている事をうっかり忘れていたりすると、混乱を引き起こします。
そうした時でもれしばに異常が記録されていないことが手がかりになるので、OnTranslateやMAKOTOを使う場合は頭の片隅に入れておきましょう。

こんな記事も参考に
関数使ってない場所で「引数の個数が~」って言われるしれしばでも異常がみつからない

れしばの注意点

OnSecondChangeやOnMouseMoveなどは記録されない

おそらく非常に高い頻度で発生するのでログがスゴイ事になるための措置。
このため、通常のランダムトーク及びなで反応といった、かなりメジャーな種類のトークについてログを確認できません。
そうしたトークでバグが出ている場合は、そのトークをどこか別の場所にコピペして、ログが見られる方法(たとえばメニューからの選択、ショートカットキー)で動作を確認するなどの工夫が必要です。

OnTranslateも記録されない

先述の実例にもある通り、OnTranslateはれしばのログに残らないSHIORI Eventです。
というのもOnTranslateは少々特殊なSHIORI Eventであるためです。
何らかのSHIORI Eventに対して、SHIORIがスクリプトをベースウェアに返却したあと、ベースウェアはそのスクリプトをReference0として、再度SHIORIに送り直します。
その時のイベントIDがOnTranslateです。
これによって、すべてのスクリプトが必ずOnTranslateによる処理を通過することになり、このことをさまざまな用途に応用できます。
つまりOnTranslateは、他のすべてのSHIORI Eventについて付属的に発生するので、それが一々ログに残ると、やはりログがすごい勢いで流れる事になります。
おそらくはそういった経緯から、OnTranslateもれしばには記録されません。

れしばを「後出し」する方法

れしばは里々のログをリアルタイムに表示するものなので、基本的には問題が発生した時に起動していないと原因を追えません。 しかし、バージョンMc158-5から「$れしばログ一時保存件数」という特殊変数が追加されており、この変数に数値を設定しておくと、最新のログからその件数分だけのログを一時的に保存して、れしばを起動したときに送信してもらうことができます。 例えば、

$れしばログ一時保存件数=100

このように設定しておけば、「れしば」を起動した時に最新の100イベントぶんまでのログを一気に送ってくれます。 問題が起きた時に急いで起動すれば、原因がわかるかも?

れしば互換/代替ツール

れしば.NET

https://github.com/nikolat/recv_net/releases
動作に.NET Framework2.0以上が必要(Windows Vista以降標準搭載)。
本家と違って表示行数の上限がないので、複雑な処理をやって何万行もログが流れるようなゴースト向き。
その他は使い方など基本的に本家と同じ。

れしばいぬ

https://github.com/nikolat/reshibainu/releases
かわいいわんこのゴーストに同梱のれしば.NET。
基本的にれしば.NETと同じはずだが、環境によってはなぜかどっちかだけ動いたりするらしく謎。

さとりすと

https://nanachi.sakura.ne.jp/satolist.html
「デバッグ⇒れしばイベントログ」でウィンドウ展開。
左上の起動ボタンを押してから、ゴーストを起動。
受信したリクエストIDのリストがまず表示され、それをダブルクリックで各イベントのログが表示されるなど、一般的なれしばと扱い方は少し違うが、確認できる情報は同じ。
無視するイベントリストなども設定可能で、本家より柔軟な部分も。
ただし里々のログ送信機能の仕様上OnSecondChangeやOnMouseMoveが受信不能なのはそのまま。


トップ   編集 凍結 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2023-11-11 (土) 07:15:13