よねぞん画像掲示板

---Aボディだけを縮小化してしまう方法---
前列真ん中の3名と後ろのモンスター肩乗り3名全6名だけがAボディです。
歴代らぶデスキャラは原寸保持のままAボディからCボディに変更、サキュバス
はそのまま、モンスターはたむたむH編集時の寸尺の状況で撮ったSSです。
今回の方法が既出でしたらスミマセン。

---やってみたALP2PMX縮小寸---
ALP2PMX固有機能の等身伸縮という項目を試してみました。
ど素人ながらも出力されたフォルダの中に [base_body_A] という
かつて中身を弄った事のあるフォルダがあるのを見つけました。
このフォルダを弄った事の無い者だけが罪人に石を投げなさいという
あれですね。という事はAボディ全部に適用が及ぶのか……個体別は無理そう。

�@まずお手持ちのAボディ使用のALPをひとつ用意して、ALP2PMXで読み込みを
実行させます。動作確認的な意味でこちらでもサンプルを用意しますが、
お手元の環境を全て引き継がせるには各自の環境下にあるALP使用が最良です。
できればお手元の環境下で一度以上更新履歴のあるALPを使用して下さい。

�A開くのボタンから行くと、下部[ファイル名]のマス目に[xxxx.alp]と
フルネームでコピペ入力しないとALP2PMXは読み込んでくれません。
下半分の左側に等身の項目があります。以下は偶々上手く行った数値を
書きます。

�Bチェックマークは全部入れたままで、左の数値入力を上から
114、0.72、0.72、0.72、0.21、と埋めます。
�CALP→ODFボタンで出力させます。
出力後に表記数値が変化してる場合がありますが、特に留意は不要です。

同じ数値を打って出力させたのに、たむたむす〜るを起動すると縮小が
実行されていない事態は数度経験しました。逆に一度通用したものは何度
でも通るようで、途中から縮小しなくなる事態には遭遇していません。
縮小は起きるか否かの2択のように見えます。今の所入力数値の差異を実感
できる状況には対面出来ていません。

---[らぶデスＦＩＮＡＬ！] 内のフォルダを弄る---
�@[\らぶデスＦＩＮＡＬ！\data\odf\Body] 内に同名の [base_body_A]
というフォルダがあるので、これをバックアップ取ってから削除します。
�AALP2PMXから出力されたフォルダ内に存在する同名フォルダ [base_body_A]
をこのフォルダだけ抜き出して [\らぶデスＦＩＮＡＬ！\data\odf\Body]
内にコピペで置き換えます。上書きはしないで下さい。

で、やってみた所、ボディに留まらず頭、髪、服、武器に至るまで
一括で全部縮小できてしまいました。どういう理由か首だけ少々長目に
なるみたいですが、この程度ならば個別の体かすたむで吸収可能な範疇です。
(SS中の6名が該当します。無修正だとこのような首の長さになります。)
とりあえず、置換実行前の [\らぶデスＦＩＮＡＬ！\data\odf\Body] の
[base_body_A] という元フォルダを多重でバックアップ保全取っておけば
何度でも元に戻すことが可能です。てか作業時は原寸の方が圧倒的に扱い易い。

あと、試した範囲内ではこのSS以下には縮小しないみたいです。
何故なのかとかは全く不明です。先述の通り可か不可かでしか結果が出ません。
プログラムやデータ解析方面は苦手で、普段から意味も分からずに数値入れて、
結果半泣きでOS入れ直すような奴なので、後は詳しい方々に道を譲りたいです。
ご質問等あろうかと思いますが、恐縮ながら何も答えられないと思います。
らぶデスFINAL、たむたむす〜る両方共プログラム実行時に何の問題も起きず、
尚且つ簡単に元に戻せるのが長所でしょうか。しかし因果は不明であり、
最悪OS入れ直すような状況が起こり得る可能性があるという点に御留意下さい。
自己責任でお願いします。しつこいですが、バックアップ必須です。

---アップロードしました---
説明文作成に一番時間が掛かってしまいました。以下の内容でアップします。
�@加工済みbase_body_Aフォルダのサンプル2種→52MBを10MBに圧縮かけてます。
�A縮小時用HAN2種→2807氏作のAボディ用と汎Aボディ用。両方低身長限定です。
�B5月末に出した4人組の更新ALP→今回用に身体微調整の上、秋服着せました。
引用元ALPは5〜6月のと同じです。今回下着だけ紳士No1039氏作のSDK SDJ Bdk
Bdjを新規追加しました。作者の皆様、ありがとうございます。

