vagonumero13 tools (REDELBE, rdbtool, g1mtools, doa6decsave) Update 17 Aug: REDELBE 3.0

[vagonumero13]

24 minutes ago, fgh1t6 said:

? ! Honoka is a very special case in DOA, Her mesh is so uncommon that parts cannot be reused for other girls. But in deed she is the most  sexy Curvy model. I do have an idea of her, it will be a kind of "hard core" though,  hope you won't mind

Great! Honoka needs more modding love. I don't mind the hard core part

[darkassj]

Hi
I seem to be running into issue with redelbe recently, the mod does not seem to load completely, the dininput8.dll is used and basic log info is generated but initialization doesn't seem to progress from there, the game version is and shown in game screen 1.22 #19.

I have used 2.8 version as well as older version(that had worked previously) both didn't work (as in game started without loading redelbe) so it doesn't seem to be related to mod itself, however maybe somebody can hint where issue could be coming from. New DOA version, AMD Radeon software, Steam ?

Log entries generated on run.

0:00:00.000: Myself path = D:/Games/SteamLibrary/steamapps/common/Dead or Alive 6/
0:00:00.000: original DLL path: C:\Windows\system32\dinput8.dll   base=00007FFC25AB0000

 

[vagonumero13]

4 hours ago, darkassj said:

Hi
I seem to be running into issue with redelbe recently, the mod does not seem to load completely, the dininput8.dll is used and basic log info is generated but initialization doesn't seem to progress from there, the game version is and shown in game screen 1.22 #19.

I have used 2.8 version as well as older version(that had worked previously) both didn't work (as in game started without loading redelbe) so it doesn't seem to be related to mod itself, however maybe somebody can hint where issue could be coming from. New DOA version, AMD Radeon software, Steam ?

Log entries generated on run.

0:00:00.000: Myself path = D:/Games/SteamLibrary/steamapps/common/Dead or Alive 6/
0:00:00.000: original DLL path: C:\Windows\system32\dinput8.dll   base=00007FFC25AB0000

 

 

Well, that's a weird log.

It seem to indicate that the initial dll routine started, but the call to the hooked GetStartupInfo never happened, which is when REDELBE would start doing the patches.

The only things I can think of is another software interfering, maybe an antivirus or maybe another .dll there doing the same thing.

[RigidRourke]

16 hours ago, vagonumero13 said:

REDELBE updated to 2.8:

 

Changelog:

- More filenames available (matching rdbtool 2.8)
- Important bugfix: the loader of additional filenames was critically slow, causing a delay of between 10-20 seconds depending of cpu speed. The new implementation has brought it down to ~40 milisecs.
  Now the game should boot faster.

 

------

 

rdbtool updated to 2.8

 

Changelog:

- More filenames available (a few effects in CE, and few island textures in ME)
- The search function efficiency of qrdbtool has been improved (mainly noticeable in MaterialEditor)
- Fixed: the search was canse sensitive.
- Important bugfix: the loader of additional filenames was critically slow. This would cause the load of MaterialEditor to be delayed by 10-20 seconds, depending of cpu speed.
  The loading speed of MaterialEditor is now significantly faster.
- qrdbtool can now preview .g1t files.

 

---------------

 

I can't believe it took me more than a year to realize that important cpu bottleneck. I guess it was a good idea to add timestamps to the log, it is what allowed me to notice something was off.

Btw, that bug is not related with the one that some people have in the splash screen. The splash screen issue is a vanilla bug.

 

This release of REDELBE was mainly to fix that bug, as I consider it important. In next release, I may add some feature.

You're psychic, man. I've been having trouble with having multiple versions of the same stages (like night/snowy/snow/dark Throwdown or Colosseum all being in the layer2 folder, for example). I figure this fix might help the game run just as smoothly when I have given it 3 or more variations of the same stage in Layer2 to draw from as when I have given it just two or one alternative. Or else my guess is way off.

 

My guess is that the game folder gets preoccupied with fetching information when there are multiple stage samples of the same stage in Layer2, even if it has already chosen one for you to go with in actual time. Like, it's still struggling to work with the other probable versions of the stage even though you're obviously just playing with one version (including vanilla). I'm not sure that the game can differentiate on its own between the actual stage being played and all of the potential other ones of it in Layer2 during a session (I'm pretty sure Team Ninja didn't build the piece for multiple variations of each stage, anyway).

 

I play with a Ryzen 9 CPU, Radeon 7 GPU, and 32 gb RAM at 2400, and the game still slows down when I'm on a stage that has more than 2 cousins in layer2 (enough to sabotage my otherwise highly skilled gameplay lol).

[vagonumero13]

5 hours ago, RigidRourke said:

You're psychic, man. I've been having trouble with having multiple versions of the same stages (like night/snowy/snow/dark Throwdown or Colosseum all being in the layer2 folder, for example). I figure this fix might help the game run just as smoothly when I have given it 3 or more variations of the same stage in Layer2 to draw from as when I have given it just two or one alternative. Or else my guess is way off.

 

My guess is that the game folder gets preoccupied with fetching information when there are multiple stage samples of the same stage in Layer2, even if it has already chosen one for you to go with in actual time. Like, it's still struggling to work with the other probable versions of the stage even though you're obviously just playing with one version (including vanilla). I'm not sure that the game can differentiate on its own between the actual stage being played and all of the potential other ones of it in Layer2 during a session (I'm pretty sure Team Ninja didn't build the piece for multiple variations of each stage, anyway).

 

I play with a Ryzen 9 CPU, Radeon 7 GPU, and 32 gb RAM at 2400, and the game still slows down when I'm on a stage that has more than 2 cousins in layer2 (enough to sabotage my otherwise highly skilled gameplay lol).

 

You mean that it gets slowed down on the fighting itself? Mmm, technically the number of layer2 mods shouldn't affect something like that at all.

[vagonumero13]

These goes mainly for stage modders. Do any of you have any of these files in your mods? (they are all from RRPreview)

 

Spoiler

