雑記(2006年3月)

銭湯行った

銭湯に行ってきた。所謂スーパー銭湯と呼ばれるところです。久々に風呂を満喫しました。家だと風呂掃除が面倒という理由でシャワー使うだけなので実家に帰らない限り湯に浸かるということが無い人なので。それを抜きにしても湯船で足を伸ばすことができるし泡風呂やサウナも有ったので非常に魅力的です。

料金も500円なので今後も時々お世話になろうかなと思った。

今日したこと

• 銭湯に行った
• PHP-Statsのアップデート
• PCのOSをFedora Core5にした

PHP-Statsの設定を変更しようと管理モードにログインしようとするとページの表示にやたら時間がかかっていたのですが理由を調べると最新版のチェック機能により無効になっていたドメイン(いつだか分からないけれど公式サイトのアドレスが変わっていた)にアクセスしてしまっていたためにやたらと時間がかかってしまっていたようです。アップデートするついでにチェックを無効にすると時間がかからなくなった。

特殊

やはりいつもと違う事をやるときはしっかり事前に告知しておかないとだめね。ゲームとして成立していなかったね。

援助

「援助掲示板」というキーワードでうちのサイトに来る人は何を思うのか。

禁止エリアを追加する時間を決める方法について

ここの配布版は禁止エリアを追加する時間を決める方法が他のバージョンとは異なっています。takuya氏のバージョンのpref.cgiは以下のようになっています。

($y,$m,$d,$hh,$mm) = split(/,/, $arealist[0]);
($sec,$min,$hour,$mday,$month,$year,$wday,$yday,$isdst) = localtime($now);
$year+=1900;$month++;