http://kienizer.com/download/493265
DLパスは英小teatimeです

Re: Aボディだけを縮小化 - のぞく人 2019/09/08(Sun) 17:40 No.827
初めまして。面白い情報ありがとうございます。

添付されているサンプル(�@の方)で試させて頂きましたが、なるほど手持ちアイテムまで小さくなりました。なお差し替えるのは「RT_body_type_A.ODF」だけでいいようです。

ALP2PMXにOdfHeightというツール(古い)が同梱されているのですが、これの説明に
「ODFの身長を変更する場合ODAも変換しないとダメ」
とあるので、ツールが作られた当時とどこか動作が変わってるのでしょうね。うん、何故ODAファイル(アニメーションデータのファイルです)を書き換えなくてもいいんだろう？

そのOdfHeight、何となく「ODFファイルの身長変更はこれがあれば大丈夫」と思い込んでいたのですが、これかすたむシリーズより前のODFファイル用だったのですね(FINAL!のRT_body_type_A.ODFを放り込んだら対応してないと怒られました)。ファイルの日付見れば明らかなんですが。なので、もしODFファイル自体の身長を変更しようと思ったら6811さんが書き込んで下さったようなことが必要になるのだと思います。

RT_body_type_A.ODFのどこが書き換わったから着てるものから手持ちアイテムまでみんな縮小されるのかとか、ALP2PMXの頭身設定で「ALP値」にチェックが入ってる時に数値設定がどの様に反映されるのかとか、調べどころが色々ありそうです。

Re: Aボディだけを縮小化 - 6811 2019/09/08(Sun) 20:14 No.828
のぞく人様、踏み込んだ詳細情報をいただき、ありがとうございます。充分な準備や精査もなく、
半可通にも満たない領域に迷い込んでしまった状況に助け船を出していただけて大変恐縮です。
Re: Aボディだけを縮小化 - 6811 2019/09/09(Mon) 18:09 No.831
のぞく人様よりご指摘いただきましたように、どうやら縮小が起きる、または起きない時の差はたむたむ起動時の
[base_body_A]フォルダ内のファイル[RT_body_type_A.ODF]にあるようです。縮小が起きないときは更新日が元に
戻っているのを確認しました。

OdfHeightというツールの情報をいただきましたのでこちらも試してみました。
手持ちのだと[ODF ver1.05]の[身長変更]ボタン押すと出てくる奴です。理由不明ながら[RT_body_type_A.ODF]は読み込み可能でした。
少々ノーマル時と上の縮小適用済みサンプル�@の[RT_body_type_A.ODF]を使用して数値入れ替えを色々試してみたところ、
こちらのツールの方が入力数値の差異が結果に反映するようです。縮小が起きない確率はALP2PMXの時と同じ位あるようです。
ただ首が長くなるバグがなくなってたり、こちらのツールの方が優れていると思いました。
OdfHeightと設定値込みでSS撮りました。もう少し色々試してから投稿書き直ししてみます。

Re: Aボディだけを縮小化 - のぞく人 2019/09/10(Tue) 01:44 No.832
OdfHeightの新しいのがODF(神ツール)から呼び出せるようになってたんですね。気付いてませんでした。前の書き込みで「かすたむシリーズのODFファイルが読めない」と言ったのはomakeフォルダにある古いバージョンのことなので、ODFの[身長変更]ボタンで呼び出されるOdfHeightでかすたむシリーズのODFファイルが処理できるのは正常動作です。

OdfHeightはらぶデス2か3の頃からあるツールで身長変更に特化してるので、「ALP2PMXで書き出してコピー」より簡単確実かと思います。ちなみに身長計算のベース値になっているのはらぶデス2のODFファイルで、aa:愛美、a:あゆみ、b:みなも、c:琴、d:奈々美、e:よつば、という対応です。かすたむシリーズのデフォルト身長だと一致するのが無いかもしれません(心愛さん158？)。

と、ここまでOdfHeightの説明をしておいてなんですが、OdfHeightやALP2PMXでボディのODFファイル(RT_body_type_A.ODF)を書き換えなくても、POSファイルやANMファイルなどで同じ事ができると思われます。

画像はRT_body_type_A.ODFをODF(神ツール)でMQO書き出ししたものですが、概ね左側がデフォルト、右側が6811さんから頂いたサンプル�@のものになります。見て頂ければ解るとおり、形状データ自体は縮小されていません。

