Hi all,
After all project files were created and events assigned to banks, FMOD creates the mixer and tag files (and possibly others…) in the project folder. When I rename the project folder to a different name, open the fmoproj and save it, the project file gets automatically renamed to the parent folder’s name. If I close the project and try to open it again, it’ll say that some files are missing because it was expecting them to have the same name as the project file. I fixed it by renaming the mixer and other files to the same name as the project has, but it’s quite anoying that the software doesn’t do it automatically.
Please take a look at it. Thanks!
edit: Actually, would be better if the app don’t rename the project to the folder’s name at all. Let’s say I create the repository in my E:\Projects\MyProject and push it to git, and someone else check out this repository to his folder Desktop\TheProject, the project will be renamed again, resulting in the same problem.
The behaviour you’ve described is not desirable, but probably not for the reasons you think.
But first, I must explain the philosophy behind an FMOD Studio project’s format and design. In FMOD Designer (FMOD Studio’s predecessor), project files had two major problems: The first was that audio files were stored externally to the project, meaning that any attempt to move the project file to a new location or machine would break the paths to all of its audio content; The second was that, as a single file, it was extremely inconvenient for multiple users to work on the same project, necessitating multi-file juggling shenanigans. We decided to avoid both of these issues in FMOD Studio by making one major change: An FMOD Studio project would be a folder, that would be treated by the user as a file. More specifically, it would be a folder that contained a whole structure of files representing different elements of the project, as well as all of its audio assets and other potentially modular content. This solution worked quite well: Separating the project’s content into multiple automatically-generated and managed files makes it easy for multiple users to collaborate via revision control without stepping on each others’ toes, and treating the folder as a single unit that contains both content and its source assets makes it very easily portable.
However, for this to work, it is necessary that the various files and folders that make up a project have some way of referencing each other; This mechanism is that each file that somehow interacts with another file or folder in the project must know that file or folder’s precise name and relative path. In order to make this system a little more resilient, we have included some basic mechanisms to allow a project to load even if it detects certain kinds of broken references, and by allowing the project to automatically correct certain errors to be more internally consistent.
Unfortunately, renaming the project folder via the OS is one of the inconsistencies it cannot automatically recover from, as it tends to assume that the project file is what has been misnamed, rather than the folder. As mentioned earlier, the project folder isn’t meant to be thought of as the container for an FMOD Studio project; It should be thought of as part of the project, itself. As such, renaming it causes problems similar to (but more serious than) if you were to edit the name of any of the files or folders it contains.
The solution to the problems you are experiencing, fortunately, is simple: Treat the project folder as a file, and make the root of your repository the parent folder of the FMOD Studio project folder, instead.
Joseph, thank you so much for providing an explanation to this issue.
I understand the reasons… but… I have to honest that I’m a bit disappointed with this solution because it’s a solution that may create other problem, and it’s not something trivial to happen.
Sometimes people do some reorganization and it’s possible that they’ll rename this folder without knowing that it’ll break their project. Sometimes people have second thoughts about the folder name. It happens.
Also, would be nice to include this information in the documentation. I’ve read it, and it doesn’t say anything about the relevance of the project folder name.
You’re right, this isn’t very clear in our current documentation. I’ll request that our documentation writer include an explicit warning in the Studio manual. Thanks for the suggestion!
In that circumstance, the solution is to open the project in FMOD Studio and select “Save As…” from the “File” menu; This will allow you to save a copy of the project under a new name - and with all of its file names and internal file references updated accordingly. Renaming this way does, of course, require your project to be re-submitted to any revision control system that you might be using, but so would most other methods of renaming the project.