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

[Jomiu]

5 minutes ago, Aurora Rain said:

neither of you are helpful right now.

use baidu

[Jomiu]

its much better than google

 

https://www.baidu.com/

 

 

[Aurora Rain]

37 minutes ago, Jomiu said:

its much better than google

 

https://www.baidu.com/

 

 

I don't have access to download from any of the Chinese sites
https://bbs.3dmgame.com/forum.php?mod=viewthread&tid=5911445

It doesn't matter anyway because it's still the same version number.
There is no g1mtools_0.8 version yet

Please stop trolling

[vagonumero13]

4 hours ago, Aurora Rain said:

@vagonumero13 thank you so much for your hard work.
I have a request that I think will serve a lot of people if it's possible.

Will you please explore a method to extract animation data from the g2a files, to be made importable into blender?
Ideally, so that it's possible to inject the animation back into the g2a file after being edited.

 

It's something that I want to do eventually, but I am a bit busy right now. Anyway, when the time arrives, I may need the help of an animator to create a test animation, before implementing injection code. But of course, the first thing to do is the extraction code.

 

IIrc, I had already deduced the basic info of g1a files, even if I forgot everything, but I wrote it somewhere here, so whenever I work on that, I should continue from there.

[Aurora Rain]

1 hour ago, vagonumero13 said:

 

It's something that I want to do eventually, but I am a bit busy right now. Anyway, when the time arrives, I may need the help of an animator to create a test animation, before implementing injection code. But of course, the first thing to do is the extraction code.

 

IIrc, I had already deduced the basic info of g1a files, even if I forgot everything, but I wrote it somewhere here, so whenever I work on that, I should continue from there.

That's good news, when that time comes, you'll have my assistance

Also could you take a look at Ayane's COS_32.g1m

When importing 7.vb into blender, then injected back into the g1m file, it creates an exploding mesh bug.
The very same process works fine for 5.vb and 6.vb without any issue.

[fgh1t6]

14 minutes ago, Aurora Rain said:

That's good news, when that time comes, you'll have my assistance

Also could you take a look at Ayane's COS_32.g1m

When importing 7.vb into blender, then injected back into the g1m file, it creates an exploding mesh bug.
The very same process works fine for 5.vb and 6.vb without any issue.

Did you try delete all the loose vertices? I notice that if meshes share a common VB, all meshes need to be exported from blend and then import back to g1m. But deleting all the loose vertices in a mesh seems will force g1m_tool to write an independent VB for it. 

[Aurora Rain]

2 hours ago, fgh1t6 said:

Did you try delete all the loose vertices? I notice that if meshes share a common VB, all meshes need to be exported from blend and then import back to g1m. But deleting all the loose vertices in a mesh seems will force g1m_tool to write an independent VB for it. 

Yes, I have, I still get starfish mesh explosion

[DD JJ]

 

WTF, I am installing this and keep getting "Failed to apply patch Layer2:PatchBGC"

What's the matter?

 

[Haruhi_Hirano]

ok i know im kinda late to this but, i just found out recently you can use rebelde to turn off the censor so u can actually punch marie, honoka, nico and kula in the face. how do i activate that?

[aiuroscar]

@vagonumero13

Thank you for the great work with the modding tools. I'm having a bit of a strange issue with the random selection, not sure if anyone else has encountered this but it's only started happening recently. I have the random options set to true in the ini file and this was previously working great. However, i've recently added a bunch of different mods to layer2 and have noticed that i'm no longer getting any of the modded outfits being selected by the CPU. Random stages and hairstyles seem to be fine but no outfits.

 

As an example I was in survival mode and went 50 rounds with zero modded outfits, in addition to that I ran through arcade 4 times and still none. It could potentially just be bad luck but it seems the odds of that must be so slim. It seems to have started after adding a bunch of additional outfits over the past 2 days, as an example I have 476 folders in layer2 including stages. I'm wondering if over a certain threshold it breaks the random selection? Would love to know your thoughts. 

 

Not a huge issue but thought it would be worth mentioning because I couldn't see this being discussed anywhere.

 

Thanks again for the hard work.

[vagonumero13]

25 minutes ago, aiuroscar said:

@vagonumero13

Thank you for the great work with the modding tools. I'm having a bit of a strange issue with the random selection, not sure if anyone else has encountered this but it's only started happening recently. I have the random options set to true in the ini file and this was previously working great. However, i've recently added a bunch of different mods to layer2 and have noticed that i'm no longer getting any of the modded outfits being selected by the CPU. Random stages and hairstyles seem to be fine but no outfits.

 

