昨日の日記に書いた内容を概念的に整理すると。
現状『単純な書式切り出し』で取り出せるアイテム名は、論理的に以下のような形式になる。

精練 頭１ 頭２ ‥ 頭ｎ 名称 尾１ 尾２ ‥ 尾ｎ S

• 個々のブロックごとの間は、半角スペース区切り。
• ブロックごとの意味は、以下の通り。
  • 精練：精練ボーナス。+1 などの "+n" 書式固定。 存在しないこともある。存在するときは必ず１つだけ。
  • 頭ｎ：接頭文字。カード起因でつく。
    「マリシャス」「ブルータル」など。
    可変長、もちろん無いこともある。
  • 名称：アイテム名そのもの。これは絶対にある。
  • 尾ｎ：接尾文字。「カード」もしくは「エンチャント」起因で付与される。
    「オブ アンダー ア キャスト」「<int2>」など。
    可変長。
    • さらに、同じ強化が複数刺さった場合の「ダブル」「トリプル」といったものがある。
      これは接頭・接尾の両方に出現しうる。
    • カード起因でつく接頭・接尾では、カード1枚で複数のブロックが発生することもある。 上記「アンダー ア キャスト」はまさにその例：カード1枚で４ブロックになっている。
  • S：スロット。装備のスロット数に応じて [1][2]など。
    スロットが無いものにはそもそもつかないことも。

で。
アイテム名として切り出したいのは、上記表現で言うところの『名称 S』の2ブロックだけ。
そして冷静に考えると、尾ｎ 部分だけ削除することができれば、機械的に切り出しができそう。

精練 頭１ 頭２ ‥ 頭ｎ 名称 S

・・・ね。文字列の最後が『名称 S』になっているんだから、単純にスペース区切りで『後ろ側2ブロック』を切り出せばいい。

また、スロットなしのアイテムでは、カード起因の接尾はつかない。
ただし、<int 1>形式のエンチャントはありうる。

これらを総合的に考えると、以下のようなステップで必要な名称が取り出せる。

1. 入力文字列に対して、正規表現 "<.*?> " にマッチする部分を削除する。
   • これは "<任意文字列> " 形式にヒットする正規表現。つまり、エンチャント類を削除する。
2. さらに、正規表現 "^\+[1-9] " にマッチする部分を削除する。
   • これは、「文字列先頭にある」 "+n " 形式にヒットする正規表現。つまり精練部分を削除する。
3. さらにもう1つ、"ダブル |トリプル |クワドラプル "も削除。
   
   • これは接頭・接尾の両方に出現しうるが、どちらも削除できる。
4. 入力文字列に "[" が含まれるかどうかチェックする。
   • もし含まれていない場合、これは「スロットなし装備」あるいは「ただのアイテム」。
     この時点で加工済みの入力文字列は『名称』形式になっているはず。
     • なぜならば：もしこれが「スロットなし装備」だった場合、スロットがないのでスロット起因の接頭・接尾はつかない。
       精練およびエンチャント形式はすでに削除したので、もはや接頭・接尾はないはず。
5. 入力文字列に "[" が含まれている場合、スロットあり装備。
   これに対して「装備に付き得る接尾語」を正規表現削除する。
   
   • 例えば『オブ アンダー ア キャスト』など。
6. 上記接尾語削除が終われば、残っているのは『頭１ ‥ 頭ｎ 名称 S』形式。
   後ろ側２ブロックを取り出すことで、『名称 S』を取得できる。

このやり方をすることで、単純に『接頭語』タイプの文字列削除を考えなくてよくなるので、かなり項目が減る。
正確に数えたわけではないが、経験的に、カードによって付与される文字は接尾よりも接頭のほうが圧倒的に多いので。

ご意見などがあれば。

• 情報メモ。
  ・重量効率があるので、重量も必要
  -- ともせ％管理人。 2016-09-03 14:32:18 (土)

アイテムの一覧について†

