PAK Emulator AddFile function indicating successful add without actually adding files

[BonQerss]

Hello

I've been attempting to use PAK Emu's AddFile function in a bit of a unique way with one of my code mods. I'm attempting to force add a custom GMO into a PAC file without a matching name. Suppose the player chooses a specific costume for a character. In that case, it loads their base gmo file (e.g., bc009.gmo) and, depending on the pac chosen for the default costume to replace (e.g., bc009_c6a.pac), it will then replace the gmo inside of said pac with the custom one, even if the name doesn't match. (e.g., bc009_c6.GMO)

The logs indicate that files have been successfully added, but when in-game, they do not show up, nor are they added to the route system via PAK Emu's GetEmulatorInput.

[13:30:50] [Reloaded] Loading: AIO Costumes
[13:30:50] [Reloaded] - AppId : p3ppc.aiocostumes
[13:30:50] [Reloaded] - Location: C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\ModConfig.json
[13:30:50] [DEBUG] PAK Emulator found and initialized successfully
[13:30:50] [DEBUG] PAK Emulator type: PakEmulatorApi
[13:30:50] [DEBUG] PAK Emulator has 4 route groups:
[13:30:50] [DEBUG] Route: init_free.bin\init
[13:30:50] [DEBUG] Route: init_free.bin\battle
[13:30:50] [DEBUG] Route: field2d\bg\b09_08.abin
[13:30:50] [DEBUG] Route: field2d\bg\b09_01.abin
[13:30:50] [DEBUG] Character: Makoto, Costume: Nahobino, BaseFile: bc001
[13:30:50] [DEBUG] SourceGMO: C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\Nahobino\Makoto\bc001.GMO
[13:30:50] [DEBUG] Variants: []
[13:30:50] [DEBUG] Processing variant: ''
[13:30:50] [DEBUG] Target PAC: bc001.pac, replacing internal GMO: bc001.GMO
[13:30:50] [DEBUG] Target aPAC: bc001a.pac, replacing internal GMO: bc001.GMO
[13:30:50] [PakBuilderFactory] Added file C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\Nahobino\Makoto\bc001.GMO with route model/pack/bc001.pac in pak path bc001.GMO
[13:30:50] [DEBUG] Added C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\Nahobino\Makoto\bc001.GMO to bc001.pac as bc001.GMO
[13:30:50] [DEBUG] Added C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\Nahobino\Makoto\bc001.GMO to bc001a.pac as bc001.GMO
[13:30:50] [DEBUG] Routes AFTER adding files: 4
[13:30:50] [PakBuilderFactory] Added file C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\Nahobino\Makoto\bc001.GMO with route model/pack/bc001a.pac in pak path bc001.GMO
[13:30:50] [DEBUG] Route after: init_free.bin\init
[13:30:50] [DEBUG] Route after: init_free.bin\battle
[13:30:50] [DEBUG] Route after: field2d\bg\b09_08.abin
[13:30:50] [DEBUG] Route after: field2d\bg\b09_01.abin
[13:30:50] [DEBUG] Costume loading completed. Total files should be added to PAK emulator.

I've been attempting to find instances in which the code is used by other mods, but after checking around forty GitHub repositories, the only mention I can find of the function is in the TBL merging code for P4G and P3P.

https://github.com/Sewer56/p5rpc.modloader/blob/master/p5rpc.modloader/Merging/Tbl/P4GTblMerger.cs#L93

Is it possible that I am using the code wrong? Is it bugged? I can't find any explanation of how it works on the wiki outside of the handful of words mentioned here:

https://github.com/Sewer56/FileEmulationFramework/blob/main/Emulator/Interfaces/PAK.Stream.Emulator.Interfaces/IPakEmulator.cs#L45

You can find my code here:

https://github.com/BonQerss/p3ppc.aiocostumes/blob/master/p3ppc.aiocostumes/Mod.cs#L506

[BonQerss]

