備忘録などいろいろ

イロイロ! 比較的Twitterの延長のノリで書くと思います。

【PUBG】思いつき次第書くその1【初心者向け戦術】

最近PCを新調したのをキッカケに、PUBG (PLAYERUNKNOWN'S BATTLEGROUNDS)遊ぶようになったのですが、ここ数日初心者とSQUAD組むことがあったので初心者向けの戦術的注意点をこのカテゴリで思いつき次第書いていこうと思います。

 

なにぶん初心者向けなので高度な戦術については書きませんがご容赦ください。

 

分隊で行動するときは付かず離れずの距離感を保つ。目安15〜40m程度(?)

移動中に敵に目視されたとき、分隊員が近過ぎると一度に全員の位置が把握されてしまう。ある程度距離を取った状態で移動することで、1人が発見されて射撃を受けても、他の分隊員が迎撃や制圧射撃などの反応を取ることで最初に発見された分隊員を生かす確率を上げられる。

ただし、距離を取り過ぎると反応までに時間がかかり過ぎて被発見者が一気に気絶→死亡させられたり、気絶状態から蘇生に向かうことができなかったりする。あくまで程よい距離感を保つべき。

 

★適切に制圧射撃を行う

初心者のプレイでありがちなのが、隠密を気にし過ぎて撃たないこと。反撃を恐れるあまり分隊どうしの交戦状態になっても、敵の姿を目視し確実に当てられる状況になるまで撃たない、かと言って積極的に有利ポジションに移動する気配もない「待ち」の時間が長いように見受けられる。ソロプレイのときはそれでも一向に構わないのだが、DUO/SQUADでそれをやられると堪らない。

有利ポジションでもない場所での「待ち」をしているプレイヤーは死んでいるも同然で、そうなれば4対4の戦いだったはずが仕事しない味方により数的不利を背負った味方分隊の残りは忽ち殲滅されてしまうであろう。味方が3名気絶した状態から撃ち勝って3名蘇生するのは、隠密を破って被弾しつつ撃ち勝つよりも遥かに難易度が高いことが多い。

味方が敵と全面交戦しているが自分は敵を目視できない状況の教科書的な立ち回りとしては、味方に敵の方位/距離を教えてもらい、その辺に弾をばら撒くことである。立場を逆転して考えてみれば、射手の正確な位置は分からないが自分の近くに撃ち込まれている状況は、そうでない状況に比べてかなり行動の自由が制限されるはず。この制圧射撃を利用して敵に有利ポジションを取らせないようにすれば、キルこそ取れないものの味方のサポートという意味で武器になる。

もしくは、自分の位置が敵に把握されていない、かつ味方戦線はある程度時間稼ぎ出来そうな状況であれば、回り込んで側面から敵を討つことも検討できる。

撃たない、しかも移動しない、という隠密行動を選択できるのは、味方全員の位置が誰にも把握されておらず誰も撃たれる事がない状況のみに限られる。

Hue買った

PhilipsのHueホワイトグラデーション スターターキットを買いました。
スンバラシイです。
フルカラーはたぶん必要ないし高いので、ホワイトグラデーション。

帰宅したときは、自動で点きます。温白色でメインライトを明るめ、ベッド脇のスタンドライトを少し控えめに。

夜寝る時間になったら、自動でメインライトはオフ。スタンドライトは電球色で、明るさはフェードアウトしていきます。

朝起きる時間になったら自動で調光。フェードオンで0%→100%へ。色は昼光色でさっぱりと目を覚ます。

外出したら、自動でライト全消し。

コントロールできるのは、ザックリ昼白色から電球色の色味と、明るさ。
HomeKit連携もできるし、独自アプリでの操作も可能。
電気をスマホでいじれるからって何が良いのか分かってなかったが、使ってみて初めて判った。色と明るさをシーンに合わせて自動で調整してくれると、生活にメリハリがつく。意志力が足りないときの起床を助けてくれる。目指せ、課金で生活習慣改善。

iOS 11 SafariのCORSに関する仕様変更点

iOSのアップデートをしました。iOS 11です。
純正ブラウザであるSafariにも公表されていない仕様変更がいくつかある模様です。
今回はそのうちの一部であるCORS処理について。
※ 雑な検証の上で判った(つもりになっている)仕様変更点です。

【変更点】
CORS (Cross Origin Resource Sharing)関連のレスポンスヘッダである
`Access-Control-Allow-Origin`ヘッダーにワイルドカードが使えない(または、使えない場合がある)。

これまでも、`xhr.withCredentials = true` ならば`Access-Control-Allow-Origin: http:///hoge.example.net` のようにワイルドカードでない値を返す必要があったが、`xhr.withCredentials = false` でもそのようにすべき、という事になりました。
バグかもしれませんが、新仕様かもしれません。

【追記】上記はもしかすると大嘘かもしれません。追加検証中ですが、safariのブラウザキャッシュがOriginヘッダの有無を考慮していないのが原因で現在私がトラブっているだけかもしれません。

【追記】大嘘でした。開発中のWebアプリケーション内で、Cross OriginなResourceに対するリクエストが「1. browser-nativeなloader経由」と「2. XHR経由」で重複して発生しているのが原因でハマってました。
1が先に起こる=Originヘッダなしリクエストに対してCORS関連ヘッダのないレスポンスが帰ってきてブラウザにキャッシュされる。
続いて、2のリクエストが起こる=CORSヘッダの無いブラウザキャッシュが返るが、その後段のcross originチェックで弾かれてxhrがfailする。
という流れです。前々から気になっていたことですが、やはりSafariはブラウザキャッシュの管理が雑すぎて時々ハマります。

【追記終わり】


by-nameでAccess-Control-Allow-Originヘッダを作る方法。
S3の場合、CORS設定のルールの中で

<AllowedOrigin>*</AllowedOrigin>


となっている部分を

<AllowedOrigin>http://*</AllowedOrigin>
<AllowedOrigin>https://*</AllowedOrigin>


と変更すれば良いみたいです。
Thanks to 

stackoverflow.com


自前appサーバの場合は自分でCORSヘッダーをうまく作ってください。


Google翻訳ってラテン語も翻訳できるらしい

Loremのイプサム
「それは痛みのニンジンであるため、また、それはそれ以上である、ミネアポリス、...取得したいです」
「それの後に追求し、それを持って望んでいる痛み自体を愛する誰もが、それは苦痛であるという理由だけで、ありません...」

サカナクションとズワイガニについて

最近Apple Musicに課金するようになりました。今まで使ったSubscription型の音楽配信サービスの中で一番良い。
最近はロクに音楽も聞いてなかったので久しぶりに色々聴き漁っている今日このごろ。

前々から気になっていたんですが、サカナクションの曲を効いてると時々「ズワイガニ」という単語が聞こえるんです。しかもいくつかの異なる楽曲で。
それまでノリノリで聴いていても、「ズワイガニ」聞こえた瞬間「ズワイガニ」にとらわれて集中できなくなったりします(今もそのせいで集中が途切れたので書いています)。

使ったことあるSubscription型音楽配信サービスの個人的な評価
Apple Musicは無難
Amazon Musicはアプリの出来が少し悪いしおすすめのプレイリストとかラジオが収束的すぎる
レコチョクはアプリもWebも完成度が最低
Spotifyは弟が使っていたので少し触ったことがあるが、アプリの完成度は一番良いかも?




ズワイガニ」はサカナクションが複数回使用している雑踏?居酒屋の環境音?の音源に収録されています。




楽曲としては、思い当たるなかでは下記の通り。(白文字になっています。ドラッグで答え合わせ)
「intro = 汽空域」の43秒時点と「雑踏」の18秒時点
ほかにもあるかもしれません。

DOCTYPE宣言の有無で変わるレイアウト

DOCTYPE宣言の有無でレイアウトが結構変わると今頃気づきました。理由はググれば分かるんですが、参考までに具体例を示しておきます。

使用したコード

f:id:qpSHiNqp:20170714130021p:plain

例として"width: 100%; height: 100%;"指定のHTMLVideoElementの高さの変化をご覧ください。これの1行目のDOCTYPE宣言の有無で比較しています。ブラウザはmacOS SierraのSafariですが、Chromeでもほぼ同様の変化でした。

 

例1: DOCTYPE宣言なし

f:id:qpSHiNqp:20170714125635p:plain

 

例2: DOCTYPE宣言あり

f:id:qpSHiNqp:20170714125638p:plain

ブラウザのウィンドウ枠とか見にくいんですが、DOCTYPEなしだと高さはブラウザのウィンドウ枠いっぱいまで。DOCTYPEありだと"height: 100%"のstyle指定があってもvideoHeightにフィットしてそれ以上の高さになりません。

DOCTYPE宣言って大事なんだね。

【仮説】requestAnimationFrameよりsetTimeoutでアニメーションした方が旧端末で安定感ある

セオリーとしては、JavaScriptでアニメーション実装する場合はrequestAnimationFrameにコールバックを渡してやるわけですが、
setTimeoutでアニメーションしたほうが旧端末での安定感があると感じることが多々あります。
誰か検証してくれませんかね。