あちこち調べて、一覧的な情報を見つけたので、それを元に csvファイル形式で作成。
必要な情報は、「アイテム名」「アイテムID」と「価格」。
アイテムには解説類や重量といった情報もありますが、それはサポートしない方向で。
つーか、それこそそんな「大量」の情報を扱いたくないです。

アイテムの価格情報、なにを基準にするか†

ROのアイテムには、実は大きく以下の3種類があります。

1. 普通のアイテム。
   「NPCからの購入価格」と「NPCへの売却価格」の両方が定義できる。
2. 販売の無いアイテム。
   「NPCへの売却価格」だけがある。
   
3. 販売禁止アイテム。 「NPCへの売却価格」がない。 当初「購入価格」基準で考えていたら、それが存在しないアイテムがあったので、どうしよう、となってるという話。

今回の意図は「NPCへの売却時にどれくらいになるか」っていう情報なんですね。
現地での重量オーバー時の破棄条件とか、ちょっとしたPTでの金銭清算のため。

# いまさら『代理購入』なんて商売は成り立たないですし。

そーすると、NPC売却価格基準でやっていいんじゃないかな、なんて考えてます。
まあその場合も「ない」ケースはあるんですが。

アイテム価格の調査・csvへの設定方法†

力技・人力でやることも考えたのですが、さすがに種類が万のオーダーなので、気乗りせず。
既存の Webサービスをうまく使おうと考えています。

候補は、Roween というサイト。
こちらでは アイテムのIDに基づいて Webページが作成されているので。

アプリでアイテム名からIDを引いて、必要なURLを構築して http通信してダウンロード。
取得したhtmlを解析して、価格情報を取り出す・・・という感じのことを考えています。 Roweenサーバに負荷をかけるわけにはいかないので、アクセス速度とかキャッシュとか、配慮は必要。
また、アイテム名⇔アイテムID の変換はアプリ責務なので、新しいアイテムが手に入ったときにはデータは別途追加が必要です。
そういうケースも含めて、友瀬側からもデータテーブル（含む価格）の提供メカニズムは必要そう。

アイテム名抽出について†

いろんなやり方がありますが、アイテム取得時にでる以下のようなメッセージを基準に判定しようと思います。

赤ポーション 1 個獲得

ただ、上記のような「簡単な」アイテムはいいのですが。
装備品の類は結構めんどくさいので、どこまでやろうか検討中。
めんどくさい理由は、以下のような様々なバリエーションが予想されるから。

• 『アイス ファルシオン [3] 1 個獲得』
  • 取得したいのは『ファルシオン [3]』。
    『アイス』はいらない。
  • 一応『スペースで区切られた文節』という解析基準はあるので、それは助かる。
    『アイスファルシオン（いわゆる宝剣）』と『アイス ファルシオン（マリナc刺しのファルシオン）』とは区別できる。
• 『ブラディウムブローチ オブ アンダー ア キャスト [1] 1個獲得』
  • 取得したいのは『ブラディウムブローチ [1]』。
    『オブ アンダー ア キャスト』はいらない。
    接尾文字列が『オブ』『アンダー』『ア』『キャスト』という複数文節になっている点に注意。
• 『+10 ダブル ブラッディ コンポジットボウ オブ バーサーカー ダブル [4] 1個獲得』
  • 取得したいのは『コンポジットボウ [4]』。
    上述の２つのパターンの復号で、わりと最悪のケース（笑）。
    
    • 接頭語も接尾語も、複数文節になりうるということ。
• 『エクスキャリバー <DEX+7> <DEX+5> [3] 1個獲得』。
  
  • エンチャント類ですね。これも削除対象。
    この場合のポイントは、<xxx> という書式で削除していいということ。
• 『回復の光 <int+1> 1個獲得』
  • スロット情報がないアイテムもあります。

つまり。アイテム文字列のデータ構造は
『（可変長接頭文字列 0〜任意数）（名称本体）（可変長接尾文字列 0〜任意数）（有無不明のスロット情報）』
・・・となっていることがわかります。

