We validate event names to check for dupe paths before path-stripping our events and creating a header file for our game to use. The script correctly identifies actual duplicates, but sometimes in a session after event copy/paste operations, it can report “ghost” duplicates that don’t actually exist anymore.
Closing and reopening FMOD and rebuilding the header file correctly builds it without reporting issues, despite no events having been changed in between.
I’m guessing it’s some kind of caching issue, but even deleting the .cache and .unsaved folders while the program’s still open won’t unblock the script. FMOD must be relaunched.
The issue appears when using the FMOD Studio scripting API, specifically:
studio.project.model.Event.findInstances()
- Accessing
event.name
and event.getPath()
- After performing copy/paste operations on events
Can you think of any workaround for this, or would you be willing to take a look at the script itself?
Posting the script, as well as a short series of steps that reproduce the issue, would be great. Also, what version of FMOD Studio are you using?
Hey Leah,
This is the script we’re working with, and we’re still on 2.02.20 as a core. I’ve been on some variant of 2.02.20 to 2.02.27 all throughout dev, and this behavior’s persisted.
A common repro would be to create a bunch of events and ensure the script runs properly with no errors. You shouldn’t see a dialog or anything if this went well.
Then, copy/paste an event a bunch of times (as if you were planning to rename the pasted events, using the original event as sort of a template for your new events – super common for us), rename all your pasted events to unique names, and try again. You should run into the issue of it thinking that events have duplicate names even though you can see they’re all unique. That’s where I feel like some kind of caching is interfering.
Hopefully you have some insights on this! The seconds and minutes of relaunching the program with our project just to build after implementing a bunch of new events really do add up and I’d love to fix it for good.
Thanks,
Luca
P.S. The file’s been uploaded as .txt to get around upload type restrictions, but it’s obviously supposed to be a .js file.
exportFMODTable.txt (12.9 KB)
Thanks for the script and repro Luca, I’ll take a look and get back to you soon.
1 Like
After some testing, this does appear to be an issue with how Studio handles finding entities that are unsaved, as they can be still fetched using studio.project.model.Event.findInstances()
when they probably shouldn’t be. I’ve added it to our bug tracker, but in the meantime, I’d recommend iterating over events from studio.project.workspace.masterEventFolder.items
instead, which should only contain events present in the event editor’s hierarchy.
Here a snippet demonstrating how you might handle this:
var allEvents = [];
function getAllEvents(item) {
if (item.isOfType("EventFolder")) {
// item is an event folder, recurse on folder's items
item.items.forEach(getAllEvents);
} else if (item.isOfType("Event")) {
// item is an event, add it to the array of all events
allEvents.push(item);
}
}
studio.project.workspace.masterEventFolder.items.forEach(getAllEvents);
console.log(allEvents);
Give that a shot and let me know how it goes.
Looks like we’re cooking, Leah. Thank you so much for the help! So many relaunches saved!
1 Like
No problem! Feel free to get in touch again if you run into any other issues.