ではどうやって縮小しているのか調べてみたのですが、ODFファイル内のFRAMチャンクという部分…ここにはボーンの情報が書かれているのですが、ここに書き込まれている情報を書き換えることで実現しています。で、これはPOSファイル等のモーション系のかすたむファイルがやっていることとほとんど変わりません。

単純に、頭と胴体で縮小比率を変えないので良ければ、透過好きさんがモーションアップローダーで公開されているファイル(yonezon.coresv.com/joyful4/joyful.cgi?read=273)が利用できるかと思います。Yomeko023さんが公開されていたPosEditというツールがあればOdfHeightが施す変更と同じ事をODFファイルの書き換え無しで多分できると思うのですが、残念ながらこのツールは現在入手できません。何れにしても、HANファイルが作り直しになってしまうのが一番の問題かもしれません。

何かやる気を削ぐような事を言って大変申し訳ないのですが、動作的にはそんな感じで他にも方法はあるよ、ということです。ただOdfHeightは数値入れると適当に計算してくれるので楽だろうと思います。PosEditでやろうとすると、自分で計算してトライ＆エラーということになるでしょうから。

Re: Aボディだけを縮小化 - 6811 2019/09/10(Tue) 09:48 No.833
のぞく人様、題材の核心に纏わる情報を、私のような者にも理解し易い文章でご解説いただき、感謝至極です。
神ツール作者様をはじめ、文章中にご紹介いただいた歴代の職人様方にも改めて感謝します。

私の場合、HANファイルを配布している都合上、DLして下さる方々とある程度環境を揃える必要があります。
なので今回の投稿の落とし所は「OdfHeight」を利用した[RT_body_type_A.ODF]を数種作成して、その条件下で
完全に動くHANファイルを別途作り直す事にしました。そちらの完成はもう少々お待ち下さい。

のぞく人様には大変お世話になりました。なりっぱなしで申し訳ないです。ありがとうございます。
Re: Aボディだけを縮小化 - のぞく人 2019/09/11(Wed) 00:54 No.834
いえいえ、そこまで言って頂き大変恐縮です。

何か調べ物をすれば必ず持ち帰るものがありますので、その辺はお気になさらずに。

Re: Aボディだけを縮小化 - 6811 2019/09/14(Sat) 03:17 No.836
---[Aボディだけを縮小化]完結編---

のぞく人様よりご提供いただいた情報を元に、9月5日投稿の[Aボディだけを縮小化]という題材について
修正とまとめをやってみたいと思います。
　
最初の投稿にありましたALP2PMXを使用して云々の件は、すべて不要になりました。
代替で、[ODF ver1.05]の[身長変更]ボタン押すと出てくる「OdfHeight」というツールを使用します。
[ODF ver1.05]は、ALP2PMX ver1.06に同梱されています。

---9月5日分との差を以下に書きます---

�@フォルダ[base_body_A]を入れ替える必要が無い。
�Aフォルダ[base_body_A]内のファイル[RT_body_type_A.ODF]だけを置換する。
　(バックアップ対象は、[\らぶデスＦＩＮＡＬ！\data\odf\Body\base_body_A]内のファイル
　[RT_body_type_A.ODF]これひとつだけになります)
�B入力数値はちゃんと反映される。これは作る方も明確な標的を持てますし、環境を共有する際の
　指標にもなります。
�C首が長くなるバグがない。
�D9月5日分のALP2PMXの時と同じく、たむたむ/FINAL起動時に縮小が反映されない時がある。
　(ファイル[RT_body_type_A.ODF]の更新日が元に戻っているので判別が楽)
�E作業が大幅に簡易化、簡略化されました。

---手順をまとめてみます---

�@[\らぶデスＦＩＮＡＬ！\data\odf\Body\base_body_A]内のファイル[RT_body_type_A.ODF]を多重で
　バックアップを取って下さい。
�Aコピペした[RT_body_type_A.ODF]ファイルを[ODF ver1.05]に読み込みさせます。
�B[ODF ver1.05]の[身長変更]ボタン押すと「OdfHeight」というツールが起動します。
�C今回のSSにあるように数値を色々入れて試してみて下さい。
�D[OK]ボタン押すと入れた数値が反映され、読み込んだ[RT_body_type_A.ODF]ファイルが更新済みになります。
�Eこの更新済み[RT_body_type_A.ODF]ファイルを[\らぶデスＦＩＮＡＬ！\data\odf\Body\base_body_A]
　内の[RT_body_type_A.ODF]ファイルと置換します。バックアップさえ取ってあれば上書きで構いません。

