忍法帖に関する新しいアイデアを話し合うスレ

【忍法帖 開発スレッド Part22】
> 145 忍法帖【Lv=9,xxxP】 ◆xvQwATc0eQ (WiMAX) [sage] 2011/11/29(火) 13:26:46.63 発信元:49.133.117.70 0 ID: Be:
> 決まったらおしえてー
> 変更するよ

もう一度ここで決めた方がよさそうだ

(a) Lv2 の書き込みバイト数＝384 が適切？
(b) Lv1->Lv2 の時間（新規HAP発行から書き込めるまで) 2分→5分?

>>844
それだとうちは助かる。
でもここで異論が出てた部分を考慮しないといけない。なので。

作成時 Lv=1
初めて書き込みで Lv=2
8〜12時間後 LvUpしてLv=3
破門で Lv=0

これだと水遁を受ける可能性のない一般的利用者が半日である程度書けるようになるのではないかと。

>>844
24時間384バイトで困るのは荒らしだけなので考慮する必要はないと思うが

勝手に決めたと言われないように少し時間をかけたほうがいいと思う
里も隠し板ではなくなったし、興味のある人は見に来るでしょ

そうだね。

まあそうしてる間にまたうちは埋められちゃうんだけどねｗ

凄い裏技発見したったｗｗｗｗ半勃起中に玉だけ股で挟むと(この時、足を交差し太ももで挟むことを意識するとやりやすい)今までに無いくらいフルボッキするぞｗｗｗｗｗｗｗｗ
亀頭が真珠のように黒光りし、血管がミミズのように浮き上がるｗｗｗｗｗｗｗｗ
これで俺もデカチンｗｗｗｗドヤｗｗｗｗ

844（ID変わってるかな）ですが、とりあえずたたき台です

384バイトも 5分も K5をはじめとする埋め立て系あらしに対する実験中で、
新規投稿5分待ちが Lv1の書き込み間隔になってしまったのでレベルシフトが起こったと。

●育てHAPでの●時限焼きが実装されたということなので、シフトした分を戻し
実験を再開して様子を見るというのもひとつの考えだと思います。
（この辺はK５部隊さんが詳しいのかな？）

まずは一度決まった24時間384バイトをレベル2にずらして同じ効果をもたらす
変更の話はその後にしないとせっかく効果を発揮していた投稿容量制限の見直しが無に帰すことになる

>>844
(a)
開発室の意見を持ってきてみる

> 123 名前：名無しさん＠お腹いっぱい。(たこやき) [sage] 2011/11/28(月) 21:38:59.89
> >>84
> 固定（500byte）かBBS_MESSAGE_COUNTの0.3倍の小さいほうを使うがいいな〜
> いちおう1000近く書き込まないと500ｋバイトいかないだろうし
> ・・・言ってみたかっただけです
>

>>844
(b)

Lv=1 240（忍法帖作成後カキコまでの待ち時間）
Lv=2 120（以下、連投間隔）
Lv=3 90
Lv=4 60
Lv=5〜6 45
Lv=7〜8 30
Lv=9〜10 20
Lv=11〜20 10
Lv=21〜30 5
Lv=31〜35 2
Lv=36以上 1

>>850
今だとlv2の上限でで500レスも打てば容量埋め出来てしまうので、ちょっとしんどいかなというところです。
実際うちは今97レスで77KB　前スレが755レスで500kb超え　前々スレが800レス　その前が814レス
●で育てて旧Lv3で埋め立ててきていたのです。
今は●を使わなくても1600byteまで書けますから水遁の効果が出なくなってきてます。
これが現行のLv2が384〜512byteになれば「●で育てて容量埋め」というパターンは回避できるようになるかと思います。

844,850です（しまった！まとめ役にされてるw）
たぶん、バイト数や時間の細かい所はすんなり決まらないと思います。
あらし対策から見たらキツめがいいでしょうし、利用者側から見れば
そんなのやめろとなるでしょう・・・

狼（全角）さんのところは埋め立てで困ってるなら 4096バイトもいるの？
というのもありますし（でも自治では決まらないんだろうなあ）、
里はせっかく増やしたけど（水遁された人が）報告しにくくなっちゃった
というのもあるかと思います。

私自身は850でも書きましたが、
実験の途中だったんでいったん戻して再開して効果が薄かったらまた考えよう
というスタンスです。

Lv2は384バイト固定で連投は>>853でいいと思う

wikiを見たら中途半端になってるのね・・・
http://info.2ch.net/wiki/index.php?%C7%A6%CB%A1%C4%A1%B4%AC%CA%AA

1レスのメッセージ容量制限 †
現在のレベルに応じて1つのレスに書き込めるメッセージの長さが制限される。
ただし、２ちゃんねるビューア（●）にログインしている場合は適用されない。
レベル　最大メッセージ長
Lv=1 　384bytes（シフトJISの全角で192文字）まで　　　　＜＝このLvでは投稿できないので無意味
Lv=2 　BBS_MESSAGE_COUNTで設定される値の0.4倍まで　＜＝これを固定値（384bytes？）に変更する
Lv=3 　同値の0.5倍まで
Lv=4〜5　同値の0.6倍まで
Lv=6〜7　同値の0.8倍まで
Lv=8以上　同値の1.0倍まで

(>>857の続き)
「書き込む」ボタンを押した際、「忍法帖」のCookieを持っていなければ
下記のエラーメッセージが返され、サーバはLv=1のCookieをブラウザに渡す。
ＥＲＲＯＲ！
ようこそ：貴方の忍法帖を作成します。５分後に再度書き込むか、お帰りください　＜＝メッセージは5分

連投間隔制限 †
現在のレベルに応じて、「忍法帖」が適用されるレスの書き込み可能間隔が制限される。
ただし、書き込もうとする板のsamba値よりは短くならない
レベル　連投間隔（秒）
Lv=1　300　　　　　＜＝現状は120(2分)
Lv=2〜3 60　　　　＜＝Lv2は60だけど以降は本当にこうなってるの？
Lv=4〜5 45
Lv=6〜7 30
Lv=8〜19　15
Lv=20〜29　5
Lv=30〜34　2
Lv=35以上　1

>>844 (a)
一律の固定値にするのは、あまりよい策ではなかったように思います
BBS_MESSAGE_COUNT が大きすぎて困る板は板で話し合って小さくするか、
BBS_MESSAGE_COUNT_LV1(LV2?) を新設して板ごとに設定可能にした方が
板の個性が失われなくていいと思います

一律の固定値にすると、弊害の出る板(たとえ一部の住人でも)もあるし、
板ごとに設定可能なら、板の自治次第で、極端な話、1バイトとかでもできるので、
柔軟な対応ができると思います

>>859
それは忍法帳導入の意図を忘れすぎてる意見だと思うね

ちょっとまて
384バイトでも足りないと批判されてるのに
さらに少なくするってどういうことか

>>860
こういう部分ですかね。

