![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
イベントとは、ゴーストが動くための基点です。
ゴースト制作とはイベントに対応することと言っても過言ではありません。
伺かの仕様の知識がある方は栞としての里々-リクエストに対するレスポンスの記述を参照して下さい。
イベントの種類については外部サイトを参照。→Ukadoc SHIORI Eventリスト
里々に限らず、ほぼ全てのゴーストはイベントに対応する事で動いています。
発信されるイベントは多岐に渡り、そのタイミングは、時間が経過したり、ユーザが何かしたりと非常に様々。
#ref(): File not found: "kanikaisetsu.jpg" at page "栞としての里々"
そんなイベントの実体ですが、こんな感じ。ナニコレ？
とりあえず、こういうのがベースウェアから大量に送られてくる、と思って下さい。
GET SHIORI/3.0 Charset: Shift_JIS Sender: SSP SecurityLevel: local ID: OnMouseDoubleClick Reference0: 201 Reference1: 186 Reference2: 0 Reference3: 0 Reference4: Reference5: 0 Reference6: mouse
上から四行くらいはとりあえず置いといて
ここで重要なのは、ID: OnMouseDoubleClickとその下に続くReference。
IDはSHIORI Eventのイベント名で、Referenceはリファレンス。
ここで「おや？このリファレンスってまさか（Ｒ０）とか（Ｒ１）の事？」と閃いたら貴方はもう里々マスター。
＊イベント(ID)名 （イベントに対応した内容や処理）
上記のように、普通のトークと同じ書き方でOK。
このイベントの中で、（Ｒ○）によってリファレンスを取得する事ができます。
なお、普通のトークと同じ書き方ということは、逆に言えばこの名前を別のトークに使ったり、変数名に使ったりすると、意図通りに動かなくなるということ。要注意。
上の例に当てはめるなら、OnMouseDoubleClickは、ユーザがダブルクリックした際に発生するイベントなので、
＊OnMouseDoubleClick ：つつかれた。
と書いておくと、ゴーストをダブルクリックする度に「つつかれた。」と喋るようになります。
補足として、当然ながらこれだけだと何をつついても同じ事を言うだけ。
そこで、リファレンスの情報を活用して、つつかれた箇所に応じた、別のトークをするように分岐させていく事で、応答の幅を広げる事ができます。まずUKADOCを参照して、OnMouseDoubleClickの内容を調べてみると…
| イベントID | OnMouseDoubleClick |
| Reference0 | マウスカーソルの x 座標（ローカル座標） |
| Reference1 | マウスカーソルの y 座標（ローカル座標） |
| Reference2 | 常に0 |
| Reference3 | 本体の場合は0、相方の場合は1。SSP/CROWでは2以降もある |
| Reference4 | シェルの当たり判定の識別子 |
| ... | ... |
と、こういうもの。では本体と相方どちらがつつかれたかを示すReference3（Ｒ３）を利用すれば…
＊OnMouseDoubleClick ＞（Ｒ３）つつかれ ＊0つつかれ ：つつかれた。 ＊1つつかれ こっちを突くな。本体をつつけ。
と、細かく分けて様々な反応を返す事ができるようになるのです。
無理に喋らせなくても、イベントがくるごとに変数をチョイチョイ弄ったり、色々仕込んでみると楽しいかもしれません。
伺かの仕様にはSHIORI Resource（リソース）も存在しますが、SHIORI/3.0以降の仕様により通常のSHIORI Eventと区別されていません。
これがどういう事かというと、要するにリソースもイベントと同じ方法で設定できます。
＠homeurl http://... または https://...
こんな感じ。homeurlはネットワーク更新のアドレスを指定するSHIORI Resourceです。
基本的にイベントやリソースに対応する時はどちらを使っても構いません。
強いて区別するとしたら、
くらいでしょうか。
汎用的には、リソースでは処理を書くケースは稀なので、＠が使われる事が多いでしょう。
ようこそ里々wikiへ！
初めての方へ
