calendar_viewer 日記/2007-02

new<< 2007-2; >>old [日記]
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28

2007/2/28 (水)

いろいろ突っ込みどころがある、今回のパッチですが。
ともあれ、万一のアカウントハック対策のために、キャラ枠埋め実施。
・・・と、いうような話をゲーム内でしたら「？」という反応の人もいたので、念のためこっちでも。

現状、アカウントハックは以下の２段階のパスワードで守られています。

ログインアカウント名＆パスワード
キャラクターごとのテンキー的パスワード

で、ここでポイントになるのが、上記のうちの後者。
これ、キャラクターが作られていない枠では当然未設定になります。

つまり、最悪のストーリーとしてこういうことが起こりうるのです。

最初のログインアカウント名＆パスワードが、何らかの手段で漏洩。
（最近よく話題になっている、ウィルス類などが原因）
→上記でログインされて、空いている枠に「アカハック者が」新キャラ作成。
→そのキャラクターで倉庫を開いて、倉庫内のアイテムを・・・

以上から、実際にそのキャラを育てる気がなくても、キャラ作成＆キャラごとパスコード設定まではやっておくことがお勧め。

つーわけで、友瀬も新キャラ枠は埋めました。
いろいろ夢もあるけれど、現実問題としてそんなに育てる余裕もないので・・・とりあえず、2ndアカウントに戦闘BS候補だけ作って、あとは育てないでいることになりそう。

なぜ今更戦闘BSかというと・・・歌屋関連で。
歌屋の店主・Kittは、1stアカウントのキャラなんですが、定点に住み着いています。
で、結果的にですね。
1stアカウントキャラが、すごく使いづらいのです（＾＾；；
2ndアカウントにはもちろんアルケミのViceがいるのですが、アレはアレで「万力屋」の看板持ってますし、あのコが歌うってのも個人的にイメージが合わないので・・・
で、見た目おんなじなBSを1人欲しかった、と。
ですから、BS転職できるくらいまでは育てます。

ちなみにキャラ名は「Karr」。
わかるお年寄りは、わかってやってください（笑）

・・・ただ・・・これ日本人にはやっぱりあんまりなじみのないつづりなので、最近多い「適当な英文字羅列のBOT名」に見えそうなのが難点（＾＾；；

黙っていようかとも思ったのですが、やっぱり言わずにいられない。
何を考えているんですかね、ガンホー。

いえ、これでも一応最近のアクションは評価していたんです。
なにしろつい先日までは、「一般人のノービス」の育成が行われるようなマップがBOTに占領されていました。
それに対して、

2/6パッチでBOT大量締め出し
→初期育成向きマップでの弓BOT横殴り地獄解消
→キャラスロット増加

・・・スロット増加は今更・遅すぎだ、っていう点はともかく、流れ自体は間違ってないですよね。

・・・なんでこのタイミングで、BOT対策解除するんですかね、あんたは。

2007/2/25 (日)

キャラスロット拡張のからみか、またいくつか変わった話がでているようで。

複数のケミ＆ホム使用。†

要はケミ＆ホムごとに、挙動を変えたい、という類。
確かに例えば攻撃スキルの自動使用率について、「バニルなら、MDEFの高い相手にはスキルを使わない」「フィーリルならMDEFは関係ない」というような指定をしたい、というのは理解できます。

Glenelgでは、現状でもすでにホムの種類ごとに各設定を行えますし、敵ごとの対処もホム種類ごとに記録しています。
また共通設定（ai_option.ini）の内容も、望むならばホムごとに設定することができます：ai_optionで定義されている設定項目を各ホムごとの ai_option_xx.ini にコピーすれば、そのホムごと設定を優先するようになっています。
詳しくはリーフの設定ファイル（ai_option_01.ini）に例がありますので、興味があれば。ともあれ、ですから使っているホムが全て別の種類であるかぎりは、完全に独立して指定できます。

ただ、よく考えると同じ種類のホムでもレベルによって動きは変わるように思う。
で、さらによく考えると、ケミ本体のタイプ（戦闘前列ケミかINT後列か）でも変わってくる気がする。

ということでこのあたりも考慮した修整を考えています。

↑

AIを置く場所。†

これはいろんなAIを試してみたい、という気持ちからなのかな。

Glenelgでは、AIを置く場所は

<RO>/AI/USER_AI/

に限定しています。
なぜそうしているかの理由は、簡単です。

<RO>/AI/

ここは、クライアントの自動更新の際に公式パッチによっていつでも上書きされる可能性があるからです。
現実的には書き換えられたことはないようですが、リスクはいつでもありますし。

とはいえ、可搬性があるのはいいことだと思います。
優先度は低いですが、/AIにおけるようにも対応したいと思います。
個人的には/AI/USER_AI をいくつかコピー作成して、必要に応じてリネームすれば十分だと思いますが。

↑

各種ツール類。†

設定ツールや情報表示ツールの類。
これも何度かの発言になりますが、Glenelg＆友瀬は、自分からこういったツール類を公開する予定はありません。
これも何度も言っていますが「ツール使用だ」という難癖をつけられるのがばかばかしいので。

情報表示にしても、Glenelgで表示しているのは「AI独自の状態」のみであり、他キャラの情報は「名前の代替であるID」以外は表示しません。
言ってみればこれは人間同士で
「あの敵は手をだすな！」「了解、あの敵には手をだしません！」
「あの敵にはスキル全力使用だ！」「了解、あの敵には全力使用します！」
「この人をパーティに追加しよう！」「了解、この人をパーティに追加します！」
「ストームガストがくるぞ！」「了解、ストームガスト対応動作を開始します！」
・・・というような発言をするのと同じレベルであり、規約上なんの問題もないと考えています。

2007/2/21 (水)

敵データをlua化した結果、しかしあんまり劇的な改善には至らなかったこと、
およびini関連以外の根本的なrequire速度問題もあることから、もっと別の対策を検討している。
少し前の日記でも書いた、段階的なAI機能強化処理というか、そういう感じ。

例えば、現状敵ごとの学習データは「すべての敵の情報を１つのファイル」に入れている。
が、これは周囲に敵が存在しなければ意識する必要はない。
また、敵がいたとしても不要な情報は不要：ROに存在する500種以上の敵のうち、一度に視界内に現れるのはせいぜい10種類といったところ。
その10種類のために、使いもしない490種以上の敵の分まで取り込むなんてのは無駄。
だから、「視界内に出現した敵限定で、敵情報ファイルを取り込む」ことができれば、格段に軽量化できる。

また別の例では。
体力が低下した際に、敵から逃げ回るような処理を持っている。
この処理用に逃亡位置を決める関数を準備している・・・が、元気に戦っている限りはこんなモジュールは不要。だからこれはそういう状況になるまでロードしないようにすれば、軽くできるケースは増える。
そんな風にしていけば、一度にロードするAIソースの量を減らすことはできる。

正直、何度もいうように、AI側でどうこうするのはばかばかしい内容ですが。