>「忍法帖」はCookieを用いてブラウザごとにレベルを設定し、連投やスレ立てにレベルに応じた制限を課すものだ。
>制限というと反発するちゃねらーが多いようだが、心配は無用。ふつーに２ちゃんねるに投稿していれば徐々にレベルが上がり、制限は緩和される。
>おそらく数日〜1か月ほどで「忍法帖」の存在が気にならなくなるはずだ。
>荒らしには多くの制限を課し、そうでない継続利用者には従来どおりの環境を提供する、それが「忍法帖」なのだ。

Lv1が初投稿者なのか水遁された荒らしなのか判別するのが難しいので大変ですが。

>>861
そこはLv3への上昇を23hから8〜12hにすればほぼ回避できるかなと。

>>86
2LvUp間隔が8〜12hとか面倒なことしなくていいだろ
Lv2の容量だけ固定でLv3以降は同じなら前より1日早くLv3になるし
Lv2の容量をいくつにするかって話だよね

863は>>862

>>844
(a)
とりあえずスライドさせる案>>850

Lv=1〜2 384bytes（シフトJISの全角で192文字）まで
Lv=3 BBS_MESSAGE_COUNTで設定される値の0.4倍まで
Lv=4 同値の0.5倍まで
Lv=5〜6 同値の0.6倍まで
Lv=7〜8 同値の0.8倍まで
Lv=9以上 同値の1.0倍まで

>>844
(a)
500byteを上限にして0.3倍で可変>>852

Lv=1〜2 固定（500byte）かBBS_MESSAGE_COUNTの0.3倍の小さいほう
Lv=3 BBS_MESSAGE_COUNTで設定される値の0.4倍まで
Lv=4 同値の0.5倍まで
Lv=5〜6 同値の0.6倍まで
Lv=7〜8 同値の0.8倍まで
Lv=9以上 同値の1.0倍まで

>>844
(b)
とりあえずスライドさせる案>>850

Lv=1 300
Lv=2 120
Lv=3〜4 60
Lv=5〜6 45
Lv=7〜8 30
Lv=9〜20 15
Lv=21〜30 5
Lv=31〜35 2
Lv=36以上 1

あまり人が集まらないなぁ
連絡スレで告知したほうがいいかな？

あれだけ書き込みに来ていた投票所の人もすっかり見なくなったし
肝心な時に人がいない・・・

(b) 発行5分の件
【★111118 複数 通称「Ｋ５」によるコピペ荒らし報告スレ11】
http://qb5.2ch.net/test/read.cgi/sec2chd/1321552924/182
> 182 ◆G3E3Ee8IMBFg-隠居♪ [] 2011/11/24(木) 01:28:29.17 ID:7oSdtwbF0 Be:
> 発行に五分かかるようになるとどうなると予想されるんだろう

http://qb5.2ch.net/test/read.cgi/sec2chd/1321552924/294-296
> 294 忍法帖【Lv=20,xxxPT】 ◆xvQwATc0eQ [] 2011/11/26(土) 17:02:09.96 ID:zBMLv17E0 Be:
> んで、忍法帳最初5minっていうのはK5にどんな影響を与えたかな?
>
> 295 名無しの報告 [sage] 2011/11/26(土) 17:07:15.34 ID:aBt2HUYS0 Be:
> それとほぼ同時にe-mobileも規制してたから何も分からなかったんじゃない
>
> 296 忍法帖【Lv=21,xxxPT】 ◆xvQwATc0eQ [] 2011/11/26(土) 17:09:06.88 ID:zBMLv17E0 Be:
> そっか

384bytesについても効果があったのかなかったのか、実験したいのか etc の意見が出てこないですね・・・

>>870
効果なら有ったよ。
Suitonされながらだとスレが潰せなくなった。
容量が足りないからね。

いまも潰せないけどせっせと埋め立てしてる。
本人はそこで会話できなくすることを目的でやってるが、
潰せずに延々と続けることで、他のスレへの被害が無くなったので目論見通り。
縛り付けておくためにSuitonと削除を繰り返してる段階。

下手に完全に穴ふさぐと、また別の手口で荒らそうとするから、
とりあえずこの状態を維持するのがベター。
もう少しスピードは押さえられたら尚良し、くらい。

resのHP作って3回くらい攻撃したら透明あぼ〜んするくらいの機能がつけばいいのか

>>866の固定値についてはBBS_MESSAGE_COUNT=2048 の板の下限614Byteで良いのではないでしょうか
この状態だとスレを容量落ちさせるまでに800レス以上、時間にして27時間近く必要（>>867より）な訳ですし
それだけのコストがかかるなら荒らし対策としては十分なのではないかと

よしそれでいこう

>>873
レベルによる制限倍率0.4〜1.0をそのままスライドさせた場合

BBS_MESSAGE_COUNT=1024

Lv2=614B
Lv3=409B
Lv4=512B
Lv4、5=614B
Lv6、7=819B
Lv8以上=1024

こういう不整合が起きるんですよね
従来でも交通情報板みたいな特殊な所では起きる可能性はあったんですけど

>>873
最低２日は要るよ。
荒らししか書き込まないわけじゃないだろ。

>>875
それだと従来の2倍にもなってしまうから意味がないね

>>875
その問題は
1. 固定値かBBS_MESSAGE_COUNTの0.3倍の小さい方を採用するようにする
2. BBS_MESSAGE_COUNT=1024の板は一律制限の対象外にする

のどちらかで良いかと

>>866 さんのように
Lv=1〜2 固定（XXXbyte）かBBS_MESSAGE_COUNTの0.3倍の小さいほう
で XXXをいくつにするかでいいかも

XXX候補＝384, 500, 614

順調に行ってた数値をスライドで問題ないかと

(a)
Lv=1〜2 固定（384byte）

Lv=3　BBS_MESSAGE_COUNTで設定される値の0.5倍まで
Lv=4〜5　同値の0.6倍まで
Lv=6〜7　819バイト　同値の0.8倍まで
Lv=8以上 　同値の1.0倍まで

>>880

間違えました
(a)
Lv=1〜2 固定（384byte）

Lv=3　BBS_MESSAGE_COUNTで設定される値の0.5倍まで
Lv=4〜5　同値の0.6倍まで
Lv=6〜7　同値の0.8倍まで
Lv=8以上 　同値の1.0倍まで

384Byteで順調だったのならあんだけ不満は出ないだろ
埋め立てペースを考えれば384Byteまで制限する必要は無い

384バイトってどういう根拠で出した数値だったの？
イマイチ理解できないので決定された過程を3行、あるいは元議論スレURLぷりーず

うん。そのままスライドでいいとおもうよ。

>>883
このスレ

>>883
384バイトについて >>657
議論の始まりは >>640 〜

その全角192文字って数字に何の「根拠」があるのっていう

>>885
じゃあ>>657が初出で、その数値を割り出した議論は他で無しってことなのかい？
規制議論の荒らし報告スレあたりで対象埋め立て対策を話し合っていて出てきた数値とかじゃないということかい？

>>640以降でここで意見を求めたけど連絡スレとかで告知をしても人が集まらなったんだもん＞＜
そんななか>>657が意見を出してくれてご隠居がそれを採用したんだ

>>888
◆Pb1ksT6CvrFp-8♪さんの水遁履歴を見るとK5などの容量埋め対策とかの人なので。