前述の通り、各文節はスペースで区切られているので、それなりに解析しやすい条件ではありますが。
接頭・接尾とも可変個数であるため、機械的な処理ではできません。
正規表現で削るしかなさそうですが、そーすると問題は、そのパターンが極端に多いってことですね。
極端な話、カードの種類と同じだけパターンが必要なわけで、消去パターン作るのが面倒（笑）
あと、それだけ条件が多いと、性能面がちょっと不安。

また、調べきれていないのですが、「アイテム名と合致する接頭・接尾後」がないかも心配。

チャット文字列の改行問題†

テストしていたログを見ていて気づいたのですが、たまにこんなログもあるんですよ。

ブラディウムブローチ オブ アンダー ア キャスト [1] 1個獲

得

わかりますかね。行が長くなりすぎて、途中で改行しちゃうケース。
この場合『xxx n 個獲得』というパターンを外れてしまうので、うまく検出できない。
次の行を先読みマージするっていうやり方もありますが、それはそれで副作用生みそうだし。
どうするか検討中。

ただ、これは普通のアイテムではなく『いろいろ付与された長い名前』でおきやすい現象。
今回の趣旨の『NPC売りしたらいくらか』というケースを前提にすると、 こういう『いろいろ付与された』モノを対象にするとは思えない。
そういう意味で、何もせずに結果的に無視、というのもアリかもしれない。

さらに、チャット窓の幅を狭く設定している場合におきやすい。
これも使用条件として明示しておく必要はあるだろう。

ちなみに、この改行問題にはもうちょっと別のパターンもある。
極端に書くとこんなケース。

ブラディウムブローチ オブ アンダー ア

キャスト [1] 1個獲得

この場合「2行目」が問題。
まるで『キャスト [1]』というアイテムを取得したかのように見える。
このケースはたぶん打開しようがないので、
『アイテムっぽくて切り出したけど、そんな名前ないから無視』というスタンスで考えている。

xxxxxxxブラディウム

ブローチ [1] 1個獲得

とかいうケースもあるだろうけど、そこまでは面倒見れない（笑）

処理フローまわり。†

今回想定している処理フローは、以下のような流れです。

• RO クライアント上で /savechat する。
• アプリがチャットテキストを読取、解析。アイテム名を抽出。
• アプリ内部処理、抽出したアイテムを知っているか？
  • ここで「知らない」なら、前述の「変な改行」問題もあるので、あきらめる方針。
• アプリ内部処理、抽出したアイテムの価格情報を知っているか。
  • ここで「知っている」なら、難しいことは何も無い。
• 知らなかった場合、Roweenに問い合わせして情報取得を試みる。
  • ここで非同期動作になるのが１つの課題。
    取得処理をしている最中に『次の savechat』がきたらどうする？
  • Roweenとの通信に失敗する可能性もある。
    とはいえ、これはあきらめればいいか。
  • ともあれ非同期通信中にユーザ放置するわけにはいかないので、 アプリとしては「調査中」表示して待機状態にするのが妥当か。
• Roweenからのhtml取得成功したら、その内容の解析開始。
  解析完了したら、その値を「保存してあるアイテムリストcsv」と「現在のチャット表示」とに反映。

・・・こんな感じ？

ただ、Roween通信を考えると上述の通り非同期処理とか面倒な話が出てくるので、正直やりたくない。
Roween のhtml書式変更だってありうる話ですし。
なので、それはやらずに済ます方針も考えています。
具体的には、Roweenとの通信は『友瀬の開発環境で実施』して。
リリースするアプリには『価格情報が全部載った csv』を同梱して、Roween通信しない、というやり方。
先々のアイテム追加については、あきらめて友瀬側で csv改訂〜配布するメカニズムを作り。
加えて、利用者が独自編集できるような仕組みも作ることになります。

こっちのほうがいろいろ問題を起こさないと思うので、自然かも。

ちなみに、アイテム種類がざっくり1万として。
Roweenサーバに負荷をかけないために『1分に1種類』の取得を行うとして。
1時間で60個、1日で 1440個。1週間くらいあれば1万個は全部探れる計算。
どうせ動作確認も必要なので、こっそり進めておくのがいいかもしれない。