正統派・邪道という考え方をするならば、Glenelgの現状の対策は邪道もいいところ。
現状でrequireが重いのがわかっているのだから、正統派としては以下のような手を打つべきだろう。

論理・アルゴリズムを検討、洗練化・最適化する。
デバッグ用にしか使わないコードや、不要な変数を削除。
思い切って、あまり有効でない機能を削ってしまう。
もしくは複数の類似機能を統合してしまう。

どんなものでも、自分が困らないと対応意欲は湧かないものです。
今回のAIロードが遅い件にしても、同じ。
例えばAIのロードを多用しない人には、あまり関係ない話だと思います。
ゲーム開始時やマップ移動したときに、「ちょっと重いな～」と思う程度のはず。

友瀬はソロプレイヤー==テレポ狩りを多用する傾向があります。
つまり、テレポアウトの際に固まってしまう今回の初期ロード悪化には困ったので、いろいろ対処を考えています。
現状のGlenelgの分割ロード方式も、最善ではないもののテレポ狩りには次善の策だと思って作りこみました。

現状のGlenelgの動作をおおざっぱに言えば、
以前は「全体を一気に読んで1秒間完全に固まっていた」ところ、
今は「ちょっとずつ読んで、0.1秒ずつ20回止まっている」という感じのもの。
トータルでの「AI稼動開始までの時間」は、単純に全体を読むよりは確実に遅くなっていますが、その代わり、AIが稼動開始する前にもユーザー操作はできるようになっています。

テレポ狩りの際に期待されるのは「着地後、すばやく次の手を判断できる」ことだと思っています。
テレポアウト後フリーの敵が1体いたとして、それに攻撃を始めるのが１秒遅れても、多勢に影響はないです：それくらいの時間は、敵に接近するまでに消費してしまいます。
が、勝ち目のないMHに飛び込んでしまったとき、逃げはじめるのが1秒遅れたらそれは致命的です。
だから友瀬は、初期のホム性能は悪くても、即画面表示&ユーザー操作（==再テレポで逃亡）できるように、現状の手を選びました。

他にAIロードを多用するケースとしては、「安息→コールホムを行うことで、ディレイ削除を狙う」人。
この人には、現状のGlenelgはまったく向いていません。

また、今回の場合、PC環境による差があるのがとにかく大きい。
友瀬も、ネットカフェで（読み込み改善未対応の古い）Glenelgを動かしてみて、まったく初期ロードに困らなかったのに驚かされました。
最初に書いた通り、「人は自分が困らないとやる気にならない」ものです。
AI作者の環境で困らなければ対処する気はおきないでしょうし、もしやる気になっても検証はできません。
そういう話。

しつこく初期読み込みまわりの話。
いろいろ状況整理をした結果のメモ。

初回の人のメモから、再考察。†

RO内でのメモリ管理が変わったとみるのが妥当そうに思えてきた。

どういうことかというと・・・先日の初回限定の人の追加情報。
初回の人自身がコメントしている以下の内容：

コンパイル後25ｋb～45kbあたりにこれ以上削っても早くならないラインがありそう。

これが非常に鋭い気がする。

つまり例えば、AI用に初期状態で準備されているメモリ量が、30KB程度。
これ以上のサイズのものを読み込みしようとすると、内部的にメモリーを再確保するのでその時間が負荷。
・・・なんてことは、非常にありそうな気がする。
もちろん、あくまで推論の域はでませんが。

↑

AIスレでのAI比較記録から、再考察。†

なにかと悪者にされるfile io 系（iniファイル）だが、ことこの測定条件でのGlenelgについては、 io はあまり影響がないように思う。

というのは、この検証が「ダウンロード直後」のAIを使っていることに起因。
こちらの動作環境でのテストでは、Glenelgでのiniファイルのうち最大の負荷となっているのは敵ごとの学習ファイルであり、そしてそれは初期状態では存在していない。
そして更にいうと、着地・テレポのような高速処理をしている限り、おそらくGlenelgは簡易モードでしか動いていない：つまりrequireをつぎつぎやっている最中のはず。

↑

敵情報ファイルのlua 化。†

「io.read + AIプログラムでデータ解析」が「require + lua内での単純代入」より遅いのは事実なので、Glenelg でも学習ファイルをlua化してみた。
結果は、確かに多少軽くなった気はする。
が、やはり目に見える負荷は存在する：手動操作でlua読み込みするような指定を作って試してみたところ、一瞬の表示遅延がある。
参考までに学習ファイルは15KB。

2007/2/20 (火)

いい加減しつこいですが（笑）

起動速度に影響するデータとして、iniファイルの重さが言われています。
で、ちょっと試して見た結果、Glenelgの場合、敵ごとの学習情報ファイル：vs_enemy_xx.ini の負荷が大きいようです。
これをまっさらにして動かすとそれなりに高速化します。

ここでいう「それなり」というのは、昨日の日記にも書いた「２段階のラグっぽさ」のうちの後半。
Glenelgでの起動では「ホム出現直後」と「ホムが出現後一拍後」の2段階の重さが感じられるはずで、この後者については上記ファイルの重さが主要因ということです。

もともとこれは学習によって生成される、ユーザー編集は期待していないもの。
luaの自動生成式にしてもいいかもしれない。

で、あと気が付いた面白いこと。
ファイルの読み込みは重いのですが、書き出しには負荷がないのですね。
いえ、もともとこの学習状況ファイル、ユーザーによる命令がなされるたびに全部を書き直ししているものです。
もし読み込みと同じ負荷が書き込み時に発生していたら、命令操作するたびに一瞬のラグが起きるはずなのに、そんなことはないので。
実際、手動で読み取り指示できるように改造・操作をしたら、ほんの一瞬ラグるような動作をしています。

逆に、enemy以外のiniについては、手動読み取りさせてもまったく負荷を感じません。
もちろん、多少の負荷になっていることは否定しませんが、すべてのiniをとりやめるほどのことはないな、と思いました。

ちなみに、友瀬のテスト環境（==実戦環境）では、enemy.ini のサイズは約5KB、ai_option.ini は12KB。
サイズ的には軽いはずのenemy のほうが、実際には時間がかかっている。
これも昨日の日記に書いた「文字列マッチング」の影響と見るのが無難そう：enemy のほうはフォーマット自体が多少複雑なので。

2007/2/19 (月)

追記。
~~初回限定の人が、ソースのコンパイルまでやって再検証している様子。~~
初回限定の人のほうでも、AIスレ報告を元に、ソースコンパイル後の情報を付加して再整理している様子。
こちら。

で、これを見ていてふと思いついたこと。
もしかして、ini ファイル読み込みの際に用いている文字列マッチングに手間取ってる？
いや、考えてみたらiniファイル読み込み処理って「* = *」って文字列検索なんですよね。
こういう領域スキャンって、かなりリソースを食うのよ、常識的に。