if (($year eq $y) && ($month eq $m) && ($mday eq $d) && ($hour >= $hh) && ($fl !~ /終了/)) { #禁止エリア追加？
    以降禁止エリア追加関連処理

$y、$m、$d、$hhはそれぞれエリアファイルに保存されている次に禁止エリアが追加される年、月、日、時で、$year、$month、$mday、$hourはここではそれぞれ現在の年、月、日、時です。このバージョンでは$year、$month、$mdayがそれぞれ$y、$m、$dと等しく、$hourが$hh以上(takuya氏のバージョンでは$hhは常に0なのでこれは常に成立)の時に禁止エリアが追加されることになります(8時間毎に禁止エリアが追加されるBRUはもっと複雑である)

それに対してここの配布版は以下のようになっています。

list($artime,$this->ar,$this->seed) = explode(",",$arealist[0]);

中略

while($artime <= NOW){
    以降禁止エリア追加関連処理

$artimeは次に禁止エリアが追加される時刻のUnixタイムスタンプです。定数NOWの値が$artime以上の時に禁止エリア追加関連の処理が行われることになります。この時、if($artime <= NOW){ではなく、while($artime <= NOW){の様にwhileを利用することでどんなに長い間アクセスが無くてもしっかりと禁止エリアが追加されるようになっています。

ちなみに最初の$artimeはreset.phpにて以下の様に算出されています。

$chk = mktime(0,0,0,$br->month,$br->mday,$br->year);
$chk += 86400;

変数名が違っていますが動作に影響は無いので気にしないでください。これを書いている時に$chkでなく$artimeにしておけばよかったと思いました。さらに式を二つに分けずに$chk = mktime(0,0,0,$br->month,$br->mday,$br->year) + 86400;でいいじゃないかと思いましたがとりあえずこのまま説明を進めます。

一つ目の式で初期化した日の0時0分0秒のUnixタイムスタンプを算出し、二つ目の式で86400を加えます。その加えたものを保存してpref.php内で$artimeとして使われます。例えば2006年3月24日に初期化をした場合は一つ目の式で2006年3月24日0時0分0秒のUnixタイムスタンプを算出し、86400を加えたものが次回の禁止エリアが追加される時刻のUnixタイムスタンプとなります。この場合、次回の禁止エリアが追加される時刻は2006年3月25日0時0分0秒となります。

この様なUnixタイムスタンプを利用した場合、禁止エリアを追加するタイミングや間隔の制御が他のバージョンと比較して格段に容易になります。例えば0時、6時、12時、18時の6時間毎に禁止エリアを1個ずつ追加したい場合は以下の様にすると良いでしょう。

reset.php

//変更前
$chk += 86400;
//変更後
$chk += (int)(($br->hour / 6) + 1) * 3600 * 6;

pref.php

//変更前
$this->ar += 4;
$this->hackflg = 0;

logsave("AREAADD",$this->ar,$this->ar-4,$artime);

$artime += 3600 * 24;
//変更後
$this->ar += 1;
$this->hackflg = 0;

logsave("AREAADD",$this->ar,$this->ar-1,$artime);

$artime += 3600 * 6;

$this->hackflg = 0;の箇所に関してはそのままだと禁止エリアが追加されるとハッキングが(変更後の場合最長で6時間)終わってしまうのでそうなるのが嫌ならば適宜修正する必要が有るでしょう。

この様にすれば6時間毎に禁止エリアが一つずつ追加される様になるでしょう。ただしそのままだと進行状況での表示がおかしくなるのでnews.phpを修正する必要が有ります。

この様なUnixタイムスタンプを利用する方法は他のバージョンでも利用できます。ただしPerl版とPHP版では記述が異なるので注意しなければなりません。また、修正する必要のある箇所が結構多いので修正は結構大変かもしれません。ただし禁止エリア追加されないとか追加されすぎるといった動作はおそらく回避できるでしょう。記述にミスがない限りは。

余談ですがpref.phpのwhileループの中にある

if($this->ar < $this->arcnt and $artime <= NOW){
    continue;
}

という記述は禁止エリアが追加される条件を満たしている限りまずは禁止エリアを追加してからその後の禁止エリア滞在関連の処理を行う様にするものです。この記述が無い場合は禁止エリアが追加される度に禁止エリア滞在関連の処理を行います。長時間放置されていた場合は処理の量を減らすことができるというメリットがありますが殆どの場合は意味は無いものです(苦笑

またミスがあった(汗

pref.phpの306行目付近

//修正前
if(preg_match("/^NPC/",$user['tactics'])){//NPCは禁止エリアから移動
//修正後
if(preg_match("/^NPC/",$mem['tactics'])){//NPCは禁止エリアから移動

$user['tactics']を$mem['tactics']に修正してください。修正しなかった場合、NPCが多分禁死します。これだけのためにバージョンアップするのもなぁと思ったのでバージョンアップは保留。

この軽さはたまらない

ノートPCのOSのクリーンインストールを実行した。やはりこれを実行した直後のPCは軽い。なぜこれほど差が出るのだというくらい。

TOPでの雑記をやめた

両方更新するのが面倒だからTOPページで雑記を表示するのをやめました。最新の雑記を読みたければhttp://hexa.cc/diary/latestをブックマークしておくと良いかも知れません。

答へてみた

CSS關係者に37+αの質問への囘答

色々配置換えした

このままだと特にEtcの所がゴチャゴチャしてきそうな気がしたので整理した。アドレスが変わることになるので弊害が出るかも知れないけどどうせ自分とクローラー以外では一日10人くらいしか来ないようなサイトだし、多分問題無いでしょう。整理の際ついでに以下のこともやった。

• これまで殆どのページがPHPだったけどHTMLのページに戻した。
• サイト内のナビゲーションはjavascriptを用いてlink要素から生成するようにした。
• htaccessを使って拡張子無しでアクセスできるようにした。
• CSSファイルの整理

BRU2.20

先日BRUの最新版の2.20が出ました。変更点はバグ修正、携帯からの閲覧に対応、不要なファイルの削除といったところです。

配布ページに今後のロードマップがありました。それによると今後は書き込み形式の見直しや変数の見直し等をする予定らしいです。この2つの変更点は恐らく後方互換性を捨てるものになります。なので今のバージョンを使っている場合、これらのバージョンにアップデートするのは若干難しいかも知れません。

改造以前の問題だろう

FTPソフトの使い方も碌に知らないのにBRを設置しようとしている人がいるという事実が自分には信じられない。知らないこと自体が問題なわけではない。誰だって始めは知らないのだ。問題なのは自分で調べようとしない事だ。フリーのFTPソフトの一つのFFFTPはとても有名なソフトなので少し調べればファイルのアップロードぐらいは出来るようになるはずである。にもかかわらずアップロードの仕方が分からないというのはどういうことか。

パーミッションの設定で躓くというならまだ分かる。自分の場合パーミッションのミスではないけれど初めてCGIを設置する時に#! /usr/bin/perlとしなければならないのに#! /usr/local/bin/perlになっていて「動かないよー(汗」ってなったことがあるんで。だがアップロードの仕方が分からないから改造援助掲示板で聞くのは完全に改造云々以前の問題で論外である。そういう人間が仮にBRを設置できたとしても改造が出来るとは思えないのだ。自分はそういう人を「自分で全く考えない人」とみなし、その人に対してまともな応対は多分しないだろう。自分と同じような態度を取る人は多分他にもいるだろうから自称初心者は聞く前にちゃんと努力をすべきである。BRに限らずね。

• 教えて君は何故嫌われるのか

スクロールが変

初めてOpera9のweekly buildを入れてみたらさとみかんでマウスホイールを転がしたら変な動きをした。ホイールを上に転がしても下に転がしても下にスクロールしてしまう。javascriptに原因が有るようでjavascriptを無効にしたらその現象は起きなかった。バグのようだけど英語さっぱり使えないしそれっぽいバグ報告も有ったのでとりあえずそのまま様子見。

修正第一弾

もう一度大雑把にチェックしてみたらミスが有ったりしたので修正版をアップロードしました。もっとちゃんとチェックしろよといわれると返す言葉もないです。あまりにも間抜けなミスが沢山有ったよ。

とりあえず改造援助掲示板ができました

とりあえず無事に改造援助のための掲示板が設置できました。まずは掲示板を探すことから始めました。自分が希望していたのは以下の通り。

• PHP+MySQLを使う。
• ツリー表示が出来る。
• 投稿者が自分で編集、削除が出来る。
• 投稿前のプレビューが出来る。
• ValidなHTMLを生成する。

しかし希望通りなのが見付からなかったから結局前に作った掲示板を元にしてまた自作したよ。掲示板自体にバグが有る可能性も有るけどとりあえず上記の条件は全て満たしたのでとりあえずオーケー。pre要素が使えるようになったのでコードを記述するのに視覚的に分かりやすく書けるようになった。尤も使わなければ意味が無いが。

最近家では殆どFedoraなんでIE系のブラウザで表示確認する機会が殆ど無くなっている。だからIEとかで見ると微妙に表示が変かも知れない。そんなに変になるようなCSSの記述はしてはいないとは思うけど。とりあえずOperaやFirefoxでは大丈夫なんで多分直さない。余程崩れていない限りは。

• 改造援助掲示板

CSSを少しいじった

現在デフォルトで使われているCSSファイルを少しいじった。h4要素とdt要素の区別が殆ど出来なかったりcite要素がやたら目立っていたりしたので少し変えた。ただ、今のCSSファイルには行き当たりばったりな記述が結構有るので直したい。その内直す。いつになるか分からんけど。

このBRスクリプトの目玉?

配布を始めたスクリプトはプレイヤーにとっての目玉機能は無いと言って良いと思う。V2002_21と比較して追加した機能でゲーム内容に関するものは殆どが今や実装されていないサイトは無い又はかなり少ないものばかりである。せいぜい3対合成くらいかな?BRUを使っていないサイトで実装されているところが少ないのは。

個人的に目玉かなと思っているのはユーザーデータの保存先を他のバージョンでは1つだったのをそれぞれのユーザー毎にバラバラにしたことですかね。ユーザーデータの保存先が1つの場合、人数が増えるとファイルへの書き込みが行われる回数が劇的に増加します。そうなるとデータ破損のリスクが高まることになります。最悪の場合全員のデータが消えてしまう可能性もあります。それに対してデータの保存先をユーザー毎にバラバラにすることで人数が増えてもデータの書き込み処理がそれぞれのユーザーデータファイルに分散するので書き込み処理が失敗する可能性を大きく減らすことが出来ると思われます。また、データの破損が起きても回りへ波及する可能性も限りなく低くなるでしょう。

まあ、実際の効果がどれ程かは試せる環境が無いので分からないと言うのが実際のところだったりするのですが。あくまで理論上はそうなるはずだと言う話。

デメリットも無いわけではありません。直接ファイルを編集してデータの修正をすることが難しくなりました。そのため管理モードからユーザーデータの修正が出来るようにしました。ただし全てのデータが修正できるわけではありません。修正できないようになっている理由は主に以下の3つです。

• データを変更すると変更されたプレイヤーに支障が出る(ID等)
• 管理モードから修正しなくてもプレイヤーがデメリット無しに容易に修正できる。(各種コメント等)
• そもそも修正する必要が殆ど無い(死因等)

これらも修正できるようにしたいなら自分で修正できるようにすることです。ただしそれでもIDは変更できるようにはしない方が良いです。

他に地味な改良点としてはユーザーデータ用の変数を追加する場合に追加すべき箇所を減らしたことでしょうか。高度な事を出来るようにするのにユーザーデータ用変数を追加する事は必須ですが追加忘れがあったりすると誤動作を起こしたりデータ崩れの原因となってしまうことがあります。なのでこのバージョンでは変数を追加する場合に追加すべき箇所を極力少なくて済むように改良しました。その結果他のバージョンでは20箇所以上あった追加すべき箇所を最大で9箇所で済むようにしました。

追加は必須

• lib1.phpの3箇所
• regist.phpの1箇所
• reset.phpのfputs($fp,"$i,$id,(以下略)の箇所

変数の性質によっては追加しなくても良い

• lib2.phpの1箇所
• win.phpの2箇所
• reset.phpのlist($type,$f_name,(以下略)の箇所

どの箇所も1行に変数がずらずらと並んでいるので探せばどこのことかはすぐに分かると思います。

変数の性質によっては追加しなくても良いとありますがそれはどのような場合かと言うと、lib2.phpとwin.phpは優勝者のデータの表示にまず使わないだろうと思われる変数の場合、追加しなくても良いでしょう。このバージョンではデフォルトではユーザーデータの変数の中の幾つか(IDやパスワード等)は保存していません。

reset.phpの場合はnpc.dat(他のバージョンではbase.dat)に新たなデータの項目を追加しない場合は追加しなくても良いでしょう。この事はBRUしかいじったことが無い人にとっては意味が良く分からないかも知れません。BRUではbase.datには名前、性別、クラス、番号しか記述せず、その他のデータは全てスクリプト内で設定するようになっています。それに対し、takuya氏のバージョン等はその他に所持品や装備品、コメント等のデータがbase.datに記述されています。そのため追加するデータによってはスクリプト内でなくbase.datに追加することがあります。その場合に変数を追加することになるでしょう。ここの場合は既存の変数であってもスクリプト内でなくNPCデータファイルで設定するようにする場合も追加する必要があるでしょう。

こんな感じでプレイヤーから見えないところの改善を主に行いました。今後バージョンアップで機能を追加することがあってもプレイヤー側にも分かるような機能の追加は多分やらないと思います。

17条?

実際に配布するにあたってBRの利用規定を読んだのですがその中には以下のようなものがあります。

利用者はスクリプトの著作権表示を削除する事は出来ません。デザイン等の変更は可能ですが、必ず見える位置に配置してください。また削除していなくても客観的に見て著作権表示と見てとれないような表示の仕方もしてはいけません（配色、大きさなど）。例え意図的ではなかったとしても、著作権侵害行為とみなします。

⇒著作権法第１７条第２項

そこで著作権法の第１７条がどうなっているのか気になったのでちょっと調べてみた。

1. 著作者は、次条第一項、第十九条第一項及び第二十条第一項に規定する権利（以下「著作者人格権」という。）並びに第二十一条から第二十八条までに規定する権利（以下「著作権」という。）を享有する。
2. 著作者人格権及び著作権の享有には、いかなる方式の履行をも要しない。

本当に17条ですか?どう見ても違うような気がします。第2項は大まかに言えば「著作権を持つのにどのような手続きもいらないよ」ということではないですかね?では規定にある事に関して書かれているのはどこだと探してみると第19条にそれらしき事が書かれていました。

1. 著作者は、その著作物の原作品に、又はその著作物の公衆への提供若しくは提示に際し、その実名若しくは変名を著作者名として表示し、又は著作者名を表示しないこととする権利を有する。その著作物を原著作物とする二次的著作物の公衆への提供又は提示に際しての原著作物の著作者名の表示についても、同様とする。
2. 著作物を利用する者は、その著作者の別段の意思表示がない限り、その著作物につきすでに著作者が表示しているところに従つて著作者名を表示することができる。
3. 著作者名の表示は、著作物の利用の目的及び態様に照らし著作者が創作者であることを主張する利益を害するおそれがないと認められるときは、公正な慣行に反しない限り、省略することができる。

第四項は省略しましたが、どうもこれのようですね。ただ正確な意味が今一つつかめない。昔から語学系がさっぱりな自分には辛いよ。誰かもっと分かりやすく説明してくれませんかね(何

配布を始めました

自分が独自に作ったPHP版BRスクリプトの配布を始めます。原作者と連絡を取る術が無いので嘗ての関係者と連絡を取って配布しても大丈夫かと聞いてみたところ特に問題はないと思われますとの返事が来たので配布しますが原作者から直々の許可を貰ったわけではないので何かあったら配布を中止する可能性がありますのであしからず。

• 配布ページ

バナー貰った

数日前にBRUの2Y氏がバナーを作ってくださいました。ありがとうございます。別に使えと言われたわけではないのでどうしようかと思ったのですが折角なので置かせてもらいます。このサイトにリンクをする際に使いたければどうぞ。使う事を強制したりはしませんが。

もっと大きな画像も貰ったのですが良い用途が思い付かなかったりします。サイトトップに使えばいいではないかと思うかも知れませんがスタイルの変更を行うとかなり違和感の有るものになるので使うのは難しいです。結局良い用途が思い付かなかったので大きい方は使わないということになりました。

カルチャーショック

当然の話ですがどのような改造をしているかはサイトによって異なるので普段プレイしているサイト以外のBRに参加すると程度の差は有れどカルチャーショックを経験する事が有るのではないかと思います。

自分の場合は一番最初に参加したのはINFINITY ISOLATIONだったのですがそこでは基本は現在地から隣り合ったエリアにしか移動できないというシステムだったので(スキルや日数等の条件で全移動になりますが)、最初から全移動というのにはかなり違和感が有りました。昔は全移動が標準であることを知らなかったのです。今はそれ程違和感は無くなりましたが個人的にはやはり隣接移動の方がしっくり来ます。

他には敵とアイテムをやり取りするというシステムにもかなりの衝撃を受けたことを覚えています。アイテムのやり取りは仲間と行うものだと思っているので敵とアイテムのやり取りをするのはちょっと...と思っています。BRは基本は最後の一人になるまで戦うので仲間だった人が最後には敵になる可能性が有るといえばその通りなのですがそれでもやはり変だなあと思います。何が欲しいか、何が必要でないかというこちらの手の内を晒すことになるので自分の場合、そういうBRに参加してもそれを使うことは殆ど有りません。

何が変かということは個人的な主観なのでどういうシステムにするかは改造する人の勝手です。ただ、普段と違うサイトのBRに参加する人は気を付けた方が良いでしょう。あるサイトのBRで通用したルールが他のサイトのBRでは通用しないことが有りますから。まあ、変な人でない限り大丈夫だとは思うけど。

更新忘れてた

そういえば前回更新した時にRSSの更新を忘れていた。RSSは完全手動なのでこういうことも有る。また、雑記が独り言みたいなものだけの場合もめんどいので多分更新しない。

RSSには何種類かの規格が有ることは知っていたけどどれを使っているか分かっていなかった。調べてみたらRSS1.0らしいことが分かった。

BRで初期化時にRSSを更新すれば良いかもしれないと思った。思っただけだが。

RSSのファイルを見ていたらでかいミスが有ることに気付いた。流石にこのミスは恥ずかしすぎる。1ヵ月以上気付いていなかったよ。もう直した。

• RSS (Wikipedia)
• RDF Site Summary (RSS) 1.0