0xa40fbdaa,MPR_CGEffect_Effect_muscleEV_flash07_kidsalb.g1t
0xa0069adc,MPR_CGEffect_Effect_muscleEV_flash07_kidsnmh.g1t
0x01578662,MPR_CGEffect_Effect_muscleEV_flash07_kidsocc.g1t
0xb4a405d1,MPR_CGEffect_Effect_muscleEV_flash07_kidsrfr.g1t
0x0153b7cb,MPR_CGEffect_Effect_muscleEV_glow05_kidsalb.g1t
0x85536c59,MPR_CGEffect_Effect_muscleEV_glow05_kidsnmh.g1t
0xfc13f813,MPR_CGEffect_Effect_muscleEV_glow05_kidsocc.g1t
0xd8924ec4,MPR_CGEffect_Effect_muscleEV_glow05_kidsrfr.g1t
0x3b1e59aa,MPR_CGEffect_Effect_muscleEV_glow06_kidsalb.g1t
0xbf1e0e38,MPR_CGEffect_Effect_muscleEV_glow06_kidsnmh.g1t
0x35de99f2,MPR_CGEffect_Effect_muscleEV_glow06_kidsocc.g1t
0x125cf0a3,MPR_CGEffect_Effect_muscleEV_glow06_kidsrfr.g1t
0xd22bf52a,MPR_CGEffect_Effect_muscleEV_rainbow01_kidsalb.g1t
0xabe04ddc,MPR_CGEffect_Effect_muscleEV_rainbow01_kidsnmh.g1t
0xfca46fe2,MPR_CGEffect_Effect_muscleEV_rainbow01_kidsocc.g1t
0x0ececf91,MPR_CGEffect_Effect_muscleEV_rainbow01_kidsrfr.g1t
0x997f0cf0,MPR_CGEffect_Effect_muscle_dis11_kidsalb.g1t
0x84c85322,MPR_CGEffect_Effect_muscle_dis11_kidsnmh.g1t
0x3bb7f1a8,MPR_CGEffect_Effect_muscle_dis11_kidsocc.g1t
0xd6538097,MPR_CGEffect_Effect_muscle_dis11_kidsrfr.g1t
0xb171a316,MPR_CGEffect_Effect_muscle_dis18_kidsalb.g1t
0xe73b7e24,MPR_CGEffect_Effect_muscle_dis18_kidsnmh.g1t
0x4934295e,MPR_CGEffect_Effect_muscle_dis18_kidsocc.g1t
0xe65e96cf,MPR_CGEffect_Effect_muscle_dis18_kidsrfr.g1t
0x08a0cd7c,MPR_CGEffect_Effect_muscle_dis27_kidsefno.g1t
0xe7794b87,MPR_CGEffect_Effect_muscle_dis27_kidsnmh.g1t
0x9e68ea0d,MPR_CGEffect_Effect_muscle_dis27_kidsocc.g1t
0x390478fc,MPR_CGEffect_Effect_muscle_dis27_kidsrfr.g1t
0xf309c978,MPR_CGEffect_Effect_muscle_dust02_kidsalb.g1t
0x70e94986,MPR_CGEffect_Effect_muscle_dust02_kidsnmh.g1t
0x97ed7bc0,MPR_CGEffect_Effect_muscle_dust02_kidsocc.g1t
0x50c3cab1,MPR_CGEffect_Effect_muscle_dust02_kidsrfr.g1t
0xd4d33285,MPR_CGEffect_Effect_muscle_exp04_mv_kidsalb.g1t
0x9f7ad984,MPR_CGEffect_Effect_muscle_exp04_mv_kidsnmmv.g1t
0xcf9372cd,MPR_CGEffect_Effect_muscle_exp04_mv_kidsocc.g1t
0xac11c97e,MPR_CGEffect_Effect_muscle_exp04_mv_kidsrfr.g1t
0x996ca270,MPR_CGEffect_Effect_muscle_fire15_mv_kidsalb.g1t
0x23b9db51,MPR_CGEffect_Effect_muscle_fire15_mv_kidsnmmv.g1t
0xf6b46b28,MPR_CGEffect_Effect_muscle_fire15_mv_kidsocc.g1t
0xaa00ea97,MPR_CGEffect_Effect_muscle_fire15_mv_kidsrfr.g1t
0x0c5bbdae,MPR_CGEffect_Effect_muscle_fire17_mv_kidsalb.g1t
0x96a8f68f,MPR_CGEffect_Effect_muscle_fire17_mv_kidsnmmv.g1t
0x69a38666,MPR_CGEffect_Effect_muscle_fire17_mv_kidsocc.g1t
0x1cf005d5,MPR_CGEffect_Effect_muscle_fire17_mv_kidsrfr.g1t
0x94b7a0d6,MPR_CGEffect_Effect_muscle_fire20_mv_kidsalb.g1t
0x1f04d9b7,MPR_CGEffect_Effect_muscle_fire20_mv_kidsnmmv.g1t
0xf1ff698e,MPR_CGEffect_Effect_muscle_fire20_mv_kidsocc.g1t
0xa54be8fd,MPR_CGEffect_Effect_muscle_fire20_mv_kidsrfr.g1t
0xa6fc802f,MPR_CGEffect_Effect_muscle_fire27_mv_kidsalb.g1t
0x3149b910,MPR_CGEffect_Effect_muscle_fire27_mv_kidsnmmv.g1t
0x044448e7,MPR_CGEffect_Effect_muscle_fire27_mv_kidsocc.g1t
0xb790c856,MPR_CGEffect_Effect_muscle_fire27_mv_kidsrfr.g1t
0xf07edd70,MPR_CGEffect_Effect_muscle_fire28_kidsalb.g1t
0x6e5e5d7e,MPR_CGEffect_Effect_muscle_fire28_kidsnmh.g1t
0x95628fb8,MPR_CGEffect_Effect_muscle_fire28_kidsocc.g1t
0x4e38dea9,MPR_CGEffect_Effect_muscle_fire28_kidsrfr.g1t
0x00743074,MPR_CGEffect_Effect_muscle_flash24_kidsalb.g1t
0x3e84b226,MPR_CGEffect_Effect_muscle_flash24_kidsnmh.g1t
0xf806c72c,MPR_CGEffect_Effect_muscle_flash24_kidsocc.g1t
0x59fa565b,MPR_CGEffect_Effect_muscle_flash24_kidsrfr.g1t
0x4bd6efb9,MPR_CGEffect_Effect_muscle_flash29_kidsalb.g1t
0x89e7716b,MPR_CGEffect_Effect_muscle_flash29_kidsnmh.g1t
0x43698671,MPR_CGEffect_Effect_muscle_flash29_kidsocc.g1t
0xa55d15a0,MPR_CGEffect_Effect_muscle_flash29_kidsrfr.g1t
0x0a1aed7d,MPR_CGEffect_Effect_muscle_glow02_kidsalb.g1t
0x87fa6d8b,MPR_CGEffect_Effect_muscle_glow02_kidsnmh.g1t
0xaefe9fc5,MPR_CGEffect_Effect_muscle_glow02_kidsocc.g1t
0x67d4eeb6,MPR_CGEffect_Effect_muscle_glow02_kidsrfr.g1t
0x9e0bd280,MPR_CGEffect_Effect_muscle_ice00_kidsalb.g1t
0xd3d5ad8e,MPR_CGEffect_Effect_muscle_ice00_kidsnmh.g1t
0x35ce58c8,MPR_CGEffect_Effect_muscle_ice00_kidsocc.g1t
0xd2f8c639,MPR_CGEffect_Effect_muscle_ice00_kidsrfr.g1t
0x82d6d8d8,MPR_CGEffect_Effect_muscle_ice01_kidsefno.g1t
0x60c2c4ad,MPR_CGEffect_Effect_muscle_ice01_kidsnmh.g1t
0xc2bb6fe7,MPR_CGEffect_Effect_muscle_ice01_kidsocc.g1t
0x5fe5dd58,MPR_CGEffect_Effect_muscle_ice01_kidsrfr.g1t
0x94a8e7c8,MPR_CGEffect_Effect_muscle_shoreline_a_kidsalb.g1t
0xb078b0c7,MPR_CGEffect_Effect_muscle_shoreline_a_kidsnmmv.g1t
0x36af9810,MPR_CGEffect_Effect_muscle_shoreline_a_kidsocc.g1t
0x2d346cc1,MPR_CGEffect_Effect_muscle_shoreline_a_kidsrfr.g1t
0x1309eba7,MPR_CGEffect_Effect_muscle_shoreline_b_kidsalb.g1t
0x2ed9b4a6,MPR_CGEffect_Effect_muscle_shoreline_b_kidsnmmv.g1t
0xb5109bef,MPR_CGEffect_Effect_muscle_shoreline_b_kidsocc.g1t
0xab9570a0,MPR_CGEffect_Effect_muscle_shoreline_b_kidsrfr.g1t
0x29de3692,MPR_CGEffect_Effect_muscle_smoke12_kidsalb.g1t
0x67eeb844,MPR_CGEffect_Effect_muscle_smoke12_kidsnmh.g1t
0x2170cd4a,MPR_CGEffect_Effect_muscle_smoke12_kidsocc.g1t
0x83645c79,MPR_CGEffect_Effect_muscle_smoke12_kidsrfr.g1t
0xb88f11f4,MPR_CGEffect_Effect_muscle_smoke12_mv_kidsalb.g1t
0x77e8f533,MPR_CGEffect_Effect_muscle_smoke12_mv_kidsnmmv.g1t
0x0440603c,MPR_CGEffect_Effect_muscle_smoke12_mv_kidsocc.g1t
0xba83cead,MPR_CGEffect_Effect_muscle_smoke12_mv_kidsrfr.g1t
0xa432a9b7,MPR_CGEffect_Effect_muscle_smoke28_kidsalb.g1t
0xe48aa6d8,MPR_CGEffect_Effect_muscle_smoke28_kidsnmmv.g1t
0x9bc5406f,MPR_CGEffect_Effect_muscle_smoke28_kidsocc.g1t
0xfdb8cf9e,MPR_CGEffect_Effect_muscle_smoke28_kidsrfr.g1t
0xa85dab5a,MPR_CGEffect_Effect_muscle_smoke29_mv_kidsalb.g1t
0x67b78e99,MPR_CGEffect_Effect_muscle_smoke29_mv_kidsnmmv.g1t
0xf40ef9a2,MPR_CGEffect_Effect_muscle_smoke29_mv_kidsocc.g1t
0xaa526813,MPR_CGEffect_Effect_muscle_smoke29_mv_kidsrfr.g1t
0xdc59746d,MPR_CGEffect_Effect_muscle_trail16_kidsalb.g1t
0x1a69f61f,MPR_CGEffect_Effect_muscle_trail16_kidsnmh.g1t
0xd3ec0b25,MPR_CGEffect_Effect_muscle_trail16_kidsocc.g1t
0x35df9a54,MPR_CGEffect_Effect_muscle_trail16_kidsrfr.g1t
0xfdfb5ea4,MPR_CGEffect_Effect_muscle_trail17_dis_kidsefno.g1t
0xf1e1e86f,MPR_CGEffect_Effect_muscle_trail17_dis_kidsnmh.g1t
0x42a60a75,MPR_CGEffect_Effect_muscle_trail17_dis_kidsocc.g1t
0x54d06a24,MPR_CGEffect_Effect_muscle_trail17_dis_kidsrfr.g1t
0xc4f350c4,MPR_CGEffect_Effect_muscle_aura27_kidsalb.g1t
0x42d2d0d2,MPR_CGEffect_Effect_muscle_aura27_kidsnmh.g1t
0x69d7030c,MPR_CGEffect_Effect_muscle_aura27_kidsocc.g1t
0x22ad51fd,MPR_CGEffect_Effect_muscle_aura27_kidsrfr.g1t
0x7e6ade63,MPR_CGEffect_Effect_muscle_aura28_kidsalb.g1t
0xfc4a5e71,MPR_CGEffect_Effect_muscle_aura28_kidsnmh.g1t
0x234e90ab,MPR_CGEffect_Effect_muscle_aura28_kidsocc.g1t
0xdc24df9c,MPR_CGEffect_Effect_muscle_aura28_kidsrfr.g1t
0xd55f21f2,MPR_CGEffect_Effect_muscle_fire04_kidsalb.g1t
0x533ea200,MPR_CGEffect_Effect_muscle_fire04_kidsnmh.g1t
0x7a42d43a,MPR_CGEffect_Effect_muscle_fire04_kidsocc.g1t
0x3319232b,MPR_CGEffect_Effect_muscle_fire04_kidsrfr.g1t
0xa9f66b0f,MPR_CGEffect_Effect_muscle_fire29_kidsalb.g1t
0x27d5eb1d,MPR_CGEffect_Effect_muscle_fire29_kidsnmh.g1t
0x4eda1d57,MPR_CGEffect_Effect_muscle_fire29_kidsocc.g1t
0x07b06c48,MPR_CGEffect_Effect_muscle_fire29_kidsrfr.g1t
0x77d6073c,MPR_CGEffect_Effect_muscle_ring00_kidsalb.g1t
0xf5b5874a,MPR_CGEffect_Effect_muscle_ring00_kidsnmh.g1t
0x1cb9b984,MPR_CGEffect_Effect_muscle_ring00_kidsocc.g1t
0xd5900875,MPR_CGEffect_Effect_muscle_ring00_kidsrfr.g1t

 

 

 