試しに、ai_option.ini のコメント類をごっそり削ってみた・・・あ～。微妙に効いてる感じがする。
iniファイル読み込みが遅いってのは確かだけど、単純なリードの遅さというよりは、解析する必要がないコメント部分のアクセスが無駄に効いている可能性もあるかも。
気のせいかもしれんけど（笑）

ん～・・・ヘルプを失くすのは忍びないんだよね。
編集ミスとヘルプがないのとだと、ヘルプない方が危ないし。
やっぱり config系はlua化するかねぇ・・・あんまり気乗りしないんだけど。

どちらにしても、Glenelgの場合分割ロードしているので、iniファイルへのアクセス開始はそれなりに遅いタイミング：全体をロードしないと始まらないので、ロード後1秒以上あとにくるはず。
実際、現状のGlenelgだと「ロード直後」と「ロード後一拍後」の２箇所のタイミングでラグのピークがあるように感じる。
後者が ini ファイルアクセスのタイミングとして、前者の改善検討がまだ残ってることになる。
下記の「連続テレポ」にしても、使い方から考えるとiniファイルどうこう以前のタイミングでの話ではないか、と思うし。

・・・まあこっちは他のAI同様、トータルサイズ削減しかなさそうなので、苦しそうですが。

AIスレで、AI起動の重さについて調査された結果があった。
単純に「テレポを20回実施」した時間を測定したとのこと。単位は sec が正しいようだ。
成績順にソートしてみる。

19min　　ホムなし
19min　　デフォルトAI　　　　　　　　　　　　　　　4.94kb　3
19min　　幻塵AI 02/12 070212　　　　　　　　　14.8kb　7
19min　　どきどきAI 08/23 060823u　　　　　　31.5kb　1
20min　　初回限定AI 02/07 0.70207　　　　　 58.9kb　17
21min　　くまーAI 07/23 0.53a　　　　　　　　　 22.2kb　4
23min　　きのこAI 02/10 0.13a　　　　　　　　　24.5kb　7
24min　　玉蟲AI 02/10 2.269　　　　　　　　　　　912kb　27(include readme.htm)
26min　　Glenelg 02/14 0.48a　　　　　　　　　　 189kb　244
30min　　こっこAI 02/13 4.53　　　　　　　　　　 151kb　1
32min　　rhapsoAI 11/29 1.53　　　　　　　　　　286kb　42(ほむTALK同梱)
34min　　可能な限りAI 02/12 1.4h　　　　　　　59.3kb　4
39min　　工体AI私的修正版 02/06 103+15　 91.5kb　27

以前に説明した通りGlenelgでは初期起動ルーチンを大きく変更したのだが、それでも正直遅い部類に入るようだ。
20回テレポだから、20秒でできれば１テレポ１秒。
ホム抜きで19秒という実力から見て、 Glenelgでは7秒オーバーだから、テレポ１回ごとに0.35秒程度損をしている計算になる。

Glenelgは、現状起動直後は「ほとんど何もしていない」。
つまり重いのは「AIのアルゴリズム」ではなく「AIの読み込み」。
だが、以前の検証で「コメントはなんぼあっても読み込み速度に影響しない」ことはわかっている。
つまり、「AIの、意味のある部分の読取」に時間がかかっている。

・・・ここからは友瀬の経験的な部分だが。
直感的に、Global変数の初期化に時間がかかっているような気がしてきた。
このあたりをちょっといじるような調査をしていきたいと思う。

2007/2/18 (日)

拍手的な。対応。
すっかり私信・対談風になってますが（＾＾；

iniファイルのlua化関連。†

いろいろご指摘ありがとうございます。
引用すると長いので、こちらの理解で書いてしまうと要は

設定用のlua ファイルを例えば「config.lua」として準備する。
エラーチェックでconfig.luaのrequire失敗は無視して強行。
- これによって、config が適切に書かれていればエラーなし。
- config不良（読み込めないレベルの編集ミス）があれば、configでの定義がなされないだけ：設定変数類がnilなり他の場所での定義値になる。

・・・ってことですね。
確かにそれならば可能そうです。

この方式に問題があるとすれば、設定失敗時（編集ミス時）の再修整が困難になりそうな点、でしょうか。

現状のGlenelg（==iniファイル方式）では、iniファイルを1行ずつ解析するので、記述ミスがあればその行を無視するだけなので、１つミスをしても他の項目は有効。
そして「どの値がうまく行ってないのか」がわかるので、それをダイレクトに警告しています。

ですが上記lua方式では致命的な記載があると、configそのもののを読めないですから、そこにある設定全体が無効になります。
そして「何が悪いか」を限定するのが困難そうです：エラーコードに行数記述はありますけど、それを見せても「luaを知らない」人がそこから直せるかというと、怪しいかもしれません。

まあ、現状でもエラーチェックが完璧かというとそんなこともないですので、ごまかせる範囲ではありそう。

2007/2/16 (金)

件の「ゼロ移動キャンセル」関連。

新しい検証はなにも行えていないが、AIサイクルがずれる話絡みから言って、おそらくクライアント側だけでの論理的解釈は無理だろう。
また、どうもホムの種類やASPDなど、条件になりそうな項目が多すぎ、限られた範囲での情報収集でははっきりした結論にたどりつくのは難しそう。

そこで、逆に「どうすればいいか」を整理して、誰でも困らないように（カスタマイズできるように）しておけばいい。
現状の３つの機能（キャンセルしない/移動/ゼロ移動）について、関連情報ごとに整理するとこうなる。

	キャンセルなし	移動キャンセル	ゼロ移動キャンセル
通信系	○問題なし	×無駄パケット増	×無駄パケット増
攻撃速度	×激遅い	○加速 *1	○加速 *1
戦闘中回復	○回復する	×回復しない	○回復する

表内補足：　*1 ホムの種類などでどちらが良いかは不明

ここから考えて、こう実装しておけば誰の環境でもごまかしが聞くはず。

対応項目１：キャンセルするか否かのスイッチを１つ準備。
「無駄パケット出してもいいから高速化」or「遅くてもお行儀良く」のスイッチ。
対応項目２：回復不要時に移動キャンセルしていいか否か（and/orそのしきい値）。

これの組み合わせで、動作は固定できる。

		キャンセル許可
		する	しない
移動許可	する	ⅲ	ⅰ
	しない	ⅱ

一切キャンセル動作をしない。
遅いがお行儀がいい。
ゼロ移動キャンセルのみ。
消耗していなければ、移動キャンセル。
消耗していればゼロ移動キャンセルのみ。

可能な限りAI1.4hの時点では、モードB（ゼロ移動キャンセル）はモードC（移動キャンセル）よりも遅いという前提で、ホムの種類ごとにどう動くかを決めている。
だから、上記表でいうところのⅱよりはⅲのほうが「より高速になる」という前提で設計されている。
自動判断という視点ではこの方向は正しい：友瀬もそう実装しようと思っていたくらいですし。
だが昨日の調査の時点で、実はゼロ移動キャンセルのほうが速いケースというのが存在することがわかってきた：そしてそれが「どのホムだとどうなる」かがわかっていないところに大きな問題。
現状の友瀬の環境では、99レベル進化原種バニルは上記表内パターンⅲ、33レベル未進化原種リーフはパターンⅱでよさそう。
だが、99レベルの未進化リーフはパターンⅱでいいのか？、というのは友瀬にはわからない。

