--------------------
◆ LimeChat 2.xを使ってみた

--------------------

ご存知の方も多いだろうが、先日、Windows向け日本語IRCクライアントのLime Chatがメジャーバージョンアップされた。
ユーザ側から見た場合、バージョン2.xで一番目に付く変更はマルチチサーバ対応といったところだろう。
これまで複数のIRCサーバへ同時に接続するためには、Lime Chat自身を多重起動するしか方法が無く、手間を承知で多窓にするか、他のIRCクライアントを使うしかなかった。





余談だが、自分はこれまで、
CHOCOA → Lime Chat 1.x → Cotton
と、たびたびメインで使用するクライアントを変更してきた。

確かCHOCOAからLime Chat 1.xに乗り換えた直接のきっかけは、CHOCOAに標準搭載されていたスクリプト言語の仕様に嫌気が差していたからだったと記憶している。
例えば、for文やwhile文に代表される反復構造がサポートされていないため、ループを表現するために、条件分岐とラベルジャンプを駆使しなければならない。
また、エラー処理が非常に曖昧なので、開発段階でわざとエラーを発生させ返ってくる文字列を確認したり、他にも高級言語ではあって当然とも言えるスコープの概念が希薄だったり……今にして思えば、我ながらよくダイススクリプトなんぞ作ったものだ。
むろん、IRCクライアントに独自のインタプリタを組み込むというのはなかなか手間のかかる設計&コーディングだというのは分かっているのだが……。

この頃、自分はLime Chat 1.xへと移行する。
Lime Chatは自作のDLLをロードさせることが出来るらしい、そんな情報だけで飛びつく理由は十分であった。
既にCHOCOA自体の公式サポートが見込めない状況だった(近いうちに配布終了されるとも言われていた)のも寄与しているとは思う。

アスキー・デジタル用語辞典によれば、DLLとは
Dynamic Link Libraryの略。
Windowsの中核技術で、動的リンク・ライブラリと訳す。
プログラムを開発するとき、リンク時にプログラムとライブラリ関数をひとつのファイルにまとめることを静的リンクという。
それに対し、リンク時にライブラリと結合するのではなく、プログラムが必要に応じてライブラリを呼び出す方法を動的リンクという。
DLLは動的リンクにより呼び出されるライブラリのこと。
とある。
アプリケーションの実行ファイルに全ての機能を持たせず、DLLファイルに分割してロードするという方式を取ることで、HDDやメモリの容量を削減したり、機能別に異なるプログラマが開発したりできるのだ。
これを応用して、一部のアプリケーションでは拡張機能を提供するプラグインとしても用いられる。


CHOCOAのようなスクリプト言語による拡張と違い、Lime ChatのマクロはDLLを用いるため、C言語などの一般的なプログラミング言語で開発が可能となる。
多少プログラミングの経験がある自分にとっては、はっきり言ってこちらの方が敷居は低い。
こうして文字列操作の勉強も兼ねて開発されたのが、拙作「OD Tool for TRPG」である。
このブログでも何度か話題にしたことがあるので、興味があれば過去ログを覗いてみて欲しい。


こうして、しばらくLime Chatを使っていたのだが、昨年当たりから複数のサーバに接続する機会が多くなり、クライアントの移行を余儀なくされる。
それまではirc.cre.jp系サーバ内だけで活動していたところを、wide系(IRC net系)にあるTRPGサークルのチャンネルにも参加するようになった。
たまに繋ぐくらいなら良いのだが、毎日のように2窓、3窓となるのでは流石に不便。
そこで目をつけたのがマルチサーバに対応しているCotton(旧Unknown)というわけだ。

とはいえ、ちょうどOD Toolが一部のオンラインセッションユーザに認知され始めていた矢先のこと。
Lime Chat用マクロの作者が、他のクライアントへ完全移行するわけにもいかなかった。
一応、CottonにもLime ChatのDLLを読み込む機能が用意されていたが、残念ながら完全な互換性があるとは言い切れない。
結局、通常のチャット用としてCottonを、マクロ開発用としてLime Chatを使い分けるという変則的な形で落ち着くことになる。


閑話休題。