>>886もだけど
>>889>>890
どもね
なるほどなるほど
じゃあ根拠は無いってことか
何かの元数値から計算して出してきたのかと思っていたけどそんなことは無かったのか
全角192文字分という意味はあるらしいけど

例えば、現行1スレッドの容量上限からとか、K5の使うコピペの1つからとかそんな風なところから計算してるのかと思っていたんよね

ここをちゃんとしとかないと許容できないって人もいると思うし今後も一々うっさいと思うんだよね
最初のLv1=0.3倍っていうエイヤッという設定はそれなりにうまく動いていた（つうか微妙に微調整していたと思うけど）からあまり気にならんかったけど
固定値にするというのは良いアイデアだったんだからその固定値を練らんといかんと思うのよね

512kb÷1000=524bytes とかさ

まぁ、あの時は一般ユーザーの不利益を訴えてみようと思ったけどゴリ押しされた感があったねｗ
おかげで結構おもしろい展開になったからいろいろ堪能できたけどねー

>>891
500byteだと>>875で逆転現象が生じるからじゃない

>>891
根拠は板設定の最小値であるBBS_MESSAGE_COUNT=1024の板に合わせたってことでしょ
1024×3ってことで
レベル1を固定したのは板の独自設定に影響されないようにってこと

>>893
そうそう、そういう議論しなきゃってことさね
後から来る人はさっぱりわからんことになるからさ

384バイトでも何でもいいけどBBS_MESSAGE_COUNT=1024が基準になってますとか
そういう説明できる状態じゃないとさ

>>893
そうそう、それもある
「仮に」384バイトで例を出したらそのまま採用された
そして>>880の384バイト固定をレベルスライド案でいいと思ってる

埋め立て荒らしのサンプル
http://yuzuru.2ch.net/test/read.cgi/car/1322215317/410 892バイト
http://hato.2ch.net/test/read.cgi/entrance2/1319096115/220 604バイト
http://yuzuru.2ch.net/test/read.cgi/bicycle/1321573426/250 423バイト
http://yuzuru.2ch.net/test/read.cgi/bicycle/1321573426/251 496バイト
http://yuzuru.2ch.net/test/read.cgi/bicycle/1321573426/256 568バイト
http://yuzuru.2ch.net/test/read.cgi/bicycle/1321573426/257 514バイト
http://hato.2ch.net/test/read.cgi/lifeline/1322278069/132 440バイト

投票レスのサンプル
http://yuzuru.2ch.net/test/read.cgi/vote/1322490890/383 405バイト
http://yuzuru.2ch.net/test/read.cgi/vote/1322490890/388 205バイト
http://yuzuru.2ch.net/test/read.cgi/vote/1322490890/389 142バイト
http://yuzuru.2ch.net/test/read.cgi/vote/1322490890/390 416バイト
http://yuzuru.2ch.net/test/read.cgi/vote/1322490890/391 301バイト
http://yuzuru.2ch.net/test/read.cgi/vote/1322490890/392 396バイト
http://yuzuru.2ch.net/test/read.cgi/vote/1322490890/394 498バイト

ということを言いたいから>>883で問いを投げかけた訳よ
意見くれって言われてもその元ネタなりベースなりを説明してあげないと
なぜその設定が提示されているのか、そこからどういう別案が考えられるのか、が
なかなか出て来ないと思ってね

ここを見てる内輪だけで決めるというならそれもまた良し
苦情処理も全てここで片付けられるなら、ね
でもそれは「話し合って決め」たことにはならないとは思うけどさ


と書いてる内に
>>896
ｲｲﾈｲｲﾈ
そういう生のデータを集めてくれるのはとても良いよ

>>881
初カキコの次のレベルが0.5倍ってことは
スライドさせる案>>850 と違って
制限を緩和するってこと？

だから逆転現象が起きる板はスルーするようにすればいいだろと言ってる訳で
議論の出発点がBBS_MESSAGE_COUNT=4096の板での埋め立て荒らしを何とかしようって話なのに
なんで2048の板まで制限する必要があるのか、納得できる説明は一つも無い

あとさ、軽く決められた感があってぐったりしてたから変忍報告のテンプレも
レス分割しないといけないなんてのもツッコミ遅れてたのよねー

>>900
何事もやってみて困ったとき考えよう!!　ということなんじゃないかね？

潜在的に泣き寝入りさせちゃった人いなきゃいいんだけどね

>>898
単純スライドなら >>865

最低レベルをキツくするから他は緩和しても良いのでは？と思ったりもする

>>898
完全にスライドさせるならこうなります

(a)
Lv=1〜2 固定（384byte）

Lv=3　BBS_MESSAGE_COUNTで設定される値の0.4倍まで
Lv=4　同値の0.5倍まで
Lv=5〜6　同値の0.6倍まで
Lv=7〜8 　同値の0.8倍まで
Lv=9以上 同値の1.0倍まで

アンカー間違えたか
補足説明サンクス

誰かこの辺りに議論してるから意見募集って書いてきてよ
俺は出しゃばり過ぎなんで今回はパス

【至急】忍者連絡・呼び出しスレッド 3
http://hato.2ch.net/test/read.cgi/sato/1312459113/

【報告・連絡・相談】質問はこちらで 5巻目
http://hato.2ch.net/test/read.cgi/sato/1321757974/

悪い子がいるせいで巻き添え食らうから、それをどうやったら解消できるのかってのはさ
けっこう忍法帖の開発初期からの胆だったりするんじゃないかしら
我慢を分かち合う事と同時に規制緩和的な要素がなきゃ理解を得られにくいよね

>>904
数値的にはそうなるとして、レベルうｐの時間の調整とかでお得感出せないかしら？
テンプレ貼りとかもあるからスレ立てレベルまでに1.0倍になるようにして
荒らしさんを撃退できる程度の時間を見込んだうえでさ、
一般利用者さんがなるべく早めにレベル上がる程度だとどんな感じなんだろね
かなり変則的になりそうだけど狐さんならたぶんやってくれる…ﾊｽﾞ

>>871
スピード抑えたいなら板ごとに抑えればいいんじゃないの？
板ごとに低レベルの書き込み可能容量を設定できれば
どこまで許容できるかの兼ね合いで、スピードも板ごとに調整できるんだし

>>890
http://suiton.geo.jp/?t=e&i=1313438552
http://suiton.geo.jp/?t=e&i=1320761854
>>667 の前後のK5を見ても、K5にはそんなに有効だとは思えないな
>>896 のような384バイト以上の大容量の埋立で困る板もあれば、
384バイト以下の小容量の埋立で困る板もあり、
板によって事情が違うんだから、板ごとに設定できた方がいいと思う

一律の固定値にすると弊害がある上、小容量の埋立には効果もないのに、
メリットは、板ごとに申請する手間が省けること以外にないんじゃないの？

>>907
その我慢を分かち合う単位が、2ch全体だから落とし所を見つけるのも難しい
板ごとにすれば、勝手に板で話し合って決めてもらえばいい

>>862を考えればLv2とLv3の間にある程度の断絶が備わればとりあえず済むこと。

>>908
384バイト以下の小容量の埋立、容量潰しがスレ潰しに変わるﾊﾟﾀｰﾝは簡易rockみたいな仕組みでもなければ無理でしょう。
うちが次に直面するのはそれでしょうけど。

