入手方法は？ †
ロックリッジコインでのガチャ。
もともとロックリッジには『クエストで入手できるコイン10枚で1回』のガチャがありました。
ロックリッジ独特の装備が手に入れられるものでしたが、今回ここに設計図が追加された形です。
どんな設計図が入ったの？ †
「z-xxx」と命名されたシリーズです。
全体的な傾向としては・・・そうですね、以前の A-Frozen に近いかな？
A-Frozenって・・・
- 単体で『凍結しない』という、比較的ユニークかつ強力な効果
- 装備の精練値に影響をうけない。低精練で十分使える。
- ライオットチップとの組合せ効果は、わずかにHPを増やすだけの弱めのもの
という感じでした。
今回のzシリーズも似たような感じの『それ単体で十分強い』傾向ということです。
とりあえず、以下、設計図効果と友瀬の思ったことを列挙しておきます。
- 『詠唱妨害されない』
- いわゆるフェンｃ効果。鎧・肩・靴用（盾にはｘ）
- フェン効果を得られる場所を選べるというのは、装備の融通性の面で非常に有利になる。
鎧や肩は属性防御で差し替えることが多いことを考えると靴に刺したいところだが。
靴は有償ガチャ限定なんだよね。
- また、フェン効果にありがちな反動：詠唱が遅くなるとかSPコスト増加するとかがない。
- 『破壊されない』
- いわゆるカナトゥスｃ効果。当然、鎧限定。
- 他の装備でできていた『破壊されない＋凍結しない』みたいなことが、エクセリオンでもできるようになった。
- 『ノックバックされない』
- ストロングシールドなど、いくつかの装備で提供されていた効果。
- これも、これといったデメリット・条件がないのが大きい。
今までのモノは『被ダメージ増加』とか『要過剰精練』とかだったはず。
- 『ハイド・クローキングを見破れる』
- MVPボスカード効果ですよ、奥さん。元カード（マヤパープルｃ）同様、靴限定。
- 非Pv/Gvプレイヤーの友瀬には、あまり価値はないけどね。
- 『死亡からの復活時、HP/SPが全回復』
- またMVPボスカード効果ですよ、奥さん。こちらも元カード（オシリスｃ）同様、靴限定。
- 『死んでなんぼ』の効果なので、かなり使いどころは選ぶ、微妙なモノ。
デスペナ上等が我慢できる人ならいいけど、現実問題としてハイレベルの人のデスペナはしゃれにならないからなぁ。
- その意味では、デスペナがない環境・条件でなら使えるのかな。
- 例えばモンスターハウスとか、イベント期間中のMDとか。
- 効果面では、SP回復が非常にうれしいかな。
ことHPに関しては、そもそも『リザ４』で全快なので。
イグ葉とか、ダンサー系とか、課金アイテムとかの『全快しない復活』もあるにはあるけど。
- 『固定詠唱時間-50%』
- 効果は、まあ読んだとおり。
- 一見強いが、ライオットチップでも同様の効果が得られる。
ある意味で究極的に『ライオットチップとの組合せが弱い』装備。
- とはいえこれは言い換えると、ライオットチップを使わずに『アンフロ・破壊されない・詠唱-50%』の鎧だけを着る、という選択肢を生む。
- つーか、頭とアクセサリ以外で詠唱短縮って、割と珍しいような。
- 『敵を倒すとSP回復』
- グラウンドデリーターｃのような、敵を倒すとSP回復するもの。
- 今回の新設計図のうち唯一、『装備精練値』が効いて来るタイプ。
高い精練値では、一度に回復する量が増える。
- エクセリオンセットはc-lifeに比べてc-soulの回復量が弱かったので、面白い位置づけ。
- さらに、この手のSP回復系装備によくある「自然回復が止まる・減る」デメリットもないのもよい
今回の設計図、ある意味でROの装備インフレの象徴でもあるかな、と思った。
例えば『破壊されない』ってのが顕著なんだよね。
最初期のRO環境では、鎧に付与できる特殊効果はカードに起因するものがすべて。
だから、『凍結対策』最優先で、それを差し置いてカナトゥスｃが使われることはほぼなかった。
時代が進むにつれて『カードを刺せる壊れない鎧』『カードを刺せる属性鎧』などがでてきて、
結果的に『壊れないアンフロ』なんてのも作れるようになってきた。
そして今や、『破壊されない』『追加ボーナス』『高精練でさらにドン！』みたいな鎧だってごろごろある。
それにカードを加えて、３つ以上の効果を抱える装備が当たり前に作れるようになってきている。
今回の追加で、『3枚刺せる』エクセリオンもその波に大きく乗った、と言えるわけです。
友瀬の状況 †
最初にも書いたとおり、とりあえずガチャってます。
400枚==40回まわして、Z-nodispel（詠唱妨害されない）x2 、z-immortal（破壊されない）x5、Z-Lillgain(敵倒すとSP回復)x1、Z-CastFixed(詠唱-50%) を入手。
モンスターハウスに備えて、『壊れない・詠唱妨害されない・凍結しない』鎧でも作りますかね。
精練値も大きくする必要ないから、安全圏で実用品だし。
ロックリッジコインは『Lv160以上の地下街系クエスト３つ』で、10分ちょっとで9枚手に入れられる。
もちろんキャラによるけれど、友瀬の魔法アカウントでは5人くらいがこれに該当：
ロイヤルガード、シャドウチェイサー、ジェネ3人ね。
このあたりで地道に稼いでいこうかと思う。
ご意見などがあれば。
そもそも「何」を連携するのか †
ChatAnalyzerはもともと「チャットを解析して何かをする」アプリです。
そしてその機能の一部に、「/where→/savechat」の内容から『/whereされたマップはどこか』を取り出し。
そのマップ名から『今いるマップにある、ユーザ独自の座標メモ』を、RO地図に重ねて表示する。
そんな機能を持っています。
これ、元々はRO地図の不足・仕様に備えたものです。
現状のROのゲーム内ミニマップには「カプラさん」「店舗NPC」などがアイコン表示されていますが。
その網羅性に不足があり、例えば『イズルードにいる弾薬屋NPC』など、表示されないオブジェクトがあります。
また、ゲーム的にマップ表示したくない、例えば『クエスト用の隠蔽オブジェクト』もあります。
こういう『ROクライアントが表示してくれないオブジェクト』を独自登録・表示できるようにしたかった。
ただ、そのためには『プレイヤーキャラがいるマップ』をどうやって知るか、という問題があって。
検討した結果前述の『/where→/savechat』でいいじゃないか、ということで、『チャット解析アプリ』に組み込んだわけです。
で、上記機能を作った際に、すでにレジャーハントを想定してはいまして。
プレイヤーがROクライアント上で『123,39』というようにX,Y座標を発言して /savechatすると、
そのミニマップ上当該座標にアイコン表示するような仕組みは、すでに入っていました。
・・・ここまでくれば、もうわかりますよね？
トレジャーハントアプリは「暗号解読して、座標を取り出す」ことができます。
なら、『解読した座標を、ROのミニマップに重ねて表示する』という連携は、できそうですよね。
暫定方針：『アプリ自体を１つにする』ことはしない。 †
現状、そういう感じで進めています。
あんまり深い理由はなくて。
CAは「チャットテキストを分析する」アプリであって、OCRするアプリじゃないよ、というだけです。
だからもしかすると、先々結合しちゃうかもですが。
連携の基本方針 †
基本的には、単純です。
『まるでROクライアントから/savechatしたように』トレジャーハントアプリが『座標情報を書き込んだテキスト』を作ればいい。
そのために、トレジャーハントアプリに、『CAが読み取っている・期待しているチャットテキストファイル名』を登録できるようにする。
これだけで大体解決します。
ただ、ちょっと大き目の課題が２つほどあって、それの実現方法の検討中。
何が課題かというと・・・トレジャーハントが『通常２つのマップで行われる』ということ。
わかりますよね？
トレジャーハントが以前ラヘルで実施されたときは、オブジェクトは『ラヘルの街』と『ラヘル↑の神殿』の２つのマップのどちらかにありました。
現状のトレジャーハントアプリは『ぬふあうえ→12345』の変換はしますが、それが『ラヘル』か『神殿』かは判断できません。
課題１：マップの判断方法について †
今、方式は２つ考えているのですが、一長一短で。
とはいえ、案Bを選ぶと思います：実際他サイトのWebアプリでは、これに近い方法を取っていると思われる節があるので。
案A：台詞解析する。
今までのトレジャーハントでは、『ぬふあうえ』的ヒントを出している吹き出しに
『それがどのマップなのか』も併記されていました。
それを読み取れば、判断することは不可能ではないです。
案A問題点１：文字認識精度。
現状使っている Windows.Media.OCRは『細かい字』への精度はそれほど高くありません。
そのため、マップ名の読取判断がうまくできないおそれが結構高い。
これは現状でも実施・確認できます：RO内の適当な吹き出し台詞を「読取」してみてください。
RO の画面のスクリーンショットという時点で、文字の解像度がちょっと粗いのです。
実際、とりだしたままのスクリーンショットデータでは『ぬめあお』『つう』あたりの判断ミスが結構多く。
そのため現状内部動作として、画像認識の前処理として画像の拡大・補完処理をしています。
が、さすがに漢字が絡んでくると、これだけでは対処が厳しい。
案A問題点２：開発までの時間
『実際にトレジャーハントが始まる』まで、どういうヒント出力になるかわかりません。
マップ名までいれるとおそらく『複数行』を解析対象にしなければならず、またどこにどのように地図名が入るかわからない。
もちろん現状でも『新しい暗号パターン』がでてくれば開発は必要なのですが、それよりも面倒な気がしています。
案B：座標とマップの関連付けを行う。
例えば 12,34 はマップA、34,56 はマップB・・・というように、ヒントの出力パターンから決める、という方式。
実際、従来の他サイトのWebアプリでは『暗号文字列』からマップまで判断していることから、
おそらくこういう紐付けで対応していると思われる。
案B問題点１：紐付けが必要。
『12,34はマップA』、『34,56はマップB』というのは、実際にトレジャーハントが始まってからでないとわからない問題です。
この紐付けをどうにかして登録しないとならないのが、大変。
案B 問題点２：完全同一座標だったらどうするか。
『マップAの12,34』『マップBの12,34』という回答パターンが両方ある、という恐れ。
これがきたら、まああきらめましょう（笑）
課題２：『今のマップではない』ときの表示方法。 †
課題１でのマップ判断の次の話。
『今回の解析結果が現在のマップにある』なら、簡単です。
CAの現状実装で十分対応できる。
ですが『隣のマップにある』と、ちょっと面倒。
隣のマップに移動するまではそのオブジェクトは表示してはならず、移動後、表示するようにしないとならない。
これを、ROTRとCA、どっちでどう意識するか、という話。
正直、この話になってくるとCAとROTRを1アプリに結合することも考えたい・・・
案A：ROTR側で意識。
ROTR側、判断の結果、『今のマップ』でよければ、普通にCAに通知。
『隣のマップ』なら通知を保留。キャラが隣マップに動いた後、ユーザが『ROTR上のボタンを押す』と、CAに通知。
その際に『対象座標』と『移動先のマップ名情報』：/whereしたのと同じようなデータとを作って吐き出せばいい。
CA側はどちらの場合においても、既存のメカニズムの中で『通知を受けたら表示』でOK。
案B：CA側で意識
ROTR側は判断したら、CA側に『座標』＋『対象マップ』を通知。
CA側は、受け取ったマップ名と現状マップを比較し、今のマップでよければ即表示、そうでないなら保留。
キャラが隣のマップに移動した後、ユーザがクライアント上で/where したトリガーで、CA側表示アップデート。
『移動先のマップ名』と『CA側から受けて保留しているマップ名』比較して、表示する。
利用者側の操作は、案Aのほうが多少楽：「ボタンを押す」だけでいいので、マウスから手を離さなくてよい。
案Bだと「/where」なので、ショートカットまで指を延ばす手間がやや大。
いずれにしても、ROTR側に「マップ名」を仕込む手間は必要・・・ここがCAとROTRを結合したい理由（笑）
ご意見などがあれば。
このアプリ、実際に開発していたのは2017/9月ごろ。
表ページの当時の日記にもメモ記事があります→日記/2017-10-01
で、じゃあなんで今まで公開してなかったかというと、単純で。
「ROクライアント対象でテストしたことがなかった」からです（笑）
もちろん、テキストエディタの文字列相手にテストとかはしてますけど。
トレジャーハントやスタンプラリーが実際に動かないと、RO環境では試せません。
さすがに実環境未テストのものをリリースする度胸は、友瀬にはないです （＾＾；
で、今回のトレジャーハントで初めて「RO対象で実働させることができた」ので、リリースに踏み切ったわけです。
逆に言うと、ですね。
このアプリはRO専用というわけでは、ないわけです。
さすがに例の「あうえ→345変換」なんてのは日常的には使えないでしょうが。
「ローマ数字→数値化」とか、「四則演算→計算」なんてのは、使い道はあるでしょう。
ご意見などがあれば。
- あれ。なんか環境によって動かないことがあるようです。
ちょっと調査します。 -- ともせ％管理人。
大前提として、RO内でのネタは「なにもありません」。
しかも上記リンクは「Twitterで発表」されたものの、公式ページからはリンクもありません。
・・・もうちょっとやる気だそうよ。
確かに今年は4/1が日曜日。
当日サーバのデータをいじりたくないんだろうな、ということはわかります。
が、「日付を見てページを切り替える」ことくらい大した手間ではないわけで。
ちなみにリンク先は。
タイトルの通り「RO関連のいろんなネタに対するクラウドファンド」を並べているもの。
でもこれも、ただ「そういう絵面のページが並んでいる」だけ。
どこにも「クラウドファンドサイトっぽい動作」がないんですよ。
・・・もうちょっとやる気だそうよ・・・
ご意見などがあれば。
差分
バックアップ