「伺か」のゴースト製作記(17)(2002/06/01)
お次は「佝」か「q」か！？(謎)
開発マシンを完全に入れ替えたんですが、そしたら長年愛用してきた WzEditor2.0 がバグって使い物にならなくなっちゃいまして。まぁこのエディタは Windows3.1 でも 16bit アプリとして動く、かなり変則的なアプリケーションですからねぇ。32bit Windows ではちゃんと 32bit アプリとして動作する……単体の実行ファイルで……いまだに仕組みが判らん(^-^;) 足して 48 ピットなのか？(爆) それとも「平均 24 ビット」アプリとか？
動かなくなった原因は判っています、テンポラリドライブが 2GB 以上あると駄目です。Win16 の時代だとパーティションあたり 2GB まででしたからね、それ以上は内部で桁が溢れて「テンポラリドライブの空き領域がありません」と来るわわけですよ。ワープロモードとか HTML 編集モードとかの余分なモードは別として、プレーンテキストのエディタとしては軽くて早くてバグレスで大変に出来のいいソフトだったんですが、このためだけに 1GB 程度のパーティションを作るのも不毛な感じ。
というわけで、ここんところはずっと、自分専用のテキストエディタを作ってまして、早い話ゴーストは手をつけてませんでした(汗) まぁ一月近くあればちょっとは触りましたがね。
特に 4/29 にリリースした版が今年一番のあかんたれで、手元でしか起動しないこの上なく酷いリリースでした。滅法、凹んでしまってました。比較的には速やかに更新しましたが……知らん間にここの日記(2002/04/29付)でボロクソ書かれてたり。まぁいいよ、この者も結構、俺と同じぐらいのボンクラみたいだし。だいたい足掛け4ヶ月でたったの750アクセスってリピート弱ぇよオメーんとこ(爆)
※ウチは立ち上げ 1999/02/01 〜 1999/05/20 で 2000 アクセス踏ませてたよ。
まぁ、多ければ多いほど良い、優秀だ、というモンでもないけどね〜確かに。いくらかの目安には……ならないか。成らなければ成らないでそれは良し。別に困らない。つーか鬱陶しいのでカウンタ非表示にしたし(笑) 参考にはしたいんでカウント自体は続けてますけど。
ちなみに2002/06/01 夕方時点で 44989 アクセスあります。CG 描くでもなく、にしたら少なくはない、と思います……多くもないにせよ。1000/month 位ですかね。大体。多い月で 2000 件てこともあります。
ああ、ちなみに掲示板やメールで報告したら必ずサポートする…とは言いわないまでも、教えてくれれば割と自発的にデバッグしてますよ。基本的に存続自体がアクティブな皆様のおかげです。ホントに。
その割にはあれこれバリアー張ってますけど(´Д｀;
で、SHIORI/3.0 特化したら、やっぱりそれで動かないって報告が(笑) まぁ口が足らんことが原因ですかね……すんまっしぇん。で、急遽 2.x 系ヘッダでも動くようにバイパス手術を施したものの、デバッグログ周りで後遺症が……まぁデバッグログ自体は特定条件下でしか射出しない設計なので、使う人には関係ないんですけどね(^-^;)
period 535 での起動は手元では確認できてます。いやほんとに。嘘じゃないよ。嘘じゃないんだけど……他所で動かないことも信じないというわけにゃ行きません。なんでだろーなー。他のゴーストは普通に安定してたりしますが。
っていうか、その点では汎用コアってゆって馬鹿に出来ません。っていうか俺は汎用コア自体を馬鹿にしたことはないはずですが、いやマジで。汎用コアと汎用シェルでマンガとかアニメのパクリやってる作者を自分より下に見てるだけです。要するにこの世には、そう多くの種族はいません。俺より凄い人、俺と近い人、俺より凄くないかもしくは全然駄目な人、そして俺自身。
どっか間違ってることは間違いない。個人的には仕様書が……といいたい所ですが、他の人だって条件は同じだし(^-^;) 出るエラー自体が大抵は EAV だもんで、やっぱりメモリ関連ですか。しかしそんな危ない橋を渡ってる積りもありませんけれども。うーむ。
メニューのすり替えとか OwnedSSTP は積極的にやってますから、どっちみち本体が用意してない拡張は当然無理がある、という事です。簡単な話ですな。
現在ストップしてる開発も、それが原因です……。すなわち、バルーン乗っ取りが。
MAKOTO とか作れる人は試した見たら良いと思いますが、MAKOTO が投げられてきたスクリプトを握り潰してデータ無しを返すと、本体は自分が MAKOTO へ与えたスクリプトを利用してしまいます。これは昔からそういう仕様でした。
バルーンを乗っ取るためにはトランスレータで NoContent にしてしまって本体にバルーンを表示させないのが一番いいんですけど、それが出来ないわけです。
結果として、Operation雛が独自にバルーンを処理して、その後で本体がまたバルーンを処理してしまいます。なんとかこれを阻止できないものか？
便宜上、バルーン自体を非表示用にしてしまう、という線を試してみました。まぁしかし本体のバルーンは完全にユーザーの自由意志に委ねられていますから、問題解決の本意ではないんですけどね。
要するに全部透過色のバルーンなんですが、ただし1ドットでも透過色以外の点がないと起動時に落ちてしまいます。
で、試すだけ試してみたものの、実際に文字を表示しようがしまいがバルーンがあれば表示処理は行われるんですよ。よく考えたらあたりまえの事だったりする。やってみるまで気が付かんかったのが、すんごく情けない話でして。
だもんで別の策が思いつくまでは前へ進めないという次第でございました。はい。
現状はまだ直ってませんが、MP5A5.DLL と USP.DLL は同じ世代じゃないと Halt させ合います。すんません、配布形式のせいでそのような事態が起こりうる、とは全然思ってもいませんでした。次のリリースではそこのところを改良しておきたいと思います。
むろん、MP5A5 や USP のお互いが知らない項目は設定させることは出来ませんけどね。こればっかりはしようがないです。
と、言うわけで最新 0.3.16.107 のアップロード自体はだいぶ前にやってたんですがリンクだけはっときますなり。
つづく。