画面デザインと表示詳細について†

とりあえずプロトなので「えいや」で作ってるところ。

どこかでてきとーに開示して、意見をもらおうかと思ってます。

その他。†

『チャットテキストを取り込んで解析してｘｘｘする』というメカニズム。
結局 ROCALFOと根っこは同じなんですね。

なので、１つのアプリで実現できるように考えています。

これについても画面デザインが絡むので、今後の課題。

こんな感じかな。

ご意見などがあれば。

実は savechat からの情報取得については、案外昔にタネがあります。
友瀬のAI：Glenelg には、冬物語さん案のチャットコマンドという仕組みが組み込まれていまして。
ROクライアント上で命令入力→ /savechat とすると、ホムAIがその保存ファイルを参照・解析して、命令として処理するという仕組みです。
で、これを組み込んだ2007年当時、さらに何かに応用できないか、と考えたことがあったのです。

そのときの日記がこちら：日記/2007-09-17

わかりますかね。
『獲得したアイテムの名称』がチャット窓に出力されるので。
それを /savechat することで『アイテム名』をファイルとして出力できるわけです。

当時はホムAIでやることばかり考えていたので、正直近視的になってましたが。
コンニチ考えてみれば、ROCALFO同様に『外部アプリ』で処理することは可能で。
むしろこの方が、『ホムのいない職業』でも使えるという意味で、より汎用的です。

で、これも ROCALFO と同様に、RO のアイテムについてのデータベース的サイトは既存です。
そちらを使うことで、アイテム名から値段や効果などを調べることは十分に実現できる。
唯一の差は、/savechat で直接テキストをアプリに渡せる、というだけです。

というわけで、どうするか迷ってる真っ最中。
アイテム名は取れる。ではその先をどうするか。
例えば上記日記で書いていた『価格の検索』を実現するにしても、 RO の『恐ろしい種類の』アイテム全てについてのデータなんて、作りたくない。

どっかでうまく利用できるWebサービス、ないかしらん。

ご意見などがあれば。

まとめとは言うものの、イベントの内容自体はすでに 先日ざっくりと書いたので、あまり新しいことはないです。

経験値的には。†

これと同じイベントがあった一昨年では、友瀬チームのキャラたちもレベルが低かったため、育成イベントとしてかなりおいしかったのですが。

ヌヌヌ他で平均150レベルくらいとなった今では、残念ながら経験値的には微妙。

必然的にドロップ狙いとなっています。

ドロップ狙いとしては。†

宝箱にはざっくりいうと「コモン」「アンコモン」「レア」--以上友瀬命名--の3段階があります。
で、ぶっちゃけてしまうと「レア」の中のレア級アイテムしか、友瀬的には意味がなかった感じです。

ありていにいうと狙いは、最近エンチャント対応された「ブラディウムブローチ」。
公式ブログにあった「ライオットチップ」あたりですね。
バレルヘルムや一碧系武器もまあレアではありますが、それも、ねぇ、という感じで。

友人の一人は「金になるから」という理由でアークワンドなどの「NPC売りで換金」できるものも拾ってましたが、正直友瀬的にはその手間すらばかばかしくて、無理でした。

ともあれ、そういう「レア箱狙い」になったので。
普段の「身内での少人数PT」ではなく「大人数の臨時PT」の利用が多かった、というのが、今回の特徴かな。

どちらにせよ、そういうPTは「人集め1時間・狩り1時間」という長いスパンになりがちだったので、数は回せませんでした。時間的にも体力的にも。

結果的な戦果としては。†

• とりあえず、精錬も込みで+7バレルヘルム1個。
  • ヘルム自体はトータルで9個くらいありましたが、たたいてこんな感じ。
  • 精錬+8でのボーナスは「正直なくてもいい」のですが、「あっても困らない」ので狙った、という感じ。
    バレルヘルムを露店売りする手間もアレだったので。
  • 一碧武器も、一式入手。
    ただし、精錬値は良いもので+7レベル。
  • これも、友瀬的にはもともとそれほど評価が高くないので、まあよしとします。
    倉庫圧迫も厳しいので、適当に処分しようかとも思ってます。

