作者別: Halipeco

Home / 作者別: Halipeco

火曜はリセット日なので

2018-12-05 | Final Fantasy XIV, halipe.co | コメントはまだありません

なにかといそがしい。
明日から奥様がバイト行くっていうので、今日は夕ご飯のあとにレクリエーションをしました。いつも気の利いたこと思いつけないので、こういうのは我が家ではけっこう珍しい。

たまたまGoogleがクリスマスのアドベントカレンダー的にアレコレ詰め込んだサービスの塊を出していて、そんなかにScratch(教育用コンピュータ言語。ブロックつなげて動作を作る)をつかったパズルがあったので、一緒にやったりしてました。

奥様もかつては、あちこちのホームページを見てはScriptを目で追い読み込み手で試し、自作のCGIやらも含めていろいろやってたらしい。そのまま続いてたらそれなりに高給取りだったのにもったいない。
今じゃロジカルな部分など毛ほど見せない人ですけど、一緒にパズルを解くくらいは付き合ってくれるかなということで遊んでました。
上下左右に進むのとループのブロックだけのシンプルなパズルだったのだけれど、大変に楽しかったみたいで、よかった。

リセ日です。リセ日なのですが、明日以降は慣れない仕事でヨレヨレということを考えると、のんびり一緒にパズルで遊んでくれるのは今日くらいということでそんなんやってました。

ほんでそのあとFF14にログインし、地図のスクリーンショットを撮り、にーむのしょのイケてないスクリプトを修理し、アルファ編やらエキルレやらを積んできょうはおしまい。

今のとこ大して人も来ないしまるで使われてる気配のないしょぼいWebサービスですが、このまま更新続けていきます。この次に作るやつも粗々まとまっているので、そろそろ設計開始であります。

FF14の地図と座標の話

2018-12-01 | 未分類 | コメントはまだありません