Did more testing on my part. I can only assume the function is not working as intended. I've tried almost every possible option to get the files to load, and nothing works. AddFile is printing lines indicating successful additions of the files to the PACs as intended, yet not loading said modified files.

[12:46:15] [Reloaded] Loading: AIO Costumes
[12:46:15] [Reloaded] - AppId : p3ppc.aiocostumes
[12:46:15] [Reloaded] - Location: C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\ModConfig.json
[12:46:15] [DEBUG] PAK Emulator found and initialized successfully
[12:46:15] [DEBUG] PAK Emulator type: PakEmulatorApi
[12:46:15] [DEBUG] PAK Emulator has 0 route groups:
[12:46:15] [INFO] Looking for GMO file at: C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\Nahobino\Makoto\bc001.GMO
[12:46:15] [INFO] Found GMO file. Attempting to add variants for Makoto...
[12:46:15] [INFO] Adding to base PAC:
[12:46:15] Physical path: C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\Nahobino\Makoto\bc001.GMO
[12:46:15] Route: model\pack\bc001.pac
[12:46:15] Virtual path: bc001.GMO
[12:46:15] [PakBuilderFactory] Added file C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\Nahobino\Makoto\bc001.GMO with route model\pack\bc001.pac in pak path bc001.GMO
[12:46:15] [SUCCESS] Registered model\pack\bc001.pac
[12:46:15] [INFO] Adding to awakening PAC:
[12:46:15] Physical path: C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\Nahobino\Makoto\bc001.GMO
[12:46:15] Route: model\pack\bc001a.pac
[12:46:15] Virtual path: bc001.GMO
[12:46:15] [PakBuilderFactory] Added file C:\Users\airin\Downloads

The lack of any other mod using the function highly indicates to me that it's not working as intended.

If anyone has any other insight, please let me know. I am at my wits' end and cannot figure out the issue still.

[BonQerss]

@AnimatedSwine37 According to the commit history, you added the function's documentation. Any insight here? I'm beginning to suspect that AddFile just works like AddDirectory and instead only allows you to enable/disable a specific file from being merged.

[AnimatedSwine37]

I think the function should work fine but I don't really know tbh.

I'd guess that you probably just messed up the arguments to the function. The way the routes work in Pak emulator are a little funny iirc. It's easy to mess that stuff up.

I can try and have an actual look sometime soonish

[BonQerss]

I'd highly appreciate that, thank you. No rush either, of course. I still have to make a couple of dozen extra costumes for the mod.

[BonQerss]

Tried doing more research on what you mentioned about routes. Couldn't find any meaningful examples that applied to what I'm doing. It kinda seems like all the instances of routes seem to only be for files that have specific pathing inside of a PAC. There might be an issue attempting to bind a file to the root of a PAC? I'm not sure, just spitballing.

[AnimatedSwine37]

Ok, I had a look. It's a bug in PAK Emulator.

Persona Essentials is what actually causes emulated files to be built. On bind it goes through all of the inputs to each emulator and gives them the necessary base files to build the emulated ones from. The problem here is that currently PAK Emulator's GetEmulatorInput function only includes directory inputs, not individual files that are added through the AddFile method.

It was fairly easy to fix this and it does seem to work. I've got the updated code on a branch here but haven't made the pr just yet. Could you try it out and let me know if everything seems ok? I've also attached a build below

reloaded.universal.fileemulationframework.pak.zip

[BonQerss]

Yup! Working just as intended! The costumes that I have selected are showing up in-game properly.

The only thing I noticed is errors being printed regarding the file size difference. Regardless, the files were loaded in-game, so I might imagine it's a non-issue.