• 純白のエプロン+8、2着。
  • 一応レア装備。ヒール強化系の服。
  • 高レベル精錬なので1着は売る予定。
    もう1着は、どうしようか思案中。

• ブラディウムイヤリングが２個かな。

• 副次的な収入、14Mzくらい。
  • レア箱狙いの臨時PTに参加してたら、ザグダムｃのドロップに2回(！)居合わせました。
  • PT終了後の競売で、1枚70Mくらいで落札。
    参加者頭割で１４M 入った、と。

• ピニョン交換
  • いろいろ迷って、ほとんどを石炭に交換しました。
  • アルケミで作ってもいいんですが、結構手間なので。

とりあえずはそんな感じかな。
何か思い出したら追記します。

ご意見などがあれば。

Ver1.05†

テキストボックスでファイル指定をしていたのですが、これだと 「決定」を押さなくても修正できてしまうパターンが発生しました。
ファイル削除する機能のあるアプリなので、うっかり事故を避けるためにポップアップ画面を使って確実にファイル名チェックするようにしました。

また、従来の動作だとチャットファイルを削除してしまう仕組みゆえに、なにかのときに動きの監視ができないので、望むならチャットファイルをリネームして残せるようにしました。
ファイル名は時刻情報を用いて生成しています。

Ver1.06†

検索候補が多すぎたときに「画面外になってしまって見落とす」レポートがあったので、 画面表示サイズの可変処理をいろいろ強化しました。

Ver1.07†

使っていて気付いた点として、/savechat した結果の新しい候補リストの内容が「前回とまったく同じ」になると、「チェックしたのかどうか」がわかりづらかったので。
チェックした時刻を表示することで、「変わった」ことがわかるようにしました。

以上そんな感じ。

ご意見などがあれば。

友瀬は、現状２つのアカウントを維持しています。

ともあれ、以下。

• 1stアカウント。自称『殴りアカ』。
  • Jose ： 殴りアークビショップ。
    
    • アドラムス・ジュデックスという「Int AB」が輝くスキルがある分、正直残念キャラになってます。
  • Alretty：スイッチ型ギロチンクロス。実は1人だけ『万力屋ギルドメンバー』じゃなかったりします。
    • 精練祭での+7ナブセット＋アルティメットでの『カウンター屋』としても動いています。
  • Kitt ：メカニック。月光剣併用の『エンドレスマグマ』を主体。
    • 当初ロボ予定だったのですが、新人にその座を譲りました。
  • XueRang： 修羅。閃光連撃型。
    • 修羅身弾を取っていない変則型。号砲のためのHP強化に偏っています。
  • さやか ： アドラ・アークビショップ。
    • 精錬祭での+7審判セット＋パッケの『ジェム不要』で、強キャラと化しました。
    • 『殴りアカ』なのに int型なのは、Joseとの一部装備共通化の都合。
  • お嬢様 ： 2軍の製造用ソウルリンカー。
    • すでに99完成なので、完全におみそです。
  • Orlena ： フィーリル→バリエリ使い。
    • 本来 AI開発用でしたが、気がつくとすごいレベルに。
  • JuliaScaret： アミストル→エレノア使い。
    • これも元はAI開発用。
  • ノエル ：魔導ギア。
    • 精練祭での+7セットで燃料不要になって、本格的に。
  • Aurora ： ワンダラー。残響型・・・がいつのまにかメタリック型に。
    • エメラルドイヤリングが全て悪い（笑
  • Barbara： レンジャー。DEX-AGIなスタンダード。
    • 白羽セットもある火力職・・・と期待されたのですが、エクセリオンの台頭でやや不遇。