As an example I was in survival mode and went 50 rounds with zero modded outfits, in addition to that I ran through arcade 4 times and still none. It could potentially just be bad luck but it seems the odds of that must be so slim. It seems to have started after adding a bunch of additional outfits over the past 2 days, as an example I have 476 folders in layer2 including stages. I'm wondering if over a certain threshold it breaks the random selection? Would love to know your thoughts. 

 

Not a huge issue but thought it would be worth mentioning because I couldn't see this being discussed anywhere.

 

Thanks again for the hard work.

 

I haven't noticed a bug in the costume selection. Technically, there is not limit, as I use dynamic containers, except limitsimposed by the variables size, but those are in the order of either 2^64 or 2^32, so nothing to be worried about.

 

The only known bug regarding random is one that specifically affects the boss stage (which cannot be selected randomly), but that one will be fixed in next version of REDELBE.

Check again if you are using latest REDELBE version (1.3), and check again the ini just in case (enable_random_costume_mods = true). You may have installed some mod that included a older version of REDELBE, that caused a downgrade of REDELBE or a fallback of the ini, so it is better to re-check.

 

If the error persists, I will prepare you some special REDELBE version with some debug strings for the log, so that we can see what's hapenning.

 

[sillv]

On 9/29/2019 at 11:13 PM, Haruhi_Hirano said:

ok i know im kinda late to this but, i just found out recently you can use rebelde to turn off the censor so u can actually punch marie, honoka, nico and kula in the face. how do i activate that?

Go into the REDELBE folder and open the redelbe.ini file. Make sure this line is set to true:

 

uncensor_loli_blow = true

[Aurora Rain]

@vagonumero13 Hello g1m_import is unable to handle, Ayane_COS_32
The vertex/index buffer 7.vb still breaks into a starfish, the other meshes don't do this.


The same export method works fine for other meshes, but 7.vb is causing trouble, I don't know if there are any others that have this issue because I haven't tested every single one, but there's something not quite right about how 7.vb is being handled.

Also, each time I use the g1m_import to re-import 7.vb, the file size of the g1m keeps increasing.

[vagonumero13]

22 minutes ago, Aurora Rain said:

@vagonumero13 Hello g1m_import is unable to handle, Ayane_COS_32
The vertex/index buffer 7.vb still breaks into a starfish, the other meshes don't do this.


The same export method works fine for other meshes, but 7.vb is causing trouble, I don't know if there are any others that have this issue because I haven't tested every single one, but there's something not quite right about how 7.vb is being handled.

Also, each time I use the g1m_import to re-import 7.vb, the file size of the g1m keeps increasing.

 

Does it happen even if 7.vb is not changed at all?

And if so, does it happen only when being exported with .vgmap or does it happen even if vgmap are not present?

[Aurora Rain]

27 minutes ago, vagonumero13 said:

 

Does it happen even if 7.vb is not changed at all?

And if so, does it happen only when being exported with .vgmap or does it happen even if vgmap are not present?

Yes, 7.vb explodes even when completely unchanged.

It's always being exported with the .vgmap because I get an error message if I delete them before exporting.

[Loаdy]

2 hours ago, Aurora Rain said:

@vagonumero13 Hello g1m_import is unable to handle, Ayane_COS_32
The vertex/index buffer 7.vb still breaks into a starfish, the other meshes don't do this.


 

Thanks! Thanks! Thanks!

everybody thanks!

especially to Ayane

 

bye!

 

 

[vagonumero13]

5 hours ago, Aurora Rain said:

Yes, 7.vb explodes even when completely unchanged.

It's always being exported with the .vgmap because I get an error message if I delete them before exporting.

 

I have noticed is that 7 shares the vertex buffer with 8 and 9, this is why you see the file size increasing, in these cases, g1m_import leaves the original data alone, as that could be used by the other meshes that use the same vb, and instead adds to it. Destroying duplicate vertex of shared vb at finalization is something I want to add in the future, to reduce the file sizes in these cases.

 

I also noticed that when using g1m2fbx on the original .g1m, the issue can be seen in blender or any other .fbx previewer, so all this suggests the problem happens in the export, not on import (or it could be both). The problem seem to be blend indices / weights related. I'll research this more later, it is quite odd.

[Aurora Rain]

3 hours ago, vagonumero13 said:

 

I have noticed is that 7 shares the vertex buffer with 8 and 9, this is why you see the file size increasing, in these cases, g1m_import leaves the original data alone, as that could be used by the other meshes that use the same vb, and instead adds to it. Destroying duplicate vertex of shared vb at finalization is something I want to add in the future, to reduce the file sizes in these cases.

 