I'm just asking, because now I realized that these filenames were slightly wrong, they were missing a prefix. The real filenames are:

Spoiler

0xa40fbdaa,CE1_MPR_CGEffect_Effect_muscleEV_flash07_kidsalb.g1t
0xa0069adc,CE1_MPR_CGEffect_Effect_muscleEV_flash07_kidsnmh.g1t
0x01578662,CE1_MPR_CGEffect_Effect_muscleEV_flash07_kidsocc.g1t
0xb4a405d1,CE1_MPR_CGEffect_Effect_muscleEV_flash07_kidsrfr.g1t
0x0153b7cb,CE1_MPR_CGEffect_Effect_muscleEV_glow05_kidsalb.g1t
0x85536c59,CE1_MPR_CGEffect_Effect_muscleEV_glow05_kidsnmh.g1t
0xfc13f813,CE1_MPR_CGEffect_Effect_muscleEV_glow05_kidsocc.g1t
0xd8924ec4,CE1_MPR_CGEffect_Effect_muscleEV_glow05_kidsrfr.g1t
0x3b1e59aa,CE1_MPR_CGEffect_Effect_muscleEV_glow06_kidsalb.g1t
0xbf1e0e38,CE1_MPR_CGEffect_Effect_muscleEV_glow06_kidsnmh.g1t
0x35de99f2,CE1_MPR_CGEffect_Effect_muscleEV_glow06_kidsocc.g1t
0x125cf0a3,CE1_MPR_CGEffect_Effect_muscleEV_glow06_kidsrfr.g1t
0xd22bf52a,CE1_MPR_CGEffect_Effect_muscleEV_rainbow01_kidsalb.g1t
0xabe04ddc,CE1_MPR_CGEffect_Effect_muscleEV_rainbow01_kidsnmh.g1t
0xfca46fe2,CE1_MPR_CGEffect_Effect_muscleEV_rainbow01_kidsocc.g1t
0x0ececf91,CE1_MPR_CGEffect_Effect_muscleEV_rainbow01_kidsrfr.g1t
0x997f0cf0,CE1_MPR_CGEffect_Effect_muscle_dis11_kidsalb.g1t
0x84c85322,CE1_MPR_CGEffect_Effect_muscle_dis11_kidsnmh.g1t
0x3bb7f1a8,CE1_MPR_CGEffect_Effect_muscle_dis11_kidsocc.g1t
0xd6538097,CE1_MPR_CGEffect_Effect_muscle_dis11_kidsrfr.g1t
0xb171a316,FE4_Field_Common_MPR_CGEffect_Effect_muscle_dis18_kidsalb.g1t
0xe73b7e24,FE4_Field_Common_MPR_CGEffect_Effect_muscle_dis18_kidsnmh.g1t
0x4934295e,FE4_Field_Common_MPR_CGEffect_Effect_muscle_dis18_kidsocc.g1t
0xe65e96cf,FE4_Field_Common_MPR_CGEffect_Effect_muscle_dis18_kidsrfr.g1t
0x08a0cd7c,CE1_MPR_CGEffect_Effect_muscle_dis27_kidsefno.g1t
0xe7794b87,CE1_MPR_CGEffect_Effect_muscle_dis27_kidsnmh.g1t
0x9e68ea0d,CE1_MPR_CGEffect_Effect_muscle_dis27_kidsocc.g1t
0x390478fc,CE1_MPR_CGEffect_Effect_muscle_dis27_kidsrfr.g1t
0xf309c978,CE1_MPR_CGEffect_Effect_muscle_dust02_kidsalb.g1t
0x70e94986,CE1_MPR_CGEffect_Effect_muscle_dust02_kidsnmh.g1t
0x97ed7bc0,CE1_MPR_CGEffect_Effect_muscle_dust02_kidsocc.g1t
0x50c3cab1,CE1_MPR_CGEffect_Effect_muscle_dust02_kidsrfr.g1t
0xd4d33285,CE1_MPR_CGEffect_Effect_muscle_exp04_mv_kidsalb.g1t
0x9f7ad984,CE1_MPR_CGEffect_Effect_muscle_exp04_mv_kidsnmmv.g1t
0xcf9372cd,CE1_MPR_CGEffect_Effect_muscle_exp04_mv_kidsocc.g1t
0xac11c97e,CE1_MPR_CGEffect_Effect_muscle_exp04_mv_kidsrfr.g1t
0x996ca270,CE1_MPR_CGEffect_Effect_muscle_fire15_mv_kidsalb.g1t
0x23b9db51,CE1_MPR_CGEffect_Effect_muscle_fire15_mv_kidsnmmv.g1t
0xf6b46b28,CE1_MPR_CGEffect_Effect_muscle_fire15_mv_kidsocc.g1t
0xaa00ea97,CE1_MPR_CGEffect_Effect_muscle_fire15_mv_kidsrfr.g1t
0x0c5bbdae,CE1_MPR_CGEffect_Effect_muscle_fire17_mv_kidsalb.g1t
0x96a8f68f,CE1_MPR_CGEffect_Effect_muscle_fire17_mv_kidsnmmv.g1t
0x69a38666,CE1_MPR_CGEffect_Effect_muscle_fire17_mv_kidsocc.g1t
0x1cf005d5,CE1_MPR_CGEffect_Effect_muscle_fire17_mv_kidsrfr.g1t
0x94b7a0d6,CE1_MPR_CGEffect_Effect_muscle_fire20_mv_kidsalb.g1t
0x1f04d9b7,CE1_MPR_CGEffect_Effect_muscle_fire20_mv_kidsnmmv.g1t
0xf1ff698e,CE1_MPR_CGEffect_Effect_muscle_fire20_mv_kidsocc.g1t
0xa54be8fd,CE1_MPR_CGEffect_Effect_muscle_fire20_mv_kidsrfr.g1t
0xa6fc802f,CE1_MPR_CGEffect_Effect_muscle_fire27_mv_kidsalb.g1t
0x3149b910,CE1_MPR_CGEffect_Effect_muscle_fire27_mv_kidsnmmv.g1t
0x044448e7,CE1_MPR_CGEffect_Effect_muscle_fire27_mv_kidsocc.g1t
0xb790c856,CE1_MPR_CGEffect_Effect_muscle_fire27_mv_kidsrfr.g1t
0xf07edd70,CE1_MPR_CGEffect_Effect_muscle_fire28_kidsalb.g1t
0x6e5e5d7e,CE1_MPR_CGEffect_Effect_muscle_fire28_kidsnmh.g1t
0x95628fb8,CE1_MPR_CGEffect_Effect_muscle_fire28_kidsocc.g1t
0x4e38dea9,CE1_MPR_CGEffect_Effect_muscle_fire28_kidsrfr.g1t
0x00743074,CE1_MPR_CGEffect_Effect_muscle_flash24_kidsalb.g1t
0x3e84b226,CE1_MPR_CGEffect_Effect_muscle_flash24_kidsnmh.g1t
0xf806c72c,CE1_MPR_CGEffect_Effect_muscle_flash24_kidsocc.g1t
0x59fa565b,CE1_MPR_CGEffect_Effect_muscle_flash24_kidsrfr.g1t
0x4bd6efb9,CE1_MPR_CGEffect_Effect_muscle_flash29_kidsalb.g1t
0x89e7716b,CE1_MPR_CGEffect_Effect_muscle_flash29_kidsnmh.g1t
0x43698671,CE1_MPR_CGEffect_Effect_muscle_flash29_kidsocc.g1t
0xa55d15a0,CE1_MPR_CGEffect_Effect_muscle_flash29_kidsrfr.g1t
0x0a1aed7d,CE1_MPR_CGEffect_Effect_muscle_glow02_kidsalb.g1t
0x87fa6d8b,CE1_MPR_CGEffect_Effect_muscle_glow02_kidsnmh.g1t
0xaefe9fc5,CE1_MPR_CGEffect_Effect_muscle_glow02_kidsocc.g1t
0x67d4eeb6,CE1_MPR_CGEffect_Effect_muscle_glow02_kidsrfr.g1t
0x9e0bd280,FE4_Field_Common_MPR_CGEffect_Effect_muscle_ice00_kidsalb.g1t
0xd3d5ad8e,FE4_Field_Common_MPR_CGEffect_Effect_muscle_ice00_kidsnmh.g1t
0x35ce58c8,FE4_Field_Common_MPR_CGEffect_Effect_muscle_ice00_kidsocc.g1t
0xd2f8c639,FE4_Field_Common_MPR_CGEffect_Effect_muscle_ice00_kidsrfr.g1t
0x82d6d8d8,FE4_Field_Common_MPR_CGEffect_Effect_muscle_ice01_kidsefno.g1t
0x60c2c4ad,FE4_Field_Common_MPR_CGEffect_Effect_muscle_ice01_kidsnmh.g1t
0xc2bb6fe7,FE4_Field_Common_MPR_CGEffect_Effect_muscle_ice01_kidsocc.g1t
0x5fe5dd58,FE4_Field_Common_MPR_CGEffect_Effect_muscle_ice01_kidsrfr.g1t
0x94a8e7c8,FE4_Field_Common_MPR_CGEffect_Effect_muscle_shoreline_a_kidsalb.g1t
0xb078b0c7,FE4_Field_Common_MPR_CGEffect_Effect_muscle_shoreline_a_kidsnmmv.g1t
0x36af9810,FE4_Field_Common_MPR_CGEffect_Effect_muscle_shoreline_a_kidsocc.g1t
0x2d346cc1,FE4_Field_Common_MPR_CGEffect_Effect_muscle_shoreline_a_kidsrfr.g1t
0x1309eba7,FE4_Field_Common_MPR_CGEffect_Effect_muscle_shoreline_b_kidsalb.g1t
0x2ed9b4a6,FE4_Field_Common_MPR_CGEffect_Effect_muscle_shoreline_b_kidsnmmv.g1t
0xb5109bef,FE4_Field_Common_MPR_CGEffect_Effect_muscle_shoreline_b_kidsocc.g1t
0xab9570a0,FE4_Field_Common_MPR_CGEffect_Effect_muscle_shoreline_b_kidsrfr.g1t
0x29de3692,CE1_MPR_CGEffect_Effect_muscle_smoke12_kidsalb.g1t
0x67eeb844,CE1_MPR_CGEffect_Effect_muscle_smoke12_kidsnmh.g1t
0x2170cd4a,CE1_MPR_CGEffect_Effect_muscle_smoke12_kidsocc.g1t
0x83645c79,CE1_MPR_CGEffect_Effect_muscle_smoke12_kidsrfr.g1t
0xb88f11f4,CE1_MPR_CGEffect_Effect_muscle_smoke12_mv_kidsalb.g1t
0x77e8f533,CE1_MPR_CGEffect_Effect_muscle_smoke12_mv_kidsnmmv.g1t
0x0440603c,CE1_MPR_CGEffect_Effect_muscle_smoke12_mv_kidsocc.g1t
0xba83cead,CE1_MPR_CGEffect_Effect_muscle_smoke12_mv_kidsrfr.g1t
0xa432a9b7,CE1_MPR_CGEffect_Effect_muscle_smoke28_kidsalb.g1t
0xe48aa6d8,CE1_MPR_CGEffect_Effect_muscle_smoke28_kidsnmmv.g1t
0x9bc5406f,CE1_MPR_CGEffect_Effect_muscle_smoke28_kidsocc.g1t
0xfdb8cf9e,CE1_MPR_CGEffect_Effect_muscle_smoke28_kidsrfr.g1t
0xa85dab5a,CE1_MPR_CGEffect_Effect_muscle_smoke29_mv_kidsalb.g1t
0x67b78e99,CE1_MPR_CGEffect_Effect_muscle_smoke29_mv_kidsnmmv.g1t
0xf40ef9a2,CE1_MPR_CGEffect_Effect_muscle_smoke29_mv_kidsocc.g1t
0xaa526813,CE1_MPR_CGEffect_Effect_muscle_smoke29_mv_kidsrfr.g1t
0xdc59746d,CE1_MPR_CGEffect_Effect_muscle_trail16_kidsalb.g1t
0x1a69f61f,CE1_MPR_CGEffect_Effect_muscle_trail16_kidsnmh.g1t
0xd3ec0b25,CE1_MPR_CGEffect_Effect_muscle_trail16_kidsocc.g1t
0x35df9a54,CE1_MPR_CGEffect_Effect_muscle_trail16_kidsrfr.g1t
0xfdfb5ea4,CE1_MPR_CGEffect_Effect_muscle_trail17_dis_kidsefno.g1t
0xf1e1e86f,CE1_MPR_CGEffect_Effect_muscle_trail17_dis_kidsnmh.g1t
0x42a60a75,CE1_MPR_CGEffect_Effect_muscle_trail17_dis_kidsocc.g1t
0x54d06a24,CE1_MPR_CGEffect_Effect_muscle_trail17_dis_kidsrfr.g1t

