【PC】デッドオアアライブ5LR MOD制作スレ7 [無断転載禁止]©bbspink.com
■ このスレッドは過去ログ倉庫に格納されています
>>748
なるほどな
>黒になる可能性はあるんじゃないかとは思うが
>それはバグを直す義務があるということじゃない
結局は作者の自己責任でしかないということか
世知辛いが仕方ないか
>それと報告をお願いする必要もない
これは全くその通りだな
>それを知った時点で少なくとも未必の故意があってですね提供罪が成立する
という話ならわざわざ知らされるのはむしろいい迷惑とも言えるｗ
>>749
>天狗は天狗にさせときゃそのうち目を覚ます
百歩譲って「お気軽にご報告ください」に「報告することを許す」みたいな
ニュアンスを感じることは認めるとしても、
それで天狗というのはいくらなんでも飛躍しすぎだろう
それに別に天狗になっても大いに結構だと思うがな そもそも、「バグが報告されてるのに放置し続けた場合」が前提条件なんですが・・・
上から云々は、はっきり言って、あなた下ですから！ 駅でキチガイに出会っても話しかけないだろ？
ネットでも一緒、スルーしとけ
関わっても不幸にしかならない なんだ。。ただの精神病患者だったか。。荒らしかと思ったよ 道徳師匠に聞くべきかどうかもわかってないんですが、
blenderからtmcmeshで書き出すとUV位置が微妙にズレてしまいます↓
http://i.imgur.com/1Nr0SSh.jpg
重なっている赤いほうが書き出し後です。
正規化とかピクセル吸着とか必要な操作があるんでしょうか？
少しデリケートな処理をしたいのでどなたか助けて下さい〜 なんかすっかり過疎ちゃったな
今年最後に述べておく
道徳神は先生であり、神。
以上だ、有難う感謝しかない
最後にひとつ聞かせてください
OH、,道徳神よ、あなたがツールモッダーとして次に目指すタイトルはありますか？ どうもです。
>>758
これはTMCのUV座標があまり精度の高い値を持てないために発生します。
つまり仕様です……
>>759
ないです。
>>708
いけたっぽい。 >>760
>これはTMCのUV座標があまり精度の高い値を持てないために発生します。
>つまり仕様です……
誤差の原因になる数値計算の部分さえ精度の高い型を使えばいいというものでもないんですか？
計算誤差の合計がHalfの丸め誤差よりも小さければ値の一致・不一致は完全に復元されると思うんですけど >>761
計算誤差ではなく、Half（半精度浮動小数点数）の問題です。
公式も先っぽの方のUVはガタガタです。 >>762
UVって基本0-1の範囲のHalfの値ですよね？
だったら点を一致させたければ同じ値を指定すればいいような気がするんですがそういうわけでもないんですか？
これが頂点の座標みたいに座標変換が掛かってて、
違うの座標変換が掛かる点同士をピッタリ一致させられないってことなら分かるんですけど
あと、公式が最善の処理をしてるとは期待できない気が・・・ 影問題が発生する理由が何ですか?
どう修正することができますか。 >>763
>>だったら点を一致させたければ同じ値を指定すればいいような気がするんですがそういうわけでもないんですか？
同じ値というのは何と同じということでしょうか？
Blender書き出し前のUV座標値ですか？ >>765
そうです。>>761と同じことですが、例えば計算時の仮数部がHalfよりも10ビット大きければ、
ざっくり1000回（プラスマイナスの相殺を想定すれば100万回）程度の計算なら完全に復元できませんかね？
まあ情報落ちって話はありますが、そんなに隅っこのUVを使うことは少ないでしょうし >>766
Single（BlenderのUV値）→Half（TMCのUV値）の変換が入るので一致は無理だと思うのですが…… >>767
Singleが全く同じならHalfも同じですよね？
そしてSingleが多少違ってもHalfは同じになります。>>763や>>766はそういう話です
・・・もしかしてからかわれてる？？？ ちなみにSingleは32ビットで仮数部は23ビット、
Halfは16ビットで仮数部は10ビットです。念のため >>768
TMCをインポートしたものをそのままtmcmeshにエクスポートすると一致します。
が、>>758さんのは細分化してるように見えますんで、
書き出し前のUV座標値はHalfで再現できるかどうかは関係ないSingle値になります。
そして書き出しでSingleからHalfへの変換が必要なので、
書き出し前と書き出し後のUV座標がズレるということなのですが……
ちなみにHalfへの変換前のUVの計算は 1 - V値（Single） だけですので、
>>758の画像のようになるほどの計算誤差は発生しない、と思っていますがどうなんでしょうか。 あと>>758の画像は結構拡大されてますので、一辺が0.05ぐらいの範囲だと思われます。 多少の誤差くらい気にすんなよ！ガキじゃねえんだからさ！ >>770
>が、>>758さんのは細分化してるように見えますんで、
>書き出し前のUV座標値はHalfで再現できるかどうかは関係ないSingle値になります。
方眼紙の１マスがHalfの一つの値に対応するとします
マスの中心以外の点はHalfで再現できないSingleの値です
方眼紙上にデタラメに２つ点を打ちます
但し二つの点はマスの辺の長さに比べて十分に小さい（例えば8万分の1）とします
2つの点が別のマスに入っていれば2つの点はHalf表現で別の値になるわけですが、
そうなる確率はどんなもんでしょうか？
>ちなみにHalfへの変換前のUVの計算は 1 - V値（Single） だけですので、
>>>758の画像のようになるほどの計算誤差は発生しない、と思っていますがどうなんでしょうか。
そう思います。HalfとSingleでは23-10=13ビット、つまり8万倍も違いますし 誤：但し二つの点はマスの辺の長さに比べて十分に小さい（例えば8万分の1）とします
正：但し二つの点の距離はマスの辺の長さに比べて十分に小さい（例えば8万分の1）とします
でした。 道徳さんは相手を下に見てるような言い回しを無意識でやるよね
意識してやってたら相当性格悪い >>760
承知しました。
次は無くとも多大なる貢献に感謝を、道徳神
楽しい日々でした、良いお年をを！ >>773
>>方眼紙の１マスがHalfの一つの値に対応するとします
>>マスの中心以外の点はHalfで再現できないSingleの値です
>>方眼紙上にデタラメに２つ点を打ちます
>>但し二つの点はマスの辺の長さに比べて十分に小さい（例えば8万分の1）とします
>>2つの点が別のマスに入っていれば2つの点はHalf表現で別の値になるわけですが、
>>そうなる確率はどんなもんでしょうか？
低いと思うのですが。
>>758の画像でも書き出し後のUV座標が横一列に結構並んでたり（Vが同じ値）しますし。
>>776
まじすか……お気づきな部分がありましたらご指摘頂けると嬉しいです……
>>777
良いお年をー。 >>778
>低いと思うのですが。
ですよね？
つまり「Halfで再現できるかどうかは関係ないSingle値」になることと
「SingleからHalfへの変換」で値が一致しなくなることはほとんど関係がないですよね？
・・・おちょくるというか試されてるならこのあたりで勘弁してほしいです。。。 >>778
道徳さんには聴く耳がありそうなので、先程のやり取りを例にあげると
>>767
>>Single（BlenderのUV値）→Half（TMCのUV値）の変換が入るので一致は無理だと思うのですが……
例えばこの語尾を濁すような言い方は、相手に何かを指摘する場合にはやめた方がいいです。
暗に相手を非難するような印象が加わります。
例えば、
〜の変換が入るので一致は無理だと思うのですが……（そんなことも分からないのですか？）
のように受け手に非難を想像させる余地を残してしまいます。
ですので、何かを指摘する際は明確に「思います。」で締めくくった方が良いかと思います。
上記の文章を「ですので、何かを指摘する際は明確に「思います。」で締めくくった方が良いかと思うのですが……。」
とすると不愉快に思われる方が少なからず出ます。 >>779
本当におちょくっているわけでも試しているわけでもないので、
ほんのもう少しお付き合い頂ければ助かります。
「Halfで再現できるかどうかは関係ないSingle値」になること → BlenderでのUV値
「SingleからHalfへの変換」で値が一致しなくなること → tmcmeshで書き出したUV値
で「BlenderでのUV値」と「tmcmeshで書き出したUV値」がズレているという問題だと思っていたのですが、
そもそもの論点について私が何か勘違いしていますでしょうか？
なにかすれ違っている気がしてきまして。
>>780
なるほど。ありがとうございます。気を付けます。 質問スレで
>「制作関係の質問なので制作スレで回答します」
っていうのも正直やめた方がいいと思う 210 名前：ほのぼのえっちさん[sage] 投稿日：2016/10/01(土) 02:29:55.05 ID:pSCVRZa20 (PC)
偉そうなことを言ってすみませんが、図々しいという表現は少し言葉が悪くないでしょうか。
熱意ある要求に対してこの言葉が使われていたときは傍から見ても気分がよくなかったですし、
ただのコリジョン問題一つにしても試行錯誤に費やした労力は質問者さん以外分かりようがないはずです。
何より、ご自分の製作熱意の無さを誤魔化すために文句を言ってるような印象を受けます。
592 名前：ほのぼのえっちさん[sage] 投稿日：2016/10/23(日) 17:35:08.71 ID:7nNyvpKI0 (PC)
疑問文に「か」を付けないって叩かれてたのは単純にその言葉遣いだけに問題があったわけじゃなく、
アップしてもらってる物に作者さんのがどれだけ手間をかけてるかということも考えずに
それが自然に湧いてくるものであるかのような態度をとってたのがよく思われなかったんだろうね。
そういう身勝手な意識を持ってなければ「もうあがってます？」なんて表現は出てこないだろうし、
作者さんを急かすことにもなりかねない発言なんだから言葉には相当気を使うはずだよ。 >>782
それは適切に誘導してるだけで、むしろ必要でしょ。
内容の住み分けはちゃんとしないと皆が困るよ。
物理と数学をを同じノートに書いてはいけない。 >>758
ちょっと考えたところ、結構面倒ですが「少しデリケートな処理をしたい」ということであれば
ズレをなくしたい部分を別オブジェクトにして、UVを拡大するという方法がありますね。
拡大倍率が大きくなればなるほどズレは減ります。
そのオブジェクト用の画像を用意する必要があったり境目を気にする必要があったりします。
（画像は拡大する必要は無く、切り抜きだけが必要です） >>783
>で「BlenderでのUV値」と「tmcmeshで書き出したUV値」がズレているという問題だと思っていたのですが、
そうすると、Singleの値が丸めによってHalfの値に吸い寄せられることが問題ってことですか？
だとすれば、その結果ズレが生じるわけですから「ズレるのは仕様」って答えは確かに正しいですね。すいませんでした
ただ、そのズレは多くの人が想像するであろうズレとは随分違うものなので、
（蓄積する性質のものじゃないとか、原点近くはズレが少ないとか、整数点の折り返しで悪化するとか）
「仕様」とだけ答えて突っぱねるのはちょっと違う気もします。。。 >>785
物理と数学の違いは確固たる共通理解があるけど
制作関係の質問かどうかは俺様ルールなところがあるというか、
俺の判断がここの総意だっていう態度の方を問題にしてるんじゃない？ とりあえずID:CbWEyb/B0がコンプレックスから噛みついてる流れは分かった。 >>787
言葉は間違っちゃいないが不親切だったってこと？
ほとんどの人間は仕様だと言われたらハイそうですかとしか言えないから
分かる人にはこういう指摘をどんどんしていって欲しい >>758をよく見ると縦方向にばっかずれてるようにみえるけど、
これもID:po3U0VG70が言ってることと関係ある？
素人考えでは横が揃えられるなら縦も揃えられるだろって思うんだけど >>791
縦方向だけ、しかも最近接点じゃなく必ず上方向に丸めてるね
これで仕様っていうのは苦しい気がするな >>787
>>ただ、そのズレは多くの人が想像するであろうズレとは随分違うものなので、
>>（蓄積する性質のものじゃないとか、原点近くはズレが少ないとか、整数点の折り返しで悪化するとか）
>>「仕様」とだけ答えて突っぱねるのはちょっと違う気もします。。。
突っぱねたつもりは全くありません。
「仕様」としか答えようが無かったのですが、もっと勉強していれば適切な回答ができましたね。
また、浮動小数点数について詳しくなかったので勉強になりました。
お付き合いいただいてありがとうございました。
>>788
>>俺の判断がここの総意だっていう態度の方を問題にしてるんじゃない？
BlenderからExportしたtmcmeshの問題でしたのでこちらへ誘導させてもらいました。 >>791
>>787での「原点近くはズレが少ない」に該当するようです。
この部分をTMCのUV原点である左上近くに持っていくとズレがかなり減りました。
（UVの上下反転だけではズレは減っているようには感じませんでした）
UVの配置を変えれば>>786のように別オブジェクトにする必要はないかもしれませんが、
それはそれで面倒そうですね。
>>792
変換に利用しているものがそうなっていまして。
何とかできないかはトライしているんですが。 >>794
銀行丸めじゃなくて四捨五入でよければこんな感じでどうですか？
Half SingleToRound_RoundToNearest(Single x)
{
// HALF_EPSILONはHalfの計算機イプシロン
return SingleToHalf_RoundTowardZero(x * (1.0 + HALF_EPSILON / 2.0));
} 758です
皆さんありがとうございます。
スクショが分かりづらくて申し訳ありません。
計算式の問題だったんですね〜
構造を考えなおさないと…
ちなみに横にもズレてますよ
>>786
たしかにスケールが大きければあまり問題がないようですね。今まで大げさな問題が出なかったのもピクセルのサイズとの差も影響していたわけですね。
ハリー方式で乳首を島UVにすれば解像度の拡大とキャラクター別の胸部テクスチャの歪みの解消が見込めたんですけど、個別に乳の歪みを取ったあと島にして、それから乳首を島にするとなると作業量が半端ないなぁ
バージョンアップは置いておこうかな… 別に立候補したわけでも任命されたわけでもないのに、事実上のボードマスターはつらいなｗ
>>778
そんな部分などないですが、おかまチックなところがないのでちょっと怖いときがあります。
語尾をおかまチックにすればモテます（見えてる罠）
>>777
よいおとしを〜 >>799
mantissa >>= F16_MANTISSA_SHIFT
を
mantissa = (mantissa + F16_MANTISSA_OFFSET) >> F16_MANTISSA_SHIFT
にすればいいと思いますが如何でしょう？ 一応補足
F16_MANTISSA_OFFSETは
F16_MANTISSA_OFFSET = 1 << ( F16_MANTISSA_SHIFT - 1)
です。符号なし整数の割り算
a / b
は
(a + b / 2) / b
と書き換えれば四捨五入になります
シフトと割り算の関係はググってください
あと稀にmantissaが繰り上がりを起こしますが
その場合mantissaをゼロにして指数部を1増やせばいいと思います（Halfはケチ表現なので）
同じことは
f16 = sign | exponent << F16_EXPONENT_SHIFT | mantissa
を
f16 = sign | (exponent << F16_EXPONENT_SHIFT) + mantissa
に書き換えることでも出来そうですね
そうすると更に稀に指数部がオーバーフローしますが
その辺の例外処理をどこまで突き詰めるかはおまかせします 発想を変えてHalf表示のUV編集ができるアドオンとかあれば接線はなんとかなるのかもしれないとふと思いました〜…
いえついふとね… >>760
> いけたっぽい。
おお、素晴らしいです！公開を楽しみに待ってます。
+ +
∧＿∧ +
（0゜・∀・） ワクワクテカテカ
（0゜∪ ∪ +
と＿_）__） + 表情変換で多少の問題があるようで報告します。
BlenderでHITOMI表情csv生成->Movie Data ToolでKOKOROに変換することになれば、
顔の表情の半分が壊れます。
KOKOROの顔のWeightの問題とも関連があるようですが
問題発生の原因を推測してみると、Face_Rootの固有値がBlenderで出力するときに変更されるようです。 Face_Rootの値によって異なるBoneの座標も相対的に変更されるために一般的に問題が生じないが、KOKOROは特殊な場合であるため問題が発生するようですね。
解決方法は、おそらくKOKOROのFace_Root数値を6.283142に変更させた後に他の座標の値を、再び相手的に調整すればいいであると推測されています。
実験することはできなかったため、正確な解決方法がないことができます。
:サンプル
http://www.mediafire.com/file/9jqqu4qrxuelnjh/HITOMI_FACE_SAMPLE.csv Rotaionも影響を及ぼすかはよく分かりませんが。。 >>802
>>806
ツールもMODも公開しないならゴミと同じだから
やることもやらずにでかい顔してんじゃねえようぜぇ Face_Root Positionを0、0、0にセット後に
調節した距離分だけ他のBone位置を逆向きに再調整すれば、なるようです。
Blenderを通じて復元することはひとまず成功しました。 Blenderを経由した表情データはRotationが(0、0、0)でセットされるようですね。
そのためにRotationが(0、0、0)の場合、AND変換ターゲットがKOKOROの場合には
Face_RootをPositionを(0、0、0)で調整して以来、下位Boneの座標を再調整する。
のような方式なら、解決がいいですか
面白い問題のようで少しおせっかいをしました; >>809
あいかわらず投げるブーメラン全部自身に刺さる芸風やな (´･ω･`) >>804
できましたー！
Movie Data Tool 0.13.0
https://www.mediafire.com/folder/9zi2gt8dyllaj/doa5mod
>>801-802
丁寧に教えていただきありがとうございます。
もう少し勉強してから対応したいと思います。
>>803
>Half表示のUV編集ができるアドオン
オブジェクトのUVをtmcmeshでエクスポートした場合のUVに変換、とかならできそうですが…… >>806-807 >>810-811
ご報告ありがとうございます。
色々とやって頂いたようなのですが、下記を試したところどちらも特に問題が無いように見えます。
■テスト1
Movie Data ToolでHITOMI_MOT_WIN_120.tdpackの顔モーションをCSVエクスポート
↓
エクスポートしたCSVをMovie Data ToolでKOKORO_MOT_WIN_122.tdpackにインポートして顔ボーンの位置調整
■テスト2
HITOMI_MOT_WIN_126.tdpackをBlenderでインポートしてCSVエクスポート
↓
エクスポートしたCSVをMovie Data ToolでKOKORO_MOT_WIN_122.tdpackにインポートして顔ボーンの位置調整
何かやり方が違ったり、特殊な条件があったりするのでしょうか。
なおツール類のバージョンは以下を使用しています。バージョンの問題の可能性もありますのでご確認ください。
Movie Data Tool 0.12.0
for Blender Bone Motion Exporter 0.4.1
for Blender DOA5PC Motion Importer 0.5.1
for Blender TMC(PC) Importer 0.11.1 こちらでは問題が続くようです。
簡単に再現できる方法は次のようです。
BlenderでHITOMI_FACE.TMCをロードします。
無表情の状態のままでcsvでMotion CSV exportします。
Kokoro Paradise.MPMに適用後Hitomi->Kokoro変換します。
BlenderでKOKORO FACE.TMCロード後に
Motion MPM Importします。
http://imgur.com/wzaTKIm.jpg >>815
ありがとうございます。
再現しましたので、どう対応するか考えてきます。 >>816
最初の状況はAYANE表情->Blender修正->HITOMI変換->KOKORO変換というちょっと複雑な状況でした。
支援ありがとうございます。 >>817
Movie Data Toolで>>810と同じことを顔ボーンの位置調整時に自動的に行うようにしました。
全てのキャラクターの公式モーションでOPT_Face_Rootの位置はXYZ全てが0にあるようですので、
こころに変換した場合だけでなく全てのキャラクターへの変換で行われます。
Movie Data Tool 0.14.0
https://www.mediafire.com/folder/9zi2gt8dyllaj/doa5mod https://video.twimg.com/ext_tw_video/781419461311987712/pu/vid/720x1280/GrssFUR4sVPr2Mzn.mp4
性の喜びを知りやがって、お前許さんぞ！
性の喜びを知りやがって自分たちばっかり、俺にもさせろよ！グギィィィ！
人の自由を剥奪しやがって。 恋愛の自由を剥奪しやがって。
許 さ ん ぞ ！！
そうしてこんななんだ。女に相手にされんだったら、ホモに転向しろかい。
バカじゃねえか。ホモとかレズってえのはいっつも言うようにな、
生まれた時から性同一障害っていうな、障害者なんだよ。
異性を愛せないという、病気なんだよ。なんで俺がそんな病気になると思う。俺は女大好きだよ！
何言ってんだ。シィッ。
変なこと、出来るわけないだろぅ！
近頃はもうそういう風俗でも行かないと寝られなくなったじゃないかぁ。病気になった完全に。
不眠症なんだよ。女性の裸みないとどっか頭が。
グラドルなんてあんな写真なんか見ておっさんが満足出来るか？
小学生じゃあるまいし。チクショウ。何がグラドルの写真だよ。バカじゃねえか。
いい歳したおっさんがグルドルのそんな若い子見て興奮するわけないだろう。
チクショウ何がグラドルだ。馬鹿馬鹿しい。
グラドルですって・・・馬鹿すぎる！
クッソゥ
自分たちは、お前たちは当たり前のこと、俺はやっとらんがな！ふざけんなよ！
週末には彼氏彼女の部屋に泊まりに行くくせに。
Weekend Lover の癖に。Weekend Lover のために色んなことをするんだ。
ああでもないこうでもない。
あんなことこんなこと、ドラえもんみたくやっとんだろ。あんなことこんなことやっとんだろお前。
あんなこといいな こんなこといいなって言いながら。Lover とやってんだろ。
Weekend Lover で。
んで、月曜日のマンデーに、
翌日、そういうのやったから･･･元気が出るんだ！ >>818
お疲れ様です
どえらい便利になりました〜ありがとうございます！ SaafRats氏のGENIって移植キャラが良いです
タイプCのボディのキャラ用です
不思議と微乳が一番気に入りました デリケートなUV計算ができないTMCちゃんのために、胸部テクスチャのアポロ式分割やってみた
http://i.imgur.com/LuVDzYW.jpg
もうギッチギチですが、結果は上場でした
http://i.imgur.com/T0D1gaf.jpg
問題
キャラ毎に汗と泥テクスチャを作る必要がある
構造が複雑すぎて気軽にいじれない
はたして作業工程の多さと効果が噛み合ってるのか… 公開しない宣言しておいてまた来たのかよ
ブログでやれよ >>828
すごいっす
使われないテクスチャの背景にも拘りが まぁ、いつも思うのが
裸ひとつのモディングでよく飽きないなとｗ
あんま変化ないのにどんだけ注力〜 やっぱ服のほうがほしい？ちょっと対魔忍作ってるけど裸より全然楽だわ
スレが死に気味だから工程上げてるけど毎回単発ちゃんに叩かれるので皆さん気分良くないなら控えます。どうしましょう モディングやってんのはおしりのおっさんぐらいだし、
画像、さらしを私物化してもいいと思うね、俺は
製作はどうとくさんがまだいてくれているし、それ以外は支配していいと思うｗ >>818
改修乙です、ありがとうございます！
>>828
もう完全にシームレスですね〜、シームレスだとまだまだちんこも立ちますｗ
多分真似はできないですけど、気が向いたら適当な技術解説などお願いします〜
これまで微妙な継ぎ目を払しょくできなかったの原因はノーマルですか？
しかし公式でさえ乳頭あたりのUVがガタガタで使いにくいと思ってたらTMCの
特性だったとは・・・こんなのよく原因突き止めましたね、ここの皆さんは。
>>835
工程楽しんでます〜
裸でもコスでも作りたいもの作っていただくのが、まわりの仲間にもおもしろい刺激に
なって良いと思いますよ〜、LLやFSDの方もここを見て楽しんでられるようですし。
今日のチラ裏
どこをどう触ったかまったくわかんねーニンジャ
http://i.imgur.com/ghd4oIU.jpg ふたばの過去ログ見てたらこころでオレのやろうと思ってたことを既にやってた人が居た！ >>843
・・・・・・・・・・・・
・・・・・・・・・・・・
・・・・・・・・・・・・
・・・・・・・・・・・・
・・・・・・・・・・・・
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
正解！ これまでの流れが流れだったし・・・ｗ
乳首ぽっち好きよ 103 : 実況しちゃダメ流浪の民＠ピンキー (ﾜｯﾁｮｲ 0fee-Rz1x) 2016/12/31(土) 00:30:31.74 ID:2NhUmAGM0
>>100
お疲れ様でした。
まぁ気が向いた時にまた試してみると、違う視点で見れて問題解決できたりしますよ。
自分がツールを作っている時はそんなのばかりです。
これは今となっては無意味かもしれませんが一応書いておきますと、
「見える化」は「全ての情報」をリストアップしなければほぼ問題解決には繋がりません。
具体的な情報と些細なことまでの詳しい情報がリストになって初めて正しく機能します。 この文章にしても、この程度でイラつくのは心が狭いけど、
心の狭い人間がイラつくことは間違いない
そういう絶妙なラインを意識的についてるとしたら
やっぱり相当性格悪い >>849
XaRZ75nn0はこれを道徳さんが書いたって言いたいんだろ
確かにツール云々とか悪意のあるミスリードを狙ってるが、
この頭の悪い煽り方は明らかに別人だな ■ このスレッドは過去ログ倉庫に格納されています