9月5日にアップしたZIPファイルを補完する形で追加分のZIPファイルをアップします。
「OdfHeight」で加工更新済み[RT_body_type_A.ODF]ファイルのサンプルを3種、[105cm近辺][115cm近辺]
[125cm近辺]と、これらに対応するHANファイルが6種入ってます。[125cm近辺]という今回分のサンプルが、
前回のサンプル�@�Aの近似値になります。なのですが首の長さが合わなかったためHANは作り直しました。
下記よりダウンロードお願いします。DLPは英小teatimeです。

http://kienizer.com/download/494168

のぞく人様、おかげさまで題材に対して、よりレベルの高い道が開けた感じがしています。
ありがとうございます。

す〜るのペイント画面を見るとわかりますが、瞳テクスチャは4ヶ所(かおる、のどか、たむたむヘッドは3ヶ所)を交互に表示することでハイライトを揺らしています。と言うことで心愛さんのテクスチャから切り出してGIFファイルにしてみました。

外部ツールでフルペイントする場合も4ヶ所でハイライトの位置を変えれば揺らすことができるはずです。実験してませんが。画力があれば炎を揺らすこともできるかもしれません。4コマしかありませんが。

どの表情でテクスチャのどの部分(AかARか、と1・3段目か2・4段目か)を使用しているかを一覧表にしてみました。よねぞんアップローダー(yonezon.coresv.com/upload/upload.cgi)の00099です。ペイントの参考になれば良いかなと思います(個人的には細かい違いがあるのを見てるだけで楽しい)。

Re: 瞳のハイライト - よねすけ 2019/02/26(Tue) 20:26 No.816
外部ツールで4箇所でハイライトの位置を変えて塗れば揺れますね。なお、す〜るのペイントでは、たとえ一瞬のクリックでも4箇所全てにペイントされてしまいます。

以前、エルガイムとか百式の横に流れるキラキラをやってみようかと思いましたけど、コマ数少なすぎて断念した覚えがあります。
Re: 瞳のハイライト - のぞく人 2019/02/26(Tue) 21:17 No.817
ちゃんと揺れますよね？
よかったー

ペイントは実際にカーソルのある位置ではなく、最初から4ヶ所同時に書き込む仕様になっているようです。かおる、のどか、たむたむの3つのヘッドはテクスチャを3コマ分しか使っていなくてペイントのカーソルも3コマ間でしか動きませんが、クリックすると4ヶ所全部に書き込まれました。

なので揺らそうと思ったら外部ツール必須ですね。

外部ツールでのペイント - のぞく人 2019/02/26(Tue) 21:20 No.818
最初の書き込みからの続きです(でも直前も受けてる気がする)。

外部ツールを使ったペイントのやり方についてはよねすけさんがよねぞん改に記事「たむ式メーカー（ALP2PMX）でテクスチャを変える」(yonezonkai.blog.fc2.com/blog-entry-19.html)を書かれていますのでそれを参考にして下さい。編集対象のファイルが「head_xxxx」フォルダの中にあるというところが違うだけです(ボタンも[ALP⇒TGA]でOKです)。

あと私がこちらに書き込んだもの(No.488「ペイントデータをいじる(目)」からのスレッド)も参考にできると思います。但し、そちらにも書きましたが、使用したツールで扱えないヘッドが有る点にご注意下さい。

ALP2PMXはたくさんのファイルを書き出すので、初めてだと「どのファイルを編集したらいいかわからない」となるんじゃないかと思います。ペイントデータは全て

[メッシュ名]@[ODFファイル名].tga

というファイル名で書き出されるので、それを探して編集して下さい。

瞳テクスチャの場合は以下の様なファイル名になります。基本的にファイル名の頭に「eye_A」「eye_AR」が付きます。

・かすたむ系、らぶデス555系、20773ヘッド
　eye_A@HEAD_RT_BASE.ODF.tga
　eye_AR@HEAD_RT_BASE.ODF.tga
　但しエイルヘッドはODFファイル名が違うので
　eye_A@HEAD_0000.ODF.tga
　eye_AR@HEAD_0000.ODF.tga

・らぶデス4系、らぶデス3系ヘッド
　eye_A_Mesh_HEAD_RT_base_Layer2@HEAD_RT_BASE.ODF.tga
　eye_AR_Mesh_HEAD_RT_base_Layer2@HEAD_RT_BASE.ODF.tga

