I have several banks and events which have been deleted with extreme prejudice, but which stubbornly refuse to die. They keep showing up in my Studio project after multiple deletes, both within Studio and Perforce and by manually deleting the files off the drive.
I’m afraid we need more information to diagnose this problem. Were the files initially deleted in FMOD Studio, in Finder or Explorer, or in Perforce? Was the change checked in afterwards, and if so, was it checked in through P4V, the P4 command line tool, or FMOD Studio?
They were initially deleted within Studio.
The changes were checked in, through P4V.
I guess my question is: Is there a guaranteed-to-work way to kill things dead, no matter how they came to be in a strange state?
Upon further examination, I have determined that the basic problem is that these files continue to exist on the P4 depot. I’m guessing Studio consults with the depot in addition to looking at the local drive? That would sort-of explain it…
We strongly recommend against doing this. FMOD Studio projects contain a number of files that should not be checked into source control, and which will result in errors if you include them in your repository. Information about which files in an FMOD Studio project should be excluded from your repository can be found in our documentation on the topic.
Instead, we recommend performing all source control operations using FMOD Studio’s built-in source control commands. These commands automatically avoid the files that should not be included, while also preventing the tendency of Perforce to mark certain files as read-only from inhibiting FMOD Studio from saving correctly.
Source control problems tend to have highly specific causes and solutions. If you know the exact cause of the problem and exactly what files it affects, you can use that information to identify the specific actions required to fix it. However, if you do not know the cause of the problem, there is no general-purpose “just fix it, whatever the problem is” solution.
I suppose you could delete everything in your local workspace, roll back the repository to the last known good version of your project, and then get a fresh copy of that revision. That’s a rather drastic solution, though, and so should probably be treated as a last resort.
Assuming you’re using our source control integration, FMOD Studio should indeed connect to the server. However, events annd banks should only appear in the relevant FMOD Studio browsers if they are still part of the project, not if they have been deleted.
Are you sure you checked in the deleted events?
Checking changes in through P4V instead of through FMOD Studio’s built-in source control commands can sometimes lead to broken internal references in your project. Have you tried running “File > Validate Project…” to detect such issues?
Thanks Joseph, this is good info. I have indeed been performing the P4 operations from within P4V, rather than in FMOD. (I seem to remember some problem doing it from within Studio, but hopefully I am mis-remembering) I will try doing them from within Studio and see if that settles things down.
And I did, unfortunately, allow the ‘.cache’, ‘.unsaved’, and ‘.user’ folders to be added to our P4 depot. I shall attempt to remove them. If I just delete them from P4, can I assume that Studio will re-make them when it notices they are missing?
Yes, FMOD Studio remakes those folders as it needs them.
The “.cache” folder contains cached data designed to save time when Studio performs certain operations. Studio automatically creates a cache or updates the existing cache whenever it does something that would benefit from having a cache. (This is why, when you build a project several times, the first time takes slightly longer.) Checking your cache files into Perforce prevents Studio from updating (and thus benefiting from) those files.
The “.unsaved” folder contains changes that have been made in an FMOD Studio session, but not yet saved. It allows you to recover unsaved changes if FMOD Studio ends without exiting properly, such as in the event of a power cut. This folder is automatically created and updated whenever you make a change to your project in FMOD Studio. Normally it’s automatically deleted whenever you close the project, but checking it into perforce prevents that and may result it it being restored from your repository even if deleted locally, so having it checked into Perforce may result in FMOD Studio reporting that there are unsaved changes that can be recovered when it loads your project.
The “.user” folder contains settings that have no effect on your project’s behavior, but which you might want to be different on different machines. Checking it into perforce may result in the user properties of one machine being overwritten by those of another machine. For example, your project’s external asset directory is a user property, so checking your “user” folder into perforce causes the external asset directory all machines that accesses the project to be overwritten with that directory - which isn’t a problem if all those machines use the same external asset directory or don’t use external asset directories, but could result in all assets going missing if they would otherwise expect those assets to be in a different spot.
Upon closer examination, I have discovered that the .cache, ‘.unsaved’, and ‘.user’ folders were in fact NOT in our P4 depot as I had thought.
At any rate, I will try to only do P4 operations through the Studio interface from now on and see how that goes.
Thank you for your help. 