2018年5月の日記

こっちもアップデート。
取り置きのはぐれタンポラが全員昇格すると聞いて、ありったけ取り置いてました。

大型アップデート。
ストーリーもレベル上げも進めていない私がやることは正直少ないのですが、写真機能だけ試してみました。

おきがえリポちゃん。
リンカのローブセットでありますな。
リンカ…会ったことあったっけ？

TGWSAdmin

画像の半自動整理実装。
タスク実行時に一時的に使うだけで他に使い道のない画像なんかがあって、そういうのはタスク実行後には基本的に不必要になるのですが、別のタスクにも使われている可能性も考慮して、自動では削除していませんでした。
タスクが幾度となく実行されて、不必要な画像が増えてきて、全自動で削除まではしなくていいから整理が必要になってきました。
ということで、セーブフォルダ内のファイル－タスク内で使用している画像という形で、未使用画像を列挙できるようにしました。
半自動削除機能も作るには作ったのですが、消しちゃいけないイレギュラーなファイルを完全に判定する手段はないので、削除はこれからも手動でやることでしょう。

funyak

Effective Bounds構想。

funyakの当たり判定の考え方は、ふにゃさんを継承していて、「自分が誰かにぶつかったら、相手の反応は相手に任せて、自分は自分の反応だけを行う」という考え方になっています。
具体例で言うと、ふにゃを弾き飛ばす効果のあるギヤバネは、ふにゃにぶつかるとバネを出し、一歩後ずさりしますが、ふにゃを弾き飛ばしはしません。ふにゃがギヤバネにぶつかって弾き飛ばされるのは、「弾き飛ばされる」という動作の主体たるふにゃの責任なのです。

と、なれば、自分が反応するためには、相手のことを知らなければならないわけです。逆に言えば、相手に反応してもらうためには、自分のことを教えなければいけないわけです。
自分の位置が、相手が「影響を及ぼしうる範囲」の外にあれば、自分は反応する必要がないのです。相手に反応してもらうためには、まず自分が相手に「影響を及ぼしうる範囲」を知らせなければいけないのです。
この、「影響を及ぼしうる範囲」を、「Effective Bounds(効果範囲)」と呼ぶことにしました。
Effective Boundsを共通的な仕組みの一つとして用意してやれば、厳密な当たり判定の前にまず影響がありうるかどうかを簡易的に調べることができるようになるわけです。

逆に、自分自身の「影響を受けうる範囲」、例えばやられ判定などについては、当たり判定処理の中で自分で考えればいいので、共通な仕組みを用意する必要はないでしょう。
自分が植わる位置を決定するための判定範囲を本体からかけ離れた位置に持つウナギカズラなんてのもいますからね。

板と針もそうでしたが、ふにゃシリーズの当たり判定は、当たる側と当たられる側で非対称な仕組みになっているのです。というか、します。

グリモアの鍵読了。
サービス終了までのスケジュール的に言っても、人物関係のきりのよさから言っても、今回が最後みたいな感じがしたんだけど、語り部のメルティはまたすぐにでも次の話をやりたそうにしていたんですよね…。

使いもしないのに無駄に実装していたTaskBaseのIDisposableを撤去。
アンマネージリソースを使うタスクはなくなったので、いらなくなっていたし、たとえいるにしても、ベース側で実装するのは見当違いでした。
Linuxサーバー上でも動かせるようにしたいので、.NET Coreで動かせるようコードの整理中なのです。

表立って影響は表れていないんですが、アンパンマンDB4のデータベース構築プログラムに誤りがあり、全然関係ないテーブルが出来上がっていました。
原因は単純なタイポで、厳しい条件にしてテストを行っていれば事前に発見できていたことでした。
ということで、テスト条件を厳しくしました。
エラーが多少多く出るようになりましたが、脆弱性につながりうる実装も見つけることができたので、これで良しとします。