早速、Lime Chat 2.xを導入してみた。
Lime Chatのバージョンアップというよりは、Cottonのユーザ・インターフェースがLimeっぽくなったという印象である。
実際、1.x系からのバージョンアップ組より、Cottonからの移行組の方が混乱は少なかったようだ。

よくよく考えれば興味深い。
あるソフトを元にして別のソフトが作られ、それを参考にして更に別のソフトが開発される。
かと思えば、大元となったソフトに、孫が持つ拡張機能が搭載されていたりする。
こうして作られた秀逸なアプリケーションのなんと多いことか。


個人的にやはり見逃せないのが、マクロの仕様である。

今までネックとなっていた複数回のコマンド(複数行に渡るメッセージ)送信の際に生じる問題が解決されたのはとても大きい。
OD Toolをインストールした方ならご存知かもしれないが、チャートの呼び出し機能などで複数行のメッセージが一度に送られるとき、ボット側では改行されずに表示されてしまう現象である。
他にも全てのコマンドを一度に送信していたために、すぐ送信上限バイト数に達してしまうなんてこともあった。
一度、Lime Chatの公式掲示板で改善要望を出したことがあり、これが実現した形となる。
人間、何でも言ってみるものらしい。

他にも、2.x系ではDllHookというコマンドが実装されている。
どうやら従来の$DLLSTRING関数やDllCallコマンドの兄弟分らしい。
ヘルプファイルに記載されている宣言の例にコメントをつけると、
extern "C" __declspec(dllexport)
void __cdecl DllHookFunction
(const char* SenderNick, /*送信者のニックネーム*/
const char* SenderUsername, /*送信者のユーザ名*/
const char* SenderAddress, /*送信者のアドレス*/
const char* Command, /*送信コマンド*/
const char* Target, /*第1引数*/
const char* Trail, /*第2引数*/
char* Output); /*出力文字列へのポインタ*/
といった感じ。
普通の発言(PRIVMSG)なら*Trailには発言内容が格納される。

リファレンスを読む限り、$DLLSTRINGと比べて
  1. コマンド送信者の情報が自動的に渡される
  2. 任意の引数を渡せない
  3. 出力文字列の容量が多い
といった違いがあることが分かる。
$DLLSTRINGだと、唯一の入力用引数である文字列(正確にはchar型ポインタ)にチャンネルや送信者名などの必要な情報を全て埋め込み、プログラム側で構文解析をしなければならなかったのを考えると、随分と楽になったと言えよう。
ただ、逆にいえば、引数が固定されてしまっているので、裏技とも言うべきダイナミックな使い方が出来なくなってしまったことも忘れてはならない。
そこを自前で処理しなければならなくなった分、目的によっては従来通り$DLLSTRINGを使う場合もありそうだ。



【2006/05/03 12:30 追記】

例えば、OD Tool for TRPGにおいて、アリアンロッドRPGのライフパス表を呼び出すコマンドは
#TABLE ARA LIFE
である。
しかし、このままでは余り直感的ではないということで、そのチャンネルのモード設定がARA(アリアンロッド)になっている場合、
ライフパス
で同様の処理を行うことができる。
これは、Lime ChatからDLLの関数が呼び出されるときに、
%n %c 1 #TABLE - LIFE
という引数が渡されるようになっているためだ。

ここで、最初の3トークン(%n、%c、1)を無視して考えることにする。
すると、その後に続く文字列(#TABLE以降)を見れば分かると思うのだが、これは標準の呼び出しコマンドそのものである。
なお、「ARA」の部分が「-」になっているのは、設定されたモード別に処理を割り振るため。
モードが「ARA」ならアリアンロッドの、「NW」ならナイトウィザードのライフパス表を参照したりというように。

この部分はLime Chat標準のマクロ形式で設定されており、ある程度マクロに詳しいユーザならカスタマイズすることも可能。
しかし、$DLLSTRINGではなくDllHookコマンドを使う場合だと、こういったテクニックが簡単には使えなくなってしまう。
ただ、実際にカスタマイズを行うユーザがどの程度いるのか、全く把握できていないのが苦しいところだ。
[PR]
R.F.D. | by odprfd | 2006-05-03 03:03 | 情報技術

--------------------

<< OD TOOL for TRP... | ぷいにゅと肉体言語と幻想主義の話 >>