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.
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.
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.
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.
EDIT:
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.
It is possible that it is sufficient on Windows to just restrict the calls to FAssetRegistryModule::AssetCreated to the editor and the other issues we encountered with packaged builds don’t occur on Windows, we certainly encountered issues beyond that with deploying packaged builds on Android and other platforms.
Hi, this sounds like the issue we’re having too. It’s the first we’re trying FMOD’s UE4 integration (and in 4.26).
We’re versioning all files in the Content/FMOD folder, but we see that the unreal assets are regenerated (and shows as modified in Git) every time the editor is opened.
Not tracking these files (except the Desktop folder) is not acceptable either as cooked builds require all the assets in the FMOD folder (but does not regenerate them like when you open the editor).
Can this issue be expected to be fixed too or should we set up the project differently to avoid all FMOD files being modified upon opening the editor?
The fix for this will be in the next release which we’re working to finalize right now.
I’m not aware of any workaround to prevent the problem in the current release, I’m afraid the best thing I can think of is to revert the generated assets - unless the FMOD .bank files have changed there is no need for the assets to be updated, so it should never be necessary to commit changes to the generated assets unless you’re also committing the .bank files. I recognize that this is a pretty awful workflow, but unfortunately I can’t think of a better way to handle it right now.
In the release we have changes to prevent the assets being re-generated needlessly, and to work gracefully with UE4’s source control integration, so the issues we’ve seen with constantly re-generating assets and crashes trying to re-generate read-only asset files are fixed.
The fixes for this have now been pushed to GitHub. There could be further changes before release but please let us know if you encounter any issues with the fixes we’ve pushed.
We are still having this issue. Unreal engine decides to rebuild .uassets from FMOD banks, events, snapshots etc. upon every launch of the engine, giving us major problems with our source control. We’ve updated our UE4 integration to the latest through the FMOD website. Is the fix live there yet, or do we need to build the integration ourselves from the GitHub?
According to AOOSG a few posts up his issue looked to be fixed. I tried the GitHub version and the newly posted 2.01.09 on FMOD’s direct website(which should be same as GitHub) but the issue still persists.
I’m sorry to hear this is still causing trouble. Are you able to provide steps to reproduce the crash you are encountering? Please include as much detail as possible so we can attempt to reproduce the issue internally.