After updating from 5.4 to 5.6, when I open some level sequences I get the message “Duplicate corrupted controls found in level sequence, just keep first set of original Control curves (recommended but may revert to an older version)?”, and after selecting “yes” or “no” some controls are in incorrect positions or have incorrect values.
Anyone else experience this, or know any solutions to this without having to manually correct every animation in the game?
Having the same issue! Tried creating a new level sequence and copying animations over with same error.
I’m updating from 5.5 to 5.6 but I have the same issue.
It seams to be all sequences with a particular rig in it. So I think it has to do with the control rig and not the sequence itself. It happens on a handful of my rigs and I haven’t found a common pattern why it should happen to those specifically.
The error isn’t very detailed so I can’t see which controls causes the problem.
To properly debug this, make sure your control rig is checked into your revision control. From there do a divide and conquer approach to delete half the controls to see if the error goes away and keep dividing until the error goes away and look at the other half of the deleted controls. You would leverage revert on revision control to revert back to the original state after isolating the error.
In my case there was a channel name that was internally duplicated with script name that was causing the error. Deleting the erroroneous channel and recreating it fixed the issue. Output log won’t show it. You have to consistently add the control rig to a fresh sequencer to check the error. Adding the control rig as a possessible won’t show up. It only shows up when created as a binding on a possessible, so the quickest way to test is to drag the control rig from content browser on to the viewport.
It’s inherently caused by a weird design setup where a channel has two internal variables. The channel name is the visible name while the script name is the unique id on the control rig for the channel. Although it may display one thing, what’s internally saved maybe something different so you may have an ok looking channel that’s actually internally corrupt. Identifying, deleting and recreating it will fix the issue.
An example of legacy tech debt not cleared from Manny/MetaHumans is head_stretch under head_ik_ctrl. This is not used anywhere in the control rig but still exists as an orphaned channel.
One example of a used one that has a different naming is local under head_ctrl. The script name is actually head_local.
In the blueprint, it is only referred to as head_local.
When you duplicate these channels internally it will try to make the script name unique. If done incorrectly it could cause corrupt internal data.