>>908
板事情の差を考慮した落としどころってことに触れるならさ
最初の倍率制が一番恨みっこなしの設定だったと思うよ
板設定は忍法帖導入の申請でばたばたして設定変更人もかなり疲れてきてるしさ
そのうえメッセージ容量だなんだってことになるとかなり気の毒な気がするわ

私も予想だと　>>904　でいくのかなーと思ってました。
せっかく改めてLv初期のバイト数を再考できる機会ですし、

>>904案の固定部分を変えるなら
固定（384）→（xxx）
私ならメモリを増設するかのように…

256+128＝384　→　更に+64＝448　と調整しちゃうかも。512が多いと思うなら間取ればいいんじゃなイカ？
N×0.4 / 0.5 / 0.6 / 0.8 / 1.0
1024 --> 0409 / 0512 / 0614 / 0819 / 1024
2048 --> 0819 / 1024 / 1228 / 1638 / 2048
4096 --> 1638 / 2048 / 2457 / 3276 / 4096

逆転現象は1024bytesのLv3（N×0.4）だから、減るのがいやなら、Lv3〜4を0.5倍にしちゃえばいい。
Lv=1〜2 固定（448byte）
Lv=3〜4　BBS_MESSAGE_COUNTで設定される値の0.5倍まで
Lv=5〜6　同値の0.6倍まで
Lv=7〜8 　同値の0.8倍まで
Lv=9以上 同値の1.0倍まで

荒らしを抑えこみたいのLv閾値が、Lv3未満としているならば、こんな変更でも目的は達成できそうな気はする。
あくまでも案…

>>908
板ごとに設定って例えばBBS_NINJA_MESSAGE_MINI=みたいな項目をSETTING.TXTに作ってみたいなこと？
投稿容量の確認はbbs.cgiでやってるからLv2ならこの項目を見て判定
それ以外なら板の制限値からLvに合わせて判定ってなると煩雑になるから負荷的にどうなんだろ

>>911
そーえば、どこかのスレでBBS_MESSAGE_COUNT_LV=*の項目新設だかの提案あったよね？
荒らしさんが特に多い板だけならば特別仕様のSETTING.TXTでもいいかも
それなら変更人さんが数板分だけ弄ってくれりゃいいしね

>>913
そーですねー…問題は荒らしの多い板を定義できるかどうか…
半分懲罰的なsettingを受け入れる人がどれだけ必要性を認識するか
そして板の話は板で決めることが前提になってしまう事。

文字数は忍者で決めてってことだけど、板設定は住民が決めてって話だからね；

うーん、あまりにも面倒臭くなるようなことはやってくれないような気も・・・

単純に最低レベルのデフォルト値を決めるんじゃダメかな
投稿バイト制限＝MIN + (COUNT - MIN) * Lv係数

MIN=384の場合
　　　　係数
Lv1-2　0.0　0384　0384　0384　<- MIN=bbs.cgi組み込みデフォルト
Lv3-4　0.3　0576　0883　1497
Lv5-6　0.5　0704　1216　2240
Lv7-8　0.7　0832　1548　2982
Lv9-.　 1.0　1024　2048　4096　<- COUNT=BBS_MESSAGE_COUNT

将来的に MINの値を板別にできるように・・・

>>916
万が一のハプニングを考えると忍法帖で集中管理してるほうがいいと思うんだけどねー

ハプニングとは？

あと補足として >>916 で
MIN=BBS_MESSAGE_COUNT * 0.3 とすれば、ほぼ現状どおり

緊急議論中
>>844-n
以下、いま出ている主な案

(a) Lv2 の書き込みバイト数＝384 が適切？
>>865 (>850 )
>>866 (>852 )
>>881
>>911
>>916

(b) Lv1->Lv2 の時間（新規HAP発行から書き込めるまで) 2分→5分?
>>867 (>850 )
>>853

稀勢の里のテロップが忍者の里に見えちゃって・・・。

448か512で固定するのはダメかな。

容量荒らし対策が問題なんだから最低でも512Byteでしょ。それならスレが埋められることも無いんだし
BBS_MESSAGE_COUNT=1024の板には
・BBS_MESSAGE_COUNT_LV=*等の項目新設
・固定値かBBS_MESSAGE_COUNTの0.3倍の小さい方を採用
・BBS_MESSAGE_COUNT=1024の板は対象外にする
等で対応

>>921
そんなに弄るなら>>911のほうがスマートでいいと思う

>>911
http://exactry.net/sato_siryou/911.png
>>916
http://exactry.net/sato_siryou/916.png

試しにグラフにしてみた。>>916　のほうがバランスはよさそう。

>>921　判定の手間がかかりすぎると思う。
ベースを512にするだけでよいのなら思い切って、512未満の設定値になるものは512を適用でよさそう。

だから、BBS_MESSAGE_COUNT=2048の板の制限を厳しくする合理的な理由を出していただきたい
>>642にあるとおり元々は4069の板だとLv1でも1228もの書き込みが可能であるのが問題視されたのであって
本来なら2048の板がさらに制限される謂れは無いはず
何故最初から容量が厳しく設定されている板を基準に数値を決定する必要があるのか
スマートだから、バランスが良いから、そういった説明で利用者を納得させられますか？

614もの書き込みができたらあっという間に埋め立てられちゃうじゃない

破門にならなければ制限は緩和されるんだけど、それほど問題なのか？
Lvが低いうちは不便なのは元来忍法帖が目指した仕様なのだが・・・

荒らしは水遁されて不便なまま
関係ない住人はLvが上がって気にならなくなる

一人で埋め立てようと思ったら最低でも800レス・27時間以上を要するのにあっという間と言えますかね

他の人間がもっと容量でかい書き込みをしてるスレなんだろうから800はいらんのと違う？
そもそもスレが容量埋め立てされないことも重要だが
リソース的にも荒らしの投稿でガンガン容量使われないことが理想だろ
レベルが上がるまでちょっと我慢してねというお話だよ

HAPの使用数制限がついたころから、特定ISPは●を使用しないといけなくなった時点で
かわいそうな利用者が出ちゃってるんだけどね。
そんなに早くでかく書き込みたいなら●使いな　でいいと思うんだが。

>>928
＞他の人間がもっと容量でかい書き込みをしてるスレなんだろうから800はいらん
そういったスレの実例を出していただかないと何とも言えませんね
依頼スレでざっと「埋め立て|容量潰し」とされる案件を見てみましたが
Lv1の制限が614乃至512Byte程度なら十分対処できるものが多いと感じます

http://toki.2ch.net/test/read.cgi/credit/1322056989/262 1926Byte
http://toki.2ch.net/test/read.cgi/compose/1317994665/494 923Byte
http://yuzuru.2ch.net/test/read.cgi/hsb/1316753400/558 664Byte
http://kamome.2ch.net/test/read.cgi/livemarket2/1319190598/367 1363Byte
http://toki.2ch.net/test/read.cgi/shar/1319525948/272 2578Byte
http://ikura.2ch.net/test/read.cgi/ms/1322375391/15 1963Byte
http://kamome.2ch.net/test/read.cgi/livemarket2/1320748174/271 1629Byte