0xc4f350c4,CE1_MPR_CGEffect_Effect_muscle_aura27_kidsalb.g1t
0x42d2d0d2,CE1_MPR_CGEffect_Effect_muscle_aura27_kidsnmh.g1t
0x69d7030c,CE1_MPR_CGEffect_Effect_muscle_aura27_kidsocc.g1t
0x22ad51fd,CE1_MPR_CGEffect_Effect_muscle_aura27_kidsrfr.g1t
0x7e6ade63,CE1_MPR_CGEffect_Effect_muscle_aura28_kidsalb.g1t
0xfc4a5e71,CE1_MPR_CGEffect_Effect_muscle_aura28_kidsnmh.g1t
0x234e90ab,CE1_MPR_CGEffect_Effect_muscle_aura28_kidsocc.g1t
0xdc24df9c,CE1_MPR_CGEffect_Effect_muscle_aura28_kidsrfr.g1t
0xd55f21f2,CE1_MPR_CGEffect_Effect_muscle_fire04_kidsalb.g1t
0x533ea200,CE1_MPR_CGEffect_Effect_muscle_fire04_kidsnmh.g1t
0x7a42d43a,CE1_MPR_CGEffect_Effect_muscle_fire04_kidsocc.g1t
0x3319232b,CE1_MPR_CGEffect_Effect_muscle_fire04_kidsrfr.g1t
0xa9f66b0f,CE1_MPR_CGEffect_Effect_muscle_fire29_kidsalb.g1t
0x27d5eb1d,CE1_MPR_CGEffect_Effect_muscle_fire29_kidsnmh.g1t
0x4eda1d57,CE1_MPR_CGEffect_Effect_muscle_fire29_kidsocc.g1t
0x07b06c48,CE1_MPR_CGEffect_Effect_muscle_fire29_kidsrfr.g1t
0x77d6073c,CE1_MPR_CGEffect_Effect_muscle_ring00_kidsalb.g1t
0xf5b5874a,CE1_MPR_CGEffect_Effect_muscle_ring00_kidsnmh.g1t
0x1cb9b984,CE1_MPR_CGEffect_Effect_muscle_ring00_kidsocc.g1t
0xd5900875,CE1_MPR_CGEffect_Effect_muscle_ring00_kidsrfr.g1t

 