I also noticed that when using g1m2fbx on the original .g1m, the issue can be seen in blender or any other .fbx previewer, so all this suggests the problem happens in the export, not on import (or it could be both). The problem seem to be blend indices / weights related. I'll research this more later, it is quite odd.

Thank you, please keep us informed

[Aritt]

1 hour ago, Aurora Rain said:

Thank you, please keep us informed

Yes, we will try.

 

[vagonumero13]

3 hours ago, Aurora Rain said:

Thank you, please keep us informed

Well, it looks like before I was wrong, I probably tested the wrong g1m (the already corrupted one), as I tested again, and the fbx resulting from the original g1m looks fine, so I guess it is some problem in the import after all. And it is isn't just the blend thing, it is that g1m_import is writing the wrong vertex or wrong indexes, but I have yet to guess why.

 

EDIT: problem found. It is a 16 bits overflow. Because of those 3 big meshes that share the same vertex buffer, due to the inefficient code when importing, the new vertex buffer will basically triplicate its size. This will make the number of vertex go well beyond 65536 vertex. However, the index buffer is 16 bits, and cannot reference indexes >= 65536. G1m files support 8, 16, and 32 bits index buffers, but g1m import is not prepared to change the current existing index buffer format.

 

Anyway, by reviewing the code, I also discovered another unrelated bug, my code for importing index buffer of meshes that share vertex buffers... well, it was broken for 32 bits indexes. Luckily, not many .g1m file use 32 bits indexes, so that bug may have been unnoticed.

 

So, well, I will fix all of these in the following days: optimize the mesh to remove duplicates vertex, upgrade 16 bits index buffer to 32 bits index buffer if overflow detected, and fix the 32 bits index import code.

[gatto tom]

23 hours ago, Aurora Rain said:

@vagonumero13 Hello g1m_import is unable to handle, Ayane_COS_32
The vertex/index buffer 7.vb still breaks into a starfish, the other meshes don't do this.


The same export method works fine for other meshes, but 7.vb is causing trouble, I don't know if there are any others that have this issue because I haven't tested every single one, but there's something not quite right about how 7.vb is being handled.

Also, each time I use the g1m_import to re-import 7.vb, the file size of the g1m keeps increasing.

I had this same bug and I finally managed to fix it on my AYA_COS004a. What you need to do is: open your mod in blender and re-export every .vb mesh and then re-import your mod using .g1m_import and everything should be fixed

[gatto tom]

@vagonumero13 Is possible to force the .ktid to load a different texture using HxD?

The problem is that we don't know the correct order and those strings are encrypted. I took also a look to some previous .ktid but the order is always different. What I didn't look are the DLCs, maybe they follow always the same path

[vagonumero13]

11 minutes ago, gatto tom said:

@vagonumero13 Is possible to force the .ktid to load a different texture using HxD?

The problem is that we don't know the correct order and those strings are encrypted. I took also a look to some previous .ktid but the order is always different. What I didn't look are the DLCs, maybe they follow always the same path

 

I think but back when they were strings, it could be used to load a different texture, although the texture file had to be one that already exists in game (not a new file with a new path, because REDELBE will ignore that). You may try to swap the string hash with that of another ktid, and see if it loads that other texture.

 

1 hour ago, gatto tom said:

I had this same bug and I finally managed to fix it on my AYA_COS004a. What you need to do is: open your mod in blender and re-export every .vb mesh and then re-import your mod using .g1m_import and everything should be fixed

 

Well, that makes sense, when doind that, it is blender itself which is removing all unused vertex.

[TheRunawayNinja]

does anyone know the file name for kasumi's blue ribbon hairstyle? i cant find it lmao. thanks in advance!! 

[gatto tom]

2 hours ago, TheRunawayNinja said:

does anyone know the file name for kasumi's blue ribbon hairstyle? i cant find it lmao. thanks in advance!! 

KAS_HAIR_001

 

7 hours ago, vagonumero13 said:

 

I think but back when they were strings, it could be used to load a different texture, although the texture file had to be one that already exists in game (not a new file with a new path, because REDELBE will ignore that). You may try to swap the string hash with that of another ktid, and see if it loads that other texture.

I did a Morphing Mod using HTM_COS_031 and what I am doing it's trying to let stop loading kidsmm1 and kidsmm2 (or replacing them with kidsalb and kidsnmh)  from it. I did a test on HTM_COS_001, because i had the same issue but changing them to kidsalb and kidsnmh won't help. When i taunt this is the result: 

Spoiler

 

The Yellow color doesn't have kidsnmm1 and kidsnmm2, so i was trying to find a solution