ぺんちゃん日記

食と歴史と IT と。 Web の旅人ぺんじろうが好奇心赴くままに彷徨います 。

執念の星三つクリア 魔人デウスエクスマキナ。

なんとしても木曜日にまでにクリアしなければ。
明日はワックスがけが予定されていてプレイ時間が確保できないかもしれないので、実質今日が最終日と考えてました。

昨日の動画を見直していて戦略を修正したほうが良いポイントがいくつかあったので調整します。
一つは終盤左側。
中段が敵の通り道になっていてブロック可能ユニットをそこに置いてしまうと気が付いたら溶けていなくなっているのでした。
そこで攻撃と同時に回復できるエターナーを配置したのですが、それでも回復力が足らないようでしたので、キョンシーと王子はそこには置かない ことにします。
左端の2列はご本尊の攻撃は届かないし誘爆にも巻き込まれないことが確認できたので急いで攻撃することもなさそうです。

もうひとつのポイントは御本尊を抱えるアーマーの回復手段です。
今までは錬金術師のスキルで回復していましたが、時間が足りなくてスキル切れしていることに気がついたのです。
アビリティの確率で敵の攻撃無効が働いていて運が良ければ次のスキルタイムまでに間に合うのですが、レベル10で運任せというのもどうかと思います。
時々キャーするのは確率の問題だったのね。
そこで リアナさん のスキルであれば届くことを思い出してヒーラーにチェンジ。
しかし彼女のスキルタイムにも間に合わない。
結局どちらも間に合わないなら二人とも使えばええやんということでスキルリレーです。
編成の枠ギリギリになっちゃった。

繰り返しプレイすることでスキルのタイミングもだんだんわかってきました。
そんなに慌ててユニットを出さなくてもスキルをファイヤーしなくてもダメージは間に合うことが確認できます。
むしろ十分に引きつけて雑魚が処理されるのを待って奥に控える大物にダメージを集中させた方が安定しました。
確実な攻略の道筋がついてプレイにも落ち着きが出てくるとミスも少なくなります。

さて記念すべきプレイ動画はこちらです。
録画ソフトの録画可能時間10分の制限にもギリギリ間に合いました。

メニュー画面ですでに星三つ点灯しているのはスルーしてください。
今回も動画を撮っていない時に綱渡り的にクリアできちゃったのよ。

完全クリアはならずも星一個でミッション完了。

午前中はパターンを変えて雑魚が出尽くすまで本体を変えようと考えていたのです。

というのも、すーちゃんのスキルが発動して望まないタイミングで本体が変形してしまうのが問題だと考えたのです。
第1形態の本体を抱えるアーマーを左下からりんねちゃんで支えて、拠点前にすーちゃんをを配置。
後ろから湧いてくる雑魚をいらっしゃいと貫通マルチでお出迎えしようという作戦でした。

もう一つ。
最近すっかり倉庫番だったウェンディちゃんの存在を思い出して、お手つきしても撤退しない彼女であれば、誘爆に巻き込まれてもへっちゃらなんじゃないかと。
装甲の厚さも申し分ないし回復支援がなくてもやっていけるから、まさにうってつけのミッションだと思い直したのです。
せっかくお迎えしたんだから使ってあげたいですもんね。

しかし結局それでも御本尊に雷をぶちかましてしまうことが判明しまして作戦撤回。
改めて右下からりんねちゃんで支える作戦に戻します。
カリスマが尽き果ててパリン知ったところでリハビリを忘れていることを思い出して満タンのまま作業終了。結局午前は無駄な試行錯誤で終わりました。

いや、無駄なんてないさ。
このパターンはダメだって結果が分かっただけ成果があったんだ。
まあとりあえず努力の過程くらいは見てください。

午後は手順を覚えきれずにくだらないミスの繰り返しです。
手順が多すぎて覚えきれないよ。
結構忙しいんだ。

奇跡的に全ての難関を切り抜けることができたのがこれです。


星一つだけどクリアメッセージが拝めました。
ここまで行けば完全クリアは目前かと思われましたが、時間もカリスマもなくなりましたので本日は終了です。

今日も今日とて魔神討伐(ほぼ返り討ち)。

