Level Sequence files are accumulating garbage even when contents are completely emptied.

4.18p3

  1. Create a new Level Sequence and Save it empty.
  2. Note its .uasset file size is 3Kb.
  3. Drag a bunch of Actors into the Sequence for Possession/animation and Save.
  4. Note the Level Sequence .uasset file size has grown as expected.
  5. Delete everything just dragged from inside the Sequence, and Save again.
  6. The file size never goes back to original 3Kb.
  7. Repeat, and the file just keeps on growing and growing, even when supposedly empty on the UI.
  8. Hex editor view shows a bunch of orphaned/previously deleted Actor names inside the file.

Loading pre 4.18 Level Sequence files also show orphaned Actor references in Reference Viewer that were historically deleted. Even deleting the contents of these Level Sequences completely again still shows the Actor references in the Reference Viewer. At least, the newly added and deleted contents do not stick in the Reference Viewer, even though they are still accumulating as garbage in the serialization of the .uassets.

It is suspect that these garbage references may lead to confusion of “Updating Asset References” and the editor getting hung as described here with a demo project:

In that BugDemo project, the 2 provided Level Sequence files are prime examples. Even deleting their contents completely, the Reference Viewer will continue to show the garbage references.

Hi,

I have gone ahead and tested the issue, and was able to reproduce it on my end. Therefore, I have logged it. If you would like to keep track of it for future reference, I have provided a link to the public tracker here. If you have any other questions regarding the issue, feel free to reopen the thread and I will get back to you.

-Thank you for bringing this to our attention

Thank you!

Dear Ridley,

I see that the developers have marked this as “By Design”.

Can you please ask them what is being stored in there? Why is it useful? And why is it not accessible to the user?

Can you also ask them, why in the above link to my other AnswerHub post and bug report Project file, Sequence files are accumulating deleted references that are now showing up in Reference Viewer at 4.18? Why are these references that were deleted months ago at 4.16 now showing up? Why are they not editable or removable from the UI any longer?

It may be By Design, but certainly it is Bad Design that will have to be overhauled in the future by more competent programmers, further risking client assets and investments.

Hi,

I have gone back into the bug report and made the developer’s notes visabable. If you look back at the link provided you should be able to view the explanation now. As for the other post mentioned above, we only focus on one issue per thread for tracking purposes.

-Thank you

Thank you Ridley for providing the developer’s hypothesis, and keeping the communication open.

Unfortunately, he is mistaken. The file size grows, even if you clear the thumbnail.

Take a look at my original statement:
“8. Hex editor view shows a bunch of orphaned/previously deleted Actor names inside the file.”

Also the problem is not innocuous. There are references left inside the emptied file, that were deleted at earlier versions of the Editor (4.16), but now show up on 4.18 Reference Viewer. This garbage is now visible, but completely uneditable, even when the file contents are completely deleted. This can confuse the new Soft Referencing systems in 4.18. And in fact they do, and Freeze the Editor, as described in my other reports.

I am including a Sequencer file, that is emptied, no thumbnail, at 24Kb, and 2 garbage References visible on Reference Viewer. Hex view is even more loaded with garbage.

Generally, it is very bad programming practice to accumulate and serialize orphaned data into user files. It is worse than leaking memory. I am sure you would agree.

BugDemoV7.zip

Thank you for relaying my notes about the deleted/orphaned references visible in a hex editor, and reopening UE-50987. It is good to see commitment to quality code, and well maintained assets.

I am just curious if this was ever resolved? If so what steps do we need to do if any to prevent this from happening.