This page linked from [ __RO_GPS.pmBBS過去ログ一覧 ]

RO_GPS.pmBBS_2003Q3

過去ログ:2002年,2003年Q1,2003年Q2,2003年Q3,2003年Q4,最新



名前 : Kuro(2003/09/28 14:34)
ども。
毎度つかわせていただいてます。
rotoold-20030919_0を
RedhatLinux? 9(shrike)にて稼動を確認しております。
エラーはいまのところみつかっておりません。
今後ともよろしくです。
※もしも時間が余っていたらドキュメントon Redhatでもつくっときます。もしもですが。

名前 : fumi.(2003/09/24 22:48)
報告が遅れましたが、20030919_0 版で問題なく動作しているようです。
patch の取り込みに感謝します:)


名前 : ynakata(2003/09/21 17:22)
2003/05/07ごろの記述ですね。すっかり失念していました。
該当部分のコードですが、trial20030530版にて修正していたようです(うろ憶え)。まだ何か問題が残っているようでしたら、報告いただければ(&原因が推定できれば)対処しますです。


名前 : somebody(2003/09/21 02:24)
>HTTPモジュールが動作しまくって他の動作を阻害してしまうというバグがあるようです。発生条件は不明ですが、怪しい挙動をした場合に接続を切ってしまうようにしてみました。
この部分ですね。(^^;


名前 : ynakata(2003/09/21 02:05)
ところで過去ログの記述ってのはこれですかね?
> 環境によってはメモリリークによりシステムを停止させる可能性があります。
ここで示唆してることはもっとヒドイ話で、最悪メモリを使い尽くしてOSをフリーズさせる、という意味ですが。


名前 : ynakata(2003/09/21 02:02)
バグ修正については、原因が特定できるものであれば対応します。原因がよくわからない場合には、推定のためのテスト版を出すかもしれません。
原因特定のためには、以下のような情報があると助かります。


名前 : somebody(2003/09/20 23:38)
HTTPモジュールの方活用させて頂いているのですが
過去ログにありましたが挙動が怪しい時に全て切断するようになっているとの事ですが
今後修正等される可能性はあるのでしょうか?

20030919_0版ですがHTTP部分が原因で落ちると思われる以外は問題なく動作しています。


名前 : ynakata(2003/09/19 17:55)
パッチを取りこんだ上で弱干改造して、RagMap?.iniに対応させました。ついでに標準付属のマップファイルもRagMap?.iniに差し替え。例によってロクなテストを通してないのでよろしく。


名前 : fumi.(2003/09/18 17:29)
ちょっと探してみたら free のマップ名対応表があるので、
これを利用するようにした方がいろいろと楽かもしれませんね:)

- RoAddr?.ini 解説所 -
<URL:http://reharmonize.net/ragnarok/RoAddr/>
(12.RagMap?.ini のところを参照のこと)

これを利用するようにすれば、マップ名変換機能を使いたい人は
最新の RagMap?.ini をダウンロードしてくればよいだけになりますね:)
これを利用するというのも一つの手じゃないでしょうか.

で、RagMap?.ini を読み込むためのパッチです。(for 20030916 版)
split のところが変わっただけですね(^^;

--- ROTool/AcoNavi/Client.pm.old        2003-09-18 17:17:50.000000000 +0900
+++ ROTool/AcoNavi/Client.pm    2003-09-18 17:16:48.000000000 +0900
@@ -70,12 +70,14 @@
     open(FD, $self->{opt}->{aconavi_map})
        or &ROTool::printlog(1," conversion map load error.\n");
     while(<FD>) {
-        my($field, $mapname) = split(/,/, $_);
+        my($field, $mapname) = split(/=/, $_);

-        $field   = "[".$field."]";
-        $mapname =~ s/\r?\n//;
+        if($field and $mapname) {
+            $field   = "[".$field."]";
+            $mapname =~ s/\r?\n//;

-        $field_ragna2name{$field} = $mapname;
+            $field_ragna2name{$field} = $mapname;
+        }
     }
     close(FD);


名前 : fumi.(2003/09/16 21:30)
取り込んでいただいてありがとうございました。
これで aconavi user みんなで幸せになれるんじゃないでしょうか:)

