Hi
I’m using Fmod with unity 2020.3.11 with other members.
I setup initial FMOD importing with my desktop and share that project through github to my team.
But at other team member desktop, “Repair FMOD Libraries” keep showing even they click repair or ignore.
This warning appear when start unity at first time, and play game in editor.
How can I solve this problem?
You can try getting your team mates to install the FMOD package on their end, but if you could please tell me your FMOD version I will try to reproduce the issue.
I haven’t been able to reproduce this yet- what are the Mac and Windows versions, and is this going from Mac to Windows or from Windows to Mac?
Have you tried getting one of your peers to reimport the FMOD integration to see if that prevents this error coming up repeatedly?
Our peers are using Window 10.
And I tried reimport FMOD integration twice.
I have not been able to reproduce this issue unfortunately. Can you please upload a stripped down reproduction to your Profile? Just a Unity project with an empty scene and the FMOD plugin installed should be plenty.
FWIW I wanted to add a comment that we recently ran into the same issue where the developer importing FMOD (v2.02.04 on Windows 10, Unity 2020.3.30f1) had no problem opening the project, even after doing a full library re-import as well as branch switching and Git clean as a sanity check, whereas two other Unity developers (also on Windows 10) were presented with the repair error upon opening the project.
Our current workaround is simply to delete the Mac lib folder as we aren’t going to be targeting Mac OS for our project but I’m curious to know if anyone figured out the actual cause of this issue.
Kind regards,
Duane
The issue is that git is replacing the line endings of the Mac libs from \n to \r\n. Clicking repair when this popup appears will switch them back to \n, but it looks like git is still clobbering the line endings every time you pull.
Deleting them if you don’t need them is one option, otherwise if you add
*.bundle text eol=lf
to your .gitattributes file then the line endings of any .bundle files will remain as \n (line feeds).
Hey we are having this exact same issue. Adding the *.bundle text eol=lf line to our .gitattributes file has not prevented the issue from occurring. As we are not targeting mac for our project I’m looking into the possibility of removing the mac > lib folder completely.
However, as our team is a mix of mac and windows will this cause any issues?
Additionally I’m not building mac banks yet when development builds have been made for mac by mac users they have not encountered any issues with audio not playing or similar. Ngl I’m a bit confused. This issue is not game breaking or anything but I would like to iron out these kinks lest they bite us on the ass down the line.
Can someone provide any clarification on this?
Edit: I’m assuming we just have to commit the repaired files, but as soon as a mac user pushes changes it will break for windows users?
It will cause issues if any of your team are running Unity on Mac. If for example your sound team are all on Mac and never run Unity themselves then you won’t need the Mac libs. If you have artists or designers who are running Unity on Mac however, they will still need the Mac libs to run to be able to run a scene in the Unity editor.
FMOD uses the same banks for Mac and Windows so there should be no need for separate Mac banks.
If you commit the modified git attributes file that should be enough to fix the issue. With that, every time anyone pushes it should automatically change the line endings to \n.
As for why this fix isn’t working for you, the only thing I can think of would be that the .gitattributes file isn’t in the base directory of your repo- can you please double check that it was committed in the base directory of your repo?
Thanks for your reply Jeff. Yes the .gitattributes file is in the base directory of the repo. This has been a bit of a headscratcher for our devs too as everything is set up as it should be.
Alright, maybe we need to be a little more explicit with the committed files on the Windows side then. Can you please add another entry to your gitattributes to force all plist files to lf?
*.plist text eol=lf
If that still doesn’t work, can you please upload your gitattributes file to your FMOD Profile so I can ensure there are no conflicting declarations?
Also, just to rule out some kind of global config overrides on individual machines- does everyone get this popup when they pull or does it only affect a subset of your team?