テンの日の続き。
全部探すのはだるいので、欲しいものだけ回収していきました。

諸事情で調べていたものがお蔵入りになったので供養…。

針と板思想、MapObjectと絡めた一般化はできていませんが、その基礎となる針と板に相当する概念は既に存在しています。
Segment2Dが針に当たり、CollidableSegmentが板として機能します。
地形関係の判定はこれでいいとして、やられ判定系も一般化したいところですね。
まあ、これは、矩形と点、円と点みたいな簡単な判定で事足りそうな気はします。

テンの日。
とりあえず今日しかできないことだけ先にやっておいて、13日まで猶予があるはぐレモンはあとでゆっくり探すことにします。

今日でサービス終了だったそうですな。
最後に喋り方の設定だけでもスクリーンショットで残しておこうかとも思っていたのですが、結局面倒でやめたのでした。

アンパンマンDB

アキタラヤメル企画として始まったアンパンマンDBも、今日でひっそりと10周年であります。
だからと言って別に特別なこともないわけではありますが。

Selenium

先日のSeleniumの記事、更新しました。
違うディレクトリから呼んでも大丈夫にしました。

アンパンマンDBをよく見ている人は、アンパンマンDBには情報提供のコメントがしばしば来るということは知っていると思います。
そして、その反映には非常に時間がかかっていることもご存じだと思います。
そんなにみんなで作りたいなら、作れるようにしたらいいんじゃないか、と考えることがあります。

Wikiは一人で記事を全面改訂できる性質上、悪意ある少人数が暴れるだけで簡単に崩壊してしまいます。
他の人がやっていたこともありましたが、実際に崩壊しました。
間違いを書く労力が非常に少ない一方、間違いを見つけ出す手間や、それを正す手間は、非常に大きくかかります。
Wikipediaは強力な管理体制がありそこそこうまくやっているようですが、サイト自体がアンパンマン向けではないため、あまり充実させることが望まれません。

私がWikiを作るというのもなしです。
私の作ったコミュニティコンテンツは総て例外なく失敗して潰れました。
だいいち、アンパンマンDBだけでも管理が追い付いていないのに、追加でより大変なものを管理するなんてだめです。

あればいいなと私が思うのは、極力メンテフリーで、みんなの「総意」が自然に表れるような、そんなコンテンツなのです。
方向性は違いますが、Anpanatorなんかは、そういった「総意」ベースで動いていて、そこそこうまくいっているようです。
例えば、キャラクターの属性とかに対して、当てはまるか当てはまらないかをみんなで評価していって、その平均値でキャラクターの性質を表していけば、みんなで作るコンテンツっぽくなるのではないかなと考えています。

行ってきたのであります。
写真はそこそこに。

アンパンマンDB

細かい履歴のページ作りました。
新履歴ページは現行のRSSを完全に置き換えるには至っていないので、しばらくは昔のRSSのページを残しておいて、新履歴ページを使うのはTwitterでの更新通知だけにします。
カテゴリ別のRSSを配信できるようになったら、トップページからの導線も用意して、全面的に新履歴ページに移行しようと思います。

TGWSAdmin

サーバーからディレクトリを消したときにセーブデータをダウンロードしようとするとエラーでタスクが中断されてしまうのですが、中断されること自体はいいとして、どこで止まったのかわからないとエラーの修正のしようがないので、タスク中断時にエラーメッセージにダウンロードしようとしたパスを含めるようにしました。

Qiitaに記事投稿。
.NET CoreとSeleniumでHeadless Chrome操作するよ

Pythonの導入に失敗して代わりに.NETでやったとか言えない…。

おきがえリポちゃんがゴールデンウィーク期間中毎日出るそうなので、いろいろおきがえ。
昨日から始まっていたのですが、昨日は別のことをしていたので、今日まとめて二日分。

新バージョン公開。
例のボタンのことと、あと見栄えの悪かった初期ステータスバーの調整です。