And for the sake of correction, I will correct these names in next version of REDELBE/rdbtool, but I want to know how much disrupt that may cause in existing mods.

[vagonumero13]

Well, after a lot of time, I finally confirmed that those strange hashes in g1m files in the Meshes section (the ones that start with "@", and which in xml I called "Type") are the shaders names, as I suspected a long ago.

 

So, for example, @11380057, is actually the hash of "PB2-H2IriSofTsbcaWt11555551", which is one of the gazillions of g1s files (shaders files) in system.rdb.

I didn't catch this before because for these they are using an alternate hash function, different to the one they usually use.

 

 

So, anyway, in the next version of g1m_xml, I will rename that field as "Shader_Name", and resolve the hash to name when possible.

[fgh1t6]

Spoiler

2 hours ago, vagonumero13 said:

Well, after a lot of time, I finally confirmed that those strange hashes in g1m files in the Meshes section (the ones that start with "@", and which in xml I called "Type") are the shaders names, as I suspected a long ago.

 

So, for example, @11380057, is actually the hash of "PB2-H2IriSofTsbcaWt11555551", which is one of the gazillions of g1s files (shaders files) in system.rdb.

I didn't catch this before because for these they are using an alternate hash function, different to the one they usually use.

 

 

So, anyway, in the next version of g1m_xml, I will rename that field as "Shader_Name", and resolve the hash to name when possible.

 

Wow! That opens another door! Can we have a function or table to convert between the file and hash? I believe there are a few shaders was not used in the g1m file but exist for fighting effects. I would like to try if they can be used in g1m file.

[vagonumero13]

23 minutes ago, fgh1t6 said:

  Reveal hidden contents

 

Wow! That opens another door! Can we have a function or table to convert between the file and hash? I believe there are a few shaders was not used in the g1m file but exist for fighting effects. I would like to try if they can be used in g1m file.

 

Sadly, I discovered one thing: you can only add additional shaders in costumes that have a .sid file in CharacterEditor.

For a example, see the (silly) attached mod.

 

This is a mod to make a NPC (from the chinese stage) playable, This mod wasn't possible before because the shader that these NPC use isn't used by regular characters.

Now after, I discover this shader thing, I did a test, I added the following shader line to the sid file of KAS_COS_004 (the name of the shader is the thing before the first ",")

 

Spoiler

PB2-Di,CE1ResourceShaderPhysicallyBased2Standard［PB2－Di］,R_G1S［PB2－Di］

 

And voila, now this silly mods works!

But the original idea would have been to make it into a Jann Lee slot. Sadly, none of the costumes of Jann Lee have a .sid file, so I ended using Kasumi for the test. It seems that for costumes without a .sid file, the game just loads some defaults or something.

 

Once I release new g1m_xml, I will have it resolve names in some comment or something, but in the meanwhile you can use the attached txt file to find the shader name of a hash  (remember to search without the "@" !)

Then after finding the name, if you want to know the exact line you should add to the .sid file, then search for the name of the shader in the file "Character.sid" in system.rdb, and then just paste that line in your sid file.

 

 

 

 

NPCTEST.zip sid_alt_hash.txt

[vagonumero13]

g1mtools updated to 1.2

 

Changelog:

- The package now includes a changelog.
- Fixed compatibility with some .g1m of FieldEditor4.rdb that used older versions of G1MF chunk, as well as compatibility with the ancient g1m files of system.rdb
- Theoretical compatibility with Atelier Ryza and OPPW4 (only the parser/save code and the xml tool have been tested and validated, that usually means the other tools will work too) (Note: this only applies to g1m, not to g1a)
- Theoretical compatibility with .g1m that use platforms other than PC/DX11. (Only tested in the ancient .g1m of system.rdb, which for whatever reason have DX9 as platform) Note: only little endian platforms are supported.
- g1m_hide wasn't updated in 1.1, and as result, it couldn't handle SNK_HAIR_001.g1m (now it does)
- Multiple changes to the .g1m.xml format (Note: the new format is not compatible with that of the previous version, and viceversa). Some of the most relevant:
  * Several previously unknown values in <G1MF> now have name, and they are also auto-calculated by the program when auto=true.
  * "num_ib" field in <G1MF> renamed as "num_layout_refs" as some unusual files of OPPW4 have proved that this is actually the real meaning of the field.
  * The data in MaterialAttributes is now presented in a better fashion, and the param that had the size is omitted now, as it can be calculated by the program.
  * NUNO/NUNV sections are now parsed, instead of just writing the binary.
  * Several fields in <Submesh> have been renamed. "U_00" has been remamed as "Flags" (and now defautls to being printed in hexadecimal), "U_0C" has been renamed as "Matpalid",
    "Material" renamed to "Attribute", "Texture" renamed to "Material" (sorry if this causes confusion)
  * MeshesSection is now divided in LodGroups before being divided in meshes (in DOA6, there is only one LodGroup, but this is for compatibility with other games).
  * Count1 and Count2 in Meshes section can now be auto-calculated by the program when auto = "true" in the MeshesSection (default in most files). When auto = true, the modder can forget about Count1 and Count2, and the program will also reorder meshes if needed.
  * Other changes in <Mesh>: "Type" has been renamed as "Shader", and the program will know print as comment the name of the shader that matches the hash.
    Previous named field "U_10" has been splitted into "Type" and "U_12", where "Type" will now use constants instead of number (like "normal", "soft", "physics1", etc)
    "Nun_ID" renamed as "External_Section_ID", as it is more accurate (e.g., for "soft" meshes, the ID is the one used in SOFT section, instead of NUNO/NUNV)
  * There are probably some other changes in the .xml that I forgot to put in the list.

 

----------------

 

So I have been looking at the cloth thing again (what people call "4D" meshes). These are the meshes that in new xml would appear as "physics1".

The more I look to it, the less likely I see of being able to achieve something to import an arbitrary mesh (like that from another game) into these. The process to convert these into a normal 3d mesh is known, but the reverse process... I have no idea about how, from vertex positions, I would generate all the other data.

 

I'm afraid that proper cloth import will require someone with more knowledge about these things.

HOWEVER, I think that "limited import" may be possible. In this limited import, only the following kind of things could be done:

 

- Removing vertex or polygons.

- Change UV.

 

The moment you add a vertex, or transform a vertex in such a way that its position change, bye bye to the edit.

 

