2008/12/31(水)来年の抱負

  1. 地図を処理しよう
    • maps.JPG
      このような有様でございます。
  2. バルクを処理しよう
    • セキュアがヤバイ
  3. バルク管理を完成させよう
    • 別に完成しなくてもいいんだけど区切りをつけたい
  4. 音楽ギアを集めよう
    • 心が折れそうです
    • せめてレアギアを一つでも...
何はともあれ、復帰早々にいい仲間達と出会えていいUO生活送ってます。
来年もよろしくお願いします。

2008/12/31(水)今更ながら

ツリーイベントが(とっくに)終わりました。
活動内容を振り返って見よう。

初日:
開始前に砂を 1000程掘る。
開始時点に居合わせる。ゴリゴリと錬金。ヒカリダケを300程寄付するも集まった中から700程をパクられる。
保安のため工場を別途作ろうか、という話になり、工場を提供しようかと声を上げるものの別の顔の広い方の土地を工場として使わせていただくことになる。現物を見て、そちらの方が広い上に専用の家なのでセキュアにも余裕があるので自分の土地にしなくてよかったと思う。

その後しばらく:
秘薬を誰にも知られず3000all程持ち出し&&1M分程自腹で買出し&&資金300,000程寄付。
ゴリゴリと錬金。GM達成。GM達成後は赤POT, 毒POT など足りないモノを重点的に作成。
春夫に相当数の秘薬、せっかく寄付していただいた現金を20,000 程パクられる。

さらにその後:
料理を始める。一気にかなり上がるもののまだスキルが足りないため、まわりが寿司や白ぶどうを作る中黙々とマフィンを焼く。
ガマンの角も狩るが、多分300本くらい。

もっとその後:
神秘ジェムが肥料になるということで音楽ギア集めと一石二鳥で狩りまくる。これも 1000個くらい。

さらにその後(ラスト1週間くらい?):
ギア(ジェム)狩りばかりで生産は不参加になる。狩りの帰りにジェムを納める生活が続き、気づいたらツリーイベントは終わっていた。

ASUKA は、途中で追い上げがあったりもしたものの、開始後の順位から大きく変わらない順位でゴールした模様。
ツリーの結果は、公園的なものを期待していたんだけどそうでもなく、豪華な木が立っているだけとなっている。

ASUKA は、UOに入り浸っている人は多くとも、イベントがあっても参加せずに普段どおりの生活を送る人がほとんど。いいとも悪いとも思わないが、寂しいな、とは正直思った。
後、他サーバの見学にも行ったけど、Kitty Guy は ASUKA が極端に多いという衝撃の事実。他サーバは現場テントも盛り上がっていたが、ASUKA じゃ考えられない点も寂しかった。

いろんな人と会ったものの、歳のせいか人の名前をよく覚えてないという寂しさよ。

2008/12/28(日)JavaScript

バルク管理CGI は一応、まだ放り投げてはいません。作業してないですが。

JavaScript を使った一括入力版を FreeBSD 7.1-PRERELEASE 上の Mozilla Firefox 3.0.5 で試してみた際の話。

JavaScript の変数オブジェクトの管理って、ハッシュで保持とかではないようだ。DOM ツリーなのはそれとして、階層ごとにハッシュで管理、でもないっぽい。アクセスがあると該当する階層のオブジェクトを頭から舐めてる感じ。
オブジェクトをズラッと並べてアクセスしてみると、後ろにあるオブジェクト程反応が重い。単純な線形アクセスとも思えない程、ほんの数個後ろのオブジェクトにアクセスするだけでパフォーマンスがどんどん落ちる。CPU 使用率が余裕で 100% 行く。

バルクを少なくとも素材別くらいの単位で分けて、その全種目を一つのフォームで入力したいんだけど、それすら無理っぽいかな。

一括入力は細かい分類毎を標準にして、ホントに全部のバルクを一括で入れるのは無し、もしくは別ページで注意書き付きになるかな。
「鬼のような性能のPCを使ってる人だけが使用してください。」と。
試したマシンは Phenom X4 9350e で mem 4GB なんだけどな。

ほんとはサーバ、クライアント間を流れるデータ量の増加の方が気になってたけど、この JavaScript 程の問題にはならんわな。
Windows 版でも同じだろうけど、一応 Windows 上で Firefox, IE7 でも試してみる。

