SEとかプログラマがFF11を語る　スレ　Ver1.11sp1

1：しがないSE：2004/05/26(水) 02:37 ID:s5wde516: 現役も元プログラマもフリーも雇われも、語ろうじゃないか。
■eの社員もどうぞ。

前スレ
SEとかプログラマがFF11を語る　スレ　Ver1.11
http://jbbs.shitaraba.com/bbs/read.cgi/game/6493/1069227138/
前々スレ
SEとかプログラマがFF11を語る　スレ Ver1.1
http://jbbs.shitaraba.com/game/bbs/read.cgi?BBS=5091&KEY=1063107648
前々々スレ
SEとかプログラマがFF11を語る　スレ
http://jbbs.shitaraba.com/game/bbs/read.cgi?BBS=5091&KEY=1050327266

ﾏﾀｰﾘ、sage進行
586：(･ω･)：2004/09/30(木) 03:00 ID:z/TASNjM: >先日、ファイナルファンタジーXI内で、ゲームシステムの意図に反して
>ギルを不正に入手できてしまう問題が発見されました。
・・・・自分たちでそういう間違った設定にしておいて、システムの意図に反して
ってどういうことじゃｗｗｗ
システムがそういう意図になってるじゃん。全然反していない。
587：(･ω･)：2004/09/30(木) 03:06 ID:Z.2X.5aQ: 間違った設定になっていて、結果的にギルを増やすことができてしまった場合
それは不正なのか？
588：(･ω･)：2004/09/30(木) 03:40 ID:desc1JaA: いや、違う。
きっと意図的に間違った設定をセットしておいて、
悪用する香具師をいぶりだして処罰する、おとりだったんだ！

な、なんだっｔ（ｒｙ
589：(･ω･)：2004/09/30(木) 03:54 ID:eqJKNmB6: 敵が１万ギルくらい落とすようにすればいいんだよな。
扱えるギルの桁を増やそうぜ。
590：(･ω･)：2004/09/30(木) 05:36 ID:YaF5hR6M: 今現在の競売履歴にゼロがふたつ増えるだけな希ガス
591：(･ω･)：2004/09/30(木) 06:08 ID:hRNu..92: リアルの世界なら建前が自由経済でも様々なスタビライザーが
仕掛けられていて経済混乱は抑えられてるが
ヴァナはほとんど無策に近いから時間変動も物品毎の格差も
めちゃ大きいね。ヴァナを見て、リアル経済に仕掛けられているものが
なぜ必要なのかよくわかる。
592：(･ω･)：2004/09/30(木) 10:12 ID:JRZVTuxw: まあ、よくある表現だが、
「システムは作った人の意図通りに動くんじゃない。作った通りに動くんだ」

>先日、ファイナルファンタジーXI内で、ゲームシステムの意図に反して
「ゲームシステムの意図に反して」じゃなくて、
「ゲームデザイナの意図に反して」だな。
そして「ゲームデザイナの意図」が正しくゲームシステムに反映されず、
その結果利用者にも伝わらなかった責任は、利用者側には一切ないわな。
593：(･ω･)：2004/09/30(木) 10:24 ID:wNyYc7nY: まぁ、今後もろくなテストしないから不具合あったらお前ら検証報告よろってことだな
594：(･ω･)：2004/09/30(木) 10:29 ID:InTHwZXo: 当然責任はないが、設定ミスを意図的に利用してギル増やしてもいいって話にはならないな。
595：(･ω･)：2004/09/30(木) 10:39 ID:uf5t.Hh2: でもシステムを正しく運用していて起こった結果が
不正な利用だっていうのはあんまりかなあ。
596：592：2004/09/30(木) 10:39 ID:JRZVTuxw: >594
ああ、その点には同意。
あくまで「ゲームシステムの意図に反して」という表現が気に入らなかっただけ。
「ごめんなさい、間違えました」位言ってみろ、とｗ
597：(･ω･)：2004/09/30(木) 11:16 ID:pQYVpMS.: 漏れ等ゲーマなエンジニアは
「デザイン」と「システム」の違いをはっきりと知ってるが、
(■eさまが顧客と思い込んでいる)一般ユーザはその違いを判ってもらえない、
と■eは思ったんじゃね？

