UE Fmod Perforce uasset (un)tracking problem


So I was able to deploy an FMOD integrated UE project to my team on Perforce.

Initially we tracked everything under Content/FMOD but realized Perforce will lock everything by default, making UE crash when trying to regenerate the .uasset files while loading the project.

We were able to obliterate them from the server depot and ignored them with p4ignore, but the next problem was once we’re in the UE editor, all the generated .uasset files will be seen as “new” by the p4 integration (and not being ignored), and every submit would be populated by those .uasset which we needed to manually unselect.

Just wondering if I’m missing something here or is it a common problem.

Throwing my hat in too - I have the exact same issue. This seems to be a new issue with the 4.26 integration. I can’t submit the new uasset files on-disk to perforce, but I can’t not submit them either due to packaging requiring them which fails CI builds.

More specifically, the assets in PrivateIntegrationData seem to be required for packaging (Failed to load asset lookup / Failed to load bank lookup cause errors if the assets aren’t present) but that directory cannot be checked in due to the plugin causing a crash when trying to overwrite them when read-only due to perforce.

Super easy to repro, don’t even need perforce - just mark the asset files in PrivateIntegrationData as read-only and you’ll get a crash on editor startup. For packaging, just use the command-line to package a project while missing the PrivateIntegrationData folder.

We’re having the same problem here with TortoiseSVN. UE4.26 with the temporary FMOD 4.26 integration found in github.

Thank you for reporting this, we’ve verified this bug internally and I’ve added an issue to our tracker for it to be fixed as soon as possible.

In the meantime if you are using source control integration with UE4 it is necessary to have the generated uasset files in source control but you will have to manually check the files out before launching the editor. Clearly this is not a good workaround but I cannot see another way around the issue until we have a fix for it.


Thanks for the quick response!

I should add for anyone else in this situation that the 4.25 integration (which doesn’t have this issue) seems to work fine with 4.26 with only minor modifications, though you have to build the plugin yourself. Not a “real” solution but it’s a decent stopgap measure.

Same issue here. As workaround in TortoiseSVN we’ve added whole Content/FMOD folder to ignore-on-commit list.

Please be very careful with this stopgap - if you modify the 4.25 integration to the point that it compiles cleanly for 4.26 you will find you cannot use packaged builds in any setting. We had to significantly rework the generated asset code for 4.26 because of that (all that rework being a good part of the reason for these new issues, unfortunately).

That’s super odd - I’ve been using packaged builds just fine with my modified 4.25 plugin. I need to go back and diff against the unmodified source to see what exactly I changed, but I’m pretty sure I didn’t change much.

I went and diffed my version of the plugin (which was sourced from 4.25 2.01.05) against the same version you have available for download.

My changes made some minor updates to use new interfaces in UFMODEventControlSection and UFMODEventParameterTrack though I don’t know if those actually work as I am not currently using FMOD in sequencer at the moment.

I added a guard in UFMODAssetTable around calls to FAssetRegistryModule::AssetCreated to only happen in the editor (this is probably not the proper fix, but it works) and fixed calls to CreatePackage.

Added some using namespace lines in FMODChannelEditors.cpp to fix compilation errors.

And that was it. My modifications to UFMODAssetTable might have been why it works for me (and those changes definitely aren’t ideal), or maybe 2.01.05 doesn’t have the issue while 2.01.08 does. Either way, sounds like you’re right that this is something to be careful with.