日記/2006-11-16

人間の判断はどうしても主観的。
「設定がやさしい」というのは、何が基準になるんでしょうかね。

Glenelgは「そのプログラム・ソースが難解」なのは否定しません。
ですが、導入・カスタマイズについては、かなり気をつかっているつもりです。
使ってもらえなければ、公開している意味がないですから。

• カスタマイズする際にいじるべきファイルは、ヘルプファイルで詳しく紹介。
• ai_option.ini の先頭で、基本的な編集のやり方について説明しているつもり。
• ai_option.ini 類は、すべての項目の詳しい「そのパラメータにはどんな値を設定できるのか」「設定を変化させたときに何が変わるのか」を記載しているつもり。
• ヘルプファイルのトラブルシューティング項目にて「〜〜という動作をさせたいんだけどどうすればいい？」というかたちで、実現したい現実から変更すべきパラメータを探すことができるようにしているつもり。

文字は量があればあるほど「圧倒されてしまう」のも事実なので、そういう逆の意味でのハードルは高くなっちゃうのは否定しませんが。

つーか、まずはカスタマイズなんかしないで動かしてみればいいんじゃないですかね。
まがりなりにも「友瀬が実際に使っている」設定なので、そんなにお行儀悪いことはしてないはずですし。
そしてもし判らなければ、掲示板でも拍手ででもメールででも、連絡してくれればいいんです。
少なければ個別で、多ければそれこそ「拍手フォロー」みたいな感じで1箇所で解説対応するくらいはしますし。

またいくつか貯まったので、拍手的な。関連フォロー。
べたべたな技術的なものばかりなのは、やっぱりそういうサイトだからなんだろうなぁ（笑）

地図情報について、その１†

ええと、数日前の日記で「地図情報BMPが未リリース」というようなコメントをしたのですが、実は「すでにリリースされている」とつっこみがありました。
つまり、友瀬の見落とし（＾＾；；

で、地図対応関連については大きく２つの課題を持って、対処中です。
ちょっとリアルがアレなので、リリースは・・・今週末は苦しいかな？

1. マップ名指定方法について。
   Glenelgでは昔から「メニューを使ってリストをスクロールするような形で、マップ名選択」という仕組みがありました。
   が、次回のリリース版ではこれは廃止する予定です。
   というのは・・・リストで管理している以上、あたらしくマップが拡張されるたびにAIの管理情報を更新しなければならないですよね。この手間が正しくないからです。
   今後は、チャットコマンドでの「/where」「/savechat」での指定が、Glenelgでのマップ名指定方法となります。
2. Glenelg独自といえる「マップ名の自動判定」の改訂作業については、ちと保留中。
   もともとメンテにもろいという問題があるのはわかっていたのですが、正直予想を遙かにうわまわる情報変動で、手が追いつかないので。
   気が向いたらよく行くマップについては直そうかとも思いますが、これもチャットコマンドという手軽な指定方法ができてしまっているので・・・

地図情報について、その２†

鋭いつっこみがもう1点。

現状Glenelgではマップ情報サポートをしていますが、その前提条件は
「セルの侵入可否は、人間は実際に移動しなくても、カーソルをもっていくとその形状が変化するので、知ることができる。
　だから、ホムがそれを（外部データを持って）知ることは反則ではない」
・・・という、友瀬的な「正当性」がよりどころです。
（参考：FAQページ Q.8）

が、こんなことを指摘されました。
「一部のマップでは、カーソルを合わせてもカーソル形状は変わらないです。」

Σ('-'つ)つ
確かにシーズモードではそういう動作のような気がする。
ターボトラックなんかもそうかな？

・・・というわけで。
近い将来、友瀬が知ることができたこういう条件にあたるマップでは、Glenelgは「マップ情報を利用しない」ような動作をするように変更したいと思います。
ただ、友瀬が行くマップは非常に限られていますので、こういう条件にあてはまるマップ名がどれになるのか、把握していません。
ご存知の方は、ぜひ情報提供ください。

クライアントの一時停止について†

技術的なお話。

「クライアントを止めずにWAITさせる方法はあります。
　AI()関数の先頭で経過時間を確認し、時間が来ていなければリターンします。
これだけで、クライアントが止まるような事がありません。」
・・・というようなコメント。

ちょっと友瀬はこんなことで困った記載をした記憶がないので、なぜこういうコメントをいただいたのか判らなかったのですが・・・
もしかしたらGlenelg開発メモ：（未実装）ASPD高速化に関するメモに書いた『AIで待ち時間を持たせると、その間ROクライアントの表示系がとまってしまう』についてのコメントなのかな？

で、もしそうだとしたら、これについては・・・申し訳ないですが、論旨がずれていまして。
上記「高速化」でのポイントになるのは、「140msサイクルのAI動作が、ASPDと数十ms単位でずれているので、この数十ms単位でのWAITが必要。」という部分で、つまりこのWAITはクライアントに制御を戻さないAI内で作り出さなければならない、という点になります。
ご指摘の方法では「クライアントに制御を戻した時点で、件の140msサイクルの限界にぶち当たってしまう」ため、役に立ちません。
クライアントに制御を戻さなければならない時点で、意味がないのです。

ちなみに技術的な話としては、これも正直申し訳ないですが、Glenelgではすでに「起動後一定時間は何もしないで処理を戻す」というご指摘の内容とほぼ同じ処理が入っています（起動後から数サイクル動作内なら即リターン）を加味した、起動時の動作について状態遷移自体を改善・ほぼ類似のことをやっています(11/17 10:05記載修整)。完全に同じにしていない理由は後述。わざわざ秒換算まではしていないべたなデータですが、そこまでの精度が必要でない部分なのでいいかげんに作ってあります。
起動後以外では、逆に、そんな「初めから時間で切る」ようなWAIT処理はする気がありません。
すべてをAI側で管理しているならば、そういう軽量化処理も意味があるのですが、ホムAIの場合「次にクライアントに制御が回ってきたタイミングで、以前と何が変わっているかわからない」ため、単純に「コマンド発行したから終了まで待つ」なんてのは、ホムの反応性が低下することになるだけです。
確かにスキルディレイ中などで「次のスキルは無意味だから出さない」とい処理はありますが、ではディレイ中にホムの体力が低下していたら？
逃げ出さなければならないのに、時間まで待つわけにはいきません。
非同期の通信・制御系で、周囲の状況もチェックせずに処理を止めるのは大きな理由がないかぎり大下策だと思います。
Glenelgでの「起動時のWAIT」は、ROクライアントが人間側への表示が未完了な状態でもホムAIはフル稼働してしまうという根本的な問題点を避けるための苦肉の策であり、これですら本来は「クライアント側から表示完了という情報が通知され、それと同時にAIが動き出す」のが正しい姿だと思っています。

とまあ、ご指摘の趣旨が見えなかったので、こちらの想いだけですが。
せっかくご指摘いただいた情報、なにか友瀬が見落としているようなことがあれば、もうちょっと補足いただけると助かります。

以上、今回は（も？）全般に開発寄りですが。