で、デザインだろうが価格設定だろうがエリアだろうが認証だろうが
「システム」の用語で統一、っと。

なめんなーと言いたいとこだが、顧客への説明って、
テクニカルタームをどこまで使っていいのか毎回苦労するもんなぁ。
598：(･ω･)：2004/09/30(木) 11:25 ID:yAJg0dRw: 「ゲームシステムの意図」とやらを理解しないユーザはbanされる可能性があるというのはどうなのかなあ。

デジョン合成みたいのならまだしも、今回の場合、ライトユーザの中には
設定ミスと判断せずにお金かせぎしちゃう人もいそうな気がするのだが。

何にせよ、自分のミスを認めないばかりか、逆に脅迫するってのは……
599：(･ω･)：2004/09/30(木) 11:31 ID:MH31JDOk: そういうもんじゃないの？
競売Dupeやデジョン合成と根本は同じだと思うんだが。

つーか「不具合」「問題」と言ってる時点でミスは認めてるんでは？
600：(･ω･)：2004/09/30(木) 13:24 ID:QXZ3XadY: >>597

お客様の言葉で話すのが原則なので、ユーザー側に見えてないテクニカルタームを
使って良い要素はゼロだね。この場合だと「ゲームシステムの意図」とやらを説明して
なかったら、漏れは×と考えるよ

今回の件についての印象は>>598と同感だなぁ。この告知を見て少なくともポジティブな
印象をもった人は居ないでしょ
601：(･ω･)：2004/09/30(木) 13:51 ID:nDozP00o: ギル増殖目的で継続的に利用→不具合の不正使用、ってことでは？
該当操作した人は全員不正とか言ってる風には受け取れないし、別に違和感は感じなかったが。

「開発側のミスだからユーザには警告も注意もなし」って方が逆に不信感を覚える。
602：(･ω･)：2004/09/30(木) 14:08 ID:9S5ufqdk: ■＜我々のミスになれていないユーザーはBANする可能性があります
　　　BANされたくなければ、仕様か不具合か見極める目を養ってください

ってことだろ、今回のは。
せめて

■＜我々のミスで一部のユーザーには迷惑をかけてすまんかった
　　　勝手ながら、キャラデータを一部巻き戻すかもしれん

って発表なら神経逆撫ですることも無かったろうに。
603：(･ω･)：2004/09/30(木) 19:45 ID:Z.2X.5aQ: あいかわらず広報が下手糞だな
604：(･ω･)：2004/10/01(金) 10:57 ID:a5GAvokw: ヴァナ基準日は2002/01/01 00:00:00ですけど
その次に基準日になりそうな日っていつですかね？
月、日あたりは、1/1じゃなくていいかと、時分秒は00:00:00でそろって
曜日月齢も初期値がいいです

参考資料
ヴァナ月:12ヶ月
ヴァナ日:30日固定
ヴァナ時:24
ヴァナ分:60
ヴァナ秒:60
ヴァナ曜日:8種類、ヴァナ1日ずつ
ヴァナ月齢:12種類、ヴァナ7日ずつ
2002/01/01 00:00:00 = 886/01/01 00:00:00 火曜新月(1日目)

どうかひとつお知恵を・・・
605：(･ω･)：2004/10/01(金) 10:57 ID:a5GAvokw: あ、追記
ヴァナは25倍
606：(･ω･)：2004/10/01(金) 13:52 ID:kob63IME: 曜日の周期 W = 8ヴァナ日
月齢の周期 M = 84ヴァナ日
WとMの最小公倍数 = 168ヴァナ日(曜日21周・月齢2周)

168ヴァナ日 = 地球時間の6.72日
6.72日の倍数が最初に整数になるのは25倍した168日後

つまり、地球時間で168日ごとに、
ヴァナで火曜日・新月・0時0分0秒かつ地球で0時0分0秒
となる日がやってくる。

そのような日は、
2002年1月1日天晶暦886年1月1日
2002年6月18日天晶暦897年9月1日
2002年12月3日天晶暦909年5月1日
2003年5月20日天晶暦921年1月1日
2003年11月4日天晶暦932年9月1日
2004年4月20日天晶暦944年5月1日
2004年10月5日天晶暦956年10月5日
2005年3月22日天晶暦967年9月1日
(以下略)
などとなる。

