Unexpected behavior on attempting to replace assets

Hi all!

We have ran into a little snag with our usual Hype pipeline. The usual behavior is that we are able to make batch changes to existing Hype Scenes in a Document by having a consistent naming convention, and then when we want to change all of the XXX elements in a Hype document, we simply drag all new same-name assets into the Resources panel and accept the Replacement prompt, thus making batch edits.

However, a file in use today has mysteriously stopped being able to accept batch edits this way. Despite being authored by the same user off of our remote drive as other Hype files which have successfully accepted batch edits, this file asks for a Replacement prompt, but then adds "-1" to all of the filenames on clicking Accept, effectively breaking the batch edit process.

Any tips on how to ensure the original behavior works would be greatly appreciated!

I see that there is a similar post from 2016 requesting this feature, so I am assuming that the original behavior is the intended behavior and this is some sort of error!

If the name is identical, it should replace it without changing. There could be ways in which the name is recognized as different, especially when dealing with a different volume - the most likely culprit would be if the capitalization is somehow different.

If that's not the case, then I would also try making sure that the document is saved (vs a duplicate/new document), quit, relaunch, and then try the replacement.

Failing that, feel free to send a zip with the .hype document and replacement files to support@tumult.com, along with details about the remote drive (protocol, file system format) and we can look further.

Thanks Jonathan!

As far as I am aware that is all the case (named same including caps, saved doc, both users have restarted their Macs and Hype, etc). We will try again tomorrow and might get back to you. It is very perplexing.

1 Like

I replied to the email - the issue is that the case of the "x" letter was different.

1 Like

Thanks Jonathan! NO CLUE how that slipped past both of us, we are usually much more diligent. And sorry about the phone tag! We appreciate it.

1 Like

It took me a surprising amount of time to spot it myself! I had to resort to looking at the byte values :slight_smile:.

4 Likes