月: 2009年2月

割と本気で悩んでるけど、今更全記事のタグ付け直しとか面倒なのできっとやらない。

オブジェクトの判別方法だけど、同じ技から出たオブジェクトは全て同じIDを持っているのがネックになっている。
そしてオブジェクトは基本的にキャラクターと同じデータ構造を持っているのでmy_○○なデータは解析いらずで取ってくることが可能。
で、具体的にどこをどうすればIDがかぶっているものを判別できるのか。

画像ID・表示倍率・角度・攻撃判定までは読めるので、この辺で色々やってやれば大体判別できるんだろうけど、一々全部書く作業になるのは大変すぎる。
何かもっとこう、見た目のオブジェクトと実際に効果あるオブジェクトをさっくり見分ける方法は無いだろうか･･････

関係ないけど
ここを読んでいる人は意外といるらしい、スレで前回記事のネタ書かれたよ！
もう一週間分ぐらい書き溜めてからリリースしようかしら･･････

またもth105_aiについて

目標としていた機能全て実装完了＝αテスト終了、βテスト開始
ドキュメント類の整備完了、使用に耐えうる程度にバグを殲滅＝βテスト終了、正式版
こんな想定をしていたつもりなのだけど、予想以上にユーザーが多くて実質βテストになってるよねって話

実装すべき機能が予想以上に多く、未だに新機能実装が続いているのでαテストの範囲ではあるんだけど
同時進行でデバッグやら周辺機能の実装までやっている状態。
これじゃα終わる頃にはドキュメントの整備しか仕事残っていない気もするけれど、新機能の実装終わる前にβいくのはどうなのか

一応0.80でα終了を目標にしているけれど、作業量的にそれまでに機能実装が終わらない気しかしない。
そのせいでバグ修正のみの場合はVer標記の数字を進めないという悪あがきをしていたりする。
(というか細かいところ気にしすぎているよね、ユーザーにとってVer番号なんて飾り程度の価値しかないし)

とりあえず、バグ取りや周辺機能は使用に支障が出ない範囲だけの更新にして
さっさと必要機能全部実装終えてβテストに移行したいところ。　ドキュメントの整備もしたいしね。

---

実装予定機能一覧：
・get_opt_xyの充実
・get_special_dataの充実
・オブジェクト関連データの充実
・食らい判定の取得
・攻撃判定の取得

ちょっと本気出してみた。

継続的しないといけない手法は一般ユーザーには損しかないので禁止するとして、一回で済む方法をざっと思いついただけやってみた。
結果は上々、自分だったら出来なくはないけどやりたくはないレベルになったと思う。

具体的に書くとデバッガの感知・一部処理の隠蔽・改造されない限り実行されない仕組みのコードをいくつか仕込んでみた。
前回の記事に書いた分も含めて全て自プロセス内で完結する機能なので、こっちに干渉してこない限り一切影響を与えない良心設計。
その分防御力は低めだけど、それはしょうがない。

一つ目：デバッガの上で動いているときは即座に終了するだけ。
二つ目：デバッガなどからいくつかの処理を見つけにくくしただけ。
三つ目：ウイルス的な動作をする罠というわけではなく、想定外の状態を検地して復帰する類の機能。
ま、たぶん失敗して例外はいて落ちることになるとは思うけどね。

前回の記事も含めて、概要だけとはいえ公開しちゃまずいんだが、
それでも内容を公開しているのは「必要な機能であろうと裏で好き勝手されるのが嫌い」という理由からくる「処理内容は最低限度は公開する」という自分ルールから。
本当ならソース公開もしたいところだけど、そうするとチートに流用されるというジレンマ。

ちなみに、この修正で一番被害を受けるのは自分。
なぜなら、開発中のデバグ作業まで上記対策の影響を受けるから。
一発でチート対策機能をON/OFF出来るようコードとmakefile書き直せばいいんだけど、きっとやらない。
万が一ＯＦＦのままリリースしたら目も当てられないしねー

またまたth105_aiの話

作者は非常に小心者なので、ネット対戦の差込マクロという話題を見た瞬間悪用されているのでは？と不安に襲われ
自力で改造試みたら割と簡単に出来てしまったので、最低限度だけでも対策をすることに。

内容は簡単、LoadLibraryExWとDbgBreakPointつぶしだけ。
実際これだけでは何の対策にもなってないのだが、やらないよりはマシの精神ということで。

ちなみに、上記の対策は
実行中に外部からDllを突っ込めない、外部からDllの読み込みを伴う機能の実行を指示できない、外部からプロセスにアタッチする機能の一部が使用できないという効果があります。