こんなんでいいのかな。

一応ばななに入力してみたらどれも火曜日・新月だった。
607：(･ω･)：2004/10/01(金) 13:54 ID:kob63IME: >2004年10月5日天晶暦956年10月5日
天晶暦956年1月1日orz
608：(･ω･)：2004/10/01(金) 14:24 ID:Ae1O6fIg: >>606
GJ （・ω・）ｂ
609：(･ω･)：2004/10/01(金) 14:36 ID:937yksAY: 一部で盛り上がったライブドア新球団名祭で、ランキング取りやめ告知
が出たわけだが
ttp://baseball.livedoor.com/info.html#1001

これを■風にすると

■＜偽情報を登録して連続投票するのは、投票システムの意図に反している
■＜このような行為を行うやつは地の果てまでもトレースして特定し、個別に警告する所存
■＜しかし、どれがイタズラかをイチイチ報告する必要は無い
■＜それではよい旅を

こんな感じ？
610：(･ω･)：2004/10/01(金) 14:55 ID:EEIDUgxU: >>609
■＜ユーザーが投票になれていない
■＜球団名以外の入力は想定外
■＜クマーな問題は、非公開にすることで回避した
■＜大変好評でうれしい
611：(･ω･)：2004/10/01(金) 15:41 ID:a5GAvokw: おおおお
＞2004年10月5日天晶暦956年1月1日
これがリアルで近いし、扱い易そう！
どもサンクスです

ttp://www2.odn.ne.jp/nya-/ff11/c100.html#b6
ここでも確認してだいじょぶそうでした

さすがに1/1までそろえると、何十年も後になっちゃうんですよね？
612：(･ω･)：2004/10/01(金) 16:32 ID:kob63IME: ひとつ書き忘れたことが。

「閏秒」のことは忘れろ、いいな。
613：(･ω･)：2004/10/01(金) 16:46 ID:a5GAvokw: 忘れるも何も、例え今日閏秒が１０秒入ったとしても
結局は、2004年10月5日天晶暦956年1月1日　だと思うのですが
気のせいﾃﾞｨｽｶ?
614：(･ω･)：2004/10/01(金) 16:51 ID:a5GAvokw: 言い忘れましたが、僕スゴイ頭悪いので
間違ってたら「間違ってるよ」の一言で十分でございます
615：(･ω･)：2004/10/01(金) 16:51 ID:EEIDUgxU: まぁ a5GAvokw が気にしないならそれで良いんじゃない
616：(･ω･)：2004/10/01(金) 17:21 ID:BFOfiitc: 忘れても忘れなくても、
■もたいした計算してるとも思えない(どうせ鯖の現在リアル時刻から同じように計算してるだけ)
だと思うのでなんも考える必要ないと思うぞ。

NTPだけしとけばおｋってだけの話かと。
考えすぎて逆に頭悪い。
617：(･ω･)：2004/10/01(金) 18:28 ID:elre1vsE: そういやFFずっと上げてると、
システム時間とヴァナ内 /clock のリアル時間がずれてかね？
抽選雑魚リポップ時間のPTへの告知とかでもうなんだかだったり。

気のせいかしらん？
618：(･ω･)：2004/10/01(金) 18:34 ID:ig.LUBIA: >a5GAvokw
俺はお前よりさらに頭悪いので、リアル時刻<=>ヴァナ時刻の変換プログラムを書いた。
619：(･ω･)：2004/10/01(金) 18:50 ID:BFOfiitc: >>617
/clockって鯖側で計算じゃねーの？
620：(･ω･)：2004/10/01(金) 18:59 ID:elre1vsE: >>619
俺もそう思ってたが、このまえ /clock ではかった時間で
「次は～分」ってPTに告知したら、「時計ずれてるよ」って言われた。
実際NTPであわせてる別マシンとだいぶ(数分レベルで)ずれてたし。

FF動かしてるマシンがどうだったかは見てないが、
それもいちおうNTPかけてるからなぁ。
裏で予約録画とかもしてるがそんなにずれることもないし。

