|
SHIORI/2.0 SHIORI/2.2 SHIORI/2.3b SHIORI/2.4 SHIORI/2.5 セキュリティ ステータスコード エイリアス |
 概要SHIORI はゴーストの中核的要素であり、この部分の挙動が人格のほぼ全てとなる。
home
+-ghost
+-naru
+-ghost
+-master
+-shiori.dll
|
ディレクトリパスが必要ない場合でも関数内でハンドルを解放しなくてはならないことに注意して下さい。
|
SHIORI/1.1 SHIORI/1.1 は「対話」実現のための仕様です。 extern "C" __declspec(dllexport) HGLOBAL __cdecl getresponse(HGLOBAL h, long len); function getresponse(h: hglobal; var len: longint): hglobal; cdecl; export; getresponse は COMMUNICATE 関数で、与えられた汎用的文章に対して汎用的返答を返します。 与えられる引数のは何の整形もない「文章」です。文節数も不定です。質問文であることすら保障されません。関数はまず文章を解釈するところから始めて下さい。。 |
|
SHIORI COMMUNICATE/1.1 SHIORI COMMUNICATE/1.1 は SHIORI 同士の対話を行うための仕様です。 SHIORI COMMUNICATE/1.1 は複合的仕様です。これを実装するには、SSTP COMMUNICVATE、Direct SSTP、FMO の仕様を理解する必要があります。 関連仕様書 SSTP Direct SSTP FMO SHIORI COMMUNICATE は SHIORI が出力する SAKURA スクリプトに COMMUNICATE フッタを付加することで実現されます。具体的には以下のようなものです。 \h\s0楽しい？\e COMMUNICATE SHIORI/1.1 Sender: さくら Age: 0 TargetHWnd: 1024 SHIORI が以上のような文字列を返した場合、SAKURA は「\h\s0楽しい？\e」を通常のスクリプトとして解釈（セリフとして発言）したあと、TargetHWnd で示される相手ゴーストに対し Direct SSTP で COMMUNICATE/1.1 リクエストを送ります。その際の Sentence ヘッダはこの出力全体となります。送られた COMMUNICATE リクエストは相手ゴーストの SHIORI の getresponse にそのまま投げられるので、ここで相手ゴーストが同じ処理を行えば2者の間で対話が成立します。 COMMUNICATE フッタは HTTP や SSTP のヘッダと似ていますが、上のサンプルで改行として表されている部分は CR+LF ではなく全てバイト値1だということとバイト値1 2つでターミネーションしないという点に注意して下さい。完全にバッファとして書けば以下のようになります。 \h\s0楽しい？\e[1]COMMUNICATE SHIORI/1.1[1]Sender: さくら[1]Age: 0[1]TargetHWnd: 1024[1] [1] = バイト値1 各ヘッダの意味は以下の通りです。
Sender は自分の名前です。 Age は要するにカウンタです。SHIORI COMMUNICATE を受信し、その返答を送信するたびに 1 ずつインクリメントして下さい。自分が最初の送信者である場合は 0 をセットします。 TargetHWnd は話しかけたい相手ゴーストのウインドウハンドルです。この値は SHIORI が SAKURA FMO を用いて自力で取得して下さい。 |
|
SHIORI/2.0 SHIORI/2.0 は 2.x 系の基礎的なプロトコルを定義する。 引数／戻り値の受け渡しは全て globalmemory で行う。gmem_fixed でデータを受け取り、ハンドルを解放、長さ len を元にデータを取得、戻り値作成後 len に適正な値を入れ直し、gmem_fixed で戻す。 extern "C" __declspec(dllexport) HGLOBAL __cdecl request(HGLOBAL h, long *len); function request(h: hglobal; var len: longint): hglobal; cdecl; export; 全てのリクエストは request という唯一の関数で行われる。 リクエストヘッダは HTTP や SSTP のそれによく似ている。全ての行は CR+LF でセパレートされ、1行目にコマンドとバージョン、2行目以降に任意の数のヘッダが配置され、最終的に CR+LF 2つでターミネートされる。 DLLロード時およびアンロード時に以下の関数がコールされる。 extern "C" __declspec(dllexport) BOOL __cdecl load(HGLOBAL h, long len); extern "C" __declspec(dllexport) BOOL __cdecl unload(); function load(h: hglobal; len: longint): boolean; cdecl; function unload: boolean; cdecl; load の第1引数に DLL のディレクトリパスが渡される。SHIORI が固有のデータファイル等を持つ場合は、ここからカレントディレクトリを取得し、そこに自らのデータファイル一式を納めなくてはならない。 文字列が必要ない場合でも関数内でハンドルを解放しなくてはならない。 load が成功した場合 SHIORI は true を、load が失敗した場合 SHIORI は false を返さなくてはならない。 GET Version GET Version SHIORI/2.0 Sender: Nobody Charset: Shift_JIS SHIORI/2.0 200 OK クライアントはここで得たバージョン情報を元に（必要があれば）リクエストのレベルを変化させる。 NOTIFY NOTIFY OwnerGhostName SHIORI/2.0 Sender: Nobody Ghost: さくら Charset: Shift_JIS SHIORI/2.0 200 OK クライアントがサーバに一方的に情報を通知するリクエストが NOTIFY である。2.0 では NOTIFY OwnerGhostName のみ実装されている。
GET Sentence GET Sentence SHIORI/2.0 Sender: User Charset: Shift_JIS Sentence: おはよー。 SHIORI/2.0 200 OK Sender: First BalloonOffset: 0,0[1]0,0 Sentence: \0\s0おはよー。\e
クライアントがサーバにスクリプトを要求するリクエストが GET Sentence である。これは基本的に「誰かが話しかけてきた」ことを示す。SHIORI/2.0 では User からの GET Sentence のみ実装されている。 GET Word GET Word SHIORI/2.0 Sender: materia Type: \ms Charset: Shift_JIS SHIORI/2.0 200 OK Word: さくら クライアントがサーバに単語（ないしスクリプト断片）を要求するリクエストが GET Word である。
Type ヘッダに渡る可能性がある文字列は以下の通りです。
GET Status GET Status SHIORI/2.0 Sender: Nobody Charset: Shift_JIS SHIORI/2.0 200 OK Status: 0,0,0,0,0,0 クライアントがサーバにステータス情報を要求するリクエストが GET Status です。 neuron,neuronm,neuronk,neurond,neurone,synapse この値は AI のスペックをグラフとして表示する際に使用されます。グラフを表示する意志が無ければこのリクエストは無視しても構いません。 リクエストがデータを要求するものだった場合、サーバはステータスコードに続けて必要なヘッダを送り返す。返すべきヘッダはリクエストによって異なり、それは SHIORI/2.1 以降で各個に定義される。例示 GET Sentence SHIORI/2.0 Sender: materia Charset: Shift_JIS SHIORI/2.0 200 OK Sender: First BalloonOffset: 0,0[1]0,0 Sentence: \0\s0‥‥。\e
BalloonOffset は省略可能な特殊かつ特例のヘッダで、バイト値 1 とカンマでセパレートされ、左から sakura.balloonoffset.x、sakura.balloonoffset.y、kero.balloonoffset.x、kero.balloonoffset.y を表す。ここで設定されたバルーンオフセット値はシェルの設定したバルーンオフセット値をオーバーライドする（即ちゴーストがシェルの領域にまで進入しており非常に特殊）。 |
|
SHIORI/2.2 SHIORI/2.2 は SHIORI に汎用的なイベントを送るリクエストである。イベントは基本的に materia 本体が動作状況に応じて発行するが、SSTP NOTIFY/1.0 および SAKURA API/1.3 を用いて外部から発生させることもできる。これらのリクエストはその安全性から SeculityLevel によって区別される（後述）。 この文書では SHIORI としてのイベントの解釈の仕方（受信）だけを取り扱う。送信については SSTP NOTIFY/1.0 および SAKURA API/1.3 の仕様書を参照すること。 Get Sentence SHIORI/2.2 Sender: Nobody Event: OnDisplayChange Reference0: 32 Reference1: 1280 Reference2: 1024 Charset: Shift_JIS Event ヘッダがイベントの識別子を表す。これは必ず unique な文字列であり、一定であり、一意である。 Reference ヘッダがイベントの付帯情報（引数）を表す。例えば上記の例では画面解像度の変化イベントである OnDisplayChange の引数に色深度と解像度が渡されている。Reference は最大で 8つ（Reference7 まで）定義される。 以下に、本体通知のイベントの一覧を示す。 
※Vanish カウント - 現環境でそのゴーストが Vanish された通算回数。
※0. false = 0、true = 1 両イベントは返したスクリプトが再生できない（捨てられる）状態でも発生するが、そのために一度しか読まないスクリプト等が知らないうちに闇に葬られてしまう可能性がある。そのような問題を防ぐために cantalk フラグが存在する。cantalk フラグは返したスクリプトが本体に読まれるのか捨てられるのかを表す。1 なら読まれ、0 なら読まれない。
当たり判定識別子はシェルによって自由に定義される。最もスタンダードなものは Head、Face、Bust
識別子 shell／ghost／balloon／plugin
reference4-6 は下記のフォーマットを施された文字列として渡される。 [1] - バイト値1 [2] - バイト値2 reference4 - あ[1]い[1]う[1]え[1][2]か[1]き‥‥ reference5 - 0 1024[1]1 1024[1]‥‥ reference6 - 0 uidl0[1]1 uidl1[1]‥‥
失敗事由
※OnUpdateBegin は更新指示があった直後即座に来る。materia はその後更新すべきファイルがあるかどうかを調査し、あれば OnUpdateReady を発行して実際の更新作業に入る。なかった場合は OnUpdateComplete に分岐しそのまま終了する。
成功／失敗事由
Reference2 以降は OnFind 時のみ渡される。OnFind フェーズは First、First and Last、Last、Next の4つで、それぞれ1ページ目、1ページ目だがいきなり次がない、最後のページ、そしてそのいずれでもないページを表す。 OnFind イベントにおいて識別子のない選択を提示すると、それがページめくりとして機能する。 \q0[][次のページへ]
現状、ヘッドラインセンスの成功は読み上げの開始を意味するので、Complete は取得に成功したが更新が無かった場合のみ通知される。 - 事由 -
  Reference エントリの最大数は SHIORI/2.2 においては8です（Reference7まで）。 OnClose 等非常に基礎的なものを除き、イベントは基本的に無視することができます（無反応、喋らない）。無視する場合はリクエストに対し 204 No Content を返して下さい。
|