Modding with GFDM old series will not work properly

[JamesLewisLiu]

Though unpack is working now, modding textures is not working properly while I'm downloading remaining games' data , with modded texture game will blank out on modded textures like this This is unpacked and converted with gitadora-texbintool.exe data And I mod like this Here's two logs ifs_hook_unpkfs_and_mod.log ifs_hook.log

[mon]

Can you send both the original tex_gf_game2.bin as well as ./data_mods/_cache/product/d3/model/tex_gf_game2.bin

[JamesLewisLiu]

_cached _cached.zip unpacked unpacked one.zip

[mon]

I'm starting to build an idea as to what causes this. If you repack using gitadora-texbintool (instead of letting layeredfs do it) does it still break?

[JamesLewisLiu]

Tried using bin as mod directly and still no luck Here's log ifs_hook.log

[mon]

And what is the expected result here? The image spans the entire screen?

[JamesLewisLiu]

Sorry for late reply Different stages have different backgrounds(and two PREMIUM ENCORE have two special one), I just want to test change every background to the A.DOGMA Special one as the following video shows https://github.com/mon/ifs_layeredfs/assets/17558260/b5ef13d9-4571-428d-ad6e-5cda7dd98b31 And with the testmod applying now not only the background but also almost every texture blank out as this screenshot shows

[JamesLewisLiu]

Today I was wondering is modding XG possible and I test with a BGA first, it works fine like this Then I tried pick a random texture and mod it however the game seems don't like it and return a HDD Game Error like this Here's log ifs_hook.log Here's texture file texture.zip

[mon]

I'm continuing to look into this, and I think I might have a reason for the crashes. Just to confirm some things:

Tried using bin as mod directly and still no luck

This was repacked using gitadora-texbintool? If so, then I have a bit of work to do to fix this😅

[mon]

If possible, for your HDD ERROR case, please send the original + modded .bin files for me to inspect. If they show the same pattern as the other non-working file, then I know what to try.

[JamesLewisLiu]

This was repacked using gitadora-texbintool? If so, then I have a bit of work to do to fix this😅

Yes, I don't know if there are any other tools to do that thing.

If possible, for your HDD ERROR case, please send the original + modded .bin files for me to inspect. If they show the same pattern as the other non-working file, then I know what to try.

Since it's been a while I test both V5 and XG again and here is my mod and log files, hope these can help you btw I watched it for a while and the XG1 instantly reported that error when ifs_layeredfs tried loading mod files V5.zip XG1.zip

[mon]

Oh dear, my pattern was wrong... I was thinking "maybe it's DXT5 compression instead of BGRA", but the XG1 file looks practically identical:

Though, since V5 doesn't HDD ERROR but instead just has a black image, DXT5 might help there as well. But it's a bit more effort, so I want to solve XG1 first.

Please give XG1 another launch with this version (always_devmode_verbose_and_logs_to_file_and_pkfs_unpack) - it won't fix anything, but it'll make some more logs around failed calls to pkfs_open, which I think might be the reason for the HDD ERROR (it's something I fixed in jubeat recently). ifs_layeredfs_3.4_RC3.zip

Also thank you for your continued assistance, I really appreciate it!

[JamesLewisLiu]

It still reports HDD READ ERROR, here's log ifs_hook.log

[mon]

Well, this is exactly the log I needed!

M:pkfs_fs_open(./data_mods/_cache/product/d3/model/tex_gf_common.bin) failed in call_real

...unfortunately, debugging this is going to be tricky. This type of call has never failed before. I can't actually find a copy of Gitadora XG. I will ask around.

[mon]

Oh, I think I finally remembered what was causing this... The same issue happens with gfdm 5...

Old GFDM uses launcherx/gfdmhook, which isn't as polished as mainline bemanitools/spice, so this hasn't been fixed yet. It has an issue where it uses the "wrong" working directory, because the game has folders structured as so:

bin/
  data_mods/ <- Possible location 1
  ...
data/
  ...
data_mods/ <- Possible location 2
  ...

When layeredfs tries to access a file, it can only see files in bin/, as that's where the exe is run from, so it needs to be in "Possible location 1". But when the game's pkfs layer tries to open a file, it looks in the top level, i.e. "Possible location 2".

As far as I can tell based on newer games, the "correct" way is to have the working dir set at the toplevel, and launch modules from there, instead of retargeting the filesystem. It then also requires intercepting avs_boot and changing the value of /config/fs/root/device from ../ to ./. bemanitools already does this for iidxhook4, iidxhook5, and jbhook1.

To fix it for now

• Move all of the game files out of bin and into the same folder as data and data_mods
• Edit boot.dll to change the working dir from ../ to ./

I can't think of a clean way to fix this in layeredfs. Will take any suggestions.

[JamesLewisLiu]

Well the gfdmhook have not been update for 5 years So I use mklink /J ..\data_mods data_mods to create a directory junction and now it works fine Since this game is not that popular may be this can be a workaround

[mon]

Do you think an addition to the README would be enough? I think if I'm clever I can probably write some sort of "is the filesystem a bit funky" test, but it might be a little work.

[JamesLewisLiu]

Do you think an addition to the README would be enough? I think if I'm clever I can probably write some sort of "is the filesystem a bit funky" test, but it might be a little work.

I think thats' enough but with a big WARNING, filesystem link is quite tricky and may cause data loss.

[JamesLewisLiu]

Just wonder maybe V4-V8 have same "wrong" directory issue and I create a link in V5 like before and it works

[mon]

I've released 3.4, and added information about the path remapping to the README. I hope that this closes this issue!