あと、すっかり忘れていたのですが、マップ名の対応表は
ROSV <URL:http://rosv.zive.net/>
から持ってきました。
(Excel と awk でていっと作ることができます(笑))

開発者向け情報として公開されているものなので再利用しても ok だとは思いますが、
もしかしたら確認を取らないといけないかもしれません(汗
私から確認のメールを送っておいた方がよいでしょうかね?
(使用許諾みたいなものがみつからなーい ^^;)


名前 : ynakata(2003/09/16 02:24)
20030916_0版を出しました。
アコナビ用マップ名修正パッチを取り込み、etc/aconavi_map.datにマップ名変換ファイルを追加しました。
更に、以下のオプションを加えました。

ただし、通常の方法で起動していれば、特に指定する必要はありません。
パッチ提供ありがとうございました>fumi.さん


名前 : fumi.(2003/09/15 23:58)
対 aconavi 用のマップ名修正パッチを作ってみました。
perl はほとんど書いたことがないのでひどい書き方をしているかもしれませんが、
取り入れてもらえるとちょっとありがたいです:)
 <URL:http://www.monochrome.jp/~fumizki/rotoold/>

説明をすると、
1. 背景
 aconavi(立ちアコ) は長らくメンテナンスを受けていないため、
 去年の冬以降に追加されたマップ名を知りません。
  そのため、aconavi では内部名(ex.

[gef_fild11]

)で表示されます。

2. rotoold での対応
 内部で変換テーブルを作ってパケットを受け取るたび(recv())に
 変換を行っています。
 変換テーブルを作るために aconavi_map.dat を利用します。

3. ここダメなんちゃうん?

という感じです。
何かの参考になれば、と書き込ませて頂きました。


名前 : ynakata(2003/08/27 19:46)
trial20030827_0版を出しました。サーバからの情報更新頻度の回りを調整しました。
これで問題が出なければ、続けて頻度調整オプションなんかも実装していく予定です。


名前 : ynakata(2003/08/27 16:13)
ちなみにrotooldは作者が既にROをやっていないため、激しくノーテストで開発・公開されています(大問題
ですので、「一部互換クライアントだと更新頻度で問題が生じる」ことすら認識していない有様でした。
送信頻度抑制については、次のfix予定に入れたいと思います。

ということで、今後ともよろしくお願いします>利用者各位


名前 : somebody(2003/08/23 03:05)
分からない人用に条件式を書いてくださってありがとうございます。
3回目の発言がちょっと不適切ですいませんでした。

これから試してみようと思います。
作者様と協力してくださった方どうもありがとうございました。


名前 : somebody(2003/08/23 00:06)
確かにデフォルトだとクライアントによっては更新頻度が高すぎてマシンに余計な負荷がかかります。
Perlの知識がほぼ無い状態でいじるのでしたら'rotoold'の178行目と179行目の間に

$client->checktimer($selecter);
}
sleep(1); #追加した
}

と・・・力業なのでもうアレ過ぎますが一応頻度は下がります。
なにも分からない人用ということでだめですか。


名前 : somebody(2003/08/20 14:24)
すいません、できそうだとおもったのですが、
どうもダメみたいです。
ちなみにほとんどPerlの知識ないもので・・・。


名前 : ynakata(2003/08/20 01:01)
簡単に改造するなら、メインスクリプト'rotoold'の167行目の$client->send();の回りをいじれば調節できると思います。あるいは、167行目の$client->send()を削除した上で、176-177行目の間(タイマーチェック部分)に条件文と一緒に適当に挿入してもいいでしょう。
と、いうぐらいの情報で大丈夫でしょうか?