• 2ndアカウント。自称『魔法アカ』。
  • Cathy： エレメンタル偏重のソーサラー。
    • ただしJobレベル上限の緩和で、やっぱりいろいろできる身体に。
  • Vise ： フラットステ ジェネティック。
    • もともとは宝剣I-Aだったのが、レベルが上がってフラットに。
    • バニル→エイラのホムAI担当。本家「Glenelg」。
    • 先日、Base165達成。友瀬チーム初の三次職オーラですね。
  • ウナ： 氷雷ウォーロック。
    • ある意味一番変わっていない。
  • 神咲薫 ： STR==INTのスキル重視パラディン。
    • Vise同様、元はI-A型で残念な感じだったのが、フラット気味の一線級に。
  • 紅蓮華 ： 名前どおりの炎重視の術忍者。
    • 範囲攻撃はないものの、単発火力ならトップクラス。
  • Karr ： 戦力的には2軍、 このアカのお財布・露店担当 ブラックスミス。
  • 武嶋蔦子 ： これも戦力的には2軍。Int-Agi のオートスペル型スパノビ。
    競争率高い『マリみて』名なので、ほんとは前後にクロス付の名前。
    • しょせんはスパノビですが、レベル上昇とエクセリオンセットでHPという弱点を解消できたので状況はかなり変わった。
  • CrimsonShadow ： 盗作オートスペル型。
    • レインボウでの4色オートスペルでにぎやかに。
  • 糖尿病治療用： 2軍だったはずのネタ名キャラ、気づくとジェネに。
    • 甘いものつながりで、ホムSは リーフ→セラAI用に。
  • 倉庫管理人： 名前通り「活動する気のない」キャラでしたが、気づくとジェネに。
    • ホムS バニル→ディータのAI用。
  • ポータル担当： 名前通り、身内の転送用だったのですが、気づくとAB。
    • 魔法アカなので、魔術師系装備で働いています。

ホムS開発なんぞしている都合で、気づくとジェネというかホムS５枠体制。
で、メカニック３人＋カート持ちスパノビと。
2アカウントでカート９個は、友人からやりすぎと言われています（笑）

ご意見などがあれば。

追加した機能：敵名称の設定支援。

• 初期画面の下側にある「学習対象」表示
• 「詳細設定」タブにある ■履歴

以上の２つにおいて、対象となる敵の名前orID数値をダブルクリックすることで、当該敵IDの名前編集を行えるようにしました。

初めて戦って「ID値が表示」されている敵を、速やかに命名できるようにした、ということです。

これだけの話なので、積極的にバージョンアップする必要もないかと思います。

あと・・・機能とは直接関係ないですが、アイコンをサポートしました（笑）

いまさらバニルアイコンなのは、友瀬の趣味です（＾＾；；

ご意見などがあれば。

いんとろだくしょん。†

イベント概要は、ここ2年ほどの恒例の『Wizardryオマージュ』もの。
友瀬の日記上だと、2年前の記録はありました。

去年は記事を書いていないですが、おととしのときの問題点 （宝まわりの操作性・レスポンス）は向上していて、こなれていた感じ。
そういう意味で、今年は『軌道に乗ったいつもの』・・・のはずだったのに、 いきなり1週間延期だったのはご愛嬌かな（笑）

今年の特徴：アイテムまわり。†

去年もそうだったのですが、宝箱にいわゆる『期間限定の当たり』があるのが特徴。

去年は『ユニコーンの兜』でした。
そして今年は『バレルヘルム』と『一碧シリーズの武器』が限定品。

一碧シリーズは、これも最近恒例的になっている『特定属性・種族への特化』装備。
今回のダンジョンは『火属性、無形/悪魔』となっており、それに対抗する水武器、ということですね。

友瀬的には、バレルヘルムだけでいいかな。
それも高精練は不要：『装備解除時に金剛も解除』という能力だけのため。

今年の特徴：敵の姿。†

ダンジョンを攻略していろいろ稼ぐ、というメカニズムには変化がないのですが。
そこにいるモンスターの姿が『変則』なのが、今回の大きな特徴です。

どういうことかというと・・・

