そして R314SB-E (テレメトリ機能がある)に技適シールが貼られているのにも納得がいく

平常時は ID でパケットを探すことができるしホッピングパターンの衝突は送信機側で検知して空いてそうなのを探せばいいだろうからこれに近いことをやってそうだなあ、受信機は電波を発生させるものではないからオートチューンのラジオみたいなもん(=定義上技適の対象ではないのでマークが印刷されてないことに説明がつく)だし

ホッピングパターンはそこまで多くない(高々十数パターンのはず)から一定時間受信して全パターンのうち最も電波強度が高かったものを送信元として採用するみたいなシステムなのかな

そもそも FHSS / 周波数ホッピング単体では Bluetooth とかでも使われてる方式なのか

リンクモード中に最初に拾ったパケットに入ってる ID の送信機とリンクするとかそんな感じだろうか

そういえばフタバの S-FHSS 方式って見た感じ片方向通信なんだよな どうやってペアリングしてるんだろう

catch_unwind して panic 情報を保存してから戻ってくるみたいなおとをする必要性が低くなったということかな

なるほど Rust → C → Rust でもいいのか

このアカウントは、notestockで公開設定になっていません。

Cherry MX 規格、キーキャップ側の高さがまあまああるからスイッチ本体だけ低くてもなあ……みたいなところがあるのか。確かに。

そういえば最深ストローク長自体が短いのが売りの MX 互換キースイッチって見たことないな、アクチュエーションポイントが浅いのはいわゆるスピード軸として売られてるけど

MX ソケットなロープロキースイッチもうちょっと出てくれても良いと思うんだけどロープロが欲しい人基本的に Choc V1/V2 ソケットしか使わんしなあ

キースイッチのソケット規格な～～

というのを抜きにしてもアバターの最低の明るさの確保のためにライトを仕込めるかというとおそらく厳しい(誰から見ても自分だけに適用するみたいなのが Unity の仕組み上難しい+光の方向が多少なりとも出てしまうので)

MA 使ってないので MA 使うワークフローに対応できない

AnimationClip からいじる対象としては per-material ではなく per-renderer でいいんだけど、ビルド後にどういう Renderer があるかビルド前にチェックするのは微妙だしなあ

MA Component 自作するしかなさそう

そうか、合成後の衣装とかのマテリアルも変えないといけないか……

あれとは微妙に違うのか

十数人がかりで 2 万 HP ぐらいあるボスをタコ殴りにするやつだっけ

「Renderer 全体の」マテリアルプロパティ変更の挙動としてはこうせざるを得ないんだろうなあという気はしてきた(Trail とか Line とかいろいろあるし……)

@prime per-renderer MPB、oneshot ではなく毎フレームオーバーライドしているのでダメそう

え、もし需要ありそうならさっきの機能 declavatar にすぐ実装します

hogehoge.material[0]._Color みたいに指定しても Missing Property になるし hogehoge.m_Materials.Array.data[0]._Color みたいにするのも無理

AnimationClip のデータ見ると操作対象の名前として hogehoge.material.Color みたいなパスが指定されててマテリアルスロットは指定できてない

(前者は追加できなかったよね……？)

逆に言うとそういうことになる(Add Property からは追加できないし Inspector から動かすと全部動く)

この仕様を受け入れて
material key="_Hoge" value=0.5
みたいな感じでメッシュ全体でプロパティいじる機能追加してもいいかもしれない、Texture と Color を指定させるのがちょっと大変だけど

マテリアルの明るさ変えるレイヤーだけ入ってる AnimatorController 作って Merge Animator で合成するみたいな

MA だったら Merge Animator 使ったらいい感じにならないかな

これはバグだけど Animator から特定スロットのマテリアルのプロパティだけをいじれないのは仕様だしもうおしまいだよ

2019.4.31f 、Animator で複数マテリアルのメッシュのマテリアルを入れ替えると特定条件で入れ替えてないメッシュまで入れ替わるというバグがあるらしく : になった

自分で作るとまあまあ面倒なのよなあ

パラメータとしてはある(デフォルト 0.05)

ほたが詳しそう

最低の明るさってやつ？

音声/SMS 用に povo 残して au 網データ通信用にギガプラン追加しようかなあとなっている(音声付きでも ¥990/5GB/月だし……)

IIJmio ギガプラン、type-D はもうあるけど type-A どうなんだろ

最近外出る機会増えてきたので povo から移るかちょっと考えてる

Joy-Con

絵文字が書いてあるだけの投稿だけ配信できるようになりてすぎ

:hsp: (HSP のアイコン)
:hsed3: (エディタのアイコン)
:start_ax: :hsptmp: (ただのファイルのアイコン)

🥵🍲💻

あと Get で作った方は Delete に渡しちゃいけない(Release の方じゃないといけない)とか

HSP 関連でめっちゃ見た情報だ……ってなった

件の関連ツイートで出てきた GDI コンテキストが正常に解放されないっての見て老人になっちゃった

でも確かに仮想メモリと言ってページファイルじゃない方を指す用例が多いかというとそういうわけでもないので難しい(仮想記憶という訳語の方が採用されていることが多そう)

a~~~~

ていうか placement new って指定のポインタ位置で new するためだけの機能じゃなかったんだ(いま知りました)

@prime そういえば hoge->~Hoge(); で個別に呼べたんだった……

そういえば delete って placement new についてはどう処理してるんだろう

🦀

仮想メモリでググって出てくる情報の 99% がスワップファイルの説明をしており、肝心のページングや MMU によって実現される連続で独立したメモリ空間に触れられていない……

仮想記憶の方が本来の定義に近い情報が出てくる

Twitter の仮想メモリ云々で気になったのでググってみたら確かに「仮想メモリ」だと胡乱な記事が大量に出てくるなあ……

これトレンドで「ルフィの次」が入ってたやつか

このアカウントは、notestockで公開設定になっていません。

クランチ圧縮だけが展開される

1 月 0 日うまれ

実は餃子のうまい店所在情報はあんまり知らなくてェ……

駅西貫通も実現してほしいなあ

ぬらりひょん

8/26 開業ですよ！

昨日の試運転の様子

受信側でサーバー単位・(リモート)ユーザー単位で NSFW 設定できる方がいいと思ってるけど DB 的コストがな……

まあ natsukitten とか estayuke よりはだいぶ見たい美少女寄りだとおもう

evendon

まあ status id が単体だから JOIN せずにその先のユーザーを取りたいみたいなことだったのかも

"(at)kb10uy hogehoge" みたいなツイートがあったとして、 in_reply_to_status_id には当然 ID が入ってるんだけど "kb10uy" が格納されてる in_reply_to_username というフィールドがあった

ツイート内で最初に書かれたメンションでだいたいあってると思う

多分ツイクラを作る場合用途がよくわからんというだけで内部実装的にあると便利とかそういう類のフィールドだと今は思ってる

Twitter API 1.1 の Status 、当時としては用途が謎だった in_reply_to_username なんてのもあった気がする

僕が始めたころにはもうすでに ir2sid あったしなあ

「直接の返信先への参照」全般を表す言葉として in_reply_to_status_id が便利すぎる

後者の挙動僕はそこそこ使ってたんだけどまあ誤爆のリスクもあるわけでそれ考えるとどっちも捨てがたい感じあるんだよなあ

リプライ、丼 WebUI デフォルト挙動の「強制的に投稿欄がクリアされる」のと旧 TweetDeck の「メンションと ir2id が追加される」のとどっちがいいんだろうねえ

「信頼を失う」

いまはもうなくなったと思いきやニコニコで発生するのか

pixiv のマイページのリンクを貼るひと