かなり謎だ。俺の勘違いか？
621：(･ω･)：2004/10/01(金) 19:42 ID:s40RPAcc: 考え得る /clockの実装
1) /clockの結果はサーバから通知される - 各プレイヤ間のずれはネットワーク依存
2) /clockの結果は端末のシステム時刻を使っている - 各プレイヤのPCの精度依存
3) /clockの結果はFFXIシステム内で保持しているカウンタから生成される - 実装依存
で、>617の体験だと 3)であるらしい、と。

2)では、システム時刻をそのまま使うとプレイヤ間で時刻のずれが生じるから、
最初にサーバに問い合わせた基準時刻を保持しておいて、
FFXI起動時の時刻と現在時刻の差を足す、って感じかな。

確か昔の windowsが、3)のように内部でカウンタを持っておいて
起動後はシステム時刻を取りに行かない実装だったっけ？
49日問題とかってそれだよね？
622：(･ω･)：2004/10/02(土) 00:53 ID:xJu3el2c: >>611
地球で2295年1月1日0:0:0がヴァナで1月1日0:0:0・火曜日・新月らしい。
天晶暦何年になるかはしらねー。

■eはともかく人類無事だといいねぇ。
623：(･ω･)：2004/10/02(土) 01:30 ID:5LuOg3BA: >>622
2038年のはるか先だなｗ
624：(･ω･)：2004/10/02(土) 08:57 ID:eaFDVkq2: >>622 すまん、スレ違いもいいとこなんだが、ふと思ったので
なんだか宇宙戦艦ヤマトが飛び立ちそうな西暦だなｗ
625：(･ω･)：2004/10/03(日) 18:10 ID:5hSrqZWI: >>609
それ思うんだけどさ
「これこれこういう名前を投稿してはいけませんよ」
と言う事をもっとしっかり強調していれば
今回のような事態にはならなかった筈なんだよな
公募で決めると言うのも急に決まった話みたいだし
入力者がどういう動きをするのかを想定出来ないってのは…
まあライブドアはシステム屋じゃないっぽいけど
626：(･ω･)：2004/10/04(月) 07:28 ID:XUnBu1e2: 駄目な名前の定義、なんて出来る訳がないじゃない。
田代の例を引くまでもなくネットでの自由投票経過をそのまま表示するところに無理があった。
人的フィルタが必須だろうね。
627：(･ω･)：2004/10/04(月) 12:15 ID:QjG0l0n2: livedoorメンテナンスなんてなかなかセインスｲｲと思ったけどなぁｗ
628：(･ω･)：2004/10/04(月) 15:55 ID:5qWaSzXg: ランキング見るだけでもライブドアIDなんてものを要求するので、ページ自体は見なかった
けど「公序良俗に反しないもの、特定個人を誹謗中傷するもの、商標を侵害しないもの」
とか抽象的な禁止事項ぐらいはされてたのかなぁ

なんにしても人的フィルタだね。最後は
629：628：2004/10/04(月) 15:57 ID:5qWaSzXg: 「～～反しない」じゃダメだ。「～～反するもの」に読み替えヨロ(汗)
630：(･ω･)：2004/10/04(月) 16:04 ID:udO1kpmk: 下手に制限付けないで、ブレインストーミング的やり方で意見を集める、
という手法は良いと思う。
が、それを自動で集計して表示ってのは、やっぱおもちゃになっちゃやな(苦笑)
631：(･ω･)：2004/10/05(火) 15:07 ID:GdkaQsmU: 誰かｱﾌｫな漏れに分かりやすく解説してくれ

ttp://bbs.2ch2.net/test/read.cgi/ff11job/1096772298/32-34
632：(･ω･)：2004/10/05(火) 15:25 ID:UC3NZSUM: >>631
32,34のような奴でもまともなプログラム組めるのかなぁ、と思った。
633：(･ω･)：2004/10/05(火) 15:26 ID:gMl9Jb/I: >>631
あー、なるほどな…
これのできる条件は、