I think, that at least things like destroyed skirts/dresses could be implemented with this limited cloth import (which atm only exists in my mind, I would have to implement it and see if the thing works).

So, would you be interested at least in this kind of limited cloth edit?

[fgh1t6]

1 hour ago, vagonumero13 said:

I'm afraid that proper cloth import will require someone with more knowledge about these things.

HOWEVER, I think that "limited import" may be possible. In this limited import, only the following kind of things could be done:

 

- Removing vertex or polygons.

- Change UV.

 

The moment you add a vertex, or transform a vertex in such a way that its position change, bye bye to the edit.

 

I think, that at least things like destroyed skirts/dresses could be implemented with this limited cloth import (which atm only exists in my mind, I would have to implement it and see if the thing works).

So, would you be interested at least in this kind of limited cloth edit?

Yes, even only the changing of UV will be very helpful, because that means UV can be moved to fit textures from other costumes .   

[Joschuka]

If that can help a member of the FETH modding community has been working on the G1MF section lately https://github.com/three-houses-research-team/010-binary-templates/blob/master/Model related formats/G1M/G1MF.bt

I don't know how much you have figured out about that section but we may have some stuff you don't know yet, like that G1MS section count or other stupid stuff cause in FETH they have 3 exact copies of the same skeleton.

 

Yeah these NUNO/NUNV/NUNS sections are really annoying. I confirmed using renderdoc that they use a vertex shader combined with these NUN sections and some semantics to reconstruct the cloth.

So it's something like cloth mesh vertices lying on the ground in some unusable shape -> driver nodes /control points positions are updated by the physics sim, probably involving these COLL sections  too -> vertices are reconstructed thanks to these nodes by the vertex shader using the GPU.

The actual vertex shader's byte code is a mess, Semory just copy pasted it in the gas machine as is. I tried to make it as compact as possible if you're interested, seem to work nicely with all these meshes https://github.com/Joschuka/fmt_g1m/blob/master/Noesis/plugins/python/fmt_g1m.py#L2553

For some reason NUNV and NUNS have never been updated ever from what I saw while NUNO is updated regularly.
NUNO0301 and NUNO0303 seem to be the only relevant chunks for meshes, it seems that NUNO0302 and NUNO0304 subchunks only contain physics params or something.

 

Interestingly enough Ryza's and DOA6 updates changed the NUNO struct a bit iirc. OPPW4 also introduced some new info in that section.

[vagonumero13]

1 hour ago, Joschuka said:

If that can help a member of the FETH modding community has been working on the G1MF section lately https://github.com/three-houses-research-team/010-binary-templates/blob/master/Model related formats/G1M/G1MF.bt

I don't know how much you have figured out about that section but we may have some stuff you don't know yet, like that G1MS section count or other stupid stuff cause in FETH they have 3 exact copies of the same skeleton.

 

Yeah these NUNO/NUNV/NUNS sections are really annoying. I confirmed using renderdoc that they use a vertex shader combined with these NUN sections and some semantics to reconstruct the cloth.

So it's something like cloth mesh vertices lying on the ground in some unusable shape -> driver nodes /control points positions are updated by the physics sim, probably involving these COLL sections  too -> vertices are reconstructed thanks to these nodes by the vertex shader using the GPU.

The actual vertex shader's byte code is a mess, Semory just copy pasted it in the gas machine as is. I tried to make it as compact as possible if you're interested, seem to work nicely with all these meshes https://github.com/Joschuka/fmt_g1m/blob/master/Noesis/plugins/python/fmt_g1m.py#L2553

For some reason NUNV and NUNS have never been updated ever from what I saw while NUNO is updated regularly.
NUNO0301 and NUNO0303 seem to be the only relevant chunks for meshes, it seems that NUNO0302 and NUNO0304 subchunks only contain physics params or something.

 

Interestingly enough Ryza's and DOA6 updates changed the NUNO struct a bit iirc. OPPW4 also introduced some new info in that section.

 

This is what I currently have of G1MF info:

 

Spoiler

struct PACKED G1MFData
{
    uint32_t signature;
    uint32_t version;
    uint32_t size;
    uint32_t unk_0C; // TODO
    uint32_t num_bones; // 0x10
    uint32_t unk_14; // TODO
    uint32_t num_matrix; // 0x18
    uint32_t unk_1C; // TODO (probably number of elements in section 1)
    uint32_t num_materials; // 0x20
    uint32_t num_material_attributes; // 0x24
    uint32_t num_attributes; // 0x28
    uint32_t unk_2C; // TODO
    uint32_t unk_30; // TODO
    uint32_t num_vb; // 0x34
    uint32_t num_layouts; // 0x38
    uint32_t num_layout_refs; // 0x3C  Note: We used to think this was num_ib, but 0x0140e596.g1m from OPPW4 proved otherwise
    uint32_t num_bone_maps;  // 0x40
    uint32_t num_individual_bone_maps; // 0x44
    uint32_t num_non_shared_vb; // 0x48
    uint32_t num_submeshes; // 0x4C
    uint32_t num_submeshes2; // 0x50
    uint32_t unk_54; // TODO
    uint32_t num_meshes; // 0x58
    uint32_t num_submeshes_in_meshes; // 0x5C
    uint32_t unk_60; // TODO (coll related)
    uint32_t unk_64; // TODO (coll related)
    uint32_t num_nuno2s; // TODO
    uint32_t unk_6C; // TODO
    uint32_t num_nuno2s_unk11; // 0x70
    uint32_t num_nuno1s; // 0x74
    uint32_t num_nuno1s_unk4; // 0x78
    uint32_t num_nuno1s_control_points; // 0x7C
    uint32_t num_nuno1s_unk1; // 0x80
    uint32_t num_nuno1s_unk2_and_unk3; // 0x84
    uint32_t bones_id_size; // 0x88
    uint32_t unk_8C; // TODO Probably related with the EXTR section
    // If version > 21
    uint32_t num_nunv1s; // 0x90
    uint32_t num_nunv1s_unk4; // 0x94
    uint32_t num_nunv1s_control_points; // 0x98
    uint32_t num_nunv1s_unk1; // 0x9C
    uint32_t unk_A0; // TODO
    uint32_t unk_A4; // TODO
    uint32_t unk_A8; // TODO
    uint32_t unk_AC; // TODO
    uint32_t unk_B0; // TODO
    uint32_t unk_B4; // TODO
    uint32_t unk_B8; // TODO
    uint32_t unk_BC; // TODO
    uint32_t unk_C0; // TODO
    uint32_t unk_C4; // TODO
    uint32_t unk_C8; // TODO
    // If version > 23
    uint32_t unk_CC; // TODO
    uint32_t unk_D0; // TODO probably related with SOFT
    uint32_t unk_D4; // TODO
    uint32_t unk_D8; // TODO
    uint32_t unk_DC; // TODO
    uint32_t unk_E0; // TODO
    uint32_t unk_E4; // TODO
    uint32_t unk_E8; // TODO probably related with SOFT
    uint32_t unk_EC; // TODO
    uint32_t num_nuno3s; // 0xF0
    uint32_t num_nuno3s_unk4; // 0xF4
    uint32_t num_nuno3s_control_points; // 0xF8
    uint32_t num_nuno3s_unk1; // 0xFC
    uint32_t unk_100; // TODO
    uint32_t unk_104; // TODO
    uint32_t unk_108; // TODO
    // If version >= 26
    uint32_t unk_10C; // TODO
    uint32_t unk_110; // TODO
    // If version >= 27
    uint32_t num_nuno4s; // 0x114
    uint32_t num_nuno4s_unk7; // 0x118 Note: because number of unk7 and unk10 match, we don't know for sure which is which
    uint32_t num_nuno4s_unk8; // 0x11C
    uint32_t num_nuno4s_unk9; // 0x120
    uint32_t num_nuno4s_unk10; // 0x124
    uint32_t unk_128; // TODO
    // If version >= 29
    uint32_t unk_12C;
    // If version >= 30
    uint32_t unk_130[22]; // TODO
};

CHECK_STRUCT_SIZE(G1MFData, 0x188); // Currently updated for version 33 (OPPW4)

 