・・・ということで、Glenelgではこんな感じのカスタマイズ項目でも作ろうかと思います。
現状すでに「移動許可条件」はつけているので、あとは単純に「キャンセル行為を認めるか否か」を追加すればいいか。

自動判定については、当面は考慮なし。
ホムタイプだけに依存すると断言できる状況でもないし、そのための情報が有志で集まるのはかなり大変：亜種・進化をあわせて16種類＊ある程度のホムレベルでのサンプリングとしなければならない。
両方を試してみて平均戦闘時間を計って云々・・・という自動予測は、それこそその「測定」の間に不自由するし、誤判定でもしたら目もあてられないので。

拍手的な。対応。

初期化をiniファイルにしなくても、LUAでエラーチェックで引っかければ？†

できないことはないと思いますが、あまりに余計な労力に感じられるので、あまりやる気はないです。

単純な異常値入力だけなら、問題ありません。一番懸念するのは、全角文字列などを記載されたり、等号記載だけで改行してしまったりと、「そもそもAIとして動作しない」状態になされてしまうケース。
この状態でも「どのソースのどの行でエラーがでたら、どこがおかしい」というようなチェックルーチンを作れば確かに対処可能かもしれませんが、それにしても余計な改行をいれられたりすると厄介です。
完全な比較対象バックアップでも持ってやればできると思いますが、あまりに「ホムのAIとしては本筋外」のところだと思っています。
商用などでがっちりやらなければならないならともかく。

↑

移動キャンセルってバグ利用じゃないの？†

まず「バグとはなんぞや？」という話でいうと、移動キャンセルはバグではありません。
誤解がないようにいうと、移動キャンセルが仕様だともいいません。
本来「仕様」という言葉は

「～～となるように作っています。」
「意図はしていませんでしたが結果的に～～となってます。そしてそれで問題ないです。」

というような開発者の明確な意思表示の元に存在するものです。
そして「バグ」という言葉は、

「仕様は～～。ですから～～は仕様とは異なった動作です。」

というような開発者の明確な意思表示の元に存在するものです。

賢明な諸氏ならご理解いただけると思いますが、移動キャンセルについては「現時点では」開発元からの明確な意見はないので、「現時点では」仕様でもバグでもない、ただそうなっているものです。

とはいえ友瀬は、移動キャンセルは「結果的にできている」たぐいのもので、そしておそらくは「そして問題がある」ものだと思っています。
そういう意味で、友瀬はこの対応については、「限りなくバグ利用に近い行為ではある」と思っています。
だからこそ友瀬は、（Attack多重化も含めて）高速化はデフォルトではOffにしています。
利用する人は意図してお行儀を悪くしている、ということです。

念のために言っておきますが、友瀬は「テスト以外で」これらのオプションを有効にはしていません。
例えばAttack多重化などは、実装当初の1月くらいは使っていましたが、その後はずっとOffです。
移動キャンセルも、実装直後の現時点ではともかく、しばらくしたらたぶんOffにすると思います。

↑

同じバグ利用のSBR44連射対応はしなかったのに、なぜ移動キャンセルは対応するの？†

「同じバグ利用」であるかどうかには大いに疑問がありますが・・・ともあれ、確かにどちらも「できるとは書かれていないが、確かにできる」ものという視点では同じです。
これについては、完全に「友瀬の俺ルール」ではありますが、きちんとした理由があります。
おおざっぱにいうと

SBR44対応は「きちんと青信号が出る信号で、赤信号を渡っている」ようなもの。
移動キャンセルは「赤信号が出っ放しで青になってくれないので、仕方なく渡っている」ようなもの。

・・・という感じでしょうか。
どちらも赤信号を渡っているのですから、お勧めはできません。
ただ、後者は「友瀬が取り締まる立場なら」お目こぼしの余地がある、というだけです。
繰り返しますが、完全に「俺ルール」です。

友瀬はSBR44の外部仕様を見て、以下のように考えました。
「SBR44は、本来ある程度の好感度を消費するものと読める。
　だから好感度消費なしで連射できるのはおかしい。」
この状況で、使い手は「好感度が足りているときのみ（手動で）SBR44を使う」という、適切な操作は可能でした。
だからAIから積極的なSBR44は採用しませんでした。

移動キャンセルは、ASPDの外部仕様を見て、以下のように考えました。
「現状の攻撃速度は、明らかにASPDを（遅くなる方向で）守っていない。」
つまりこの状況は、「ホムが本来できるはずのことができていない」というものになっています。
そこで仕方なく、強引に「高速化」する手法を選べるようにしました。現状ではASPD以上の速度になってしまっている、というのも理解はしています。
が、残念ながらホムから「適切な速度に調節」という方法がないので、妥協しています。

繰り返しますが、あくまで「俺ルール」です。

↑

BOT対策が来た、って判断は早計では？†

ちと今更ですが、2/7の日記へのつっこみでした（＾＾；
一応、2/6に確かにBOT対策はなされていたようです。
でも、現時点でかなり突破されてしまっているようですね・・・残念。

2007/2/15 (木)

すっかり検証するのを忘れていたことがあったので、ちと試してみて、よくわからなくなった。
とりあえず、公開メモという感じで。

話題：ゼロ移動キャンセル。†

可能な限りAIで提案されている、攻撃高速化の一手法。
プログラムのつくり自体は、すでにある程度確立されている「移動キャンセル」と同じ。
違いは、ホムの移動先指定。
普通の移動キャンセルは、実際にホムを1セル程度歩かせる位置を指定するのに対して「ゼロ移動キャンセル」は文字通りゼロ距離：ホムのいる位置そのものを指定する。

追記：
可能な限りAIの作者・horoさんの解説では

移動しないキャンセル（ゼロ移動キャンセル）を「Bモード」動作
移動するキャンセル（1セル移動キャンセル）を「Cモード」動作

・・・と呼んでいます。
ゼロ移動ってのは友瀬の造語なので、誤解なきよう。

↑

効果のほどは？†

確かに、ゼロ移動キャンセルでも攻撃は高速化されている。
ただ、友瀬が使っている99レベル原種進化バニルでは、通常の移動キャンセルと比べると確かに遅いように感じる。

↑

もう少し具体的に調べて、困った。†

上記の「感じる」というのが非常に主観的なので、もっと具体的な手が使えないか考えて、Attack()を呼び出したタイミングを記録してみることにした。
と、その結果がよくわからないことになってきた。
試行回数はそれぞれ２，３回程度の平均なのでばらつきはあるかもしれない。

99進化バニル	通常なし	１セル移動	ゼロ移動
草を倒す所要時間	5秒台	4秒台	5秒台
AIサイクル	18回前後	15回前後	10回前後