1. 鯖側はロット要求パケが来るたびに新たなロット候補を生成
2. そのロット候補をクライアントに送信
3. クライアントは鯖に受信OKパケを返す
3. 鯖側は受信OKパケ戻って来るまでロット候補確定を保留

まぁありえないロジックとはいえないな。
返答見て、期待のモノでなければ受信OKパケをブロックし、新しい要求パケ投げれば、
意図せずしてロットしなおし。

ふつう、ロット要求パケで最初に生成された数のみでロット処理しちゃって、
ロット返答パケのみ受信OKが来るまで再送、ってするとは思うが…
ログ飛びとかもあるみたいだし、投げっぱな気も。
634：(･ω･)：2004/10/05(火) 15:38 ID:RPmA.woU: >ふつう、ロット要求パケで最初に生成された数のみでロット処理しちゃって、
>ロット返答パケのみ受信OKが来るまで再送、ってするとは思うが…

どこが「ふつう」なんだ？
まだFFXIの規模のデカサがわかってないようだね
635：(･ω･)：2004/10/05(火) 15:46 ID:UC3NZSUM: アフォか。
TCP使ってるのに、なんでアプリケーションレベルで再送を意識するんだよ。
636：(･ω･)：2004/10/05(火) 15:50 ID:gMl9Jb/I: >>634
「通信」だとふつうっしょ。
そのへんを「教科書的に実装しちゃいましタ！テヘッ」とか、ありそじゃない？
なんせ競売デフォルトソート順がアレだったりする連中だぞ？

>>635
そう思う。
が、そのへんよーわからんうちに組んじまった…ってことは無いとはいえんのでは。
637：(･ω･)：2004/10/05(火) 16:17 ID:mh1DzhqQ: いやぁ、ロット操作への夢はなかなか潰えませんなぁ。