・らぶデス2系ヘッド
　Mesh_HEAD_RT_base_Layer2@HEAD_RT_BASE.ODF.tga
　但しあゆみヘッドは
　Mesh_HEAD_RT_base_Layer2@HEAD_R.ODF.tga
　またロタヘッドは
　Mesh_HEAD_RT_base_Layer2@HEAD_0100.ODF.tga

らぶデス2系ヘッドだけ名前が「eye_」で始まらないので注意して下さい。また通常目しか無いので編集対象のペイントデータも1つです。

これらのファイル名はどのヘッドを使用しているかだけで決まります。顔かすたむで目のタイプを変えていても関係ありません。らぶデス2系の目を選択していてもヘッドがそれ以外であれば、通常目とAR目のペイントデータは別々に保存されます。

同様に、どの表情で瞳テクスチャのどの部分を使用するのかもヘッドだけで決まります。これも目のタイプを変えていても関係ありません。瞳テクスチャをペイントで完全に塗りつぶしてしまうのであれば、目のタイプはどれを選んでいても関係ないです(プログラム的に余計な操作が入らないという意味でデフォルトがお勧め)。

表を作っていて気付いたこと - のぞく人 2019/02/26(Tue) 22:29 No.819
気付いたことをいくつか。

上にも書きましたが、かおる、のどか、たむたむの3つのヘッドは瞳テクスチャ4コマ分のうち3コマ分しか使用しません。使わないのは3・4段目の右側です。これは通常目、AR目どちらでも同じです。

但し、ペイントに関しては上にも書いたように使わない右下にも書き込まれます。ヘッドを換えた時にペイントデータが引き継がれても問題はありません。それも含めてただ「3コマ分しか使ってないんだなあ」というだけで、別段問題になることは無いと思います。

次。らぶデス4系ヘッドはデフォル目を使用する表情で指定と実際に表示される表情がずれています。「びっくり」はいいのですが、他は

？　→　＞＜
＞＜　→　ほっこり
ほっこり　→　キラリッ！
キラリッ！　→　？

という具合に別の表情が表示されます(きちんと確認していませんが、デフォル目の表示だけがずれているのではなく表情モーフの指定がずれていると思われます)。

スクリーンショットを撮る際はそれを考慮した上で表情指定すれば済む話ですが、いくらか面倒かなと。フリーモードとか戦闘モードだと間違った表情になっているものと思われますが、遭遇することがあるのかどうか。

次。こちらもデフォル目絡みです。みなも、奈々美、よつばの3ヘッドは表情に「？」「＞＜」「ほっこり」「キラリッ！」が指定された時に瞼の影響が出ます。みなも、よつばヘッドは瞼が動いているのがわかり、奈々美ヘッドは瞼は閉じた状態で固定されていますが、デフォル目のメッシュより上に出てしまっています。

らぶデス2系ヘッドのデフォル目は「びっくり」以外は放置状態(テクスチャは一応あるが切り替えるようになっていない)なので、ビューワーモードではこれらの表情を使わなければいいのだと思います。こっちもフリー／戦闘モードで出くわすかもしれませんが、アップにしなければ気付かない…か？

最後。カレマチカノジョとす〜るv.4体験版で気付いてらぶデスFINAL!では起きてないことを確認してますが、つばめヘッドでAR目を表示させると(「無表情放心」等)瞳が(正面から見て)左に寄ります。ただ「大泣き」では寄りません。

モーフ指定は他の555!系ヘッドと同じなのにつばめヘッドでだけ起こります。謎です。そしてODFファイルは全く変わっていないのに、らぶデスFINAL!では起きなくなりました。

原因のわからない不思議な現象だとは思いますが、問題になることは無いと思います。が、ビューワーモードで「視線が思う方を向いてくれない！」とかなるかもしれません。未確認ですが(FINAL!使ってる分には起きないし)。

以上。長々と失礼しました。

追加 - のぞく人 2019/02/27(Wed) 21:27 No.820
ペイントデータのサイズについて補足です。

瞳テクスチャのペイントデータのサイズ(ファイルサイズじゃなくて画の大きさの方)は、ODFファイルで指定されたテクスチャのサイズと同じになります。「目のタイプ」で本来のテクスチャより大きいサイズのテクスチャを選択しても解像度は上がりません。

例えば、同じODFファイルを使用するあゆみヘッドとロタヘッドでは指定する瞳テクスチャのサイズが違うので、ペイントデータのサイズもそれぞれ256dot角、512dot角と異なります。あゆみヘッドで目のタイプにロタを選択しても、ペイントデータのサイズは256dot角のままで512dot角にはなりませんでした。