去年までだと、モンスターは『既存マップにいる既存の姿』なんですね。
だから例えば『ラタトスク』だったら、その姿を見たとたんに『魔法反射がある』と予測して行動ができる。

ですが、今年は『見た目はホムS』『中身がラタトスク』というような形になっています。
しかも、マップによってそれが多少変わる：『見た目は同じホムS』でも、『中身はラタトスクではない』こともある。

結果、対処に多少差がおきる。
同じ見た目でも魔法反射の有無はやってみないとわからない。

ある程度のなれで対応されてしまうことではありますが、 ある意味で『お決まりの対応』ができない、新鮮さはあります。

・・・個人的には、ね。
Wizardryオマージュなんだからさ。
最初の見た目はホムS、何か、例えばルアフ当てたら元の姿になる、とかでもよかったかな、と思ってます。
ええ、贅沢ですとも（笑）

とりあえずこんなところかな。

ご意見などがあれば。

Ver1.03 では、どういう問題がおきていたのか。†

実行ファイル自体は動作しており、かつ、内部的な動作も妥当。
ただ、アプリ画面上のオブジェクト表示が異常になっており、調査結果などが一切画面から確認できない状況でした。

すごく基本的な話に見えるけど、なんでそんなことに？†

このバージョン、「友瀬の開発環境」では完全に正常動作していました。
実際、この現象が発覚したのは『友人とのPTプレイ中での動作確認である程度安定したので、友人に配付した』後、 『その友人からバグ報告を受けた』という状況です。
その際も、まさか画面がおかしくなっているなどとは思わず、状況再現に苦慮したくらいです。

# 内部動作をチェックするデバッグ版を渡しても、『正常』に見えた。

# 表示系をチェックするなんて仕組み、ないからねぇ。

原因はなんだったの？†

開発環境 VisualStudio が自動生成する resource.resx が破損していました。

これには、当該アプリの画面上にどういうコントロール（ボタンとかテキストボックスといったパーツ）が、どういうサイズ・レイアウトで置かれているか、というような情報が記載されています。
これが破損していたため、友瀬の想定していない画面表示になっており。
例えば調査結果を表示するテキストボックスが、利用者には見えない状況でした。

不思議なことに、繰り返しますが、友瀬の開発環境PC上ではこの現象は再現していませんでした。
いわゆる「開発環境上のデバッグ版」だけでなく、普通のリリース版オブジェクトでも。
友瀬の別PC上で動かしてみて「なんじゃこりゃ」と気づいた、という状況でした。

さらに根本的には†

上記ファイルは「自動生成」、すなわち VisualStudioで普通に操作している限りは、こんな破損は想定しないんですね。
なので、そもそも破損した原因も不明。

ただ1点だけ、ちょっと気になることがありまして；

ローカライズ切替えでデザイナが破損してしまう
https://social.msdn.microsoft.com/Forums/vstudio/ja-JP/9b53b1cd-cd2a-4cb5-a518-e5f86a32e33f?forum=csharpgeneralja

今回、操作しててうっかり「言語設定：フィンランド」とかにしたタイミングがあったのです。
もちろん日本語に戻してはあるのですが、これがひっかかったのかも、と。
・・・なんですが、上記リンク先も、たいした情報が無い（＾＾；；

とりあえず、言語設定だけは二度と触るまい、と心に誓いました（笑） 当面海外向けリリースなんて予定ないし。

ご意見などがあれば。

やりたいことはわかりますよね：
イベントでのヒント文字列から、罠を特定する処理を行うアプリです。

似たようなWebサービスは公開されているので、それと同じことをやるのでは意味がないので。
Windowsアプリ独特の処理をしています。

このアプリでは、ROクライアントの /savechat を利用して入力を自動化します： クライアントが作ったテキストファイルを解析し、そこにあるヒント文字列を自力でかき集めます。

つまり、Webサービスでは『自分でRO画面上の文字列を読んで、それをWeb入力』という手順を踏んでいたところ。
このアプリを使うと『クライアント上で /savechat』するだけでよいのです。

そんな感じ。

ご意見などがあれば。