はりぺこです。
半年くらいかかってヨロヨロ作っていたサイトをいまプレビュー的に公開(ロケハンちゃん(https://halipe.co/)しています。
あちこちの風景を切り取って素敵な写真にしてる人とかに使ってもらえたらと思ってます。

地図のスクリーンショットを撮ってはつなげる作業というのをやってます。言うまでもないことですがロケハンちゃんに使う地図をつくってるわけです。
スクリーンショットを保存するフォルダにはこれからやろうとする主にザナラーン地方とクルザス地方の地図の断片183ファイルがあたしの作業開始を待っております。
これは3ファイルが一枚の地図に、つまり地図61枚ぶんという、全部やろうとするとめまいを感じずにはおれない物量だったりします。
むろんそんなもんでは終わらない。ギラバニアもドラヴァニアも他のエリアもあるので、嫌になっちゃってブログ記事をかきはじめています。

よく、エオルゼアで見つけたいろんなことを文章にして残す立派な人々がいるのを思い出したので、大抵の人は気にもとめないであろう、地図の話を書いておこうと思います。
深い考察とかをしているわけじゃなくて、見てる範囲じゃこんなふうだよ~みたいなのを書きなぐるだけのエントリになるはずです。
あまりにも地味な話なんで、お暇な時にでもどうぞ。

座標の基本

学校で方程式と一緒にグラフ描きましたね。あれは(高等数学に行く前までは)左下がx=0,y=0で、右に行くについれてxが大きく、上に行くにつれてyが大きくなるというルールでした。
コンピュータの場合は、左上をx=0,y=0として画面をとらえます。
FF14の座標系も同じです。左上が1.0、右下がなんぼかの値を取り、必ず正方形の空間として設定がされています。

フィールド

フィールドとは、中央ラノシアとかああいう、いわゆるお外のことを指します。こいつらは(おそらく)例外なく、マップの左上の端を1.0、右下の端を42.0、もしくは44.0として設定されています(書いてて気づいたため冷や汗が出ております。一律42.0だと思ってた!!!)。これはもうラノシアなどの古いエリアが42.0で、3.0以降のフィールドだと44.0あるっぽい。
いやーまじか。これまじか。42と44あるんか。わー。一部データ直さないとずれるわ。。。

ダンジョン

いわゆるアイディーとかいうてルレでアレしてる遺跡や洞窟やその他諸々。バリエーションは実に豊かですが、いくつかの例外を除いて左上が1.0、右下が21.4となっています。サスタシャでも闇の世界でも同じです。

ダンジョン4枚とフィールド1枚が同じ広さなのね。
フィールドでも都市でも、うちのはりぺこさんやあなたのキャラクタは一定のスピードでの歩行と走行が可能です。一定時間内に移動できる距離の単位はIDでもフィールドでも同じでしょうから、そのルールに基づいて地図や空間が作られているということでしょう。
そのうち実際に測量でもしてみようかとは思ってますけど、おそらくダンジョンで使っている座標の数字の間隔は、フィールドとは同じと思われます。
ひとたび設定となるとすみずみまで偏執的にやりつくし、とくに空間に対するレギュレーションが厳しく設定されているFF14の場合、座標の設定を雑にするというのは考えにくいです。

ほとんどのエリアは1.0~21.4で空間が作られていますが、たとえばイシュガルド教皇庁は「いくつかの例外」に該当します。

ここはほんとに変わっていて、左上6.1、右下16.2という設定になってます。
迷宮や要塞、海賊の島やらと違って、たった一つの建物内に展開されているダンジョンですので自然と扱う範囲は狭くなります。地図はそのぶん拡大した状態のものを持たせてくれているということでしょう。IDの地図ってスカスカなのが多いので、教皇庁くらい拡大してくれると個人的には嬉しい。

これは古城アムダプール(Hard)のB1F。余白がもはや余っているとかいう次元でない。
あたしの作業的にはすごいしんどくなるんだけど、でもやっぱある程度拡大した地図を搭載してほしい。。。こんな要望間抜けすぎて出しにくい。。。

その他のエリア

変わり種というとウルヴズジェイル係船場があります。ハートマン軍曹みたいなおじさんがいたり、Pitがあるとこですね。
ここは左上3.5、右下8.6です。

なんで1.0~6.1じゃないんだろうという疑問はあるものの、たぶんこの島のある位置が半端なことに起因した数字なんでしょう。大変にこだわり(もしくはレギュレーション)のある設定の中にそれぞれの空間が切り取られているのだなあということがわかります。

へーそうなんだ~、というところでそろそろ作業に戻ります。よい週末を。

画像の変換が辛い

2018-11-29 | Final Fantasy XIV, halipe.co, Python | コメントはまだありません

ニームの書(https://halipe.co/

まだ全然データ足りないんだけど、色んな人にボコボコにしてもらうほうがモチベーション保てると思って見切り発車しちゃった。地図足りてないんで日々追加してます。

SS撮る(1600ピクセル四方くらい)→Firewirksでつなげてトリミング→色調補正バッチに食わせて出力→サーバに転送

なんてダルいんだ。色調補正バッチがうまいこと稼働してるので、地図張り合わせるのがすごくダルいくらいで済んでる、それはいいんだ。
今日の問題は色調補正バッチ。さくさく変換してくれるのはいいんだが、一枚あたり30秒かかる。ほっときゃいいとはいえ辛い。というか、あきらかに遅い箇所があって、さすがにバカなことやってる箇所だから直したい。

実験用にJupyterNotebook起動。

import os,sys,re
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
from PIL import Image
import matplotlib.pyplot as plt
import itertools as it
import time
%pylab inline --no-import-all

いつものやつ。余計なのも入ってるが気にしない。

img = Image.open(r"la-noscea_サスタシャ浸食洞.png")
im = np.array(img)

サスタシャの地図を一枚読み込む。
今回やろうとしとるのは、ゲーム内の画像そのまんまだと色調があまりにもくすんでいるので明るい感じに修正する、というもの。実際には前にやっていて(FF14の画像をバッチで画質処理+コピーライトの貼り付けしたい)、こんかいはそれのリファクタというかありえないコードになってるとこを直す話。

元のコード

30秒かかるのは流石にやばい。これ書いた当初は「画像の変換って時間かかるんだな~」とか牧歌的に思ってたが、PhotoShopがこんな速度でフィルタかけてたらAdobeは今頃地上から消えていたはずだ。
なにが問題かというとまあさすがに明白で、ピクセル一個ずつをループで丁寧に変換して歩いてるところ。当時は書き方わかんなかったし、改善よりも歩を進める事を優先したので斯様な惨状を放置する運びに。

なんでじゃあ改善するかというと、リリースしてガンガン地図増やすぞという頃合いになると、所要時間がだんだん冗談で済まされなくなってくるから。
いま作り終わってる地図が33枚あるんだけど、こいつの処理完了に15分かかる。ちょっとこれは引く。

修正後

あれこれすっ飛ばして結論。行列への関数適用をずばっとやってくれる関数を見つけたので、何となくこうですか的な具合で書いてみる。
0.27秒。意味がわからん速度が出た。いやわかるわ。30秒が意味分かんないわ。
ということであっけなく変換バッチの改善作業が終わった。

まったく苦労してないので、今回もまたnumpyとからへんが身につくほどの作業量にならずじまい。
画像の変換は触り始めると楽しいので、継続的にやってこうかなという気にはなってる。

こんかいつかったnotebook(gist)
https://gist.github.com/mezquita/0d4d99e2d66c9397949966840853779e

Firebase+Nuxt.jsでTwitter認証する

2018-09-26 | JavaScript | コメントはまだありません

tl;dr

API Keyの入力欄にAccess Tokenを入れたことに気づかず数日を無駄にした。
おわり。

以下のあれこれは、上記キーの取り違えに気づくまでの間にやった意味不明な作業のメモで、役に立たないです。どんなミスをしたのかを書いています。

—-

勘違いだらけで間抜けだったので罰として残します。
Qiita見てても分だの秒だの爆速だのでサクッとうまくいった記事ばっかなので、要領悪い記録が混じってもいいだろうと思って。

  • Firebaseにのっけたい。便利なツールが色々あるので使いたい
  • Nuxt.jsでWebアプリを書いてる
  • 認証をTwitterのやつ使おう
    (Google認証とか色々あるけどまずはTwitter)

余談ですがTwitter避けようぜキー発行厳しくなるし的な話ちょいちょ見かけますけど、個人的には厳しかったことは一度もない。
開発者アカウントの発行完了は秒でしたし、その後も特段困るような何かには遭遇してません。

API Keyを間違えてる場合

> code:”auth/internal-error”

のエラーが返ってきます。

FirebaseのAuthentication

Twitter側のコールバックURLに設定しろという謎のurlだが、これはFirebase側で引っ掛けて勝手に持っていく。
黙ってTwitter側のアプリ設定(Settings→Application Details
→Callback URLs)に入力したら、以降は忘れてよい。
自分のアプリ→Twitter→Firebase→自分のアプリ
と遷移するんだわな。
自前でやるときは自分のとこにコールバックさせるところを、ユーザ情報しまいこんだりする都合でワンクッション挟んでるだけだと(よくわかってなかった)。

https://myproject-id.firebaseapp.com/__/auth/handler

こんなん。
nuxt.js使ってるとアンスコで始まるurlって変数として使ったりするので、

  • こんな奇妙なページ用意せんとあかんのか?
  • でもそんなページ用意してる記事見かけないなー
  • はっ もしかしてこの辺が面倒で誰も記事書いてないの?
  • なんかGoogle認証だけで済ませてる記事はお茶濁してるの!?

という変な飛躍をし、nuxt.jsのrouterにextendRoutesして謎ページ作ったりすることで時間を浪費。

nuxt.config.js(無駄)

router: {
  extendRoutes(routes, resolve) {
    routes.push({
      name: 'auth_handler',
      path: '/__/auth/handler',
      component: resolve(__dirname, 'pages/Info/Hoge.vue')
    })
  }
}

上記のミスをするのは私が人類で最後です。
こんなことはせんでよく、ただPopupだかRedirectだか指定して叩けばいいだけだった。

最初から最後まで、たんに初手でApiKeyを取り違えたとかいうミスですべてが上手くいっておらず、それに気づかないまま迷走しただけの話でした。