名前 : somebody(2003/08/19 23:18)
申し訳ないです。
言葉がたりませんでした。
ソースみてそれらしいところあるんですが、スキルがそこまで高くないので直せないもので、すいません。

で、質問したかった内容なのですが、後者です。
ソースのどこ書きかえればいいかまで教えていただければ自分でできるとおもいますので、よろしくお願いします。


名前 : ynakata(2003/08/19 19:52)
えー、読解してソースをいじれば直りますが、という回答は却下ですかそうですか>サーバの更新時間

冗談(でも半分は本気)はさておき、とりあえず用語が曖昧なので確認します。
「鯖の更新時間」という語は何を意味しているのでしょうか?
今ぱっと考えても次の2通りの解釈が思いつきます。

(「ちかちかしている」という文言から考えると、後者ではないかと思うのですけれども)


名前 : somebody(2003/08/18 20:10)
いつも使わせていただいています。
またアップデートの方もご苦労様です。

早速ですが、鯖の更新時間を変更する方法または、変更できるようにしていただきたいのですが。
今の状態だとちょっとちかちかしているのでもうちょっと遅くしたり早くしたりできたらなと思いまして。
調べた限りなかったようですが既出であったり実装されていたらすいません。

よろしくお願いします。


名前 : Nioizo(2003/07/29 19:28)
アップデートおつかれさまです。
私の環境ではtrial20030729_0版で正常に機能しております。
まだ公開されてさほど時間がたっておりませんが報告させていただきました。


名前 : ynakata(2003/07/29 13:08)
Nioizoさんの改造版に触発されて、trial20030729_0版をリリースしました。
HTTPでアクセスした場合、(カレントディレクトリの)public_htmlというディレクトリ内を適当に探して、見つけたものを返すようになりました。
trial20030729_0版では、index.htmlとindex.plの2つがサンプルとして用意されています。
index.plでは、その気になればかなりいろいろ出来るはず、です(セキュリティ的には大穴ですが)。
動作確認はRedHat Linux 8.0にて行ないました。


名前 : arumi(2003/07/29 02:23)
>Nioizo様
サンプルの方ありがとうございました。
いじって無い物と比べながら自分なりに触ってみようと思います。
御手数おかけいたしました


名前 : Nioizo(2003/07/28 22:45)
ynakata様いつもrotooldを愛用させていただきありがとうございます。

HTML化ということですがhttpモジュールを自分なりにいじってみたもので良ければ・・・
ttp://fragment.no-ip.com/etc/HTTPmodule.lzh
perlにあまり詳しくないものでおかしい部分がいくつかあるかと思いますが私の場合はこれで正常に動作しています。
環境:VineLinux?2.5
別なところからCSSファイルを読み込んでデザインの変更をしやすくしております。
そのCSSファイルのサンプルも同梱しておきます。


名前 : arumi(2003/07/28 19:51)
最近、導入させていただいたのですがHTML化がよくわからないので
書き込ませて頂きました。
下の方の書き込みでHTML化の方法がかかれていましたが
私ではよくわかりませんでした(^^;
サンプルなりがあれば参考にしてみたいと思うのですが・・・。

よろしくおねがいします。


名前 : ynakata(2003/07/28 19:26)
仕事で多忙により放置してました。
ということで、 "要望文中の「アドレスデータ」=RO上での所在情報" という解釈でもって回答をば。

要するに必要なのは特定のユーザーをkick(蹴り出す)する機能でしょうか。
それだと、kickの条件をどう設定するかが問題になりそうです。httpモジュールをベースにインターフェースを作ることになるのでしょうけど、ぶっちゃけ面倒なので作りたくないです(ぉ

IPレベルでの接続拒否については、適切なFWソフトウェアを使えばIPレベルの接続拒否は可能、という答えではダメですかそうですか。こちらはもう少し積極的に検討しますです。