ウェブからリファレンス読んだりしてただけだけど、JavaScript の参考書を読んでおいた方がいいかも。普通に考えてこのパフォーマンスは無しなので、なんかあるはず。...ないかも。

2008/12/24(水)ボス沸き

ボス沸きなんぞをやってます。

包帯戦士に耐えられるのはネズミくらいかな。
アンデッド沸きは序盤からきつい。

あんじは動く沼タイルをゲッツしてご満悦のご様子。

俺はゴミみたいなスキルプラススクロールがばしばし沸く。うれしいようでいて実際はゴミ。

と、散歩中に 18x18 の空き地を発見して別荘に決定。
外装もまだハンパで内装は皆無な状態。

そんなここ数日でしたとさ。

クリスマスって年賀状の締め切り日のことだよな。

2008/12/22(月)大丈夫か

EA のプログラマに不安がいっぱいです。
以下、愚痴を不愉快に思う人は読まないでね。


KR
KR で見た地図なんですが、拡大、縮小すると表示がバグります。
DeviceContext や DIB の扱い方として、ゲームプログラマならさくっと書けないとおかしくね?っていうコードなはず。

生産ウィンドウの「もう既にパスタになってしょうがないので状態遷移ぶち切っちゃいます」的な動きが気になる。あと、クリックされた座標の扱いもおかしい。

非矩形オブジェクトのイベント受信がおかしい。表示に使うのとイベント受信に使うマスクデータに同じもの使ってないの?

2D クライアントで家建築の時に建設予定のスケルトンが表示される位置がずれるのって、フィールド画面じゃなくゲーム全体のウィンドウの座標を使っちゃってるから、というのが動きから推測できるんだけど修正されてない。原因がわからないということはありえないので、修正できない程パスタなのか。

同じものが原因と考えられるものとして、KR でクラシックコンテナ表示した時に、アイテムがドロップした場所に落ちないっていうのもある。座標変換が2回かかってるとか、ユーザーインタフェースサイズの変更を考慮せずにマジックナンバーで突っ込んでるとかしてないか?

上記の点はまぁ、ブリ王に惹かれて UO を作っていた人がいなくなったり、OSI 解散したりで人材不足なんだろう。(いつからの話だ、っていうか頭数の問題じゃねぇし)

問題は今日の Five on Friday ですよ。
「4. 2Dクライアントでプレイしているのですが、設定ファイルはどこにいってしまったのでしょうか?
<略>
セーブデータが、Microsoft準拠の場所に保存されるようになったのです。」

ダウトです。

MSDN の 「Windows ロゴプログラム "Designed for Microsoft Windows XP" アプリケーション仕様」 のセクション1:ロゴの要件
の 3項に、
  • 3.1 ユーザーが作成したデータの保存先は、デフォルトで「マイ ドキュメント」に設定すること
  • 3.2 アプリケーション データを正しく分類し、保存すること
とあり、3.2項にはユーザーが直接作成、操作することを意図しない、アプリケーションが生成するデータは以下の場所に置くように、とある。
  • 共通アプリケーションフォルダ (CSIDL_COMMON_APPDATA で識別) のサブフォルダ、または
  • ユーザー プロファイル フォルダには、アプリケーション データ (CSIDL_APPDATA) またはローカル アプリケーション データ (CSIDL_LOCAL_APPDATA) を保存する。
えーと、要するにマイクロソフトは今回のような、"プログラム自身の動作のために生成した設定ファイルをマイドキュメント以下に置く" という実装を推奨するようなガイドラインは示してない。
何に準拠したんだ。夢の中の神のお告げにでも準拠したか。

プログラミング云々の話じゃねぇ。技術分野では一次情報を追わないヤツは業界に居続ける資格はない。お前に食わせるタンメンはねぇ。



なんでこの点が気になったかっていうと、数日前にマイドキュメントをファイルサーバ上に移動させたんです。
  • ユーザープロファイルが置かれたディレクトリはローカルにあるからマイドキュメントは移動しても大丈夫。
  • 実際、マイドキュメントの場所を変えることは Windows の機能として用意されている。
  • 俺が意図しない操作でマイドキュメント以下のファイルが操作されることはない
という前提でいて問題ないはずなのに、その前提を崩されると困る。
ネットワークがおかしくなったり、裏で Samba をアップデートしてリスタートをすると困ったことが起きちゃう可能性がある。

ていうか、うちのファイルサーバ時々止まるんでマジ困る...。