＞リソース的にも荒らしの投稿でガンガン容量使われないことが理想
スレが容易に埋め立てられない程度の投稿なら問題ないと言えるのではないでしょうか

>>930
＞Lv1の制限が614乃至512Byte程度なら十分対処できるものが多いと感じます

対処してきたのか
忍者としての活動履歴見せてくれ

＞そういったスレの実例を出していただかないと何とも言えませんね
え？君言ってることおかしいよ？
他の人間が614程度以下のレスばっかしてるようなスレで
レベル低い内からそれだけの容量投稿できないと困るとかないでしょ？
他の人の一般の投稿がそういう程度の容量の投稿で事足りるスレなら
レベルが低いちょっとの期間がもうちょっと少ない容量でも大した事無いでしょ？

>>931
客観的に見て、614Byte制限があれば水遁をしてLｖアップを防ぐことで
埋め立て効率を抑えることができそうだ、という意味ですがそれと私が忍者であるかどうかに何の関係が？

>>932
埋め立て荒らしが現れるスレは他の利用者も大容量のレスをしているはずだ、というのが>>928でのあなたの主張ですよね
荒らしが他の人間の投稿状況に左右されるというのは考え難いので実例を示していただきたかったのですが

なお、今話し合ってるLv1での容量制限は1スレ1板単位の細かな事情を勘案するようなものではない事をお忘れなきよう

こうして会議が踊っている間にもうちはLv2で存分に埋め立てられてくのさ。

http://hato.2ch.net/test/read.cgi/morningcoffee/1322484349/166-189

>>933
大綱のような枠組みの話をしているのに、一板一スレっていくらなんでもミクロすぎる

いやいや順番が逆でしてよ
レベルが低い内から614の容量がないと困るような板であれば
当然通常の投稿が一々大容量なのだろうといういうことですよ
そうであれば通常の投稿で容量は常に圧迫され気味だろうから容量荒らしも容易いだろうという予想

そもそもレベルが低い少々の期間から614の容量が必要な板というのはどこのお話なんですかね？
AA板だとか創作系の板で職人さんが不便とかいうのはまだわかるんだけど
そういう板は4096あるところが殆どだろうし、あなたはそういう板については気にしてないようだし実に疑問だ
どういう利用の板で不便になるとかんがえてるのかな？

不便だという板はnashiの設定してもらえばいいんだよ
創作系の板は荒らされるリスクを許容してその道を選んだ

AA・創作系の板はそもそも忍法帖が入ってないでしょう。http://suiton.geo.jp/bbsnin.html
忍法帖による容量制限の話でなぜ引き合いに出されるのか理解に苦しみますね

いやそういう板が制限されたら不便と言うのはわかるという話だよ
で、君が言ってるのはどこの板の話なのかな？

やはり現場から乖離するねえ。

>>938
手前味噌だけど>>926についてはどうお考えで？

>>940
たいして意見も出ないうちに決まってしまうより、いいことだと思いますよ

>>939
繰り返しになりますけど具体的な板名を挙げて進めるような議論ではありません
・BBS_MESSAGE_COUNT=4096の板での容量潰しを何とかしようというのが出発点
・Lv1での容量制限が614Byte(BBS_MESSAGE_COUNT=2048での基準)ならば容量潰しの効率は著しく落ちる
こういう前提があるのに何故BBS_MESSAGE_COUNT=2048の板をさらに制限する必要があるのかと、そう言っているのです

>>941
今までのシステムで十分「Lvが低いうちは不便」という状態は実現されていると感じます
Lvが低いうちは不便なのも甘受しろ、というのが行きすぎると低Lvでの書き込みは不可 とかなりませんか？
(実際に開発室等ではそういった意見も散見されます)
低Lvでの不便さにも一定の下限は設けておくべきだと思います
そして私はその下限を一般的な板のものを基準にしようと提案している訳で

また、発行→初書き込み(Lv2)の間隔が5分に引き上げられ、荒らしの効率も落ちているのではないでしょうか
>>934のスレを例にしてみると以前見かけた埋め立てのペースとは随分違って見えます
http://hato.2ch.net/test/read.cgi/morningcoffee/1320292218/792-814

>>942
俺は忍法帖によってISP規制を減らすって流れに全面的に賛成してるので
荒らしをなんとかしろっていう住人の声が大きくなって逆戻りしてしまう事態は避けたいと思っているんだ

ここで議論しているのは妥協点を見つけることであって
レベルが低いうちは我慢してね、というお願いでもあるよ

>>942
1228では大きすぎる→どこまで制限するか
であり、板の元もとの容量に関係なく384くらいまで制限するのがいいんじゃね？って話をしてきてるんだよ
2048の板を制限する話をしているわけではない
板名を挙げてするような話ではないと言うが君の常駐板の問題にしか聞こえてこない
たかが１日２日の間384の容量制限を受けることがそれほど不便かね？
荒らしを抑えるためにみんなで不便な思いをしようと言った場合に
それでも我慢できないほどの不便さかね？
とてもそうは思えないから君の抱える事情に過ぎないのではとの思いをぬぐえない
不便だと思う人間が多いような事情を持つ板ならばnashi設定にすればいいとも思うしね

他の板の荒らしをどうにかするための制限を押しつけて我慢しろと迫るのがそもそもおかしくありませんか？
「荒らしを抑えるため」と言ったってその「荒らし」はBBS_MESSAGE_COUNT=4096の板のローカルな問題でしかない
不便ならnashiにしろというなら、容量潰しに困ってるなら板のMESSAGE_COUNTを小さくしろ、という理屈だってあるわけで
その上で全板横断的な制限を課すならば、ある程度の納得のいく基準が必要だと思います
少なくとも何の説明も無しに突然出てきた「384Byte」なる数字が説得力のあるものだとは言えないのではないでしょうか

>>937>>944
自由度の問題
板で選択できるのが nashi/checked だけにした方がいいのか、
Lv1-2 の容量制限も板で選択できる自由度があった方がいいのか
固定値「で」いいという案には、固定値「が」いいという積極的理由がないと思う

>>944
> たかが１日２日の間384の容量制限を受けることがそれほど不便かね？
そうした方がいいのなら、2chの全住人に甘受してもらわなければならないけど、
そうしなくてもいい方法もあるのに、固定値にした方がいい理由は何？

そうしなくてもいい方法というのは、
BBS_MESSAGE_COUNT を小さくするとか、BBS_MESSAGE_COUNT_LV1(LV2) を新設するとか、
あるいは、固定値にしたとしても、
BBS_MESSAGE_COUNT_USEFIX=nashi が設定されてる場合は固定値を使わない
という選択肢を用意しておく方法もあるし、
BBS_MESSAGE_COUNT2=384,576,704,832,1024 (>>916)
という感じでLvUpによる緩和の割合も板ごとに設定できるようにすることもできる

出来れば今日ぐらいにはなんらかの変更が欲しいところ。