本当なら、コードセクションのハッシュなり例外処理によるデバッガー介入の検地など色々やっておきたいけれど
そこまでいくとパフォーマンスに影響が出るので自重。
本気で対策するならもっと画期的な何かを考えないとなー

th105_aiの話

約11日に及ぶ試行錯誤の末、ようやくcreate_threadの再実装完了。
まさかcreate_thread動かすためだけに1/3近く書き直す羽目になるとは思わなかったよ、ほんと。
そのくせ一番時間とられたのがカスタムリソース周りだというのだから、自分の無能さ加減に鬱になる。

ただ、今度は保護モードOFFにもかかわらずエラーがLua内部で処理されるようになってしまっていて
あからさまな構文エラーしてもエラー吐かずにスレッド終了するという状態。
Luaのマイクロスレッド(コルーチン)は優秀なんていわれているけれど、地雷だらけすぎるだろ・・・・・・

というわけで、しばらくはエラー保護周りで試行錯誤することになりそう。
楽しい新機能実装のターンはまだですか？

上手くなる秘訣は悪い点が見つけられるか、だと思う。

自惚れに過ぎないかもしれないが自分は割りと上手い方だと思っているけれど
それは客観のときだけで、主観的にはまるで出来ない。

たとえば、他人が作った物に10のダメダシができる時、
まったく同じプログラムを自分で作った場合はせいぜい1～2程度が限界。
まだありそうだとは思うのだが、それ以上探すという行為に思考を割けなくなってしまう。

本来ならば、ホワイトボックステスト的な意味の思い込みが阻んで見つけられないという話になるんだろうけど
自分の場合はたぶんやる気の問題で、意欲さえわけば8～9まではいけるとおもう。

で、なんでやる気が出ないのかという話。
おそらく人の間違いを指摘するのが好きか、自分の間違いを探すのが嫌いかなんだが
前者だと思いはするものの、微妙に軸がずれているような、よくわからない感じ。

ここ自覚できれば自分の生産力上げられそうなんだけどねー

タイトルと内容は一切関係ありません、念のため。
(他の記事は最低限、人が見るかもしれないと意識して書いた物だけど
今回はそんなこと関係無しの記事なので、という意味も含む)

luaとマイクロスレッドの噛み合せについて
lua内のマイクロスレッドの構造を覗いてみたけど複雑怪奇、というより上層から最下層まで処理が散在しているためいまいち理解できず。

とりあえず分かったのが、スレッドごとにエントリーポイントと思わしき部分を分けているらしいこと。
で、単純に退避後復帰みたいな安易な処理ではなく、もっと色々やっているらしいこと。
ぼんやりとだけど、C言語中から抜けられない理由も把握。

で、結論として今の構造じゃ両立は無理。
Luaのマイクロスレッドを使い、C言語側のAPIからLuaの機能を一切使わずyieldも呼ばない形にすることで一応実現可能ではあるが、
その場合はAPIの大部分を書き直し、もしくはLua上に移植しないといけなくなる。

マイクロスレッドは大して優先度の高い機能ではないのでスルーするべきだとは思うのだが
開発初期からずっと構想を練っていただけに、ここまできて捨てたくはないというのが本音。
それに上記方法で実装するとした場合、後になればなるほど大変でもある。

さて、変更が必要なAPIと変更するとした場合の作業量ざっと見積もってきますかね。

主に解析が趣味の人なので、時々改造に手を出しては痛い目にあっている。
たとえばth105_packとか……
AIはなんとか許容範囲内だったみたいだけど、最初は叩かれないかとビクビクしていたり。

自分はまだ視界が狭すぎる若造で、他人に迷惑をかけてしまうことの多いこと多いこと。
こういう人がある程度技術を持っちゃうとほんと手に負えない。
でも、持っちゃったからには有効活用したいし、作ってしまったからには公開したくなる。
本当に手が負えないよね。

改造解析関連で一般的に許容されるボーダーラインはどのあたりなんだろう？

マイクロスレッドの上でLuaを動かすとなにやらよくわからないエラーが出る件

C言語オンリーであれば問題が起きない(？)あたり、Luaとマイクロスレッドの相性問題？
Lua自体にもコルーチン(マイクロスレッドみたいなもの)が実装されているからスレッドセーフのはずなんだけど、うーん。
というか、マイクロの実態はシングルだし、生半可な処理ではアクセス違反とか無縁のはずなんだがなぁ

もしかして、Luaスタックの退避＆復帰は手動でやらないといけない？
だとしたらまた数日かかるレベルの大工事になるんですけど……