ATOKを使っているとファイルを保存する時の漢字変換の最中にす〜るが落ちるという現象ですが、回避できそうなので報告します。

現象が起きたのはWin7Pro32bitのPC(ATOKは2014)です。同じような構成でもWin7Home32bitの別のPCではファイル保存時に落ちることはないので、発生条件は今一つはっきりしません。ただ「こうなると落ちる」は分からなくても「落ちる時はこうなっている」の方は見えてきました(多分)。

ATOKはデフォルトの設定だと、変換候補のウィンドウが表示された後2・3秒止めていると情報ウィンドウという候補の言葉の補足説明のためのウィンドウが表示されます。落ちるのはこの情報ウィンドウが出た後に思えたので自動で表示されないようにしたところ、ファイル保存の時の漢字変換中に落ちることはなくなりました。

なお「情報ウィンドウが出た後」と書きましたが、落ちるタイミングはウィンドウ表示直後であったりウィンドウ消去の時であったりとまちまちです。

Microsoft IMEで変換する分にはす〜るが落ちることはないのですが、こちらは情報ウィンドウのような追加のものを出さないことが関係しているのかもしれません。

設定手順1 - のぞく人 2018/12/09(Sun) 17:26 No.751
回避のための設定変更ですが、ATOKの環境設定から行います。

まず言語バーのメニューのボタンをクリックしてATOKのメニューを表示させて、比較的下の方にある「プロパティ(環境設定)」を選択します。

ATOKの設定はユーザー毎であってアプリケーション毎ではないので、別にす〜るを起ち上げてやる必要はありません。でも、画像です〜るを起ち上げて設定をしているのには理由があります。

私の場合PCは通常一般ユーザーで使うことにしています。一方す〜るは起動時に管理者パスワードが必要、即ち管理者アカウントで動いています。なので、す〜るのファイル保存時に呼び出されるATOKを設定するには管理者アカウントのATOKを設定しなければなりません。一旦ログオフすればいいのですが、す〜るのウィンドウがカレントになっている間は管理者アカウントの言語バーが表示されるので、そのタイミングで設定を行った次第です。同じようにPCを運用してる方はほとんどいらっしゃらないと思いますが、参考までに。

設定手順2 - のぞく人 2018/12/09(Sun) 18:01 No.752
「ATOK プロパティ」のウィンドウが表示されたら左側の「設定項目」から「表示」を選びます。次いで「情報ウィンドウを表示」の項目を「する(自動)」から「する」もしくは「しない」に変更します。あとはOKで抜けて設定完了です。

「情報ウィンドウを表示」を「する」に設定した時は、「End」キーを押すと情報ウィンドウが表示されるようになります。即ちす〜るのファイル保存の時に誤ってEndキーを押すとす〜るが落ちます。ただ他のアプリケーションを使う時に情報ウィンドウが表示されないというのも嬉しくないことだと思うので、個人的には「しない」より「する」がお勧めです。

取り敢えずATOKの設定変更について書きましたが、もちろん漢字やかなを使ったファイル名を付けなければ回避できます。また前の方にも書きましたが、Microsoft IME(MS-IMEから名前変わってた模様)なら問題が起きないようなのでそちらを使うという手もあります(す〜るの時だけ切り替えるのはちょっと面倒だと思う)。そもそもATOKなら必ず問題が起きるという訳でもなさそうですし…


イベントログを見てわかったのですが、実はWin8以降でMQO読み込みを行った後に落ちる時と同じアドレスです〜るが落ちています。何回かに1回は「障害が発生しているモジュール名: XAudio2_7.dll_unloaded」とログに残ります(頻度はかなり違う)。なので、確認はしていませんが、XAudio2対策パッチでも対処できるのかもしれません。MSの人が「Win7でだって同じことが起きうるよ」と言っていたのが証明されたと言いますか…

双方に共通しているのは「す〜るから外のプログラムを呼び出してそのウィンドウを表示させている」といった辺りです。こういったことはシステム(Windows)側に変更があったりすると影響を受けやすいので、古いプログラムには一番辛いところなのかもしれません。

ミスマさんから戴いた情報ですが、らぶデスＦＩＮＡＬ！のインストールDVDの中には特定のドライブで上手く読み込めないものがあるそうです。インストールが延々と終わらずに、挙げ句PCのハングアップに至ったりするとのことです。