>>941
それはそうなんだけど、384固定時には●を連鎖的に停止できさえすれば抑えこめるはずだったからそれを訴えてきたのに
せっかく●の連鎖停止が成ったら今度は384が外れて、これでしょう。
今は5分の縛りもないので以前の8分間隔から4分弱での連投に切り替わってしまってもいて、少々うんざりしてる。

>>942
対応してる私が思うに、以前より悪化してますが>>854。
低Lvでの不便さにも一定の下限と言ってもそれは荒らし易くすることでもあるし難しい所ですなあ。

24時間後には住人が決めた板設定に準拠するんだから
レベル1.〜2は384バイト固定でいいじゃないですか

新規の人がたかが24時間の間に384バイトで困る事例が多くあれば別ですが。

荒らしを押さえ込めるメリットが圧倒的に多い現状でわざわざ振り出しに戻す必要はないと思いますがね

上限まで書けるようになるまでのLv上昇を7日間以内に収めるような時間設定とか出来ればいいのかな>>923
私はLv3への上昇を23hから8〜12hすれば、とか言ったような気がする。

K5のデータ置いときますね
http://qb5.2ch.net/test/read.cgi/sec2chd/1321552924/324-331

だからお前らどこの板の利用を想定してるんだよ
レベルが上がれば制限は解除される
殆どの板で１〜３行程度のレスが一番多いと思うんだが
１日２日程度の間の容量制限が我慢ならん614なければ足りないって
どういう板の危機感なんだかちっとも実感がわかん

機上のウーロンだからさ

>>949
まだ時間については触れてもいませぬ（隠居の決めてねー→容量の話だった気がする）が、
スライドによって現状のCOUNT×0.5になるまでの時間が短縮されている。（Lv1→Lv3まで2×23h掛かっていたのが3min）

書込容量をもう一度制限する代わりに、
今の状況をそのまま利用者サイドの恩恵として承継するのであれば8h〜半日でLv3→4もあり。
そうでなく、そのまま容量制限を加えた場合でも、Lv4まで23hと3minだから、
…要はその約1日が利用者にとって我慢できるかどうかって線だよね。
（今まで我慢できていたのはCOUNTによるスライド制だったというならば、COUNTが元々多い板の言い分なんじゃないかと）
あとは忍者が荒らしを抑えこみたいラインとしてどこまで妥協できるかといった所。

ちょっと整理。
破門→Lv0
発行→Lv1　2min　　//Lvシフト（発行の為にLvを割り当てた）容量は固定384バイト　5min〜10minに調整する案がある＠開発スレ
Lv2-3　1min　　　　　//従来のLv1だったもの。ここの容量を前の固定バイトにしようか議論中。現在Lv3はCOUNT×0.5
Lv3-　23h　　　　　　//従来のLv2↑のテーブル。ここをLv3-4の間を　8h〜12hに短縮する案 >>949

＞Lv2-3　1min

レベルアップじゃなくて連投間隔じゃないの？

【忍法帖 開発スレッド Part22】
> 26 忍法帖【Lv=21,xxxPT】 ◆xvQwATc0eQ (WiMAX) [sage] 2011/11/26(土) 17:12:09.55 発信元:49.133.125.232 0 ID: Be:
> こういう風になればいいなぁ、改造してみた
>
> 作成時 Lv=1
> 初めて書き込みで Lv=2
> 24時間後 LvUpしてLv=3
> 破門で Lv=0
>
> Lv=1 120sec
> Lv=2-3 60sec
>
> 目論見通りに動いているか試してみて欲しい

> 52 ◆RillyOFbbmix (あら) [sage] 2011/11/27(日) 17:27:45.36 発信元:219.167.70.60 0 ID: Be:
> >>26
> 24じゃなくて、当初の仕様と思われる 23hで１LvUPの確認ができました。
> 書込間隔 Lv3　60sec　確認ができました。
> とりあえず目論見通りの模様

あれ・・こんがらがってきた。

もう一度確認してみた。

> スライドによって現状のCOUNT×0.5になるまでの時間が短縮されている。（Lv1→Lv3まで2×23h掛かっていたのが3min）

ここはLv1下駄履かせてすっ飛ばしたから　（Lv1→Lv3まで2×23h掛かっていたのが　23ｈと3min）　に訂正


> ちょっと整理。
> 破門→Lv0
> 発行→Lv1　2min　　//Lvシフト（発行の為にLvを割り当てた）容量は固定384バイト　5min〜10minに調整する案がある＠開発スレ
> Lv2-3　1min　　　　　//従来のLv1だったもの。ここの容量を前の固定バイトにしようか議論中。現在Lv3はCOUNT×0.5

Lv2-　23h　　　　　　　　//ここのLv2-3の間を　8h〜12hに短縮する案 >>949　　　に訂正　　　

>>953　を書きなおした。
>>949
まだ時間については触れてもいませぬ（隠居の決めてねー→容量の話だった気がする）が、
スライドによって現状のCOUNT×0.5になるまでの時間が短縮されている。（Lv1→Lv3まで2×23h掛かっていたのが23ｈ+3min）

そのまま容量制限を加えた場合でも、Lv3まで23hと3minだから
…要は今まで言われてた、その約1日が利用者にとって我慢できるかどうかって線だよね。（到達までの時間が減っているにもかかわらず）
（我慢できていたのはCOUNTによるスライド制だったというならば、COUNTが元々多い板の言い分じゃないと辻褄が）
あとは忍者が荒らしを抑えこみたいラインとしてどこまで妥協できるかといった所。

ちょっと整理
破門→Lv0
発行→Lv1　2min　　//Lvシフト（発行の為にLvを割り当てた）容量は固定384バイト　5min〜10minに調整する案がある＠開発スレ
Lv2-　23h　　　　　　//従来のLv1だったもの。ここの容量を前の固定バイトにしようか議論中。現在Lv3はCOUNT×0.5
ここのLv2-3のLvup間隔を　8h〜12hに短縮する案 >>949

完全スライド案
Lv=0

↓新規忍法帖発行

Lv=1メッセージ容量固定（384byte）

↓※5分固定（初めて書き込めるまで）

Lv=2メッセージ容量固定（384byte）