Apparently version 33 added a lot of data in the G1MF (0x40 bytes more than version 31, those are 16 new variables), but I haven't noticed any new chunk in OPPW4, which is the only game where I found that version.

 

I saw your nuno code, in concrete the part where those 3 vectors, a, b, c are calculated, and then with that and the data that is stored in the fourth component of normals, the position is calculated. It doesn't seem like something that would be easy to reverse, e.g. from the position, reconstruct all that data.

 

I noticed too the changes from version 29 to 30 in some nuno structures, in concrete the most changed part was Nuno4. I don't know what this Nuno4 is for, but I have noticed it being used in meshes that use the physics type 2.

[Delphinium12]

my use DOA6 v1.14 what v should use?

[Joschuka]

10 hours ago, vagonumero13 said:

 

This is what I currently have of G1MF info:

 

  Reveal hidden contents

struct PACKED G1MFData
{
    uint32_t signature;
    uint32_t version;
    uint32_t size;
    uint32_t unk_0C; // TODO
    uint32_t num_bones; // 0x10
    uint32_t unk_14; // TODO
    uint32_t num_matrix; // 0x18
    uint32_t unk_1C; // TODO (probably number of elements in section 1)
    uint32_t num_materials; // 0x20
    uint32_t num_material_attributes; // 0x24
    uint32_t num_attributes; // 0x28
    uint32_t unk_2C; // TODO
    uint32_t unk_30; // TODO
    uint32_t num_vb; // 0x34
    uint32_t num_layouts; // 0x38
    uint32_t num_layout_refs; // 0x3C  Note: We used to think this was num_ib, but 0x0140e596.g1m from OPPW4 proved otherwise
    uint32_t num_bone_maps;  // 0x40
    uint32_t num_individual_bone_maps; // 0x44
    uint32_t num_non_shared_vb; // 0x48
    uint32_t num_submeshes; // 0x4C
    uint32_t num_submeshes2; // 0x50
    uint32_t unk_54; // TODO
    uint32_t num_meshes; // 0x58
    uint32_t num_submeshes_in_meshes; // 0x5C
    uint32_t unk_60; // TODO (coll related)
    uint32_t unk_64; // TODO (coll related)
    uint32_t num_nuno2s; // TODO
    uint32_t unk_6C; // TODO
    uint32_t num_nuno2s_unk11; // 0x70
    uint32_t num_nuno1s; // 0x74
    uint32_t num_nuno1s_unk4; // 0x78
    uint32_t num_nuno1s_control_points; // 0x7C
    uint32_t num_nuno1s_unk1; // 0x80
    uint32_t num_nuno1s_unk2_and_unk3; // 0x84
    uint32_t bones_id_size; // 0x88
    uint32_t unk_8C; // TODO Probably related with the EXTR section
    // If version > 21
    uint32_t num_nunv1s; // 0x90
    uint32_t num_nunv1s_unk4; // 0x94
    uint32_t num_nunv1s_control_points; // 0x98
    uint32_t num_nunv1s_unk1; // 0x9C
    uint32_t unk_A0; // TODO
    uint32_t unk_A4; // TODO
    uint32_t unk_A8; // TODO
    uint32_t unk_AC; // TODO
    uint32_t unk_B0; // TODO
    uint32_t unk_B4; // TODO
    uint32_t unk_B8; // TODO
    uint32_t unk_BC; // TODO
    uint32_t unk_C0; // TODO
    uint32_t unk_C4; // TODO
    uint32_t unk_C8; // TODO
    // If version > 23
    uint32_t unk_CC; // TODO
    uint32_t unk_D0; // TODO probably related with SOFT
    uint32_t unk_D4; // TODO
    uint32_t unk_D8; // TODO
    uint32_t unk_DC; // TODO
    uint32_t unk_E0; // TODO
    uint32_t unk_E4; // TODO
    uint32_t unk_E8; // TODO probably related with SOFT
    uint32_t unk_EC; // TODO
    uint32_t num_nuno3s; // 0xF0
    uint32_t num_nuno3s_unk4; // 0xF4
    uint32_t num_nuno3s_control_points; // 0xF8
    uint32_t num_nuno3s_unk1; // 0xFC
    uint32_t unk_100; // TODO
    uint32_t unk_104; // TODO
    uint32_t unk_108; // TODO
    // If version >= 26
    uint32_t unk_10C; // TODO
    uint32_t unk_110; // TODO
    // If version >= 27
    uint32_t num_nuno4s; // 0x114
    uint32_t num_nuno4s_unk7; // 0x118 Note: because number of unk7 and unk10 match, we don't know for sure which is which
    uint32_t num_nuno4s_unk8; // 0x11C
    uint32_t num_nuno4s_unk9; // 0x120
    uint32_t num_nuno4s_unk10; // 0x124
    uint32_t unk_128; // TODO
    // If version >= 29
    uint32_t unk_12C;
    // If version >= 30
    uint32_t unk_130[22]; // TODO
};

CHECK_STRUCT_SIZE(G1MFData, 0x188); // Currently updated for version 33 (OPPW4)

 

Apparently version 33 added a lot of data in the G1MF (0x40 bytes more than version 31, those are 16 new variables), but I haven't noticed any new chunk in OPPW4, which is the only game where I found that version.

 

I saw your nuno code, in concrete the part where those 3 vectors, a, b, c are calculated, and then with that and the data that is stored in the fourth component of normals, the position is calculated. It doesn't seem like something that would be easy to reverse, e.g. from the position, reconstruct all that data.

 

I noticed too the changes from version 29 to 30 in some nuno structures, in concrete the most changed part was Nuno4. I don't know what this Nuno4 is for, but I have noticed it being used in meshes that use the physics type 2.

Ah I didn't see that since I don't bother about G1MF myself that much. But I think the only single change I saw with OPPW4 when I added support was the upgrade to NUNO v32, which added some new stuff in NUNO so that's probably related.

Also in OPPW4 they introduced a new animation type that renders incorrectly, it's parsed perfectly fine like the others though : all animations with 3 digits in their names don't work correctly, while the others (most of them) work as expected. I guess they must be additive animations or something but I didn't really look into it yet.

 

 

Just saw your update in more details btw, that's interesting to see that SOFT sections seem to be quite similar to NUN stuff, with an ID in the Mesh section and all that.

[Delphinium12]

when i press f it dont do nothing.

[fgh1t6]

4 hours ago, Delphinium12 said:

when i press f it dont do nothing.

Can run, no error,  means you are using the right version.  You need to know which slot your mod is using and go to the selection slot then push F

[fgh1t6]

17 hours ago, vagonumero13 said:

 

This is what I currently have of G1MF info:

 

  Reveal hidden contents