33未進化リーフ	通常なし	１セル移動	ゼロ移動
草を倒す所要時間	7秒台	7秒台	6秒台
AIサイクル	20回前後	30回前後	10回前後

確かに、ゼロ移動キャンセルには一定の効果はある。
上記バニルのケースでは「キャンセルなし」も「ゼロ移動」も5秒台となっているが、厳密にいうとゼロ移動のほうが速いのは確か。
通常キャンセルとゼロ移動キャンセル、どちらが効果的かはよくわからない。
少なくとも上記を見る限り、進化原種バニルでは移動キャンセルのほうが速いが、未進化原種リーフではゼロ移動キャンセルのほうが速い。
どちらのケースにしても、移動キャンセル/ゼロ移動キャンセルを絡めるとAIサイクルの挙動が怪しい。
特にゼロ移動時のサイクル数の少なさは、かなり異常と言っていいだろう。
草のHPは10なので、10回攻撃が必要：つまりゼロ移動キャンセルをした場合、Attack()するたびに実際に攻撃が出ている、といっても過言ではないペースまで、AI動作が減速されているといえる。
移動キャンセル時の見た目について補足：
進化バニルでは、攻撃回数のほうが移動回数よりも多い：「攻撃・攻撃・移動」になることがある。
未進化リーフでは、攻撃よりも移動回数のほうが多い：「移動・移動・攻撃」になることがある。
- そういう意味では、リーフのほうが移動キャンセル時に遅いのはなんとなく理解できる。
  移動キャンセルによるメリットよりも、移動モーションによる無駄のほうが大きいのでは。

どのケースもソース・プリント出力タイミングなどは変えていないので、プリント出力によるディレイ差という問題ではなさそう。
まあいずれにせよ、まだまだ検証は必要な段階。

2007/2/14 (水)

一応定点露店をしている身、こういうイベントではそれなりに甘いものも並べたい。
が・・・
「本来14日に並べないと意味のないものを、
　13日のパッチで実装しないでおくれよ（＾＾；」

まあ、今回の実装内容は、友瀬的には合格点をあげます。
クエストはそれなりに面倒でしたが、所持キャラのうち1人でもクリアすれば他のキャラでも作れるというのは、今までのこの手のイベントにはない快挙といっていい。
チョコを買うキャラのお財布が苦しいんですが（＾＾；；；

・・・そうか、３アカ目のネタ名商人を起こさないと（笑）

問題の火急度が高いので、臨時でのパッチを作成しました。
こちら。

臨時パッチforVer0.48

ええと、ごめんなさい、さすがに勤務先なのでテストしてません。
多分問題ないと思いますが、念のためバックアップを取った上で適用してください。
上記パッチでは怖い、という方は、動作確認＆正式版リリースを今夜実施予定なので、そちらをお待ちください。
提供物件は「actor.lua というファイル」そのものです：Ver0.48にある同ファイルを上書きしてください。

変更点
- 掲示板で指摘された、「第三者が近くにいる際のアクティブ策敵範囲」の不良動作を修整。
  Ver0.46での策敵周りの全面見直しの際の修整漏れです。

2007/2/12 (月)

さらにいろいろ考えてみたのを、整理をかねてメモ。

カスタマイズレベルでの実施条件（HP/SPリミット）は、今まで通り残す。
上記１に加え、既存の「敵ごとの優先度」を「その敵に対してDanceMacabre要否」に重複利用する。
- 優先度7～9は強敵なので、HP/SP状態に関係なく全力戦闘（DanceMacabre許可）
- 優先度1～3はどうでもいい敵なので、HP/SP状態に関係なくゆっくり対処（DanceMacabre不許可）
- 優先度4～6は、カスタマイズ設定値に準ずる。
更に、緊急時向けの「強制的にDanceMacabre実施」操作を作る。
これは前述１、２よりも更に高いレベルの指定として扱う。
これにより、HP/SPで手加減している状態でも無理矢理DanceMacabreさせる。

・・・こんな感じで。

昨日の日記で考えていた「敵ごとに移動キャンセルするか否か設定」。
悩んだ結果、当面は対応しないことにしました。

理由は技術的なことではなく、感情的なこと：先にも書いた「これが本来不要な機能」というのが大きい。

技術的に可能なのは、現状のGlenelgでも多彩な対応をしているのでご理解いただけるかと。
ですが、それを組み込むにはそれなりの労力もかかりますし、ユーザーの操作負担も増えます。
あんまり力を入れて、でもまた仕様変更（元に戻すor適切なASPD対応）された結果労力が無駄になる可能性がそれなりにありそうなので、様子見、という感じです。

まあそれでも不自由はあるように思うので・・・
１操作で強制的に「移動キャンセル実施」「禁止」を指示できるような仕組みは作ります。
今日はお昼から外出してしまうのですが・・・できれば今日中にお試し版はだします。

2007/2/11 (日)

高速攻撃対応の件。

ver0.47 で対応はしましたが、実際に使ってみるといくつか気になることが見つかってきています。

弓系の敵が絡むと、おかしいことがある。
長距離射程とステップ移動位置との兼ね合い。
SP設定による制限が存外厳しい。
敵多数に囲まれる
→カプリス使用率増加
→SP枯渇
→SPリミットに引っかかり移動キャンセル動かなくなる
→殲滅力かえって低下・・・という悪循環的コンボで、イマイチな感じに。
わざわざステップするまでもない敵・状況では、移動しないで回復して欲しい気がする。
アルデバラン地下廃屋なら、ドレインリアー1匹相手くらいならステップしないで回復したい。

DanceMacabre使用について「敵ごと設定」「（ブースト系スキルのような）状況による使用要否判断」といったものを組み込むべきかもしれません。
ちょっと考えてみます。

2007/2/9 (金)

別の言い方をすると。

今回追加した「ロード高速化」や「移動キャンセル」は、ROの07/02/06パッチクライアントに対応するため「だけ」のもの。
つまり「ホムの論理的な思考・行動」のためのものじゃないんです。
クライアントが変わったら、意味がなくなってしまうもの。

そういうのが、嫌なわけです。

まったくどーでもいい話ですが、今回の「攻撃モーション移動キャンセル」。
その結果生まれる怪しい挙動を、あちこちの人がいろいろな表現をしているのが面白かったです。

　　.　 　 　 　 　_, ,_　ﾊﾟｰﾝ
　　ﾊﾟｰﾝ_, ,_　（　ﾟдﾟ ） _, ,_ﾊﾟｰﾝ
　　　（　‘д‘）　Ｕ☆ミ　（･д･ ）
　　　　　⊂彡☆))Д´(☆ミ⊃
　　. ﾊﾟｰﾝ, ,∩彡>> ミ∩,ﾊﾟｰﾝ
　　. 　 （ 　　） ｳﾜｧｧｧﾝ!!（ 　　)
　　ぐるぐるぐるぐるぐるぐるぐる

