イベント

イベントとは、ゴーストが動くための基点です。
ゴースト制作とはイベントに対応することと言っても過言ではありません。

伺かの仕様の知識がある方は栞としての里々-リクエストに対するレスポンスの記述を参照して下さい。
イベントの種類については外部サイトを参照。→Ukadoc SHIORI Eventリスト




イベントの流れ

里々に限らず、ほぼ全てのゴーストはイベントに対応する事で動いています。
通知されるイベントは多岐に渡り、そのタイミングは、時間が経過した時や、ユーザが何かした時など、非常に様々です。
ゴーストの機能は、通知されたイベントに、トークをすることで実現します。

kanikaisetsu.jpg

イベントの正体

イベントとは何か、と言うと、ベースウェアが通知してくる以下のような文章です。
これは普段は見る機会がないので、意識する必要はありません。
こういうものが送られてきて、里々があれこれ使いやすいように処理してくれている、とだけ覚えておけばよいです。

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はリファレンス?
Referenceの中身は、里々の書き方では(R0)や(R1)で取得できます。

里々でイベントに対応するには

*イベント(ID)名
(イベントに対応した内容や処理)

上記のように、「*イベント(ID)名」と書き、その下の行からそのイベント時のトークを書きます。
このイベントの中で、(R○)によってリファレンス?を取得する事ができます。
ただし、イベント(ID)名が別の変数の名前と同じになっていたりすると正しく動かなくなってしまいますので、変数関数の名前の付け方には注意しましょう。

書き方の例

上の例に当てはめると、ユーザがダブルクリックした際に発生するイベントOnMouseDoubleClickは以下のように書くと動作します。

*OnMouseDoubleClick
:つつかれた。

このスクリプトにより、ゴーストをダブルクリックする度に「つつかれた。」と喋るようになります。

リファレンスの活用

当然、上記の書き方だと何をつついても同じ事を言うだけです。
そこで、リファレンス?の情報を活用して、つつかれた箇所に応じた、別のトークをするように分岐させていく事で、応答の幅を広げる事ができます。
まずUKADOCを参照して、OnMouseDoubleClickの内容を調べてみましょう。

イベントIDOnMouseDoubleClick
Reference0マウスカーソルの x 座標(ローカル座標)
Reference1マウスカーソルの y 座標(ローカル座標)
Reference2常に0
Reference3本体の場合は0、相方の場合は1。SSP/CROWでは2以降もある
Reference4シェルの当たり判定の識別子
......

このようにOnMouseDoubleClickが通知された時のリファレンス?がまとめられています。
本体と相方どちらがつつかれたかを示すReference3(R3)を利用すれば、以下のようにつつかれたキャラごとに別の対応をさせることができます。

*OnMouseDoubleClick
>(R3)つつかれ

*0つつかれ
:つつかれた。

*1つつかれ
こっちを突くな。本体をつつけ。

喋らせるだけでなく、変数にリファレンス?を格納しておいて別のイベントで使ったりも出来ます。

*OnMouseDoubleClick
$つついたキャラ【タブ】(R3)
>(R3)つつかれ

*0つつかれ
:つつかれた。

*1つつかれ
こっちを突くな。本体をつつけ。

#変数にとっておいたリファレンスをランダムトークで使ってみる
*
>相方が突かれたトーク【タブ】(つついたキャラ)==1
:さっきはよくもつついてくれたな。

*相方が突かれたトーク
な、こっちをつついても楽しくないだろ?

里々でリソースを設定するには

伺かの仕様にはSHIORI Resource(リソース)も存在しますが、SHIORI/3.0以降の仕様により通常のSHIORI Eventと区別されていません。
これがどういう事かというと、要するにリソースもイベントと同じ方法で設定できます

@homeurl
http://................

homeurlはネットワーク更新のアドレスを指定するSHIORI Resourceです。

*と@

基本的にイベントや対応する時はのどちらを使っても構いません。
ただし、リソースは@(単語群)で対応しなければいけません
例えば、シェルのツールチップを指定するにリソースtooltipに以下のように書いたとします。

*tooltip
>(R3)(R4)ツールチップ

*0Headツールチップ
本体のあたま
#表示結果
\1本体のあたま

このように、「*」で始めると余計なものが含まれてしまいます。
上記は分かりやすいですが、ネットワーク更新先を示すhomeurlを「*」で書くと、アドレスにおかしな文字が入ってURLとして成立しなくなり、更新出来ないバグとなるでしょう。
最初のうちは、以下のルールで書いておくと余計なバグを出さずにすみます。

  • イベントは、「*」で始める
  • リソースは、「@」で始める

上記のツールチップを正しく表示出来る処理は、ちょっとややこしくなりますが以下です。

@tooltip
(when
、(単語群「(R3)(R4)ツールチップ」の存在)
、((R3)(R4)ツールチップ)
)

@0Headツールチップ
本体のあたま
#表示結果
本体のあたま

イベントにはどちらを使ってもかまいません。強いて区別するとすれば、以下のようになります。

  • *は分岐処理?やトークをしたい場合に向く
  • @は一行で完結する書き方なので、短い応答に向く

リソースの例外

里々は、sakura.recommendsitesやsakura.portalsitesなどのリンクを表示するリソースに対して、特殊な処理を行っています。

sakura.recommendsitesの里々の書き方は以下ですが、ukadocに書いてある仕様と全く違います。

  • 1行目がサイト名
  • 2行目がジャンプ先URL
  • 3行目がバナーURL(省略可)
  • 4行目以降はジャンプ時に表示される会話文(省略可)
*sakura.recommendsites
SSP配布ページ
http://ssp.shillest.net/

:SSP配布ページだよ。

これは、里々が書きやすさを重視して、特別に処理しているためであり、SSPに実行させる時にはukadocの仕様に合わせた形に裏で整形しています。

用語注釈

イベント
主にSHIORI Event(栞イベント)を指しますが、基本的にはベースウェアから通知される全ての情報はイベントと呼んでも間違いではないです。
SHIORI Resourceはリソースと呼んで区別はしていますが、これも総称するならイベントの一部になります。理由は、現在使用されているSHIORI/3.0規格において、イベントとの実装上の明確な違いがないためです。
リソース
前述の通りSHIORI Resourceのこと。ベースウェア本体が必要な都度通知を送り、栞+辞書が内容を返す形は普通のイベントと変わりませんし、その方法もほぼ同じです。
リクエスト
直訳すれば要望、要求。
伺かの仕様において、主にベースウェアなどが「イベントを発信し反応を求めること」をリクエストと呼びます。どちらかといえば難しい言い方ですが、「通知」が単に全てのイベントが送られてくる事を指すのに対し、「リクエスト」は反応(レスポンス)を要求するイベントに使われる事が挙げられます。
レスポンス
反応のこと。リクエストに応えるのがレスポンス。
関数でお馴染みの「何かを要求すると何かが返ってくる」ような動作を、「リクエストに対しレスポンスを返す」というような形で使います。
栞イベントやSAORIで稀に登場します。
スクリプト
文章。
ややこしいですが、栞においては「さくらスクリプト形式のトーク」を指す事が多いです。トークをさくらスクリプトの形式に変換した状態のもの、とも言えます。
基本的に、イベントのレスポンス内容は大半がスクリプトであるため、栞の動作に言及する際に用いられる事があります。

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2017-10-28 (土) 18:14:49 (118d)