struct PACKED G1MFData
{
    uint32_t signature;
    uint32_t version;
    uint32_t size;
    uint32_t unk_0C; // TODO
    uint32_t num_bones; // 0x10
    uint32_t unk_14; // TODO
    uint32_t num_matrix; // 0x18
    uint32_t unk_1C; // TODO (probably number of elements in section 1)
    uint32_t num_materials; // 0x20
    uint32_t num_material_attributes; // 0x24
    uint32_t num_attributes; // 0x28
    uint32_t unk_2C; // TODO
    uint32_t unk_30; // TODO
    uint32_t num_vb; // 0x34
    uint32_t num_layouts; // 0x38
    uint32_t num_layout_refs; // 0x3C  Note: We used to think this was num_ib, but 0x0140e596.g1m from OPPW4 proved otherwise
    uint32_t num_bone_maps;  // 0x40
    uint32_t num_individual_bone_maps; // 0x44
    uint32_t num_non_shared_vb; // 0x48
    uint32_t num_submeshes; // 0x4C
    uint32_t num_submeshes2; // 0x50
    uint32_t unk_54; // TODO
    uint32_t num_meshes; // 0x58
    uint32_t num_submeshes_in_meshes; // 0x5C
    uint32_t unk_60; // TODO (coll related)
    uint32_t unk_64; // TODO (coll related)
    uint32_t num_nuno2s; // TODO
    uint32_t unk_6C; // TODO
    uint32_t num_nuno2s_unk11; // 0x70
    uint32_t num_nuno1s; // 0x74
    uint32_t num_nuno1s_unk4; // 0x78
    uint32_t num_nuno1s_control_points; // 0x7C
    uint32_t num_nuno1s_unk1; // 0x80
    uint32_t num_nuno1s_unk2_and_unk3; // 0x84
    uint32_t bones_id_size; // 0x88
    uint32_t unk_8C; // TODO Probably related with the EXTR section
    // If version > 21
    uint32_t num_nunv1s; // 0x90
    uint32_t num_nunv1s_unk4; // 0x94
    uint32_t num_nunv1s_control_points; // 0x98
    uint32_t num_nunv1s_unk1; // 0x9C
    uint32_t unk_A0; // TODO
    uint32_t unk_A4; // TODO
    uint32_t unk_A8; // TODO
    uint32_t unk_AC; // TODO
    uint32_t unk_B0; // TODO
    uint32_t unk_B4; // TODO
    uint32_t unk_B8; // TODO
    uint32_t unk_BC; // TODO
    uint32_t unk_C0; // TODO
    uint32_t unk_C4; // TODO
    uint32_t unk_C8; // TODO
    // If version > 23
    uint32_t unk_CC; // TODO
    uint32_t unk_D0; // TODO probably related with SOFT
    uint32_t unk_D4; // TODO
    uint32_t unk_D8; // TODO
    uint32_t unk_DC; // TODO
    uint32_t unk_E0; // TODO
    uint32_t unk_E4; // TODO
    uint32_t unk_E8; // TODO probably related with SOFT
    uint32_t unk_EC; // TODO
    uint32_t num_nuno3s; // 0xF0
    uint32_t num_nuno3s_unk4; // 0xF4
    uint32_t num_nuno3s_control_points; // 0xF8
    uint32_t num_nuno3s_unk1; // 0xFC
    uint32_t unk_100; // TODO
    uint32_t unk_104; // TODO
    uint32_t unk_108; // TODO
    // If version >= 26
    uint32_t unk_10C; // TODO
    uint32_t unk_110; // TODO
    // If version >= 27
    uint32_t num_nuno4s; // 0x114
    uint32_t num_nuno4s_unk7; // 0x118 Note: because number of unk7 and unk10 match, we don't know for sure which is which
    uint32_t num_nuno4s_unk8; // 0x11C
    uint32_t num_nuno4s_unk9; // 0x120
    uint32_t num_nuno4s_unk10; // 0x124
    uint32_t unk_128; // TODO
    // If version >= 29
    uint32_t unk_12C;
    // If version >= 30
    uint32_t unk_130[22]; // TODO
};

CHECK_STRUCT_SIZE(G1MFData, 0x188); // Currently updated for version 33 (OPPW4)

 

Apparently version 33 added a lot of data in the G1MF (0x40 bytes more than version 31, those are 16 new variables), but I haven't noticed any new chunk in OPPW4, which is the only game where I found that version.

 

I saw your nuno code, in concrete the part where those 3 vectors, a, b, c are calculated, and then with that and the data that is stored in the fourth component of normals, the position is calculated. It doesn't seem like something that would be easy to reverse, e.g. from the position, reconstruct all that data.

 

I noticed too the changes from version 29 to 30 in some nuno structures, in concrete the most changed part was Nuno4. I don't know what this Nuno4 is for, but I have noticed it being used in meshes that use the physics type 2.

 

I tried to replace the NUNO and NUNV block in a g1m file with same character g1m file using the g1m_xml tool, but Game crashed.

I tried to replace the soft body binary 0.soft only, but game also crashed. 

Is there some settings in the G1MF  I need to be changed manually even using auto="true" in the  <G1MF version="29" auto="true"> block?

[fgh1t6]

6 hours ago, Joschuka said:

Ah I didn't see that since I don't bother about G1MF myself that much. But I think the only single change I saw with OPPW4 when I added support was the upgrade to NUNO v32, which added some new stuff in NUNO so that's probably related.

Also in OPPW4 they introduced a new animation type that renders incorrectly, it's parsed perfectly fine like the others though : all animations with 3 digits in their names don't work correctly, while the others (most of them) work as expected. I guess they must be additive animations or something but I didn't really look into it yet.

 

 

Just saw your update in more details btw, that's interesting to see that SOFT sections seem to be quite similar to NUN stuff, with an ID in the Mesh section and all that.

 Would you have any information about the g1s file? There are so many of them, I feel like they have packed the whole library into DOA6. I means these files may have been used in other games too.

[Delphinium12]

32 minutes ago, fgh1t6 said:

Can run, no error,  means you are using the right version.  You need to know which slot your mod is using and go to the selection slot then push F

i have delete the Layer2.xml and workarounds.xml so it wll work.

the error was faild to apply "layer:patchMRCWL"

if im using wrong version of REDELBE

my DOA6 version 1.14.

[vagonumero13]

3 minutes ago, Delphinium12 said:

i have delete the Layer2.xml and workarounds.xml so it wll work.

the error was faild to apply "layer:patchMRCWL"

if im using wrong version of REDELBE

my DOA6 version 1.14.

 

Without that file, layer2 will not work. Current version of REDELBE only works with 1.22. Maybe with 1.21 or 1.20, but not lower than that.

[Delphinium12]

thanks

 

[vagonumero13]

40 minutes ago, fgh1t6 said:

 

I tried to replace the NUNO and NUNV block in a g1m file with same character g1m file using the g1m_xml tool, but Game crashed.

I tried to replace the soft body binary 0.soft only, but game also crashed. 

Is there some settings in the G1MF  I need to be changed manually even using auto="true" in the  <G1MF version="29" auto="true"> block?

I don't know yet about the remaining fields of the G1MF, if they are related to these section or not. But have in mind that the ids used in the meshes section must exist as "idx" in the nuno/nunv (sometimes you will see the ids being over 10000 or over 20000, I have yet to look at what the game does exactly with that, but at the moment just consider the lower part of the id).

[Joschuka]

45 minutes ago, fgh1t6 said:

 

I tried to replace the NUNO and NUNV block in a g1m file with same character g1m file using the g1m_xml tool, but Game crashed.

I tried to replace the soft body binary 0.soft only, but game also crashed. 

Is there some settings in the G1MF  I need to be changed manually even using auto="true" in the  <G1MF version="29" auto="true"> block?

Yeah it's not trivial to mess with these sections unless you have some good knowledge about the format. There are a lot of dependent sections. In your case it probably comes from the indices in the Mesh section.

 

38 minutes ago, fgh1t6 said:

 Would you have any information about the g1s file? There are so many of them, I feel like they have packed the whole library into DOA6. I means these files may have been used in other games too.

I only know that there are g1s and g2s files and that they're related to these names in the Mesh section but I didn't look into them.

 

8 minutes ago, vagonumero13 said:

I don't know yet about the remaining fields of the G1MF, if they are related to these section or not. But have in mind that the ids used in the meshes section must exist as "idx" in the nuno/nunv (sometimes you will see the ids being over 10000 or over 20000, I have yet to look at what the game does exactly with that, but at the moment just consider the lower part of the id).

With trial and error I came to the conclusion that for clothType1 stuff the ID in section 9 is

integer for NUNO0301
10 000 + integer for NUNV0501
20 000 + integer for NUNO0303

 

This is how I made it work on all the KT games , not 100% sure if the game uses it like that though but so far it worked on pretty much all KT games.

 

 

[vagonumero13]

27 minutes ago, Joschuka said:

Yeah it's not trivial to mess with these sections unless you have some good knowledge about the format. There are a lot of dependent sections. In your case it probably comes from the indices in the Mesh section.

 

I only know that there are g1s and g2s files and that they're related to these names in the Mesh section but I didn't look into them.

 

With trial and error I came to the conclusion that for clothType1 stuff the ID in section 9 is

integer for NUNO0301
10 000 + integer for NUNV0501
20 000 + integer for NUNO0303

 

This is how I made it work on all the KT games , not 100% sure if the game uses it like that though but so far it worked on pretty much all KT games.

 

 

 

I have located the part of the game that checks for these 10000 and 20000 numbers. I have plans in the future to do some tool that allows to copy a mesh or a submesh from a .g1m into other (will probably give variated resutls depending of the source/dest). When I do that, I will debug that code and check what the game exactly does there, since I will be needing it when copying cloths and "ponytails".