結局昨日はレベル7をギリギリクリアして、レベル8は Creator の罠にまんまと引っかかってギブアップして終わったのでした。
しかもレベル7は偶然クリアできてしまったので証拠の動画を撮っていないという。
動画を撮っているとプレッシャーがかかるのか、肝心なところであわわわってなって失敗するんですよね。

ちなみにレベル8の初見はこちら。

そしてレベル8クリアの動画も残っていないという。

まあでもやっと攻略の糸口がつかめてきたと言うか、クリエイターからの「このミッションはこうやってクリアしてね」という声が聞こえてきたようで、結構楽しくなってきました。
頑張ればレベル10までは行けそうですね。

ここからはいよいよレベル9に挑戦です。
ものの見事に罠に引っかかった
待って待って。
そんなにスキルを使えないの。
無情にもダメージを与えきれずにゆうゆうゴール。

面倒だけどドルチェを第二覚醒させました。
これで最後に漏らすことがなくなりました。
今度こそきちんと録画しなければ。
たとえくだらないミスを繰り返そうともレベル9は全部録画することにします。

そしていよいよ待望の瞬間。
緊張のあまりマウスさばきが震えます。

ギリギリ誘惑に耐えてるところがありますがご愛嬌。

いよいよレベル10挑戦圧倒的物量の前に踏み潰されました。
本気で火力を出したら第2形態までは行きましたけど ギリギリですね。

今日中にクリアしたかったところですが限界です。
ブログ更新の時間も確保しなければ。

ゲームは悪い文明。

千年戦争アイギスに新しい魔神実装されました。
その名もデウスエクスマキナ
どうも私のプレイスタイルとは食い合わせが悪いらしくて全くクリアできそうにありません。
いつもならレベル10まではサクサクなんですけど、今回に限ってはレベル5で完全に足踏みしています。
こんなにアクション性高いの無理。

もうのめりこんじゃってブログどころじゃありません。
これは連続更新が途絶える予感。
ひとつだけ更新できる可能性があるぞ。
それはプレイ動画の紹介。

私のへぼいプレーを見てくださいな。

はてなブログにGitHubページのソースコードを一部だけコピペ引用する【AutoHotkey】。

これまでの経緯。

昨日の作業で what to do から How to do まで準備することができました。
今回はそれを元に機能を追加してみようと思います。

実装してみた。

心配していたクリップボードによるテキスト選択の判別はすんなりと行きました。
ただし、ちゃんとテキスト部分がアクティブ(青く反転)していることが条件です。
f:id:yasushiito:20190628090128p:plain

選択されていても入力フォーカスが URL バーにあるなど、薄いグレーになっていると判定に失敗します。
f:id:yasushiito:20190628090155p:plain


スーパー pre 記法のタグは必ず行の先頭に記述するという条件になっているので、改行コードは適切に挿入しなければなりません。

            ;スーパー pre 記法による引用のタグを生成する。
            res := ">|" . lang . "|`n" . selectedtext . "`n||<`n"

myahk/blogrefemb.ahk at v01 · yasushiito/myahk

