瀏覽 OpenKEEPS Ver.2 便利な機能 その4
------------------------------------------------------------------------------
OpenKEEPS Ver.2 便利な機能解説 その4
Ver.2.2で追加された機能
2003/05/04
文責: さとー
------------------------------------------------------------------------------
■ はじめに
OpenKEEPS Ver.2.2は、Ver.2と比べて幾つか機能が追加されています。これらの機能
は、ゴーストのより高度な演出、より簡便な記述、よりセキュアな記述を可能とする
能力があります。以下の文章では、その機能の詳細を解説します。
■ 派生式キャラクタモード
キャラクタモードをゴーストの感情等に割り当てた場合、1つ困ったことが起きます。
それは、仮に感情に関係なくイベントの応答をしたいと思っても、キャラクタモード毎
に同じイベント応答文を書かなくてはいけないことです。仮にコピー&ペーストで対応
するとしても、手間であることは事実です。また、カンマを使った複数エントリへの
同時記述では、キャラクタモードごとに別ファイルにするという、管理を楽にする方法
が使えなくなります。
こうした問題に対処する為、キャラクタモード変更に、従来の切替式のほかに派生式を
導入しました。プログラムを書く人は、クラスの派生のようにキャラクタモードを派生
させると思ってください。
具体的例を挙げながら解説します。今、A〜Fの6個のキャラクタモードを考えますす。
B〜DはAから派生したキャラクタモード、EはDからさらに派生したキャラクタモードと
します。派生関係を図にすると、次のようになります。
Aを「普通」、Bを「嬉しい」、Cを「悲しい」、Dを「不機嫌」、Eを「激怒」、Fを
「別人格」のキャラクタモードと捉えると、関係が分かりやすいでしょう。
● キャラクタモードの関係
A---+--B
|
+--C
|
+--D---E
F
● 派生式キャラクタモードにするには
起動から最初のイベントが来るまでの間に、$(OverrideOn)を実行します。
標準的記述法として、
> System.Callback.OnLoad : $(OverrideOn)
または
> kp.callback.OnLoad : $(OverrideOn)
を推奨します。
● 派生キャラクタモードを定義するには
キャラクタモードBをキャラクタモードAから派生したと定義したい場合、
> B.InheritFrom : A
と記述します。一般的に、
<キャラクタモード名>.InheritFrom : <派生元キャラクタモード名>
とキャラクタモードの派生関係を定義します。
● 派生式キャラクタモードにするとどうなるか
キャラクタモードBに存在しないイベントトークが要求された場合、キャラクタモード
Aのイベントトークを探して答えます。
例えば、キャラクタモードBに時計合せイベントトーク(B.TalkNTPstart等)が無かった
場合、Aの時計合せイベントトーク(A.TalkNTPStart)を探し、これを使って応答します。
一般に、あるキャラクタモードに存在しないイベントトークは、派生元キャラクタ
モードのイベントトークを使って応答します。
● 派生元キャラクタモードにもトークが無かった場合
派生元キャラクタモードの、さらに派生元キャラクタモードのトークを探します。
このトークの検索は再帰的に行われます。
例えば、キャラクタモードEにnarファイル作成時のトークが無かったとします。
この場合、先の動作に従えばキャラクタモードDのnarファイル作成時のトークを使いま
す。しかし、もしキャラクタモードDにもnarファイル作成時のトークが無かった場合、
さらにキャラクタモードDの派生元であるキャラクタモードAのトークを探し、応答しま
す。
もし派生の一番の根っこに当たるキャラクタモードAにも対応トークが無かった場合です
が、その時はキャラクタモード無しの(要するに通常時の)トークを使います。
● 派生元キャラクタモードに遡ってほしくない時
用途によっては、キャラクタモード無しのトークにまで遡って欲しくない場合があると
思います。例えばキャラクタモードFの場合です。これは他のキャラクタモードA〜Eと
共通にしたくない、別人格だとします。この場合、
> F.InheritFrom : __self__
と、「__sefl__」というキャラクタモードが派生元だと定義すると、それ以上遡って
トークを探しません。
一般に、あるキャラクタモードで派生を遡ることを止めたい場合、
> <キャラクタモード名>.InheritFrom : __self__
と記述します。
文章で書くと難しく感じますが、実際にやってみると直感的に理解できると思います。
OpenKEEPSサンプルゴースト「きぃ&ぷしゅう」には、この機能を試すスイッチが設けて
あります。メニューの「人格オーバーライドON」を選んでから別人格にした場合と、OFF
にしてから別人格にした場合の動作を比較してみると良いでしょう。人格オーバーライ
ドのON/OFFで、派生式と通常の切替式を変えられるようになっています。
■ 自己クラッシュ検出
何らかの原因でゴーストが正常に終了しなかった場合、次回起動時にそのことを検出
することが出来るようになりました。TalkCrashedエントリにトークを記述しておくと、
ゴーストの不正終了後の起動時にそのトークを話します。これは起動・ゴースト切替
等に優先して話します。
■ セキュアなReference参照
イベント通知を外から送り、本体からの情報と偽ってゴーストをクラックする危険が
指摘された為、一番危険なReference参照を安全に行う関数を追加しました。
標準で使えるReferenceコマンドとよく似ていますが、危険なさくらスクリプト、
華和梨のエントリ参照等を漉しとったものを返します。
現在は次の5種類のコマンドを使うことができます。
・SReference…危険なさくらスクリプトタグを無害化してReference参照
・IntReference…Reference中の整数のみを抜き出して参照
・NonNegReference…Reference中の0以上の整数のみを抜き出して参照
・EntNamReference…Reference中のエントリ名に使える文字のみを抜き出して参照
・NormReference…Referenceを正規化して参照
使い方はいずれの共通で、第1引数にReferenceの番号を書きます。例えば、危険な
さくらスクリプトタグを漉しとってReference0を参照したい場合、$(SReference 0)と
記述します。
■ メニューグループ
メニュー作成の手間を少しでも軽減する為、メニューグループの概念を導入しました。
従来通りのメニューも、当然使えます。
kp.MenuGroupエントリにメニューグループ名(総合、トーク頻度、キャラクタ等)を設定
すると、OnChoiceSelectでReference0の前にピリオドを挟んでメニューグループ名を挿
入します。すると、同一選択肢IDを\qタグが返しても、メニューグループがあれば区別
することが出来ます。IDを重複させないよう設定する手間が省けます。
具体的例を挙げて説明します。いま、kp.MenuGroupエントリが「submenu1」だったと
します。この時、\qタグが返したIDが「Cancel」だった場合、トークに使われるエント
リは、「Select.submenu1.Cancel」になります。
一般に、メニューグループが有れば「Select.<メニューグループ名>.<ID>」エント
リ、無ければ従来通り「Select.<ID>」エントリをトークに使います。
kp.MenuGroupエントリですが、誤動作防止の為、一回OnChoiceSelectイベントが呼ばれ
た時点で内容がクリアされます。このエントリが空の場合は従来と同じ動作をしますか
ら、IDが多くて大変なメニュー等だけメニューグループを使い、他は従来通りといった
使い方も出来ます。
また、メニューグループはOnChoiceTimeoutイベント、OnChoiceEnterイベントでも有効
です。OnChoiceTimeoutイベントの時は、メニューグループが設定されていれば
「TalkTimeout.<メニューグループ名>」エントリ、設定されてなければ従来と同様に
「TalkTimeout」エントリをトークに使います。
OnChoiceEnterイベントの場合、OnChoiceSelectと同様、メニューグループが有れば
「Selecting.<メニューグループ名>.<ID>」エントり、無ければ従来通り
「Selecting.<ID>」エントリをトークに使います。
なお、メニューグループ設定用にsetMenuGroupコマンドを追加してあります。第1引数
にメニューグループ名を書くと、kp.MenuGroupに設定されます。また、引数省略時は
kp.MenuGroupをクリアします。
| |