審問だと未確定の発言は何時までも発言フォームの近くに漂っていましたね。
物語の今の実装では流れていきますけど。


で、話し戻して。

例えば同時発表の時、審問だと６秒遅れ発表なんて職人技が有ったとおもうのですけど（３窓開いて、リロード繰り返して結果を見てから正しい方を発言みたいな）……ありましたよね？
審問畑じゃないから思いこみかもしれないですけど。

こっちだとそれは出来ないんです。
（サーバー負荷考えると歓迎できないけれど/笑）

10:05 あわせで 保留 60秒で発表
とすると、

10:04:00 60保留 真が発表
10:04:30 5保留 纏めがマーク発言
10:05:01 5保留 狂人さんが発表

とすると、発言順から実際に同時発表していないのが確実にわかるんです。

だから仕様的びみょうかなぁ……って。

あとあと、発言順を直しても、右肩の発言時間。
これがログ書き込み時間のまま（今の仕様）でも駄目ですね。
それも、発言時間の前後で同時発表していないのが判明しますから。

なので、余計な外部情報を持ち出されないためには、審問のように「確定時の時間」で「確定した順番に」表示されるようにしないとだめかなって。

もうひとつ、保留 0秒も必要ですね。

これで、5秒以内だから同時だとかって言い切ることも出来なくなりますし。

>>978
vil.cgiに保存かー。なるほど…。
そのほうが楽だったかも。

＞logデーターに fixtime エントリーを追加
これ、エントリー追加が分からなかったんですよね…。
というか、キューのときはちゃんとデータが保存されているのに、確定時にデータがクリアされてしまって。
どこかで受け渡しに失敗しているんでしょうけれど。

「保留発言が多くなると処理が重くなる」のは、保留時間に手を加えていない状態での素のスクリプトでも同様…なのかな？

>>980
美しくないのは確かですよね、発言番号や時間が前後するのって。
ただし時間表示を確定時間に変更する場合、物語国なのによそと動きが違う！ということになりかねないのが、ちょっとプレイヤー的に混乱を招くところかもです。
そして600秒保留は、今の状態だとどこに現れるかが全く不明なんですよね。
更新間際に発言が多かった場合、物凄く前のページにポコっと現れる。
それって気づかないまま見逃されてしまったりする可能性が…。
やはり最長でも60秒かなぁと思います。

>>983
ありましたね(笑)。
だから、遅れの最大値は5秒までで、6秒以上だと疑われたり…。
審問があったので、時間的なところがキツくなったのは確かでしょうね。

>>985
保留0秒か…。
正直、鳩の動きが分からないので、箱でしか仕込んでないんですよね。
鳩は20秒のままです。
保留時間変更って、私の場合「誤爆撤回」でしか考えていないです。
同時発表がどうこうという考えは無いんですよね。

どうしよ、vil.cgi方式に変えようかな…。
「審問がcookieで持っていた」と考えたのは、村を変わっても初期保留時間がちゃんとセットされていたからなんですよね。
ただ、今考え直すと、審問はユーザーページ経由で村に入っていたから…「村の参加者情報」ではなく、「ユーザーのログイン情報」のデータに記述してあった可能性が高いですね…。

とりあえず、うちのデバグ環境でも、次の村に入るときの第一声は設定保留時間が採用されます。
cookieから取っているので。
しかしvil.cgiかユーザーデータに記録すれば、動作的には一緒にできるなぁ…。

ええとですね、審問は同時入村できなかったですよね？
つまり、プレイヤーデーターに村情報が関連づけられていた筈なのです。
つまり、保留時間に関しては【プレイヤー毎に一定】なので、村を変わっても同じ値。

ということなのです。

そもそも、人狼審問は cookieは一切残してなかったはず。
cookie警告は一度も来た覚えないですよ。

>>968
ボタンの表示に手を入れない場合は重くなりません。

my $datalabeltext = <$fh>;
if (defined($datalabeltext)) {
chomp($datalabeltext);
if ($datalabeltext ne '') {
my @datalabel = split(/<>/, $datalabeltext);
$self->{'datalabel'} = \@datalabel;

# 移行処理
if( $self->{'datalabel'}[11] eq 'monospace'){
$self->{'datalabel'}[16] = 'fixtime';
}

}
}

>>990
そう言えば！

>>991
いや、フィルタ状態はＩＤ違っていても残っていたので…。
だから少なくともそこはcookieを使っていたと思います。
ＩＤまではちょっと、分からないんですけれど。

file_log_data.pl
のラベル変更は、新しく建てた村から有効になるんです。
なので、既存村に適用させるには、

file_ra.pl　にさっきみたいな移行処理用パッチを当てる必要があります。
既存村が全部終了したら、パッチを削除して、既存村の log.cgi のヘッダを書き直せば大丈夫です。

>>992
ボタンの表示というのは「〜に確定」という時間表示ですか？
私はこれ、結局、保留時間の秒数をcookieから取って表示させることにしたので…。
だったら問題ないのね。

それ以外のところでもしかするとパフォーマンスに問題が出ているかもしれないけれど。
特に退村者情報をvil.cgiに保持しているあたりが…。
これでlogidx.cgiに「pno」を記録しようとして、分からなくて断念しちゃったんですよね…。

>>994
あれ？
そうだったのですか。
セキュリティレベルで cookie 不要なところは面倒だから切ってる〜、最初から切ってたのかな？

それに保留時間は気にしてなかったし。

だったら、クッキーなのかもですね♪

>>993
…ヤバ、何をやっているのか良く分からない(汗)。
そもそもfile_ra.plって何をやっているんだろう？
今まで一度も開いたことが無いような気がする…。

>>995
既存村のヘッダ書き直し…。
村が多くなればなるほど、大変なことに…。

>>996
そうです。
「〜に確定」という表示。

初期実装だと、quelist を検索して logid が同じ物の確定時間を引っ張ってきていたのです。
それだと、未確定発言が多いと毎回キュー検索が走るので重くなるのですよね。
だかた、ログデーターに記録しました。

>>997
確かにＩＤやＰＡＳＳはＵＲＬに埋め込まれてました。
だから同時に複数の参加村を開けたんですよね。
ただしフィルタだけはどのページにも同じように作用されてしまうので、困った記憶があります。

めろんさんの方式だと、60秒保留の後に、5秒保留したら、60秒保留も 5秒保留ってひょうじされるのですね。

>>1000番 おめでとうですよ〜♪（笑

>>998
うちはスクリプトでやってるから。
ログファイルのサブディレクトリへの移動もスクリプトで。

file_ra.pl は配列形のデーターファイルの汎用ランダムアクセス処理担当です。