漏れ？
サポジョブを37まで上げるのに、印章10個しかGetできなかったYO！
乱数の女神さま………どうかお慈悲を………（´・ω・`）
638：(･ω･)：2004/10/05(火) 16:23 ID:VDDXU0.Y: >>635
tcpdump でもしてみれば分かるが、TCP つかってるところはほとんどないぞ。
UDP ばかり。

しかし、パケット来るたびにロット値生成しなおすなんて
あふぉなロジック、普通に組んだらありえないだろ？
639：(･ω･)：2004/10/05(火) 16:31 ID:d554rXPc: >>638
実際にパケット見たことあるみたいだから質問。
何らかの符号化はしてなかったの？
もしかして素で送ってるわけじゃ・・・
640：(･ω･)：2004/10/05(火) 16:33 ID:kzY72zHg: >>633
そのロジックだとパーティー（アラ）組んでいる
全クライアントにロットツールを入れておかないと
実現できないよね。
641：(･ω･)：2004/10/05(火) 16:38 ID:VDDXU0.Y: >>639 パケットをドコに送ってるか調べただけで、中身までは見てないっす。
642：(･ω･)：2004/10/05(火) 19:30 ID:lH7vX6Yg: 自分のロット値が見えてなくてもロット勝ちした事があるので
クライアントが数値を正常に受け取ったかどうかなんて1ミリも気にしていない筈。
643：(･ω･)：2004/10/05(火) 19:39 ID:gMl9Jb/I: >>642
やっぱそうかw
重さ考えりゃログなんて投げっぱだろうしなぁ。
644：(･ω･)：2004/10/06(水) 03:30 ID:2VyYhEHM: >>638
> しかし、パケット来るたびにロット値生成しなおすなんて
> あふぉなロジック、普通に組んだらありえないだろ？
ロット値生成システムと、アイテム分配システムが別だとした場合、
ロット値を保存して再送するよりは、make_lot()を一回呼んだほうが早いと思われ。

まぁ、アイテム分配システムでロット値を生成＋保存してない時点で、
設計がだめだめなんだが…
645：(･ω･)：2004/10/06(水) 05:30 ID:MXvuRqO6: >>644
>アイテム分配システムでロット値を生成＋保存してない
鯖側では保存されているが結果は一度しか送信されないので
一度クライアント側でその数値を失うと確認する事が出来なくなる、と考えた方がスマート。
こっちが確認しているかどうかなんて全くお構い無しに処理を進めるのが一番まともなチート対策だ
646：(･ω･)：2004/10/06(水) 09:08 ID:yLmQtjn2: >>638
俺も見てみよう。

しかし、UDPでNAT越えるのは難儀だろうな。
647：(･ω･)：2004/10/06(水) 15:38 ID:dv/QeCnI: >>646

そもそもUDPでNATって越えられるの？

使用ポート番号で判別して強制的に流すしかないかな？
648：(･ω･)：2004/10/06(水) 16:05 ID:Zq1.dq3Q: 現時点でもロットのやり直しはできるから、
穴があってもおかしくないとは思う。
649：(･ω･)：2004/10/06(水) 16:07 ID:Fjvl3rr.: >647
単に outの source addressと inの destination addressを書き換えるだけだから、
特に問題ないだろう。実際、FreeBSDで構築した Firewallではちゃんと通してる。

商用の個人向けルータで UDPを通す機能があるか、って話だったら、すまん。

昔はパケット内に IPヘッダとは別に source addressやらの情報持ってて、
NATかけると動かねえ、ってプロトコルは確かにあったが、
今は、IPv4使う限りは NAT/NAPT必須のご時世だからねえ。
650：(･ω･)：2004/10/06(水) 16:17 ID:dKa33V.E: NAPT必須だとぅ((((ﾟДﾟ;))))
メリケンとパーテー組むの怖いよﾏﾏﾝ
651：(･ω･)：2004/10/06(水) 16:20 ID:NYgC3F/2: 家庭用ルータもUDP、ふつーにNATして通すよん。心配無用。

UDPが良く問題になるのは、
・「サーバからUDPの指定ポートにパケットを投げてくる」場合
・UDPパケットにて生成されたルータ内NATエントリはTimeoutが早いため、
　ちょっとした隙に消えてしまい通信不能になる
などですな。
652：651：2004/10/06(水) 16:24 ID:NYgC3F/2: あ、ごめん、表現が足らん。
>・「サーバからUDPの指定ポートにパケットを投げてくる」場合
UDP上のプロトコルで、こういう手順をいきなり踏むやつが多いんですわ。
メッセンジャー系、ヴォイスチャットなどに多かった。
今はUPnPでNATエントリをPCがコントロール出来るようになったので、
ここらへんは(ちょっと強引に)解決してる御様子。
653：(･ω･)：2004/10/06(水) 16:24 ID:yLmQtjn2: >>647
外部起点のパケットを全部DROPしても、POL/FF11ともに
普通に使えているから、基本的に内部起点のパケットしか使っていないみたい。
となると、ネットワーク内のクライアント同士で連絡を取り合って
使うUDPポートを決めているか、UDPデータ内にPOLIDが入っているか、
そんなところだろうと思う。

>>648
やり直しって、ロットしたアイテムをパスする時しかないような。
654：(･ω･)：2004/10/06(水) 16:28 ID:dv/QeCnI: >>649

端末がトリガーだから、sourceポートをルータが憶えておけばいいのか

>・「サーバからUDPの指定ポートにパケットを投げてくる」場合

で、2垢運用とかしたときにどっち宛パケットか迷子になりそうと思ってしまった

> 昔はパケット内に IPヘッダとは別に source addressやらの情報持ってて、
> NATかけると動かねえ、ってプロトコルは確かにあったが、

IPsecがそんな感じだね
655：(･ω･)：2004/10/06(水) 16:30 ID:Fjvl3rr.: >650
NAPTを使いこなせる奴が、これからの勝ち組ｗ
あんたのスキルをアップさせる、うまい使い方を探してくれｗ

>651
解説感謝。
656：651：2004/10/06(水) 16:36 ID:NYgC3F/2: > 昔はパケット内に IPヘッダとは別に source addressやらの情報持ってて、

まぁ、UDPでなくTCPの話っすけど、ftpがこれに該当するです。
しかも、テキスト化されたIPアドレスがTCP/21を流れるですよ。

解析したことがあったんですが、ルータが書き直して、シーケンスナンバーを
ずらしてました。勿論Ackパケット内のシーケンスナンバーも捏造。
すごいよ……これを一番初めに作ったやつはすごすぎです。はい。
657：(･ω･)：2004/10/06(水) 16:43 ID:L64HQClA: >>653
ロットのやり直しは普通にできるだろ？
勿論、ロットして勝てればアイテムは手に入る。

1. A, B, Cの3人でPTを組む。
2. A, Bがロット。Cは放置。
3. A, Bでロットが低かった人がエリア切り替えして戻る。
4. ロットイン可能。
658：(･ω･)：2004/10/06(水) 16:50 ID:S0VfPM5c: >>657

そんなこと出来たんだ。2年半FFやってて初めて知る事実
659：(･ω･)：2004/10/06(水) 18:02 ID:GyNLaRes: >>656
IRCも、DCCやるときにアドレスを埋めこんだりしてます。
NATルータでFTPに対応してないのなんてほとんどないだろうけど、
IRCのDCCに対応してるのはあんまりなかったりします。
660：(･ω･)：2004/10/06(水) 19:48 ID:N4E3qYSw: >>657
AF2出たら回線落ちするやつ続出wwwwwwwwwwwwwww
裏じゃ無理かねぇ…。
661：(･ω･)：2004/10/06(水) 21:55 ID:zGUK87Yk: >660
Cが放置してるのがポイント
662：(･ω･)：2004/10/07(木) 02:01 ID:GeiDNvqc: >>660
ちなみに、裏の最後にアイテムが流れる人は、
最後に裏に入った人になっている。
そのため、終了間際に回線落ちを実行すればアイテムウマーとなる。
663：(･ω･)：2004/10/07(木) 13:54 ID:s/ahl7lo: 誰もいないな、ネ実の挑発ツールスレに出張か( ´_ゝ`)？
664：(･ω･)：2004/10/08(金) 16:02 ID:8JIVGWtE: 激ﾜﾛﾀ