↓※23時間固定(レベルアップまで）

Lv=3　BBS_MESSAGE_COUNTで設定される値の0.4倍まで

↓以下通常

Lv=4　同値の0.5倍まで
Lv=5〜6　同値の0.6倍まで
Lv=7〜8 　同値の0.8倍まで
Lv=9以上 同値の1.0倍まで

素朴な疑問。
Lv3以降って荒しに何か効果有るの？

こんなのはダメなん？
Lv=1 384
Lv=2 0.3倍
Lv=3〜7 0.5倍
Lv=8〜 1倍

if文へりますしおすし。

>>959
今はLv1を発行専用に割り振っていて、初書込でLv2になるようにスキップしている状態なの
それがこないだのLvシフト。Lv3っていってるのは、閾値（前で言うLv2）がそこにあるってこと。

Lv2 384
Lv3 0.3倍
Lv4〜7 0.5倍
Lv8〜　1倍

Lvの数字だけ置き換えますね

>>926
自治スレでVIPタイプ忍法帳の導入に反対する人と、同じような理屈なんだよね。
反対する人は、頻繁に水遁されることを前提で考えているから話がかみ合わなくなるのよ。
大局的に見ると、やっぱり縮小の方に合わせるのがいいのかな〜。

>>960
あ〜、そういうことなのね。

こんがらがるから、とりあえず比較表を作ってみた。

http://exactry.net/sato_siryou/henkouan20111201.png

案１　Lv1-2　固定384B　他は現仕様のまま　>>880　他(a)がいっぱいあるけど >>881 >>904 選べるってことで
案２　Lv1-2　固定512B以下で　Lv3-4　×0.5　Lv5-6　×0.6　Lv7-8　×0.8　Lv9-　×1.0　>>911
案３　MIN値を設定（384B）　以降をMIN + (COUNT - MIN) * Lv係数で可変　>>916
　　　 Lv1-2 0.0　Lv3-4 0.3　Lv5-6 0.5　Lv7-8 0.7　Lv9-. 1.0
案４　Lv1-2　固定384B　Lv3〜は現仕様の完全スライド　>>958
案５　Lv1-2　固定384B　Lv3（×0.3だと下がるので0.4で）　Lv4-7　×0.5　Lv8　×1.0　>>959-960

Lv1で書き込んで、作成から24時間以内ならうｐしない、というのは？

>>963
発行→有効までの秒数を変更してみたら、Lv１のあいだじゅう５分になっちゃったそうで
その回避策で、Lvシフトをしたんですが、Lv1から23時間縛り（多分23hもどこかの定数なんだとおもう）をすると
発行→有効の時間を弄った時に、ずーっと…10分かけなかったり5分書けなかったりすることになるかも

このへんの解消をするにはちょっとややこしい変更を狐さんにお願いしてしまうことになるかも

水遁常習者には効果抜群だろうけど、反発もすごそう。

>ずーっと…10分かけなかったり5分書けなかったりすることになるかも
発狂する人が出そうですね。

議題(a)の１レスの書き込み容量はまだまだ時間がかかりそうですな

議題(b)の連投間隔（Lv1の新規HAP発行のみLvアップ待ち時間）だけでも意見がまとまるなら
とは思うもののコチラへの意見が少なかったり・・・

変更なんでまとめてからと思ってたんだけど、やっぱりまとまりにくいんじゃないかと思います。

最低レベルの投稿バイト数固定には反対意見もあり、一度白紙に戻したということにして、
せっかくシフトして初期書き込み時間が設定できるようになったのだから、
それを生かして実験してみるかどうかを先に決めた方が良いかも知れません。

(b) 初期書き込み時間(Lv2になるまで）
現状 2分→K５対策実験 5分＆間隔もスライドさせる >>867
> Lv=1　　300 (秒)
> Lv=2　　120
> Lv=3〜4　60
> Lv=5〜6　45
> Lv=7〜8　30
> Lv=9〜20　15
> Lv=21〜30　5
> Lv=31〜35　2
> Lv=36以上 　1
でいったんやってみて、これでも容量制限の埋め立てがひどい等があれば
(a)の 最低レベルでの投稿バイト数の固定を再検討するということではどうでしょうか？
（現在でもK５すいとんが行われているので変化が見られるのではという期待もあります）

>>967 追加
(a) 最低レベルの投稿バイト数の固定は白紙に戻す
> Lv=1　(384byte) ※書き込みはできないんで無効
> Lv=2　BBS_MESSAGE_COUNTで設定される値の0.3倍まで　←現在繰り上がって 0.4倍になっている
> Lv=3　同値の0.4倍まで
> Lv=4　同値の0.5倍まで
> Lv=5〜6　同値の0.6倍まで
> Lv=7〜8　同値の0.8倍まで
> Lv=9以上　同値の1.0倍まで

　 　 　 ＼∧＿ﾍ　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣
　,,､,､,,,　/ ＼〇ノゝ∩ ＜　1000取り合戦、いくぞﾓﾅｧ！！　　　　　　　,,､,､,,,
　　　　/三√ ﾟДﾟ)　/　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿　　,,､,､,,,
　　 　　/三/| ﾟＵﾟ|＼　　　　　　,,､,､,,,　　　　　　　　　　　　　　　　　　　　　　　,,､,､,,,
　,,､,､,,,　Ｕ （:::::::::::）　　,,､,､,,,　　　　　　　　　＼オーーーーーーーッ！！／
　　 　 　//三/|三|＼　　　　　∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　∪　 ∪　　　　　　 （　　　　）　　　 （　　　　 ）　　　（　　　　）　　　 ）
　,,､,､,,,　　　　　　　,,､,､,,,　　∧＿∧∧＿∧∧＿∧ ∧＿∧∧＿∧∧＿∧∧＿∧
　　　　　　,,､,､,,,　　　　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）　　　 （　　　　）
※レス数が980を越えたスレは、980突破後最新のレスから２４時間以内に
レスが付かなかった場合強制的にdat落ちします。
1000まで埋め立てたい場合は980突破後速やかに1000まで埋め立てましょう。
また、埋め立てたくない場合は980突破後、２４時間放置しましょう。

1000取り合戦間近スレを報告するスレ
http://kamome.2ch.net/test/read.cgi/mog2/1301989517/l50
より、1000取り合戦のお知らせでした

>>962に　>>968　→　案６として追加、再UPしました。（リンク同じです）

一旦発行時間の変更を実装してみて様子見というのも無難ですね。（水遁をするとどの程度大人しくなるか）
対象が複数ブラウザ＆回線複数持ちですとかになると、封じる方法を模索する必要がいずれでてくるかもしれません。
そのための暫定384byte縛りだったともいえます。（K5も狼も）

例の件はre-disやunagiを容易に回避できる性質から、COUNT=4096な板は容量オーバーが発生しうる状況が再現した場合、
どのように困っている（進行している）かデータを集めて傾向を把握しておくことが肝要かも。
もしかすると全く新しい仕組みに行き着くかもしれません

あと実現するとおもしろいかなあと思うことも書いておきます

最低レベルでの投稿バイト数をすいとんにより減少させられれば
同一文字列投稿（スクリプト）にもいぢわるできるんじゃ？

1. 初期値 COUNT_Lv2[区分]=BBS_MESSAGE_COUNT x 0.3
　※区分には、ISP毎、鯖毎、板毎とか考えられる
2. Lv2のHAPですいとんを n回受けると COUNT_Lv2[区分]減少 0でお断り
　※固定文字数だと変更しないと投稿できなくなる
3. h時間すいとんがなければ、COUNT_Lv2[区分]は初期値に戻る
（re-disを応用してできないかなと思ってみたり）

まあ思いつきです

>>971
Lv2を対象に、re-disに水遁回数を記録させて、その鯖もしくはその板の某ISPからの
Lv2の書込に対して、段階的に容量制限もしくはお断りをしてしまう…ですか
ほとぼりがさめたらリセット

Lv2以外のLvの書込には影響が出ない点も魅力的ですね。
嫌でもHAPの作り溜めでもしない限りは、空白連投すらもできなくなる→あとは…何か抜け穴ないかな？

現在起きているのは
１）マルチさんを水遁する
２）マルチさん復活でLv2
３）マルチ続行
なので、この輪廻を切りたいでｓｎ

>>971　自己レス
区分を（板毎以外の）ISP毎、鯖毎だと COUNTの初期値
（板別の)BBS_MESSAGE_COUNT x0.3 から減少じゃダメじゃんorz