この改行コードを\nで挿入しようとしてちょっと悩んだのは内緒です。
AutoHotkey ではエスケープは`nのようにバッククォートで行います。

改行コードといえば、 テキスト選択の末尾が問題です。
ユーザが行の末尾で選択を止めた場合と改行コードを含めて次の行まで選択した場合で挿入すべき改行コードの数が違ってきます。
細かいことは気にせずにとにかく開業を差し込めばいいんだよという話にしても良いのですが、やっぱり意味のない空白行が挿入されると気持ち悪いので、 適切に処理したいところです。
そこで末尾が改行コードで終わるなら一度削除してしまって、改めて通過する形式にしました。

            ;選択範囲が改行で終わっている場合、改行がダブらないように一度削除してしまう。
            selectedtext := RegExReplace(selectedtext, "\n$" , "")

myahk/blogrefemb.ahk at v01 · yasushiito/myahk - Google Chrome

参照元にリンクするタイトルはウィンドウのタイトル名を利用します。
このままだとブラウザ名称の- Google Chromeまで入り込んでしまいますから削除しましょうか。

            WinGetActiveTitle, title
            ;ウィンドウタイトルに含まれるブラウザ名称を取り除く。
            title := RegExReplace(title,"- Google Chrome$", "")

myahk/blogrefemb.ahk at v01 · yasushiito/myahk


特筆すべき点はこれくらいでしょうか。
ソースコード全体はこんな感じになります。


使ってみた感想。

早速この記事で引用しています。
GitHubファイル全体の差し込みボタンと間違わないように意識しながら使っています。
同じGitHub関係なのだから、GitHubボタンで引用で来ても良さそうな気がしますが、将来的にはよそのブログとか Wiki の資料を引用したりしたいので、リンクまたは引用牡丹に育てたいと考えています。

この記事に登場するAutohotkey スクリプトについて

この記事の中で私が作成したプログラムは、全て自由に使うことができます。
詳しくはこちら

はてなブログにGitHubページのソースコードを一部だけコピペ引用する【AutoHotkey】。

f:id:yasushiito:20190403184928p:plain

もっと読みやすくしたい。

以前のスクリプトによってGitHubにあげたソースコードをブログで参照できるようになりました
これはこれで便利なのですが、ちょうだいなソースコードになると本文が分断されて非常に読みづらいと思うのです。
特に部分的に修正を加えたり、注目すべき要素に言及するなど、限定的に欲しい時にとても使いづらい。
f:id:yasushiito:20190627071447p:plain


今更ですけどね。

対策を考える。

GitHubからコードの一部を引用するショートカットを用意しても良いのですが、あまりにボタンが増えるのも使いづらいので、可能であれば既存のボタンに追加機能として実装したいです。
f:id:yasushiito:20190627071843p:plain
ここにボタンを追加するか、ボタンの機能を複数に分けるか。
上から3段目左から2番目のボタンが編集フォームに埋め込みリンクを差し込むためのボタン。
三段目の右端がとハーブのソースコードを編集フォームに差し込むためのボタン。

GitHubのページを表示してボタンをクリックしたときにテキスト選択していたらソースコードの引用とするようにしたらどうでしょうか。
GitHubのページを表示しているかどうかは URL を取得してみれば、ある程度は判断できますが、ソースコードの一部を選択しているかどうかまで Auto HOT key から判断できるのでしょうか?ここは少し不安があります。

はてなブログソースコードを引用する場合はスーパー pre 記法となります。
スーパー pre 記法を使う場合は シンタックスハイライトのための言語を指定できるので、何言語のコードを引用しようとしているのかを判別できた方がかっこいいです。

次のような画面の状態でボタンをクリックされたら
f:id:yasushiito:20190627071447p:plain

次のようなタグが編集フォームに挿入される。

>|autohotkey|
    ;入力ボックスからフォーカスが外れることが時々あるのでクリックする。
    ;作業ディレクトリからの相対パスで探すので作業ディレクトリをバックアップして書き換える。
    wd := A_WorkingDir
    SetWorkingDir, %A_ScriptDir%
||< 

やりたいモヤモヤがピックアップされてきました。

モヤモヤをまとめる。

漠然とした やりたいことの詳細を詰めていきます。

差し込みタイプの判定。

一つのボタンを二つの機能が共有するので、どちらのタイプで記事にコンテンツを差し込むのかを判定しなければなりません。
defaultでは 表示中の Web ページの URL を埋め込み表示形式で差し込むようになっています。
それを少し変更して、表示中の Web ページの URL のドメインGitHubだったらソースコードの引用として機能するようにします。
URL のドメイン部分の判定はGitHubのタブを探す処理で既に 経験しているので問題ないはずです。

引用スタイル。

スーパー pre 記法で引用することにします。
完全なるコピペなので元のソースコードが編集されてもブログには反映されません。
引用は特定部分を解説したい時にするものなので内容が変わらない方が好都合です。

引用有り無しの判定。

あらかじめクリップボードを空にしておいて、 Ctrl + C でクリップボードにコピーすると、テキスト選択されている場合はそれがコピーされ、何も選択されてなければコピーされることなくクリップボードが空になっているはずです。
これでクリップボードの中身を調べることによって引用部分の取り出しとテキスト選択有り無しの判定ができるかと思います(できればいいな)。

リポジトリへの誘導。

スーパー pre 記法で引用した直後にファイル名(タイトル)からリポジトリにジャンプできるようにします。
URL とタイトルが分かるので、引用元への誘導が可能です。
こんな感じのtagを挿入してみてはどうでしょうか。

<cite><a href="https://github.com/yasushiito/myahk/blob/v01/lib/portmessenger.ahk">myahk/portmessenger.ahk</a></cite>

シンタックスハイライトの対応。

GitHubで表示されているソースコードのページの URL を使って判定する以外ありません。
URL の末尾がファイル名の拡張子なので、これが.ahkで終わっていれば AutoHotkeyスクリプトを表示しています。

うまくいかなかった場合。

想定通りに実装できなかった場合、 Visual Studio Code から引用することになります。
既存のショートカットとは全く違う機能だから、ボタンは新規が作成しなければなりません。
eltestにボタンを追加するのは結構面倒なんですよね。

f:id:yasushiito:20190627093403p:plain


Visual Studio CODE のウィンドウタイトルを確認してみましたが、開いている言語の種類である AutoHotkey が含まれています。
最悪の場合は Visual Studio CODE のウィンドウをアクティブにして、ウィンドウタイトルからAutoHotkeyであることを判定して、左端からファイル名を取得、テキストの選択部分をクリップボードにコピーして引用することになります。
この手法ではGitHubリポジトリにリンクできないのでソースコード全体がわかりません。
うまくいかなかった時の保険なので細かいところまで考えなくても良いかなと思います。

今日はここまで。

さすがにこれだけの機能変更を1日で行うのは無理なので、実装は次回に回します。

tab探索ではてなブログの編集ページを見つけられないことがある【AutoHotkey】。

f:id:yasushiito:20190403184928p:plain

間違いを修正したら。

昔の記事に間違いを見つけて編集ボタンで編集したんです。
例えば紹介した Amazon のアイテムが間違えてたりとか。
過去を振り返らないブログといっても、この類の放置はさすがにまずいと 直すわけですよ。
それで Amazon のページを開いてブログ記事の編集フォームにコピペするボタンを押しますね。
Chrome のタブからはてなの記事編集フォームぽいものを探してペースト処理をしてくれるはずなのですが、ここで修正中の編集ページが見つからないんです。
それもそのはず。
記事表示画面からの編集リンクを押してもタイトルはおろか URL すら書き換わらない。
タイトルをキーに検索しているんだからタブが見つからないのも当たり前です。

selecttab(work,"ブログ記事編集 - はてなブログ")

こんな感じにはてなブログの編集ページのタイトルでタブを探しとるスクリプトは全てこれらの不具合が発生します。
スクリプトの実行が中途半端なところで終わってとってもみっともないので何とかしたいです。

対策を練る。

URL から編集ページの URL を生成してジャンプすれば良さそうです。
ところが、記事を表示する URL は日付をもとにしたもので、記事を編集する URL はエントリ ID を元にしたものです。
例えば先日の記事の URL はこんな感じです。
http://yasushiito.hatenablog.com/entry/2019/06/25/073000
それをダッシュボードの記事の管理から編集ページを開いた時の URL はこんな感じになります。
http://blog.hatena.ne.jp/yasushiito/yasushiito.hatenablog.com/edit?entry=17680117127205730030
entryの右側の数値または日付が記事を特定するための情報ですが、そのフォーマットはまるで違います。
それもそのはず。
はてなブログは著者が自由に URL を設定できるのですから。
日付からエントリ ID を変換することができないので URL を書き換える方式でのページ遷移は不可能となります。

ポップアップメニューをキーボードショートカットでいじくり回して編集ホームに移動できないものかと企みましたが、ページ内にはどこにも見つかりません。

ならば管理ページから該当記事を探し出してゴニョゴニョとできないのかと企んでも見ましたが、管理ページも JavaScript 主体のユーザーインターフェースになっていて Auto HOT key からは手を出せそうにありません。

結果。

3時間ほどゴニョゴニョやって無理そうなので諦めました。
労多くして功少なし。
足りないのはペースト処理だけでクリップボードには入っているので格好悪いけど妥協します。

せめてこれだけは。

こんな放置の仕方はあんまりだと思ったので、将来の自分が混乱しないためにもコメントを残せる形式にしておこうと思いました。
編集中のページを探す処理を関数にしてファイルを切り分けレバ注意書きをコメントで記述することができますし 、将来的に対策が取れそうな時にも修正が容易です。