633 名前： (･ω･) 投稿日： 2004/10/08(金) 15:48 [ wKbb97J. ]

取れたてほやほやの愚痴

シャクラミにて風エレ殴り中、竜騎士が背後に来た

それまで安定していた通信がR0～R4500等になった

エレを倒し終わると離れていく竜騎士

スニークかけてＭＰ回復…R200～R300にて安定しました

中華と思われる奴…何かツール使ってタゲ持ってる奴を落とすことが出来たりするのか？
665：(･ω･)：2004/10/08(金) 19:37 ID:pdIGRpw.: >>664
まぁ、笑えるが、仮にマクロコマンドやエモートで
・モーション無し
・ログ表示も無し
・でも周囲のクライアントには通知される
みたいなものがあったとしたら十分ありえるとは思う。

例えば/grin motionはいくら連打しようが表面上は何も起きないけど
モーションのID(？)は周囲のクライアントに通知されていたとしたら・・・？

モーションのモデルデータがあるかないかを
わざわざサーバーで判定するとも思えないので十分ありえると思う。
モーションの差し替えとかできるかわからんけど、
他のモーションのデータをgrinに差し替えれば検証はできるな。
666：(･ω･)：2004/10/08(金) 19:39 ID:pdIGRpw.: もっとも、その場合でも中華はもとよりNAやEUなんかはさらに
JPより回線で不利なので、無駄パケットで固まらせようと思っても
(外人vsJPなら)自分の方が先に固まるだろうけどな。
667：(･ω･)：2004/10/08(金) 20:40 ID:fRunaIhY: そうそう、上りのが遅いだろうから、回線に自信がなきゃ逆効果だよな。

でも、フィルターはサーバー側でやってるんじゃなかったっけ。
ずっと変更されなかったのはサーバープログラムいじらねばならなかったからとこのスレで結論でたような。
668：(･ω･)：2004/10/12(火) 11:48 ID:MiGcm/HM: メッセージフィルタがサーバ側なのは巨大モンスの時にアナウンスしていたけど
モーションフィルタがどっちで制御しているかはアナウンスしていたっけ？