x0.3 の係数を 0.01ずつ減らしていけばいいのか x0.29 x0.28 ... x0.01 x0.00

もうすぐ1000だけど結論は出たの？

>>971>>973 自己レス２
最小限の巻き添えを考えた場合、板「スレ」毎に管理できればいいんだが
スイトン例：
> Suiton http://hato.2ch.net/test/read.cgi/entrance2/1319096115/182
> Suiton(修行中)→ NinjaID[Dentrance21322736518820741(Lv2)]を破門した。

"(Lv2)" のとき　"http://hato.2ch.net/test/read.cgi/entrance2/1319096115/" を
（もしくは"entrance2/1319096115"だけでもよい？）
キーにしてre-disに時限付き回数記録していけばいいのかな？

re-disのHAPって水遁期限の12時間保持されてるん？

>>977
たしか1時間書き込みがなければ消滅

>>978
そんな感じですよね。
余力まだ有るのかな。

>>976
スレ別だとピン過ぎてマルチに弱いからそこは板別か鯖別が無難かも。
覚えさせるものはLv2の書込が水遁された、板もしくは鯖名と、水遁初回時刻、水遁最後の時刻、水遁カウント数
にしておくと覚えるものが少なくて負担が軽いかも。
そして今どの板で一定時間にどの位水遁されているか、unagiみたいにデータをdmpさせると
この板荒れてんねー、板設定どうしよーみたいな話に持って行きやすくなるね。
（未設定板とかのデータ収集が今後のchecked議論の役に立つかも）

>>975
どうしましょ？
変更を恒久的と考えると議論が長くなりそうだし、実験的とすればやってみたら？で済みそうだし
自分としては忍法帖はまだ実験なんだからのスタンスでいるんですけどね

>>979
今の re-disはキーとして IP別に 5つのHAPを覚えているのかな（６つ目であぼん）
キーが板別でも 800程だから、全然余裕かも（すいとん有りのは半分位？）

>>980
マルチか・・・
いまのすいとんだけで全てのあらしに対応するのも難しかったり・・・
忍者が判定するんだから、専用の部隊と忍術で対応をしてみたり・・・

使うかどうかは別にして板別、鯖別、ISP別のデータも取っておくのもいいよね

残件なすスレに書いたら誘導されたんでこちらに・・・

●の停止は別々の3人の忍者に同じ●に紐付いたIDを水遁された場合にすればどうだろう？
120時間に3回とかにして、板は別々でも同じ●で書いた事のあるID全て
そうすれば乱射やミスの被害者が減り荒らしは確実に停止できる

代わりに停止時間をお試しは336時間（2週間で事実上の没収）
正規を120時間位（5日間）に厳しくする
●を使った荒らしには、ID無し板も含めて絶大な効果があると思う

Lv=2の容量だけでも変えてもらえば？
1日でLv=3になるから前よりは緩いよね？

>>982
乱射、誤射などの救済処置として【忍法帖 開発スレッド Part22】
> 147 忍法帖【Lv=15,xxxPT】 ◆xvQwATc0eQ (もこりん) [sage] 2011/11/29(火) 15:30:41.83 発信元:211.121.91.107 0 ID: Be:
> 一時停止されている●IDを格納するDB
> 現在はすいとん時に追加される or 時間がたったら消える
>
> これに、削除機能があればいいのかな?
> !bybykin abcdefgabcd(●ID)

将来的には　停止→焼き　まで自動化させたいとも言っていたから、
同じ●で何回もスイトンされたら停止期間が長くなっていく（最終的には1年＝焼き）とかになるんじゃないかと

>>983
>>844　決まらんのよ
前に変えた人たちが出てこないのも、勝手に変えるといちゃもんがつくからじゃないかと
・固定になってたんだから固定にしろ
・勝手に決めるな、固定はやめろ（板別にできればいいよ　みたいな）
次スレで投票をした方がいいのか、変えなくても誰も（多数の忍者さんも）文句言ってこないんで放置でいいのか

固定にしても384Byteはやりすぎ
埋め立てを防ぐなら512Byteとかでも十分なはず

512byteだと逆転現象が生じるから>>875
Lv=2固定なら384〜409だよね

だから逆転現象が起きるから数値を低くしよう、って当初の目的からズレズレじゃん
逆転現象を回避するための方策を立てるのが筋だろ

384って全角192文字だぜ？
１日２日の間それ以上の長文が投稿できないからって困るような板は特殊なとこだけだろ？
マルチコピペのテンプレが作りにくくなるから反対してるだけじゃね？って疑惑がわいてくるわ

容量潰しに困ってるなら住民同士で話し合ってBBS_MESSAGE_COUNTを小さくしてください
本当ならこうなるところをわざわざ他の板に迷惑かけてまで新たな制限かけようとしてるんだってことを忘れんなよ

はいはい忘れません
俺の常駐板にそんなに容量のでかいとこないけどね

マルチで貼られるでかいコピペとか鬱陶しいしやっぱ384がいいな

これだもんなー以前はコピペなんて容量いっぱいいっぱいに使われてただろうが
0.3倍にまで制限してもらったのにまた慣れたら文句を言うようになる
こういうやつがそのうちLvが低い奴はROMらせろとか言い出すんだ

まあまあ落ち着いて。

>>987
その方策を。

全然読んでないけど
スレ容量が約500KBなんだから最低時(Lv2)の制限は512辺りが妥当って話か

>>985 >>986>>987
512byteで逆転現象が起きなければいいのかな？>>916>>918

案>>923での例
BBS_MESSAGE_COUNT=1024 / 2048 / 4096 (byte)
最小512byte固定の時

Lv2　　 (x0.3)= [307]->512 / [614]->512 / [1228]->512
Lv3　　 (x0.4)= [409]->512 / 819　　　　　/ 1638
Lv4　　 (x0.5)= 512　　　　　/ 1024　　　　 / 2048
Lv5-6　(x0.6)= 614　　　　　/ 1228　　　　 / 2457
Lv7-8　(x0.8)= 819　　　　　/ 1638　　　　 / 3276
Lv9-. 　(x1.0)= 1024　　　　 / 2048　　　　 / 4096

※最小384byteなら、逆転は 1024時のLv2のみ（おまけ）
※最小614byteなら、1024時のLv2〜Lv4(x0.5)まで614とする

>>994 補足
あと、倍率で小さい方を採用すると言う案もあったね
例で言えば 最小512byteで
　1024 Lv2 のときは 512->307
　1024 Lv3 のときは 512->409

次スレ立てました

忍法帖に関する新しいアイデアを話し合うスレ 2
http://hato.2ch.net/test/read.cgi/sato/1322752981/

そんなに512bytesが好きならLv2-3まで一律512にしたら公平だな()

3バイトくらいでいいよ

3行書けるなら困らんですばい

忍法帖に関する新しいアイデアを話し合うスレ 2
http://hato.2ch.net/test/read.cgi/sato/1322752981/

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。