どのロットのDVDがアウトなのかとかどのメーカーのドライブが駄目なのかなど細かいことは分かりませんが(情報が失われてしまったとのこと)、TEATIMEの指示に従って何か調べてそれが一定の条件に当てはまっていれば新しいDVDが送られてくる程度には明らかな問題が有ったようです。

インストールディスクが上手く読めない時にはイメージ化して…………という手は結構よく使われるものと思いますが、これも読み込めるDVDドライブがあればこそです。「インストールプログラムでは上手く読めなかったけどイメージ化は出来た」ということも無くはないでしょうが、基本的には別PCか外付け光学ドライブが必要になると思います。

Windows10はディスクイメージをそのままドライブとしてマウントできるので、少しだけ楽かなと。

なお本当にすんなりイメージ化できるかの確認はしておりません。

よねぞんアップローダーにFixODFの新しいのを置かせて頂きました(00098.zip)。readmeを読んでも「そんなところに何か問題あったの？」という反応が返ってきそうな修正点が多いので、画像を上げておこうかと思います。
最初のバージョンの分は他所に画像を上げたので割愛します。

bra_291とbra_70002 - のぞく人 2018/11/03(Sat) 10:15 No.725
bra_291(828, 白水着トップ)とbra_70002(70112, きわどいブラ)です。単なる色違いです。さっき「fc /b」で比較したらODFファイル自体は全く同じでした。

画像は上段が修正前、下段が修正後になります。これは以下全て一緒です。

乳首スライダーを動かしてもブラが変形してくれないため乳首が飛び出してしまう点を修正しています。「Nip_B」を含む名前が付いているモーフデータが乳首スライダーに対応するのですが、bra_291とbra_70002にはありません。「Nip_A」で始まるモーフデータは持っているので、これを「Nip_B」に書き換えて流用しています。

本来Nip_Aの形状データとNip_Bの形状データでは違いがあるのだと思いますが、上手い具合に隠れてくれたので良しとしています。なお、ブラのODFファイルは大抵Nip_AとNip_B両方のデータを持っています。但しす〜るではNip_Bの方しか使われていないようです。

cloth_001とcloth_002 - のぞく人 2018/11/03(Sat) 10:33 No.726
cloth_001(550810, 尼塚学園制服)とcloth_002(811, いちごの尼塚学園制服)です。こちらも基本的に色違いですが、ODFファイルは全く同じではありません。ぽっこりスライダーを動かした時にリボンの先端がおなかに埋まってしまうのを修正しています。

ぽっこりスライダーに対応するモーフデータは「Nin_A」を含む名前が付くのですが、リボンのモーフデータの名前は「Nia_A」で始まっているためぽっこりスライダーに反応しません(形状データの名前は「Nin_A」で始まっているのでぽっこりスライダー用のデータだと判別できます)。この「Nia_A」を「Nin_A」に書き換えることで対処しています。

画像を見れば分かりますが、先端が少し埋まるだけだし斜めに伸びるより下に垂れてる方が自然に見えないこともないので、もしかしたら制作サイドで1byte書き換えて動かないようにしたのかもしれません。この辺り判断が難しいです。

cloth_107 - のぞく人 2018/11/03(Sat) 10:54 No.727
cloth_107(706, ブレザー)です。ネクタイがぽっこりスライダーと連動しないのでスライダーを動かすとお腹に埋まってしまう点を修正しています。ブレザーを脱いでないとわからないです。

これはネクタイ下側のモーフデータの名前が「Nin_A」ではなく「Nip_A」で始まっているために起きます。なので「Nip_A」を「Nin_A」に書き換えることで対処しています。

ちなみにす〜るではNip_Aのモーフデータは使われないので、「乳首スライダーを動かすとネクタイの先が動く」ということにはなりません。が、ALP2PMXで変換したデータをMMDで動かすと乳首と一緒にネクタイが動いてくれます。

cloth_1526 - のぞく人 2018/11/03(Sat) 11:57 No.728
cloth_1526(1565, バニースーツ)です。網タイツ背中側の縁(ゴムのところ？)とお尻の谷間の辺りがT字型の1つのメッシュになっているのですが、ぽっちゃりスライダーを真ん中より右側に持っていった時にこのメッシュがクシャッと丸まったようになってしまうのを修正します。バニースーツを脱がした状態で使うことはあまりないと思うので(ぴったり編みタイツがあるから)目立たないと思いますが、「ぽっちゃりスライダーを動かしていたら腰の辺りに黒い固まりが出現した」という方はいらっしゃるかと思います。

