思い出した…。
審問では保留時間コミで確定時間が決まるんだった。
だったら番号が前後することは無いですよねぇ。

cookie ではなくって、発言（白・赤・灰・青・緑・紫）書き込み時に vil.cgi に初期設定を保存しています。
playerデーターに、'fixtime'というエントリーを設けています。
審問も動作的にはプレイヤーデーターへの保存だとおもいます。

確定時間は最初は、表示の時にキューデーターを検索していたのですが、保留発言が多くなると処理が重くなりますので、logデーターに fixtime エントリーを追加しました。

プレビューに隠し属性で埋め込んでいるので「発言」「独り言」ボタンを押したときのプルダウンの値が有効になります。　だから窓を沢山開いて、表で会話しながら、保留発言連投も出来ますよ。

鳩さんは今夜テスト国で試してから投入予定です。

表示順番についてはそれが仕様ですね。
審問は未確定データーは別に未確定として別に持っていた筈です、だけど、物語は発言と同時にログに書き込みますので。

確定時に順番を入れ替える仕掛けを設けるか、保留中の発言は別のところにデーターを奥かしないと確定順にはなりません。

確定順の方が見やすいのでそこはいずれ変更した方が良いのかなって気はしますけど。

保留時間の長い人が「誤爆対策として長くしている狼さんだ」

って言われたらと思うと。

審問ではあわせて発言確定時の時間が発言時間になっていたのですよね。
その方が良いかな？

発言番号の前後や、番号直しても時間の前後で保留がバレルのは余計な外部情報を持ち込んだって事になるので。

同時発表をきちんとしているよってのも【確実な証拠】が残ってしまいますから。

問題と言ったら、

■保留時間の情報が残ること。
■番号が前後してログが読みにくくなること

だけですね。
番号はログID由来だからシステム的な不具合はないはずですよ。

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


で、話し戻して。

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

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

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」を記録しようとして、分からなくて断念しちゃったんですよね…。