先週の日記書いたのに上げてなかった。いっしょに上げておこう。
日曜にTRPGやろうと思ってたんだけどプレイヤー集まらず中止になった。
原因はいろいろあるわな。
準備ができてなくて、ルールブックをちゃんと読み始めたのが一週間切ってからだとか。 自分がルールを把握できてないので、ルールブック無い人でもいいですよーとは言えなかった。
ダブルクロス3rdをやるつもりだったが、ダブルクロスについて説明不足だったってのもあるな。どんなゲームか説明してなかった。 もしルールブック無い人でも大丈夫だと言えてもプレイヤー集まらんわ。
告知が不十分だった。とはいえここで告知すればいいという場所が無いのが難しい。
時間が合わなかったかもしんない。その時間は寝てたという人があとから出てきたんだけど、いや日曜の昼過ぎなのでみんな寝てることを予期できる時間ではないのだけれども、ピアキャス民の活動時間的には土曜夜の方がいいのかもしれないという気はする。 どのくらいの時間で終わるか明示してもらえると参加しやすいという話もある。オンラインセッションの時間感覚がわからなかったので明示できなかったんだけど、準備さえちゃんと整っていればオフでやるのとそれほど変わらない感じという気はしたので次からは明示できるかも。
以前やったクトゥルフとSW2.0はまあなんとかプレイヤー集まったんだが、もしかしたらそのくらいメジャーなタイトルじゃないと誰もやらんのではないかという危惧もある。 確かに知らんゲームって参加しづらいよなぁ。でも俺はいろんなゲームやりたい。クトゥルフとSW2.0やって慣らしてから他のゲームに手を出すってのも考えたけど、きっと他のゲームになった瞬間にみんなやらなくなるんだろう。おおこわいこわい。
知らんゲームに参加しづらいってのは、やっぱり充分に説明できていればハードル下げられるだろうな。ダブルクロスは……ちょっと説明難しいな。俺が説明しやすいゲームをやるべきだ。
そんな話をしつつ、次回の予定を考えてみた。
日付だけ先に決めて準備が進まなかったのはよくなかったので、準備が出来た時点で日時を決めることにした。しかし間が空くとまたやらなくなってしまうので7月末から8月頭くらいを目安にしたい。
ゲームは準備が簡単な物をやりたい。
クトゥルフはきっと人も集まりやすいだろう。ルールブックは6000円もするが、ルールは簡単だしゲームをやる上で必要なデータも少ないのでプレイヤーがルールブックを持っている必要はない。 問題はシナリオを作るのがけっこう大変なことだ。 ダイス振ってれば終わるゲームじゃないというか、ぶっちゃけダイス振らなくても(振った結果失敗しても)とりあえずいいところまでは進むように作らないといけないのがしんどい……。
ハンターズムーンもやってみたい。 データは必要だが1巻分だけなら資料用意するのもそんなに大変ではないだろう。 ルールブックは手に入りやすいとは言えないが1500円でリプレイもついてくるので値段的にはそんなにきつくない。 ルール自体も複雑なところは無いからプレイヤーがルールブック持ってなくても説明は簡単だろう。 あと何がいいってダイスさえ振ってれば終わるゲームだ。 オープニングをちょろっと演出したらあとは戦ってるだけだからな！GMもプレイヤーも考えずに進めるので楽ちん。 問題は戦闘は真面目にやらないとすぐ死にそうってとこだな。やっぱりプレイヤーもルールブック欲しいかもしんない。 あとやっぱりマイナーな感じではあるので説明しないとわからんってことですな。 現代でモノビーストっていう一般人には見えなくて満月の夜にしか殺せない化け物をみんなで倒しにいってぶっころしたりぶっころされたりするゲームですよ、でほぼ全部なんだけど。あとほぼ全編戦闘な。
とりあえず準備は両方してみるのがいいかもしんない。頑張ってみよう。
先週は帰省した。しかし温泉に行くとのことで猫にはあんまり触れず。
戻ってくる時に東北新幹線のグランクラスに初めて乗った。2時間くらいだしもったいないかなーと思ってたんだけどいつも気になるくらいなら一回乗ってしまえと。
18席しかなくて高級感溢れる車内でうひょーとか言ってしまった。乗るとすぐに乗務員が来ておしぼり持ってきて、飲み物と食事とデザート的なのをどうするか聞いてこられた。そんなんこっちが恐縮するわ。 ごはんは普通においしかったし、食い終わったころにはゴミ回収もされて飲み物もう一杯どうですかとか聞かれた。至れりつくせりだなおい。
飯とか飲み物もまあよかったけど、やっぱり一番良かったのはシート。広いし寝れるくらい倒せてフットレストが伸びてきたりもする。いくら倒しても後ろのシートに影響無いようになってるから気兼ねすることもないし、片側一席しかないところに座ったので隣を気にする必要もなかった。っつーか途中まで俺しか乗ってなかったし、あとから乗ってきた人も遠くに座ってたのでそりゃ全く気になるわけないんだけど……。でも席が埋まってたとしてもそんなに気にならないと思われる。乗務員が行ったりきたりするのは気になるかもしんない。
2時間だとちょっと短くて残念だけどよかったねー。グランクラスの料金だけで9000円と倍になっちゃうけど無理っていう値段ではないので、一回乗ってみるくらいには払える。というかグリーン車とか無いわ。普通の指定席と何が違うんだかわからんグリーン車に4000円払うならあと5000円追加してグランクラス乗れよってくらい違う。まあ高いからもう乗らんだろうけど。2時間しか乗ってないし。
途中郡山から俺以外の客が乗ってきたんだけど、郡山→東京って一時間しかないんだよね。一時間のためにグランクラスって運賃+特急料金よりグランクラスの料金の方が高いんでねーの。これが本当の金持ちですか。
直したつもりのCPU食い潰しがまだ発生するよーということなので調べてみる。
といってもついこの前のが再発してることはないだろうしなぁと以前のCPU食い潰し問題を再現できるテストを動かしたら落ちた。InvalidOperationExceptionというのが出てるな。エラーで落ちる報告も上がってたのはこれだろうか。
原因は簡単で一旦切れて接続スレッドが終了したチャンネルに再接続リクエストが殺到すると、スレッド再立ち上げ処理中にスレッド再立ち上げメソッドに再入されて落ちてた。確かにそんなこともあるなぁ。
受信用のスレッドと送信用のスレッドが競合しないようには考えてたつもりなんだけど、送信用のスレッド同士が競合するってのは考えてなかった。最初は再接続リクエスト無かったからかー。
スレッド再立ち上げ処理を排他制御すればいいんだけど、競合する可能性は他でも沢山あるのでちゃんと直したいところ。うーん。
あと受信スレッドが終わってるのにチャンネルの状態がずっと接続中になってしまう問題は、受信スレッドの終わり際に送信スレッドから再接続要求が来ることで起きてた。受信用スレッドと送信用スレッドの競合発生してるじゃないですかー！
これは再接続処理をする前に受信スレッドが終わり際かどうかチェックすればいいだけなんだけど、チェックした時に終わり際だったらどうすりゃいいんだろう……。まともに考えると切断処理が終わったあとに再接続始めるべきだろう。でも切断処理終わると受信スレッドも終わっちゃうからその後から再接続処理するってのが現状できないな。
スレッド再立ち上げ処理で競合が発生する原因でもあるんだけど、受信処理はオブジェクトの生存期間とスレッドの生存期間が一致してないのがまずいな。送信側はほぼ一致してるのでそんなに難しいことになってない。接続切れたあとも再接続がありうるんだからとスレッドを立ち上げっぱなしにしとくか、スレッドの再起動を許可せず再接続時には受信処理オブジェクトを再作成するかだな。再接続要求の受け付けさえなければ切れたら終わるだけなんで簡単なんだけどなー。
結局大変なので切断処理始めた状態での再接続要求は単に無視するだけにした。これで少なくともずっとチャンネルがSEARCH状態のまま残ることはなくなった。
でまあCPU食い潰しに戻るんだけど、やっぱり再現はしなかった。
しかしありがたいことに発生した状況のスクリーンショットはもらえた。RECEIVE状態で受信処理は接続中あるいは接続されていると思い込んでいる状態で、送受信レートは0kbps。視聴接続が10本以上つながってていずれも0kbpsで止まっているという状態だった。これは新しい症状だな。
受信処理でも0バイト受信で無限ループすることがあるかっつーと、受信側は最初から0バイト受信すると切れるようになってるように見えるので発生しないと思われる。受信と同じように0バイト送信が連続で行なわれてたら無限ループは起きうるけど、わざわざ0バイト送信しようすることはないし、送り切れなかった場合はエラーになるので0バイト送信はないな。あったとしても送信開始時には未送信バッファクリアしちゃうからそんなに送る物なくてCPU食い潰しはしない。
視聴接続が10本以上つながっちゃうのも気になる。チャンネルは正常に接続されているように見えるのにプレイヤーには一向にデータが送られてこないので再接続が何度もかかってるんだろうという気はするんだけど、以前の接続は切れないものだろうか。切れてないのに再接続されてるってのも不思議だがプレイヤーが何やってるかよくわからないからなぁ。
視聴してるチャンネルが終わったあと延々と最後の部分が繰り返し再生されるという報告があった。
俺が使ってる分にはそんなことはないんだが、プレイヤーとの相性のようだ。プレイヤーが視聴再接続をしてきた時に貯まってる最後の部分のパケットを返してしまい再生されて終わるのでまた再接続をしてきて……という感じだろう。
HTTPの視聴出力の時にRangeやら何やらを見て途中から返すってことをしてないのが悪いんだろうなぁ。それだけじゃないかもしんないけどとりあえずそこは悪いだろう。なんとか対応できるといいんだけどどんなリクエスト来てるのか確認しないといけないな。
あとチャンネル終了しましたという通知が延々と出てしまうという報告もあったんだけど、これも同じ問題の可能性があるな。 普通にチャンネルの終了を検出するんだけどプレーヤーから再接続要求が来る。再接続してみるんだけど終了してるんでチャンネル終了の通知を出す。しかしまたプレーヤーから再接続要求が来て……という流れだと思われる。プレーヤーはなんで何度も再接続要求しちゃうんだろう。何を判断して終わったことにしてくれるんだろうなぁ。
予想としては再接続したあとにちょっとでも再生できたら再生できたことにしてそのあと切れると再接続要求するようになってるのかな。なので最後のパケットを投げ直すのをやらなければ再接続諦めてくれるんじゃないかと思う。
最後のパケット投げ直さないってのがちゃんとできればいいんだけど、リクエスト時に上手く判別できる情報渡ってきてくれるかな。こればっかりはプレイヤーの動作見てみないとわからんな。
あーERRORになってるチャンネルの再接続をした時に貯まってるパケットクリアするってのがいいかもなぁ。