以下説明長いです。

す〜るの体型スライダーからは数字が生成されます。例えばぽっちゃりスライダーだったら左端：50、右端：150と定義されています。値はスライダーの位置に応じて1次関数的に(直線的に)変化します。

ODFファイルはモーフデータ毎に数字と形状データの対応関係を記した表を持っています。例えばタイツやニーソックス等ではほっそり体型用、ノーマル体型用、ぽっちゃり体型用の3つの形状データを持っていて
{0，ノーマル形状データのindex}
{50，ほっそり形状データのindex}
{100，ノーマル形状データのindex}
{150，ぽっちゃり形状データのindex}
という4エントリーの表を持っていたりします。大抵のODFファイルではノーマル形状はMESHチャンクのデータの形状と同じです。また割り当て表の0のエントリーも必須なようで、通常はノーマル形状が割り付けられています。

す〜るはこの割り当て表とスライダーから送られてきた数字を照らし合わせて、登録されている形状を元に線形補完して実際に描画する形状を決めます(そう推測しただけですが、多分間違ってないと思います)。

で、cloth_1526の問題が起きるモーフデータでは割り当て表が
{0，ノーマル形状データのindex}
{50，ほっそり形状データのindex}
{100，ノーマル形状データのindex}
{150，子0のindex}
となっています。「子0」とは何かと言いますと、「形状データと並んで記録されているけれど形状データではないもの」になります。モーフデータは体型毎に形状データを持っていますが、その形状データ群の前に必ずこの「子0」があります(形状データ群は子1以降ということになります)。

実際にはこの子0も形状データではあるのですが(大抵はMESHチャンクの情報と全く同じ)、頂点の並び順がモーフ用の形状データと全く異なります。なのでこれを体型データのつもりで読み込むと頂点があらぬ方向へ移動することになってしまいます。

問題のモーフデータではぽっちゃり体型用のデータがちゃんとありますから、割り当て表の問題のエントリーを
{150，ぽっちゃり形状データのindex}
と書き換えることで対処しています。

cloth_2028 - のぞく人 2018/11/03(Sat) 12:00 No.729
cloth_2028(2028, ひらひらワンピース)です。上の画像で楕円で囲ってあるところのメッシュがぽっこりスライダーに追従してくれない点を修正しています。スカートをのぞき込まないとわからない所です。

これはスカートのこの部分のモーフデータ名が「Nin_A」ではなく「Wear_703」で始まっているために起きます。「Wear_703」を「Nin_A」に書き換えることで対処しています。ただこれだけだと既にあるモーフデータ名とバッティングするので(親メッシュが違うので多分問題にはならないと思いますが)、後ろに「_#27」と付けるなどの細工もしています。

これは動かなくする意味が無いと思うので、単なる書き間違いか修正のし忘れではないかと。

cloth_2031 - のぞく人 2018/11/03(Sat) 12:02 No.730
cloth_2031(2031, ピアスセット)です。先に画像だけ上げておきます。

cloth_2038 - のぞく人 2018/11/03(Sat) 12:04 No.731
cloth_2038(2038, オープンメイド服ダーク)です。先に画像だけ上げておきます。

cloth_5000その1 - のぞく人 2018/11/03(Sat) 12:07 No.732
cloth_5000(5000, 仲居着物風制服)のぽっちゃりスライダー関連です。画像だけ先に上げておきます。

cloth_5000その2 - のぞく人 2018/11/03(Sat) 12:09 No.733
cloth_5000(5000, 仲居着物風制服)の胸Bスライダー関連です。画像だけ先に上げておきます。

cloth_20002 - のぞく人 2018/11/03(Sat) 12:11 No.734
cloth_20002(60004, まきなワンピ)です。画像だけ先に上げておきます。

cloth_70007 - のぞく人 2018/11/03(Sat) 12:14 No.735
cloth_70007(70007, パピヨンドレス)です。画像だけ先に上げておきます。

shorts_290とshorts_1602 - のぞく人 2018/11/03(Sat) 12:18 No.736
shorts_290(831, 指定水着)です。画像だけ先に上げておきます。

これは上下で変化が無いはずのものです。

保留中のcloth_70000 - のぞく人 2018/11/03(Sat) 12:22 No.737
修正し切れてないことが判明したため今回見送ったcloth_70000(70000, 騎士ドレスＳ)です。画像だけ先に上げておきます。