とか、

　∧＿∧ 
　(　･ω･)＝つ≡つ 
　(っ　≡つ＝つ 
　/　　　) ﾊﾞﾊﾞﾊﾞﾊﾞ 
　( /￣∪

とか、

「ボコボコにしてやんよ」
なにこの赤きサイクロンｗ　全てを巻き込み粉砕したくなるから困るｗ
アラバマの黄色いサイクロンきたこれ
「見た目」的には逆に超避けまくってヤンマーニって感じだZE！

とか。

いささかブームに乗り遅れた気もしますが、友瀬&Glenelgではこいつは
「Dance Macabre（死の舞踏）」
って命名にて。

つーわけで、2時間ほど過ぎた26:00相当ですが（笑）
件の2007.Feb.06の「ホム周りいろいろアレなパッチ」への対応を行いました。
正直「こんな対応やりたくない」系の変更がたくさんあるのですが、それをしないとホムとしてはかなり苦しいので、泣く泣く対応したもの、とご理解ください。

なぜ「やりたくない」といっているかというと・・・これ、AIとしては本来気にする必要がないところばかりだと思っているから。

例えば、ロード時間なんてのはプラットホームが意識すべき話で・・・例えばホム無しならロード時間中は「暗転・進捗表示バー」が出てますよね。なんで同じようなコトを「AIのロード中に」ついてやってくれないのでしょうかね。

攻撃モーションキャンセルに至っては、もっと深刻です。
以前の攻撃速度が異常だったのは否定しません。
だから、攻撃速度を「ホムの本来のASPD相当まで」落とすというのであれば、友瀬は何の反対もしませんし、たぶん「移動キャンセル」も実装しませんでした。
なんで、こんな両極端なんですかね。

・・・と、これが正論なのには絶対の自信がありますが、問題はガンホーの腰の重さ。
ガンホーがどう思うか、直すかどうかなんてのはわかりませんが、どっちにしてもその結論を待っているだけで何ヶ月かかるかわかりませんし。

・・・アレな機械も戻ってきてるしなぁ・・・
ほんと、なんとかして欲しいものです。

2007/2/8 (木)

追確認実施。

無意味に長いコメントをつけたファイルを作成。
→ロード時間変わらず。
つまり、コメントをケチる必要はなし。
参考までに、コメント量は2000KBをつけていたが、変わらず。
全てのソースを１つにくっつけた、巨大AIソースを作って、require回数をなしに。
→やっぱり召喚直後は重い。
つまり、ソースを無理矢理１つに固める意味はあんまりない。
参考までに、Glenelgの全ソースを固めたものは約300KBだった。
使わないiniファイルを取り除いて、テスト。
→体感できる差は感じず。
こちらの意味でも、ファイルを複数に分けても特にデメリットはなし。
本来読み込むべき ai_option.ini を撤去。デフォルト値で動作するように。
→多少起動時の重さが増加。
やはりファイルアクセスが遅くなっていると見るのが無難か。

前にも言いましたが、Glenelgでカスタマイズ用にiniファイルを利用しているのは、比較的素人の人に備えてです。
luaソースを編集して、もし予想外の値を書き込まれてしまった場合、AIが再起動しなくなってしまいます。
iniファイルなら、読み込み側でどうにでもなるので。
ただ・・・現Glenelgのiniファイルは、解説テキストが異常に多いので、その分重いのは間違いない。
そこを改善しますかね。

・・・と、ここまで書いて。
友瀬はこれから、イベント対策でいろいろとやらなければなりません。
AIは、ちと後回し。

Glenelgで攻撃速度改善を渋っているのは、時間が取れていないという点もさることながら、その対応が大量のMove()を吐き出してしまう、という点への懸念もあります。
もし将来その対応をGlenelgにいれたとしても、それはあくまでオプションレベルにするつもりです。

つーか・・・みんな結局利己主義ってことなんだよね。
いや、利己主義は友瀬もそうだから否定しないけどさ。

昔AI開発がはじまった当初、
「標準AIは追従移動が遅い」
→「標準AIは追従セルに到達してから、再度移動するから遅い。
　　移動中にも随時Move()をすればだいじょぶだよ」
→「それすると大量の移動パケットを出すのがお行儀悪い」
・・・って議論があって、各AI、それを出さないように改善したはず。

より負荷が高いはずの戦闘中に、そして本来はしなくていい移動をしてまで、上記を覆すってのはどういうことかね、って。
多重Attackもそうだけどさ。

正確にいうと、結果として遅く見えているのが require 全体での処理。
どの部分が遅いのかは、現状判っていない。
つーかさすがに朝30分の調査だけじゃ、無理ですってば（＾＾；；

可能性はいろいろある：
ファイル検索に時間がかかるようになったのかもしれない。
requireの際、読み取っているファイル内容そのものをチェックしているのかもしれない。
読み込んだソースにあるGrobal変数の初期化：RO内のメモリ管理の方法が変わったのかもしれない。

とにかくいろんな意味で、調査は必要。

とりあえずやらなきゃならんと思っているのは、以下のことかな。

コメント量による依存度確認。
現状のソースに大量の無駄コメントを追加して、ロード性能が落ちるかどうか見てみる。
AIフォルダでのファイル数。
各種*.iniファイルは別フォルダに移動。検索に時間がかかっているなら、多少なりとも速くなるはず。
逆に大量の無駄ファイル作成。検索に時間がかかっているなら、多少なりとも遅くなるはず。

どちらのケースにしても、iniファイルや地図情報に関しても同じ話があるはず。
可能な部分は多少なりとも速いrequireに差し替えないとならなんかな。

・・・メモリの話だったら、結構きついなぁ。
AIの作りではいかんともしがたい。

とりあえず明確に判ったこと。
AIの初期ロードの重さは、やはりソースをROに読み込む速度自体に問題がありそうだということがわかった。
iniファイルとか地図情報とか、ロードとAI動作が同時におきるとか、そういう点ももちろん影響はすると思うが、それ以前の根本的なrequireの総合的な速度の低下が起きていると見るのが妥当そう。

何を試したかというと・・・２つ。

前提：Glenelgはいくつかのソースリストを持っており、従来はその全てのソースリストを「AImain() がロードされたとき」に連鎖的・一気にrequireしていた。この場合、ホム召喚直後は敵描画すら滞ってしまう。起動直後はホムとケミしか見えないが、一拍おいて敵が表示されるような感じ。
そこで以下のようなことを試してみた。

最初、ホム召喚後の数AIサイクルは、本当になにもせずにAI離脱するようなソースを導入した。
→それでも初期起動時に固まる。
→AI()部分はほとんど何もしていないのだから、GlenelgのAIの作り的・アルゴリズム的な初期化プロセスの複雑さ・重さ以前に、なにか重いことが起きている。
→考えられるのはrequireしかない。
初期ロード方法変更：「AIサイクルがくるたびに、少しずつrequire」するようにしてみたところ、ロード時は多少ラグっぽくはなるが十分ケミが活動できるような感じになった。
requireタイミング以外なにも変更がないのに重さが変わるという時点で、AI挙動の複雑さ以前にrequireが重くなっている、ということ。

つまり、単純にAIソースの総合的大きさが大きいだけで、初期動作が重くなるということ。

分割requireをすることで、現状よりは多少ましになる、ということは事実だが、もちろん、上記はあくまでテスト。
現状のGlenelgにただ単にこのような初期化方法を適用するだけでは、ホム召喚後数瞬はホムは一切駆動しないため実用品ではない。
故に、現状そのままそれを正式版としてリリースはしない。
だが、現状は結構深刻だと思うので、一応ここにテストパッチは置いておく。
興味がある方は上書きしてみてほしい。
(テスト用パッチfor0.46：AImain.lua ソースそのものなので、上書きすること。)

ともあれ、そういう意味での改善の道は見えた：初期ロードではとりあえず追従動作とゼロ距離反撃程度の最低限の仕組み部分だけをrequireして動作させ、他のモジュールのrequireが完了したら完全動作するように切り替えればいい。
これによって、初期活動はそれなりに軽量で、完全にrequireできたら高機能、というような動きが可能なはず。

逆にいうと、上記のような考えで行くならば、「機能を削ってでもシンプル・小型ソース」ではなく、「全体としては複雑でも、段階ロード・動作できる高機能」というような道もありそう。
まあここまでくると、かなり夢物語っぽいですが。

2007/2/7 (水)

もう一度、数日前の可能な限りAIからみの検証を絡めて整理すると、だ。
こう考えるのがよさそうだ。

ホムの攻撃は、大きく考えると以下のような動きになっていると思われる。
前の解説同様、縦点線がAIサイクル。

用語確認。
上記でいう「攻撃画像」とは、クライアント上でユーザーが見ることができる、ホムの攻撃アニメ全体のこと。
「攻撃一周期」とは、ホムが攻撃～ディレイで次の攻撃ができるようになるまでの、実質的な「１回の攻撃」全体のこと。

以前は、攻撃画像と攻撃一周期とでは、攻撃周期のほうが優先されていた。
そのため、標準AIでも攻撃一周期が終わった次のAIサイクル（上記図の左から４本目の縦点線）で、攻撃画像をキャンセル（モーションキャンセル）して、次の攻撃が行えていた。
今回のパッチで、その優先度が入れ替わってしまった：攻撃一周期が終わっても、まだ攻撃画像が残っているならば、次のAttack()が認められない。
その結果、標準AIで攻撃できるのは攻撃画像が終わった次のAIサイクル（上図の一番右の点線）になる。
- この攻撃画像部分は、Move()を使うことで削ることができそう（移動キャンセル）。
  ただし、キャンセル可能なのはあくまで攻撃一周期が終わったあとではないかと思われる：上記図なら左から４本目のタイミングでMove()をするのが最速だと思われる。このタイミングで削れたあと、次の５本目タイミングで攻撃できるはず。

上記赤線の「AIサイクルの壁」を乗り越えるには、多重Attack()による攻撃予約が必要になる。
もしかしたらMove()もこれににた予約的入力==移動キャンセルができるかも。

・・・省みるに。
今まで友瀬がまとめていたページでは、多重Attack()でモーションキャンセル云々という記載があるが、それはまとめて見直さなければならないね。
多重Attack()でできるのは、単にAttack()の予約的動作だけと思われる：何しろ標準AIでも（遅いとはいえ）モーションキャンセルはできていた、というわけだから。
その結果、モーションキャンセルが引き起こされるだけに過ぎない。

・・・とまあ、いろいろ検証してるけどさ。
これって本来は、RO開発側でいろいろつぶしておけば、こっちでは気にする必要がないところなんだけどなぁ（＾＾；

よくよく考えてみると、Attack多重送信はモーションキャンセルとは関係ない可能性があったんだね・・・
すまん、ちと先走ったかもしれん。

正直、思い込み＆自分は使ってないから試してなかったんだけどさ（＾＾；；
そのあたりも含めて検証が必要か。

どうも「ホムが重い」というような話が出ていて、言葉と現象が混乱を呼んでいるようなので、整理すると。

１．ホム攻撃速度低下。
文字通り、攻撃速度が遅くなる。

従来（標準AIレベルでも起きていた）毎AIサイクルでのAttack()によって行われていたモーションキャンセルが、できなくなった様子。
影響のあるAIは、すべて。
AIの作りには関係がない。

対策手段として、一応、攻撃モーションをmove()でキャンセルすることはできる。
現時点では、こっこAIで試験的に導入という感じ。
Glenelgでは当面様子見。

２．ホムロード時間増大。
文字通り、ロード時間が遅くなる。
ロードするたびにロスが発生するということで、「テレポ狩り」や「安息・コールホム多用」といったプレイヤーには被害大。
逆に一度ロードしたあとの動作は、今までと変わらず。

友瀬の見る限り、不正ツール対策のファイルチェックが動いているっぽい。
つまり、AIのファイル数が多いほど、ファイルサイズが大きいほど、チェック時間がかかって遅くなるはず。
ただし詳細は未検証。
上記推論が正しければ、当然そういうAIほどダメージはでかいと思われる：Glenelgは正直苦戦するのでは。

対処手段は、とにかくひたすらファイルサイズ・ファイル数削減しかなさそう。
だがこれのために機能や可読性を落とすのは間違っている方向だと思うので、Glenelgでは当面様子見。

３．ホム不安定？
しばしば接続切断されるらしい。
友瀬は未経験。

未経験なので詳細は不明だが、多重Attack()処理がきいているのではないか、と推測される。

ともあれ、こっちは情報待ち。
自分で起きていないので、わざわざ調べる気はあまりない。

どうやら今回のパッチで、いわゆるBOT対策が入ったようで。
2/7朝時点で、Geffen近郊で見られていたBOT群がまったく見当たりません。

つーかですね。
朝の接続数を見て、さすがに笑ってしまいました。
友瀬は露店のアイテム入れ替えもかねて毎朝接続数を見ていたのですが・・・

1月半ばで1500前後。
1月末～2頭のいわゆる「2倍」期間で、2500前後。
で、今朝、500切ってます。

人間、プレイスタイルなんてのはそんなに急には変わらないですから・・・単純ではありますが、1月末からの差分量はBOTだった、と見ていいでしょうね。
・・・最近は最大でも5000くらいしか接続していないわけで、２０％がBOTだったと。
・・・やだやだ（＾＾；；

2007/2/6 (火)

ええと、一応普通の人間PCでもできるいわゆる「移動キャンセル」を使えば、多少の高速化は見込めるようです。
が、Glenelgでは当面その対応はしない、と明言しておきます。

もともと以前のモーションキャンセルの際にも、理屈不明、お行儀悪いという理由で採用を渋っていた内容です。
特に移動キャンセルではSP回復が発生しないという致命的な問題があるので。

とりあえず、あちこちのケミ関連スレで大騒ぎになってるので、簡単にメモだけ。
今回のパッチで、ホム関連でいくつかの修整がなされている。
まったく告知のなかった変更なのでどこまでが仕様変更なのかはわからないですが・・・とりあえず大きい話は２点。

攻撃速度の激減。†

ケミスレでの情報を元に書くと、どうやら
「ホムの攻撃速度は、ホムの画像的な見かけ上の攻撃モーションに合致」した速度に落とされたらしい。
別の言い方をすると、今まで多くの人がきちんと見たことがない「ホムの完全な攻撃モーション画像」が、必ず画面上に表示される。
今までは（攻撃が遅いとされていた）標準AIですら、そういう表示はされていなかった。
つまり、あらゆるホムの攻撃が減速したとみていいだろう。

これ、うちでも技術メモを書いている多重Attack()によるモーションキャンセルや、先週くらいに可能な限りAIで考えていた多重Attack()の手加減の話を完全に上書きする内容。
~~つまり、多重Attack()はまったく意味をなさなくなった。~~
つまり、多重Attack()はまったく意味をなさなくなった可能性が高い。
まあ、これについてはもともと確実な裏づけのない経験則からのものなので、仕方ないところか。

ただ問題がまるでない、というわけではなさそう。
問題の１つは、そのホムの攻撃速度が能力値のASPDに関係がなさそうということ。
つまりASPDがどんなに速くても、モーション画像が多い（より複雑な動きをする）ホムは遅い様子。
これはきちんとして欲しいですね。

↑

ロード時間の増加†

コールホムやテレポなど、AIが新規起動する際に大きなタイムラグが発生しています。
うちの環境では、テレポ暗転解除してケミの姿が見えてから、他のPC・敵類・ホムが表示されるまで約1秒弱、一切の挙動ができません。
モンハウど真ん中におちたら死ねそうなくらい。

↑

ともあれ・・・†

まあ、努力してるのは、わかった。

でもね。それならもっと先に直すべきことがないかい？
カオティックとかOVSとかさ。

<<2007-032007-01>>

▼過去ログ

2023	Log:2023-12	Log:2023-11	Log:2023-10	Log:2023-09	Log:2023-08	Log:2023-07
2023	Log:2023-06	Log:2023-05	Log:2023-04	Log:2023-03	Log:2023-02	Log:2023-01
2022	Log:2022-12	Log:2022-11	Log:2022-10	Log:2022-09	Log:2022-08	Log:2022-07
2022	Log:2022-06	Log:2022-05	Log:2022-04	Log:2022-03	Log:2022-02	Log:2022-01
2021	Log:2021-12	Log:2021-11	Log:2021-10	Log:2021-09	Log:2021-08	Log:2021-07
2021	Log:2021-06	Log:2021-05	Log:2021-04	Log:2021-03	Log:2021-02	Log:2021-01
2020	Log:2020-12	Log:2020-11	Log:2020-10	Log:2020-09	Log:2020-08	Log:2020-07
2020	Log:2020-06	Log:2020-05	Log:2020-04	Log:2020-03	Log:2020-02	Log:2020-01
2019	Log:2019-12	Log:2019-11	Log:2019-10	Log:2019-09	Log:2019-08	Log:2019-07
2019	Log:2019-06	Log:2019-05	Log:2019-04	Log:2019-03	Log:2019-02	Log:2019-01
2018	Log:2018-12	Log:2018-11	Log:2018-10	Log:2018-09	Log:2018-08	Log:2018-07
2018	Log:2018-06	Log:2018-05	Log:2018-04	Log:2018-03	Log:2018-02	Log:2018-01
2017	Log:2017-12	Log:2017-11	Log:2017-10	Log:2017-09	Log:2017-08	Log:2017-07
2017	Log:2017-06	Log:2017-05	Log:2017-04	Log:2017-03	Log:2017-02	Log:2017-01
2016	Log:2016-12	Log:2016-11	Log:2016-10	Log:2016-09	Log:2016-08	Log:2016-07
2016	Log:2016-06	Log:2016-05	Log:2016-04	Log:2016-03	Log:2016-02	Log:2016-01
2015	Log:2015-12	Log:2015-11	Log:2015-10	Log:2015-09	Log:2015-08	Log:2015-07
2015	Log:2015-06	Log:2015-05	Log:2015-04	Log:2015-03	Log:2015-02	Log:2015-01
2014	Log:2014-12	Log:2014-11	Log:2014-10	Log:2014-09	Log:2014-08	Log:2014-07
2014	Log:2014-06	Log:2014-05	Log:2014-04	Log:2014-03	Log:2014-02	Log:2014-01
2013	Log:2013-12	Log:2013-11	Log:2013-10	Log:2013-09	Log:2013-08	Log:2013-07
2013	Log:2013-06	Log:2013-05	Log:2013-04	Log:2013-03	Log:2013-02	Log:2013-01
2012	Log:2012-12	Log:2012-11	Log:2012-10	Log:2012-09	Log:2012-08	Log:2012-07
2012	Log:2012-06	Log:2012-05	Log:2012-04	Log:2012-03	Log:2012-02	Log:2012-01
2011	Log:2011-12	Log:2011-11	Log:2011-10	Log:2011-09	Log:2011-08	Log:2011-07
2011	Log:2011-06	Log:2011-05	Log:2011-04	Log:2011-03	Log:2011-02	Log:2011-01
2010	Log:2010-12	Log:2010-11	Log:2010-10	Log:2010-09	Log:2010-08	Log:2010-07
2010	Log:2010-06	Log:2010-05	Log:2010-04	Log:2010-03	Log:2010-02	Log:2010-01
2009	Log:2009-12	Log:2009-11	Log:2009-10	Log:2009-09	Log:2009-08	Log:2009-07
2009	Log:2009-06	Log:2009-05	Log:2009-04	Log:2009-03	Log:2009-02	Log:2009-01
2008	Log:2008-12	Log:2008-11	Log:2008-10	Log:2008-09	Log:2008-08	Log:2008-07
2008	Log:2008-06	Log:2008-05	Log:2008-04	Log:2008-03	Log:2008-02	Log:2008-01
2007	Log:2007-12	Log:2007-11	Log:2007-10	Log:2007-09	Log:2007-08	Log:2007-07
2007	Log:2007-06	Log:2007-05	Log:2007-04	Log:2007-03	Log:2007-02	Log:2007-01
2006	Log:2006-12	Log:2006-11	Log:2006-10	Log:2006-09	Log:2006-08	Log:2006-07
2006	Log:2006-06	Log:2006-05	Log:2006-04	Log:2006-03	Log:2006-02	Log:2006-01
2005	Log:2005-12	Log:2005-11	Log:2005-10	Log:2005-09	Log:2005-08	Log:2005-07
2005	Log:2005-06	Log:2005-05	Log:2005-04	Log:2005-03	Log:2005-02	Log:2005-01