おなまえ Ｅメール タイトル コメント 参照URL 添付File 暗証キー (英数字で8文字以内) 画像認証 （右画像の数字を入力） 文字色 ■ ■ ■ ■ ■ ■ ■ ■ ■
ネタがす～る直のことじゃなくてアレなんですが、C#でツールを書くにあたり新しい.NETと.NET Frameworkで変える必要がある点をメモ的に。まず最初にお断りしておきますが、単純に.NET Frameworkから.NET(含む.NET Core)への移行の話であって、最新の話題ではないです(本来なら2年くらい前の話題)。自分が今になって経験したというだけです(経験したことなので移行に関する話のほんのほんの一部です)。なお本来なら一次情報に当たるのが最善なのですが、日本語訳があまりにアレなので書いておくことにした次第です(https://docs.microsoft.com/ja-jp/dotnet/api/system.text.codepagesencodingprovider.instanceの日本語訳が一番マシかも)。
.NET6を使ってみたの2 - のぞく人 2022/03/03(Thu) 00:55 No.1860 .NETが何者かの説明は後に回していきなり本題に行きます。今のところですが、出くわした要変更な要件は2点です。一つはバイト列から文字列を読み出す際に必要なEncodingオブジェクトの取得方法、もう一つはNull許容参照型への対応です(こちらは回避しようと思えばできる)。なおプログラムのビルド環境ですが、.NETのSDKを使っています。Visual Studioは使っておりません。なのでVisual Studioでは状況が異なる部分もあると思いますが、使っているライブラリ自体は同じ(なはず)であることとVisual Studioもビルド時はSDKを呼び出しているはずなので、大きく変わることはないはずです。.NET(含むFramework、Core)を使ってファイル等から文字列を読み込む場合はEncodingクラスのオブジェクト(インスタンスの方がしっくり来る人は以下読み替えて下さい)を使って string name = enc.GetString(buf, 0, len);のようにします(「enc」がEncodingオブジェクト、「buf」はファイルから読み込んだ生のデータを格納した配列、「len」は読み込むデータの長さ)。このEncodingオブジェクトは読み込んだデータで使われている文字エンコーディング(コード体系)に応じたものを使います。ツールを書いたりす～るをバイナリエディタで見たことのある方はご存じのことと思いますが、す～る関連のデータで使われている文字エンコーディングはCP932(Shift-JISを若干拡張したもの)です。ではEncodingオブジェクトを得るにはどうするかと言うと、自分の場合は Encoding enc = Encoding.GetEncoding(932);のようにしていました。他に Encoding enc = Encoding.GetEncoding("shift_jis");のように文字列で指定する方法もありますが、とにかく.NET Frameworkでは(そのOSがサポートしている)文字エンコーディングに対応したEncodingオブジェクトが一回のメソッド呼び出しで取得できました。が、.NET Core以降、Windows(と言うかOS)と.NETの切り離しを進めるためだと思いますが、この辺りの事情に変化がありました。Unicode系(とUS-ASCIIと西ヨーロッパ言語)だけが標準でサポートされるようになったのです。.NET Frameworkの時のソースそのままでもビルドは通るのですが、実行時にUnhandled exception. System.TypeInitializationException: The type initializer for 'DecMDL.DecMdl' threw an exception. ---> System.NotSupportedException: No data is available for encoding 932. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. at System.Text.Encoding.GetEncoding(Int32 codepage)のようなエラー(例外)が発生します。Shift-JIS等のエンコーディングが標準でサポートされなくなったと言っても、幸いなことに使えるようにする方法と必要なデータは標準で用意されています。上のエラーメッセージにも「EncodingクラスのRegisterProviderメソッドを調べろ」と書いてありますが、ドキュメントを読むとEncodingProviderオブジェクトを取得してRegisterProviderメソッドで登録してやればいいということが分かります(解読できれば)。具体的には EncodingProvider encprovider = CodePagesEncodingProvider.Instance; Encoding.RegisterProvider(encprovider);の2工程の追加です。1行目でCodePagesEncodingProviderクラスのInstanceプロパティからEncodingProviderオブジェクトを取得して、それをそのまま2行目でランタイム環境に登録しています(2行にする意味無いですね、これ)。EncodingProviderオブジェクトに関しては設定も何もありません。CodePagesEncodingProviderクラスから渡されたオブジェクトを右から左で次に渡すだけです。以上の手順を踏んだ後であれば、今まで通り Encoding enc = Encoding.GetEncoding(932);で必要なEncodingオブジェクトが取得でき、バイト列を文字列に変換することができます。なお上で「ランタイム環境に登録する」と書きましたが、スコープ外でGetEncodingメソッドを呼んだ場合は正しいEncodingオブジェクトが返ってこないと思われますので(確認してないけど多分。やるべきじゃない気が…)、その辺りはご注意下さい。あと変数名の前に一々型名を書いてますが(説明上そちらの方がいいと思ったので)、全部varでビルドは問題なく通ると思います。 .NET6を使ってみたの3 - のぞく人 2022/03/03(Thu) 00:58 No.1861 上で文字列の読み込みはできたのですが、実は公式ドキュメントにはもう一工程、「System.Text.Encoding.CodePages.dll アセンブリへの参照をプロジェクトに追加します」と書かれています。「参照の追加ってやり方こうだったっけ？」と思いながらプロジェクトファイル(csprojファイル)に<ItemGroup> <Reference Include="System.Text.Encoding.CodePages"/></ItemGroup>という項目を追加してみたのですが、その結果ビルド時に・warning MSB3245: この参照を解決できませんでした。アセンブリ "System.Text.Encoding.CodePages" が見つかりませんでした。アセンブリが間違いなくディスクに存在することを確認してください。 コードにこの参照が必要な場合、コンパイル エラーが発生する可能性があります。・warning MSB3243: "System.Text.Encoding.CodePages, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" と "System.Text.Encoding.CodePages" の間の競合を解決する方法がありません。一時的に、"System.Text.Encoding.CodePages, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" を選択します。と2つの警告が出されました。1つ目を見る限り参照追加の方法がどこか間違っていると思われますが、2つ目の警告を見るとSystem.Text.Encoding.CodePagesは参照アセンブリの中に既に存在しているようです。実際参照追加のための行をプロジェクトファイルから除いたところ、今度は警告を出さずにビルドが終了しました。SDKだけを使ったビルド環境ではSystem.Text.Encoding.CodePagesへの参照追加は必要ないようです。Visual Studioを使う場合、参照アセンブリの管理はプロジェクトファイルを直接編集せずにUIから行うようになっていたと思います。管理方法が違うので同じように参照の追加なしで行けるのか判断が付きませんが、「ビルド時にエラーになるようなら参照を追加する」みたいな進め方でも大丈夫なんじゃないかと思われます。 Re: .NET6を使ってみた - のぞく人 2022/03/03(Thu) 01:02 No.1862 2件目のNull許容参照型について。公式ドキュメント(https://docs.microsoft.com/ja-jp/dotnet/csharp/language-reference/builtin-types/nullable-reference-types)によるとC#8.0で導入されたものみたいです。「Null許容参照型」という新しい分類の型が導入された訳ではなく、null値が代入された状態の参照型変数を参照してしまうことを防ぐための追跡機構を構成するもの、ということのようです(型扱いした方が話が簡単なので型と呼ぶことにした模様)。.NET6のSDKが(自動で)作成するプロジェクトファイルに<Nullable>enable</Nullable>という行があるのですが、これをdisableにしてやればNull許容コンテキスト(追跡機構の根幹)は無効になるそうです(.NET5以前ではdisableがデフォルトとのこと)。古いコードを使う場合、手っ取り早くdisableに設定するか、enableにしてコンパイラが出す警告を見ながらコードを手直しするかのどちらかになります。で、どの辺りでこのNull許容参照型が使われているかですが、自分の場合はファイルパスの処理で出くわしました。PathクラスのGetDirectoryNameやGetFileNameWithoutExtensionといったメソッドの返値がNull許容参照型であるstring?に変わっていて(引数もstring?に変わっているがこちらは影響なし)、以前のままのコードでビルドを行ったところ・warning CS8600: Null リテラルまたは Null の可能性がある値を Null 非 許容型に変換しています。という警告が出されました。これはstringとして宣言した変数に返値をそのまま代入していたからです。また・warning CS8603: Null 参照戻り値である可能性があります。・warning CS8604: 'void File.Move(string sourceFileName, string destFileName)' 内のパラメーター 'destFileName' に Null 参照引数がある可能性があります。といったコード分析の結果と思われる警告も出ました(デフォルトの設定ではいずれも警告で、ビルドエラーにはなりません)。次に、警告にどう対処するかですが、最初のCS8600に対しては単純に返値を格納する変数を「string?」で宣言してやればOKです(stringで受けても警告が出てない箇所もあります。処理の流れ的にnullが返ってこない所だからなのか、単に見落とされているだけなのか不明です)。あとは変数を参照する前にnull値が格納されていないかチェックすることになります(stringならString.IsNullOrEmpty()を使うとか)。それで他の警告も消えてくれるはずです。とは言え、返値を格納した変数がnullかどうか毎回チェックするのも面倒です。なので変数を使う箇所で変数名の後ろに「!」(このケースでは「null免除演算子」と呼ぶそうです)を付けるという回避手段が用意されています。例えば File.Move(srcpath, bakpath!);みたいに使います(bakpathはstring?として宣言している)。使いどころとしては、処理の流れ上明らかにnull以外の値が代入されている所や、nullが代入されていたとしても敢えて後ろに流したい所を考えているようです。上の例も「bakpathを得るためのメソッドを前に呼び出していてそちらでnullでなかった場合にのみそこに来る」ということを踏まえて使用しています。他にも、自分で書いた文字列及びnullを返すメソッドの型をstring?に変更してみました(そのままでも警告は出されなかったのですが、一応)。併せて受ける変数の型もstring?に変更し、使用前にnullが入っていないかチェックする処理も加えています。これら一連の書き換えを行って警告が出ない状態になれば、Null許容コンテキストに取り敢えずは対応できていると思います。 .NET6を使ってみたの4 - のぞく人 2022/03/03(Thu) 01:07 No.1863 以下、上に書いてある内容が必要な方には多分要らない内容だと思います。まずエンコーディングについて補足を少々。基本的な文字コードの話やそれをどの様に記録するかの話は長くなるので割愛します。大本の文字コード体系からコンピュータで処理するのに都合が良いように手を加えた別のコード体系が作られ、更にメモリー上のデータと記録媒体上のデータとでは違うコード体系が使われていたりと複雑怪奇なのです。あるコード体系から別のコード体系への変換はみんな「エンコード」か「デコード」な訳ですが(目線の方向で呼び名が変わる)、プログラミングの場合は記録媒体に書き出す方向の変換をエンコードと呼ぶようです。で、この「エンコード」のやり方(規則)を「エンコーディング」と呼ぶ、みたいに自分は理解しています(でも大抵の場合「エンコーディング＝文字コード体系」の意味で使われているかも)。たむたむす～る他のTEATIMEのゲームに限ったことではありませんが、当時のプログラムには記録媒体(ハードディスクとか)に文字データを書き込む際「Shift-JIS」(を元に拡張したCP932)というコード体系を用いているものが多数あります。なので古めのゲームを扱うツールを書く際には上に書いたことは必須です。一方、Unityを使って開発されたイリュのゲームなどでは「UTF-8」というコード体系が使われています。こちらは.NETの標準サポートなのでEncodingオブジェクトの取得はCP932より簡単にできます。が、.NET(含むFramework、Core)を使う限り(UTF-16LEのデータであっても)Encodingオブジェクトを介して文字データの読み書きを行うという手順は一緒です。も一つ。平文のODFファイルをバイナリエディタで見たことがある方は気付かれたのではないかと思いますが、す～る付属のデータではメッシュやモーフの名前は全てアルファベット表記です(「全て」だったはず)。じゃあ「CP932」ではなく「US-ASCII」のEncodingオブジェクトを使えば話が済むのでは、と思われるかもしれませんが、MQO読み込みで作成されたODFファイル(MODも含む)の場合はメッシュ名に仮名や漢字が含まれる場合があります(実在する)。なのでODFファイル(含むODAファイル)しか扱わない場合でも仮名や漢字への対応は必要と思われます。なお、かすたむデータファイルは作者名(ALPはキャラクター名も)で仮名や漢字が使われています。 あ、.NET6を使ってみたの6だ - のぞく人 2022/03/03(Thu) 01:10 No.1864 冒頭で説明を飛ばしたので.NETについて簡単に。自分でプログラムを書く方以外は.NETとか.NET Frameworkとか言われても「たまにランタイムとかいうものをインストールしろと言われるやつ」というくらいの認識なんじゃないかと思います。が、プログラムを書く人間にとっては「プラットフォーム」などと呼ばれる様々な機能を提供してくれる存在です。特にC#というプログラミング言語を使ってアプリケーションを書く場合はWindowsの機能を呼び出す方法が事実上.NET(含むFrameworkとCore)経由一択なので、とても重要な存在です。Windows2000の頃に.NET Frameworkが登場してからWindowsと共にバージョンアップを重ねてきましたが、何年か前に「一度Windowsと切り離して0から書き直そう」という話になり、「.NET Core」というものが登場する運びとなりました。その後「.NET Frameworkと.NET Coreを統合しよう」と話が進み、現在の「(ただの).NET」へと至ります。.NET FrameworkはWindows Vistaの頃からランタイムライブラリ(プログラム(この場合は.NET Frameworkを利用して書かれたプログラム)を実行する時に必要となるプログラム)が標準で添付されるようになり、併せてソフトウェア開発に必要なコンパイラも標準搭載となったので(みなさんのPCにもcsc.exe(C#コンパイラ)やvbc.exe(Visual Basicコンパイラ)といったファイルが入っているはずです)、特に個人でちょっとしたプログラムを書く際に広く使われるようになりました。そして新しい.NETへの統合に向けて新規の開発が止まり、バージョンが4.8で打ち止めになっているのが現在の状況です。 .NET6を使ってみたの7 - のぞく人 2022/03/03(Thu) 01:13 No.1865 今まで.NET Frameworkのランタイムが標準添付されていたことから考えて、適当な時期を見て標準添付のランタイムを.NET5(今なら.NET6)のものに切り替えるものと自分では予想していたのですが、いまだにそうなっていません。Windows11に至ってもまだ.NET Framework4.8のランタイムが添付されています。なので今.NET Frameworkから.NETへと移行する特別な理由は無いと考えます(SDKやVisual Studioを使うぶんには新しめのC#で書けますし)。でも、いずれ切り替わることになっているのだから試してみてもいいよなあと思った結果が上で書いたことです。今から新しくす～るに向けてツールを書いて下さる方がいらっしゃるかと言うと限り無く0だろうなとは思いますが、古いツールのメインテナンスに役立つかもしれないし、古めのゲームを今からいじろうって方もいらっしゃるかもしれないので、少しでもどなたかの参考になれば幸いです。「谷間」の時期のためか情報があまり多くない気もしますし。以上。連投失礼しました。関係ないですが、イリュのゲームのランチャー、今でも.NET Framework3.5で書かれてるの何とかならんですかねえ。今動いているPCに入っているランタイムはみんな4.8になっていると思うのですが。何かコンパイルする時のターゲット設定変えるだけじゃ済まない話があるのかなあ…(私自身はexe.configファイルを置くことで3.5ランタイムのインストールを回避しています)
どうもはじめまして。いきなりの質問で申し訳ありません。タイトルの通り過去の質問と被る部分があるかと思いますが数年ぶりにALP2PMXでALPを変換しようとしたら「実行時ｴﾗｰ'9':ｲﾝﾃﾞｯｸｽが有効範囲にありません」と表示され正しく変換できなくなっていました。Modelとodfファイルに顔と体のペイントデータのみが出るだけで正しく変換されません。FINAL製品版を使っているかつ数年前はちゃんと変換できていたのですがエラーがNo.454の方と同一なので同じくレジストリの問題なのでしょうか。素人ながらに見様見真似でレジストリを追加してみたりしたのですがどうも解決できなく質問をした次第です。
Re: 454と重複するかもしれ - よねすけ 2021/01/23(Sat) 17:57 No.864 mandamさんこんにちは！私もしばらくalp2pmxを触ってないのですが、エラーの9番は原因がいくつか考えられるため、とりあえず現在の環境とalpに使ってる素材を記載していただければだいたい（のぞく人さんとかが）わかるのではないかと思います。もし体験版を使っているなら、製品版とは参照先が異なるため、No.454そのままとは思いますが。 Re: 454と重複するかもしれ - のぞく人 2021/01/23(Sat) 18:17 No.865 mandamさんとは初めまして、でよかったでしょうか？のぞく人と申します。実行時エラー9は大抵の場合ファイルが見つからない時に起きます(と記憶してるけど時間が経ってるので勘違いが混じっているかも)。「ファイルが見つからない」も大きく分けて２パターンありまして、インストールされているゲーム(FINAL!やカレカノ等)が見つからない場合と、ALPで指定されているファイルがインストールされているゲーム中に見つからない場合とがあります。後者はDLしてきたALPで使っているアイテムが環境に無い場合、例えばFINAL!にしか無いエイルの服を使ったALPをカレカノや体験版で変換しようとするケースです(要は自分のところで表示できないALPを変換しようとしている)。す～るに馴染みがないとやりがちなことだと思いますが、mandamさんは長らくす～るを使ってこられた方なのでこっちは大丈夫かと考えます。レジストリの登録情報に関しては再インストールが一番手っ取り早いと思います。が、古いPCからコピーしてきたFINAL!がPC上にあるのでインストール情報だけ入れたいということでしたら、基本的には454のスレッドに書いてある通りです。ただレジストリに書き込むゲーム名がFINAL!の場合は「らぶデスFINAL!」とインストールフォルダ名と違うので(FINAL!の部分が半角)それだけ注意してください。あとインストール先のフォルダ名の後ろはらぶギアと同じで「\\」が付きます。もし体験版しか入ってないPCでALP2PMXを使いたいということだと少々話が変わってきますが、FINAL!が認識されないということでよろしいでしょうか？ Re: 454と重複するかもし - mandam 2021/01/24(Sun) 13:49 No.866 よねすけさんこんにちは、お久しぶりです。のぞく人さん初めまして、ありがとうございます。>ALPで指定されているファイルがインストールされているゲーム中に見つからない場合FINALで正常に表示されているALPですしデフォルトのALPでもダメだったのでご指摘通りその可能性は薄そうですね。>FINAL!が認識されないということでよろしいでしょうか？そうですね。数年前に瞳を外部ツールでペイントする為に変換していた時は問題なくできていたのですが数年ぶりにやる気になってやろうとした所正常に変換できなくなっていました。PCを新調していたりファイルの場所を変えたりはしていません。FINAL!を半角にしてレジストリを登録しましたが改善されず。魔改造されているので少々手間がかかってしまいますが再インストールしようとしましたが再インストールしようとすると固まって落ちたり、データを削除してもそもそもインストールという項目が出ない(本編＆すーるを開始するという項目しかない)と再インストールができず。なのでネトワクの方を再インストールしたらネトワクのデータは正しく変換できるようになりました。（因みにネトワクの方も再インストール前は正常に変換できませんでした）変換も瞳を外部ツールでペイントする為に使用したかったので取りあえずは目的は達せられそうです。FINAL!も再インストールできれば解決できそうなんですがコンパネにFINAL!のデータがそもそもないんですがそういう仕様でしたでしょうか？ Re: 454と重複するかもしれ - のぞく人 2021/01/24(Sun) 17:02 No.867 まずコントロールパネルにFINAL!のアイコンがあるかどうかですが、申し訳ないのですが今手許のPCにす～るの体験版しか入ってないのでFINAL!そのものでの確認ができません。ただ体験版は「プログラムと機能」にアンインストール用のアイコンが表示されています。記憶をたどってもTEATIMEのゲームは全部アイコンが表示されるようになったと思います(再インストールしたカレカノのアイコンも表示されてるかと)。ただし、プログラムと機能にアイコンがあるのはインストールに使用した管理者アカウントだけで、一般ユーザーのアカウントには出来ないようです。PCにユーザーアカウントを複数作っていなければ関係ないことですが。基本的にコントロールパネルへのアンインストール用アイコンの作成とレジストリへのインストール情報の書き込みとはインストール時に必ず行われるはずです。なので、どこかの段階でPCからインストール情報が失われたものと思われます。例えば「PCのリフレッシュ」を行うと自分でインストールしたソフトの情報は全部消されてしまいます(だったと思った)。Windows10の機能アップデートの時もリフレッシュと似たような動作が走るので、どこかでズッコケるとインストール情報をすっ飛ばすとか十分あり得ます。ただ、メニューというのはディスクを入れた時に出るメニューのことだと理解したのですが、通常の起動メニューが出て「インストールします」が出ないということは、最初に起動する「autorun.exe」というプログラムが「既にインストール済み」と判断しているということでもあるはずなので、その辺りが謎です。なおインストールメニューが出ない場合でも、「LoveDeathFinal!」フォルダにある「setup.exe」を直接実行すれば強制的に上書きインストール出来ると思います。(でも全く認識されてない訳でもなさそうなので…)レジストリの状況ですが、手許のPCだと画像のようになっています(インストール先フォルダがちょっと特殊ですね、うちの場合)。mandamさんのPCでも、同じようにTEATIMEというキーの下に再インストールで作成された「カレマチカノジョ」やご自分で追加された「らぶデスFINAL!」等のサブキーがあることと思います。今までの経験からするとALP2PMXはゲームのインストール確認はここしか見てないはずなので、ここに間違いが無いのにALP2PMXが動かないとなると私も理由がわかりません。レジストリエディタで今一度内容が正しいか確認(カレマチカノジョとらぶデスFINAL!でどこか違っているか)していただければと思います。なお454のスレッド等で値「INSTALLDIR」のデータ中のフォルダの区切り文字が「\\」となっていますが、これはREGファイル中はそうしなければいけない決まりがあるからであり、レジストリエディタで直接編集する時は通常通り「\」1つです。あとは「INSTALLDIR」に正しくFINAL!のインストールフォルダが入力されていればいいはずなのですが…(なお、レジストリも「ゲームインストール時のユーザーアカウントとALP2PMXを動かすアカウントが違う場合は…」という話があるのですが、カレマチカノジョの再インストールでALP2PMXが動作したということであれば多分要らない話だと思います。)最後にFINAL!のインストール中に固まったということですが、ディスクをガチャガチャ読み込んでる時に問題が出ることがあるらしいので、それじゃないかと思います(固まらなくても精神衛生上よくないですよね、アレ)。Windows10の場合は一旦ディスクのイメージファイルを保存して、それをマウントしてそちらからインストールを実行することで回避できるんじゃないかと思います。あ、そうだ。レジストリを編集する時は、先にレジストリのバックアップを取っておいてください(もしくは復元ポイントを作っておくとか)。 Re: 454と重複するかもしれ - のぞく人 2021/01/24(Sun) 17:12 No.868 追加。再インストールした場合ですが、インストール(レジストリへの書き込みやコントロールパネルへのアイコン作成やスタートメニューへの項目作成等)が終わったら、今まであったデータにゴッソリ入れ換えてしまって大丈夫です。ちょっと推測を付け加えておきますと、ディスクを入れた時に走る「autorun.exe」は多分レジストリ中に「らぶデスFINAL!」のキーがあるかどうかでインストール済みかどうか判断していると思われます。なので追加されている「らぶデスFINAL!」のキー名は多分間違ってないと思います。一方ALP2PMXは同キー中の値「INSTALLDIR」の内容を見ます。変換に必要なファイルの場所はこの値を見て判断します(って外から見て言ってるだけですが)。なので、この値がどこか違うんじゃないかと思っています(失礼)。なおFINAL!のゲーム自体やす～るの動作には、このキーは関係しません。あっても無くても動作します。(過去作の性格が使えるかの判断は過去作のキーの有無で行う。) Re: 454と重複するかもしれ - のぞく人 2021/01/24(Sun) 22:57 No.869 お詫びと訂正。ディスク入れた時のメニューでゲームの起動メニューが出るということはautorun.exeがFINAL!のインストール場所を見つけられるということだから、レジストリの内容も合ってるはずということですね。大変失礼しました。ALP2PMXが上手く動かないのはどういうケースがあるのか、出来る範囲でもうちょい探してみます。 Re: 454と重複するかもしれ - のぞく人 2021/01/24(Sun) 23:57 No.870 訂正の追加。上でautorun.exeがレジストリのキーが存在するかどうかしか見ていないと書きましたが、値の内容もちゃんと見ていました。画像の上側が「らぶデスFINAL!」のキーに値「INSTALLDIR」を作成する前で、下半分が「INSTALLDIR」を作成してインストールディレクトリを書き込んだ後です。なのでメニューに「インストール」が無いということは、レジストリに書き込んだ値は正しいということになります。本当に失礼致しました。なお「INSTALLDIR」の末尾に「\」が無くてもALP2PMXからは認識されるようです。FINAL!で正常に表示されるALPだということなのでファイルシステムの問題でALP2PMXから見えないということは考えづらいのですが、コマンドプロンプト(管理者として実行)で chkdsk [ゲームがインストールされているドライブ]:とやってファイルシステムに問題が無いことを確認しておいていただけると助かります。 Re: 454と重複するかも - mandam 2021/01/25(Mon) 17:42 No.871 色々と調べて下さってありがとうございます。コマンドプロンプトは特に問題は見つかりませんでしたと出ました。ディスクのイメージファイルを保存は保存してる途中で何度やっても固まって落ちてしまいますし「LoveDeathFinal!」フォルダにあるsetup.exeを起動させると即固まってインストールに移らず。取りあえずこれからもちょくちょくチャレンジしてみますが一度ネトワクに移す必要があるもののALPを変換して外部ペイントツールで目を塗る当初の目的は達しているのでいいかなと思っています。以前は問題なかったのにできなくなった原因がよく分からないのはちょっと解せないですけども。 Re: 454と重複するかもしれ - のぞく人 2021/01/25(Mon) 19:34 No.872 ディスクチェック、御協力ありがとうございます。原因切り分けに潰しておきたい項目なので。以前ミスマさんから頂いた情報なんですが、DVDのロットによって相性が悪いドライブが存在することがあるそうです。イメージファイルの保存途中で固まるのはそれかもしれません。TEATIME健在な頃は連絡すればDVDを交換してもらえたそうなのですが、今となっては…setup.exeが即固まる件はちょっとわからないです。こちらで動かしてみるとインストールが始まるので…。謎です。幾つかのケースを試してみたのですが、レジストリに「らぶデスFINAL!」のキーがあって且つそのキー中の「INSTALLDIR」に書かれているインストールパスが無効な場合に、「実行時エラー9で即落ちして出力にModelフォルダとodfフォルダが作成されてペイントデータがそこに書き出される」という状況になりました。こちらでは、キーそのものが無い時やキー中に「INSTALLDIR」が無い時はまた違う挙動になっています(前に何を変換したのかも影響する模様)。ただ、レジストリに書かれているインストールパスが無効だとautorun.exeで出てくるメニューにインストールの項目が表示されるはずなので、そこが矛盾するよなあと。autorun.exeがFINAL!の存在を見つけられるのにALP2PMXが見つけられないという状況に「？？？」です。変換しようとしているALPファイル固有の問題ということも考えましたが(表示できるALPでも変換が上手くいかないことがある)、デフォルトのALPでも上手く行かないということでしたので、やっぱり違うんだろうなと。(表示できるけれど変換できないALPにゲーム付属のeir.alpとrota.alpがあります。ALP2PMXが通常通り動作する場合も「頂点数が一致しません」というエラーが発生します(TGA書き出しだけなら発生しないかも)。す～るで一旦保存し直せば変換できるようになります(eirの方は記憶がハッキリしてるけどrotaの方もそうだったはず)。)幾らか調べてはみたものの、原因まで行けなかったですね…FINAL!のALP(実際はALP以外のWBSやFSP等の部分のかすたむファイルでも行けると思います)であっても、変換する時にALP2PMXの「ALPファイル」の下に並んでいるラジオボタンで「ネトワクネトラル」を選択すれば、FINAL!のデータを見にいかずにこちらのデータを参照して変換します。FINAL!にしか無いアイテムを使っていると問答無用でエラーな気がしていたのですが、無い時はそこだけ飛ばして変換するようです。もしかしたら服アイテムと髪エクステでは挙動が違うみたいなこともあるかもしれないので、エラーになったらごめんなさい(飛ばしたアイテムもフォルダが作られたり作られなかったりで挙動が今一つ掴み切れてないのです)。 Re: 454と重複する - mandam 2021/01/26(Tue) 20:05 No.873 ALP2PMXでネトワクにチェックを入れると正常に変換できましたね。これならわざわざネトワク用にALPを変換する手間をかけずにできそうです。コントロールパネルにFINALの項目がないというのもおかしい気もするんですが正常に動いている時からなかったような記憶がありますしその時から変わった点はWindows10のアップデートぐらいでしょうか。でも他に同じような案件を聞かない所を見るとWindows10のアップデートは関係ないですよね。 Re: 454と重複するかもしれ - のぞく人 2021/01/27(Wed) 00:18 No.874 Windows10の機能アップデート(バージョンUP)でインストール情報が消えたみたいな話は確かに聞いてないですが、十分有り得るんじゃないかと思います。あれはファイルの置き換え以外にも結構色んなことを書き換える処理なので、自分的には直前でPC全体のバックアップを取ってなければやらないようにしています。「ロック画面の画像の設定が保存されない」という影響が出たこともありますが、設定関連のフォルダやファイルで所有者情報やアクセス権(ACLというものにまとめられています)の書き換えが上手くいかないケースがあると個人的には思っています。この辺がおかしくなると、ファイルがあるけど見えないということやシステムからアクセスできないということも起こり得ます。レジストリの情報とコントロールパネルの登録情報が両方無くなるというのもちょっと難しいよなあとは思いますが、アップデートを行ってる最中に走る登録情報を引き継ぐ処理が途中で止まってしまえば起こり得なくはないかと考えます。まあ、誰かのところで「プログラムと機能」からアイコンが無くなっていたとして、今からアンインストールしようという方はまず居ないだろうから気付かないんじゃないかなあと。とまあ、インストール情報が吹っ飛ぶもしくは見えなくなるということは起こりうると考えていますが、autorun.exeとALP2PMXは同じユーザー権限で走っているはずなのに一方からはFINAL!のインストール先が見えて一方からは見えないというのがやっぱり分からないー！あとカレマチカノジョの方は見えるのにFINAL!の方は見えないというのも。レジストリキーのアクセス権の関係で見えないとかも考えたけど、同じユーザーが走らせているプログラム同士だし… Re: 454と重複するかもしれ - のぞく人 2021/01/28(Thu) 19:33 No.875 「プログラムと機能」のアンインストール用のアイコンですが、こちらでは存在するのが確認できました。画像はWin7から引き継いだやつですが、Win10に新しくインストールしたPCでもアイコンが作成されました。mandamさんのPCではどこかのタイミングでインストール情報が失われたか、存在してるけど読めない状態になっているかだと思われます。(うちのメインのPCはここのアイコンが無くおとうさんのところもそうらしいのですが、どちらもインストールプログラムを動かしてないので無いのが“正しい”状態です。) 454とは既に方向が - のぞく人 2021/01/29(Fri) 19:29 No.876 訂正AutoRunLauncher(autorun.exe)はレジストリキー「らぶデスFINAL!」の値「INSTALLDIR」の存在だけ見ていて、中身まで見ていませんでした。書かれたパスにファイルが存在しなくても、値が空でもゲーム起動の方のメニューを出します。なのでメニューに「ゲームのインストール」が無いのはレジストリに書かれたパスが有効かどうかとは関係がありません。setupが固まるのは、もしかしたらレジストリに値があることで情報の不整合が生じているのかもしれません(まだ何とも言えない)。もう少しチェックしてみます。 念のため - のぞく人 2021/01/30(Sat) 16:52 No.877 お手数掛けますが、画像みたいな手順で「らぶデスFINAL!」キーの値「INSTALLDIR」を設定し直してみて頂けないでしょうか。今まで通りALP2PMXがFINAL!を認識しない可能性が高いとは思うのですが、これだと手入力を介さないでパスが入るので、念のためということで。setupが固まる件ですが、今のところこちらでは「固まる」という事態には遭遇しておりません。が、InstallShieldがFINAL!が存在するフォルダを見つけるとそこをチェックし始めるので、とても時間が掛かるということが判りました。この時「応答なし」となるので固まってるように見えます。少なくともファイル名のチェック、もしかしたらファイル内容のチェックまでしてるのかもしれません(ウィルスチェックプログラムまで見に行ってました)。mandamさんの場合saveフォルダ以下にファイルが大量にあることと察せられますから、これに掛かる時間が特別長く固まっているように見えるのではないかと推測します。本当に固まっているのかもしませんが。フォルダのチェックが始まるタイミングはインストール先がデフォルトかどうかで違うようです。デフォルト以外(うちの環境だとこっち)だとインストール先フォルダを指定したところでチェックが始まり、デフォルトだともっと早く始まるようではあるのですが今一つよくわかりませんでした。また一つ訂正。FINAL!のインストール、ディスクイメージ(やDVD)からでなくてもできました。「LoveDeathFinal!」フォルダの中身全部、もしくはフォルダごとどこかにコピーしてそこからsetup.exeを実行するので行けます。ディスクイメージが駄目、DVD直も駄目ということでしたら、この方法も試してみて下さい。 Re: 454と重複する - mandam 2021/01/30(Sat) 21:10 No.878 色々試した結果、何とか再インストールができALP2PMXでFINAL産ALPが変換できるようになりました。正常になったと思われるレジストリを見ても違いが判らなかったので原因はよく分かりませんがともかく助かりました、本当にありがとうございました。結局は困ったら再インストールしろという至極シンプルな話でした。 Re: 454と重複するかもしれ - のぞく人 2021/01/30(Sat) 23:18 No.879 再インストール成功されたのですね。ALP2PMXが無事動くようになったとのこと、良かったです。「レジストリの値が正しくてもアクセス許可情報がおかしければALP2PMXが動かないことはあり得るかな？」と考えていたのですが、その場合チェックや修正がとても難しそうだったので、再インストールが上手くいってくれて正直良かったと思います。何か役に立ったことがあったのなら何よりです。
あけましておめでとうございます＆お久しぶりです。カスタムした衣装って、保存して更に保存してあるカスタムした衣装と合わせる時ってみなさん、どのようにやっておられますか？今さらなんですが、カスタムしたスタジャンとカスタムしたジーンズ着合わせようと思ったら、「あれ？片方は一から作り直さなきゃならんのか」と今、思っている最中なんですが、いい方法とか「なんだ、そんなのは・・・」とか解決策、いただけると嬉しいのですが・・・
Re: カスタムした衣装を… - のぞく人 2021/01/06(Wed) 18:06 No.861 おめでとうございます。例としてスタジャンとジーンズが別衣装ということでいいのでしたら、まずジーンズを履いてる状態で「着替え」→「服かすたむ」と進んで、ジーンズの装備スロットを選んで「セーブ」を選択します。ここからジーンズのかすたむデータを保存できます。次にスタジャンを着た状態で「着替え」→「服かすたむ」と進んで、ジーンズを装備したい空きスロットを選択して「ロード」を押すと服かすたむデータの選択メニューになるので、そこで先程セーブしたジーンズのかすたむデータを読み込めます。…って感じでOKでしょうか？ちなみに服かすたむデータはsave\Importフォルダにicpという拡張子で保存されます。「オーバーオール＆ジャケット」みたいなデータで別々にかすたむしたジャンパーのデータとジーンズのデータを合成したいということでしたら、うーん、出来るのかなあ…取り敢えず思いつくのはスロット2つ使って別々に読み込むという手ですか。もしかしたら、かすたむ画面で一方の形状かすたむデータとペイントデータを保存しておいて、他方のデータを読み込んだ状態でかすたむ画面に入って残したい箇所を編集対象から除外して、メニューから形状データ・ペイントデータを読み込む、で行けるかもしれませんが、試したことないですし、上手く行きそうな気があまりしないです。 Re: カスタムした衣装を - ゴート 2021/01/06(Wed) 20:55 No.862 のぞく人さん、毎度ありがとうございます。早々のお返事、ありがとうございます。完全な経験不足を露呈して、恥ずかしい限りです。早速実践させていただきました。出来ました、ありがとうございました。今年こそは、お酒を辞めて、粉骨砕身の気持で、たむたむす～るの創作に励めるよう、かように思う次第でございます。・・・ありがとうございました。(＠＾－＾)
6811さんへの返答の範疇を超えると思うので別スレッドで。ALP2PMXを使った方法以外でテストしてみた時の画像です。何れも右側の心愛さんは6811さんから頂いたサンプル①のボディAを、左側はボディCを使用しています。一番上は827の書き込みと同じ画像でボディCはデフォルトのままです。真ん中はファイルRT_body_type_C.ODFのFRAMチャンク内、ボーン名Frame_2_RT_base_Layer1_Pivotのボーン名と行列データをいじったものです。行列の回転部分の数値を1.0から0.84(サンプル①のODFファイルのものと同じ)に変更し、ボーン名は後ろに“#Modified”を追加しています。一番下は、832の書き込みに書いた透過好きさんがモーションアップローダー273として公開されている「縮小POS.zip」の中から「0.9倍ボーン.pos」を利用したものです。正直POSファイルの利用の仕方をまだ把握しきれてないのですが、まあなんとか縮小できてるように見えます(本当はまだ問題抱えてるのですが、静止画だと分かりません)。RT_body_type_C.ODFはオリジナルのものです。取り敢えず画像のみで。
Re: サイズ変更テスト - 6811 2019/09/15(Sun) 21:43 No.838 せっかくご紹介いただいたので、透過好き様がモーションアップローダーで公開されているファイル(http://yonezon.coresv.com/joyful4/joyful.cgi?read=273)を使用させていただき、HAN作ってFINALフリーH上で動かしてみました。HANでPOS利用の類似ケースを辿ると、男をでかくするパターンでたいぞう様がモーションアップローダーで公開されています。(http://yonezon.coresv.com/joyful4/joyful.cgi?read=241)このSSはここ用にワンシーン作って全コマコピペした物です。3Pの3P-Fェラです。のぞく人様の書かれたとおり、[Aボディだけを縮小化]のスレッドで私がやろうとしていた事と同じ事が全ボディで可能です。先に許可を仰ぐべきだったかも知れません。yomeko様に[Aボディだけを縮小化]のスレッドのリンクを貼らせていただきました。事後報告になってしまい、大変申し訳ありません。たむたむす～るで長さを膝丈に長くした[英国っ娘スカート]が、長くした分だけ原寸で伸びる珍現象を確認しました。FINALフリーH上限定で起きます。シャツをワンピ化したり、長くする変形は良くやるのですが、他のは通常通りに縮みます。「本当はまだ問題抱えてるのですが～」の件も作業してみると把握できますね。
---Aボディだけを縮小化してしまう方法---前列真ん中の3名と後ろのモンスター肩乗り3名全6名だけがAボディです。歴代らぶデスキャラは原寸保持のままAボディからCボディに変更、サキュバスはそのまま、モンスターはたむたむH編集時の寸尺の状況で撮ったSSです。今回の方法が既出でしたらスミマセン。---やってみたALP2PMX縮小寸---ALP2PMX固有機能の等身伸縮という項目を試してみました。ど素人ながらも出力されたフォルダの中に [base_body_A] というかつて中身を弄った事のあるフォルダがあるのを見つけました。このフォルダを弄った事の無い者だけが罪人に石を投げなさいというあれですね。という事はAボディ全部に適用が及ぶのか……個体別は無理そう。①まずお手持ちのAボディ使用のALPをひとつ用意して、ALP2PMXで読み込みを実行させます。動作確認的な意味でこちらでもサンプルを用意しますが、お手元の環境を全て引き継がせるには各自の環境下にあるALP使用が最良です。できればお手元の環境下で一度以上更新履歴のあるALPを使用して下さい。②開くのボタンから行くと、下部[ファイル名]のマス目に[xxxx.alp]とフルネームでコピペ入力しないとALP2PMXは読み込んでくれません。下半分の左側に等身の項目があります。以下は偶々上手く行った数値を書きます。③チェックマークは全部入れたままで、左の数値入力を上から114、0.72、0.72、0.72、0.21、と埋めます。④ALP→ODFボタンで出力させます。出力後に表記数値が変化してる場合がありますが、特に留意は不要です。同じ数値を打って出力させたのに、たむたむす～るを起動すると縮小が実行されていない事態は数度経験しました。逆に一度通用したものは何度でも通るようで、途中から縮小しなくなる事態には遭遇していません。縮小は起きるか否かの2択のように見えます。今の所入力数値の差異を実感できる状況には対面出来ていません。---[らぶデスＦＩＮＡＬ！] 内のフォルダを弄る---①[\らぶデスＦＩＮＡＬ！\data\odf\Body] 内に同名の [base_body_A] というフォルダがあるので、これをバックアップ取ってから削除します。②ALP2PMXから出力されたフォルダ内に存在する同名フォルダ [base_body_A] をこのフォルダだけ抜き出して [\らぶデスＦＩＮＡＬ！\data\odf\Body] 内にコピペで置き換えます。上書きはしないで下さい。で、やってみた所、ボディに留まらず頭、髪、服、武器に至るまで一括で全部縮小できてしまいました。どういう理由か首だけ少々長目になるみたいですが、この程度ならば個別の体かすたむで吸収可能な範疇です。(SS中の6名が該当します。無修正だとこのような首の長さになります。)とりあえず、置換実行前の [\らぶデスＦＩＮＡＬ！\data\odf\Body] の [base_body_A] という元フォルダを多重でバックアップ保全取っておけば何度でも元に戻すことが可能です。てか作業時は原寸の方が圧倒的に扱い易い。あと、試した範囲内ではこのSS以下には縮小しないみたいです。何故なのかとかは全く不明です。先述の通り可か不可かでしか結果が出ません。プログラムやデータ解析方面は苦手で、普段から意味も分からずに数値入れて、結果半泣きでOS入れ直すような奴なので、後は詳しい方々に道を譲りたいです。ご質問等あろうかと思いますが、恐縮ながら何も答えられないと思います。らぶデスFINAL、たむたむす～る両方共プログラム実行時に何の問題も起きず、尚且つ簡単に元に戻せるのが長所でしょうか。しかし因果は不明であり、最悪OS入れ直すような状況が起こり得る可能性があるという点に御留意下さい。自己責任でお願いします。しつこいですが、バックアップ必須です。---アップロードしました---説明文作成に一番時間が掛かってしまいました。以下の内容でアップします。①加工済みbase_body_Aフォルダのサンプル2種→52MBを10MBに圧縮かけてます。②縮小時用HAN2種→2807氏作のAボディ用と汎Aボディ用。両方低身長限定です。③5月末に出した4人組の更新ALP→今回用に身体微調整の上、秋服着せました。引用元ALPは5～6月のと同じです。今回下着だけ紳士No1039氏作のSDK SDJ Bdk Bdjを新規追加しました。作者の皆様、ありがとうございます。http://kienizer.com/download/493265DLパスは英小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]を入れ替える必要が無い。②フォルダ[base_body_A]内のファイル[RT_body_type_A.ODF]だけを置換する。 (バックアップ対象は、[\らぶデスＦＩＮＡＬ！\data\odf\Body\base_body_A]内のファイル [RT_body_type_A.ODF]これひとつだけになります)③入力数値はちゃんと反映される。これは作る方も明確な標的を持てますし、環境を共有する際の 指標にもなります。④首が長くなるバグがない。⑤9月5日分のALP2PMXの時と同じく、たむたむ/FINAL起動時に縮小が反映されない時がある。 (ファイル[RT_body_type_A.ODF]の更新日が元に戻っているので判別が楽)⑥作業が大幅に簡易化、簡略化されました。---手順をまとめてみます---①[\らぶデスＦＩＮＡＬ！\data\odf\Body\base_body_A]内のファイル[RT_body_type_A.ODF]を多重で バックアップを取って下さい。②コピペした[RT_body_type_A.ODF]ファイルを[ODF ver1.05]に読み込みさせます。③[ODF ver1.05]の[身長変更]ボタン押すと「OdfHeight」というツールが起動します。④今回のSSにあるように数値を色々入れて試してみて下さい。⑤[OK]ボタン押すと入れた数値が反映され、読み込んだ[RT_body_type_A.ODF]ファイルが更新済みになります。⑥この更新済み[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近辺]という今回分のサンプルが、前回のサンプル①②の近似値になります。なのですが首の長さが合わなかったためHANは作り直しました。下記よりダウンロードお願いします。DLPは英小teatimeです。http://kienizer.com/download/494168のぞく人様、おかげさまで題材に対して、よりレベルの高い道が開けた感じがしています。ありがとうございます。
Page: | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
- Joyful Note -