[11:06:44] [PakEmulatorApi] TryCreateFromFileSlice: Registering C:\Users\airin\Downloads\Release\Mods\crifs.v2.hook\Bind\3960\R2\model\pack\bc009.pac
[11:06:44] [FileAccessServer] Registered C:\Users\airin\Downloads\Release\Mods\crifs.v2.hook\Bind\3960\R2\model\pack\bc009.pac
[11:06:44] [FileAccessServer] File Size Override | Old: 0, New: 1268992 | C:\Users\airin\Downloads\Release\Mods\crifs.v2.hook\Bind\3960\R2\model\pack\bc009.pac
[11:06:44] Merge R2\model\pack\bc008.pac Complete. Cached to Files\pfxfuift.dio.
[11:06:44] [FileSliceStreamW32] Failed to read all requested bytes. This isn't good.
Current Pos: 0, Num To Read: 1194588
Slice: FileSlice { Path: C:\Users\airin\Downloads\Release\Mods\p3ppc.aiocostumes\P4AU\Yukari\bc002.GMO, Offset: 0, Length: 1194588, Handle: 1944 }
[11:06:44] Merge R2\model\pack\bc009a.pac Complete. Cached to Files\4e0ybngr.yco.

2025-08-10 18.06.27 ~ P3P.txt

Attaching my log file just in case.

Thank you so much for looking into this for me. I am truly, truly grateful for it. Thank you again.

[BonQerss]

Is this issue solved? Am I supposed to close it? I haven't seen an update in R2 for the changes made here.

[AnimatedSwine37]

Sorry, no it's not. I intended to have a look into that error that you saw in your logs first in case this has broken something. I'll try and do it tonight, if not then the next few days.

I haven't really gotten anything done in the last few weeks. I was pretty sick for a bit, thankfully I'm mostly fine now

[AnimatedSwine37]

Turns out you've found what seems to be another problem in FE Framework :)

Your mod registers one real file to two virtual files. e.g.

• ...\Koromaru\bc00A.GMO -> model\pack\bc00A.pac\bc00A.GMO
• ...\Koromaru\bc00A.GMO -> model\pack\bc00Aa.pac\bc00A.GMO

I think this should be fine, although you might be one of the first or only people who's done this so far.
When PAK Emulator uses these it makes a FileSlice for each. The file slice class has a cache of handles to speed up subsequent creations. This means that both end up with the same handle.

It seems that if you're unlucky reusing the handle breaks stuff. That error gets logged because the native ReadFile function returns 0 bytes read. I assume this is because the file pointer is already at the end of the file since the native function returns a non-zero value indicating that the read did actually "succeed".

I'm not 100% certain about this since according to the ReadFile API it should fail if "a read operation on a file begins at or beyond the end of the file". If that were the case I'd expect it to fail, not succeed... This is the only thing that I can think of that would cause this behaviour though so idk.

I tested removing this handle cache so each gets its own handle and everything seems to be fine. It is a race condition so it's random when it happens and which files it happens to but I ran it a fair few times so I'm pretty sure that does actually fix it.
Before I push that and make the pr though @Sewer56 do you think it's fine to just remove that cache or do you have any other ideas about this issue?

[Sewer56]

If you're certain about the behaviours, you can remove the cache.

I don't remember the exact reason for creating the cache (other than performance), so do check.

I'm not currently at home, or on my computer as a result, so not much I can say at the moment.

---

Do remember, opening handles on Windows is a bit expensive, perf wise.

[AnimatedSwine37]

Alright, well I'll leave it for tonight and think over it some more tomorrow. Maybe there's something else that I've missed that could fix it instead.

[BonQerss]

Is it weird to say I'm flattered that I'm the only person to attempt such a solution? I mean, it made the most sense at the time.

Do I need to test your cache solution, or is it working fine on your end?

[AnimatedSwine37]

It is a sensible solution. I guess it's just not a very common problem.

I think it's probably fine but a sanity check definitely wouldn't hurt. Lmk how it goes FE Framework Stuff.zip

[BonQerss]

Seems fine on my end from the testing I did. Slightly slower, I think? I can't tell if that's just a fluke or not. Should be fine to post.