普通に考えればサーバ側だけどね
669：(･ω･)：2004/10/12(火) 14:51 ID:8oMn7JY.: フィルタで通信量の低減を狙ってるのなら，やっぱり鯖側だろうな．
クライアントから見たら，相手は鯖一匹だけど，鯖から見たら
子供何千匹だからな．
670：(･ω･)：2004/10/13(水) 09:40 ID:zRSHCJn.: >>664
ふとおもったが、装備変更を乱射（？）していたとかそういうのはないだろうか。
装備を変えると点滅するということは、周辺のＰＣにも装備データがある程度は送信されているかと。
これを連発すれば通信量が増えてＲに影響が出ると思う。

とはいっても、自分自身はＳとＲ両方影響あるからなぁ。
自分自身のほうが不利になってしまうか。
671：(･ω･)：2004/10/13(水) 15:12 ID:MXl/u0RM: >>670
それでGM呼んだらくるだろうか
672：(･ω･)：2004/10/13(水) 15:31 ID:2XOdUJj6: >>671
[+]＜おちますた
673：(･ω･)：2004/10/13(水) 17:54 ID:MXl/u0RM: GMだってサーバーにぶらさがってるんだから，落ちるだろうね．
674：(･ω･)：2004/10/13(水) 18:04 ID:6bYlcGgk: だから最近は直tellモードに移行してるんじゃ。
675：(･ω･)：2004/10/13(水) 18:42 ID:MXl/u0RM: ひざカックンみたいなもんやね．
676：(･ω･)：2004/10/13(水) 19:05 ID:Q0EPGXXg: >>670
ふとおもったが、中華が1000人集まっていっせいにそれやったら落ちるかもしれん。
中華も数百人おちるだろうがなｗ
677：(･ω･)：2004/10/14(木) 08:36 ID:CVBNpays: >>676
１エリアに１０００人集まった時点で落ちる
678：(･ω･)：2004/10/15(金) 05:06 ID:1xECYlu.: この分野は門外漢な漏れから質問させてくれ。
サーチで全エリア＞フレンドと絞っていくと、全エリアにいるフレンドのみ
表示されるんだが、その並び順はどういう規則に則ってるんだ？
必ず１番上に表示される奴がいるのが気になったんだが
フレンドに登録した順番でもないし、現在地から近い順番でもなく
どこに誰がいようと、必ず決まった順序で結果が表示されるのだが
679：(･ω･)：2004/10/15(金) 08:55 ID:w0p3SJnQ: FFXIで影のアルゴリズムってどういうの使ってるのかな

凸凹した場所で戦闘不能になって転がった時に、
体の一部が地面に潜った状態になって、潜った部分の影が
体の上に有る地面に落ちていた。
680：(･ω･)：2004/10/15(金) 09:47 ID:ATXBJ1JI: >>678
POL-IDとか、その辺じゃないか？
681：(･ω･)：2004/10/15(金) 09:49 ID:Q/yn/0IQ: >>678
その「先頭」に来る人の名前、
アルファベット順で一番若かったりしませんか？
682：(･ω･)：2004/10/15(金) 10:28 ID:7rXQfpUU: >679
あんなもんてきとーだろ
デコボコのところで影がとんちんかんなトコに出たり
２つ出たり、埋まったり
683：(･ω･)：2004/10/15(金) 11:43 ID:aaG9mz8A: >>679
かなり高い確率でシャドウマップ。

あと、階段やオーバーハングになっている部分での写り方からの推測だが、
PS2とPCでは投影方法が若干違っていて、
PS2では仮想光源から見たシャドウマップを斜めに投影していて、
PCでは仮想光源方向に押しつぶしたモデルを
真上から見たシャドウマップに描画して真上から投影しているのだろうと思う。

別フロアから突き抜けて見えるウォークライや
召喚魔法の魔方陣エフェクトも恐らく同じ手法。
684：(･ω･)：2004/10/15(金) 13:32 ID:W2hf10VM: >>683
床の上に落ちた影って、床の裏面にまで達してるからなあ。(´・ω・｀)
それでもPSOみたいなただの丸い影よりは、随分マシとは思うが。
685：(･ω･)：2004/10/15(金) 13:45 ID:ATXBJ1JI: 影と言えば、
チョコボに乗ってるときの影
キャラとチョコボが重なってる部分だけ濃いのなｗ

SEとかプログラマがFF11を語る スレ Ver1.11sp1