[Closed] TRASHCLASS issues
Been struggling with TRASHCLASS issues for a few days now. The issue is similar or the same as referenced quite a few places: https://udn.unrealengine.com/questions/265552/trashclass-and-function-override.html
Basically modifying a base function's input arguments in class A, that is overridden in subclasses, breaks in class C (With a hierarchy A -> B -> C). With an error message like:
Compiling A or B fixes the error in C, but restarting the editor will make the issue return, and packaging always fails. We've also tried to just create a new function so we don't modify the original function, but the new function gets the same issue.
TJ Ballard claims that the issue has been resolved in https://answers.unrealengine.com/questions/305169/trashclass-compile-errors-when-overriding-custom-e.html
This issue is quite a setback for us, as the only option besides getting it fixed is to recreate large portions of our blueprints. And we're not certain that will avoid the bug in the end.
Any ETA on when we can expect a fix? Or can we get a reference to the changelist so we can apply the fix ourselves?
The question has been closed Feb 24 '16 at 08:45 PM by AndrewHurley for the following reason:
The question is answered, right answer was accepted
So, I would guess this is a cyclic dependency issue (probably a parent/child cyclic dependency chain). What is most likely happening is that C is being compiled as A is being regenerated. It is validating connections that haven't been fixed up yet (ones that are left referencing an old, now intermediate/defunct, class).
This is a problem that is cropping up more and more. Since we fixed up cyclic dependency load crashes, we've seen an increase in this type of error (probably means this would have just crashed before). We're slated to address it on the whole, but fixing up individual issues has become a lot like whack-a-mole (fix one, and you've just undid another fix). There are a lot of causes (a lot of things that bring in different dependencies), which is why one got fixed but you're still seeing this.
The proper solution is a refactor of our compiler. We need to turn it into a multi step (well divided) process (something more akin to compilation and then linking). As you can imagine though, this is a lengthy task that first requires a well thought out design and then a lot of work. In the meantime, I'd suggest you restructure your content a bit and untangle the dependency chain. The easiest way to do this is to break in UBlueprint::RegenerateClass() for C, and then look at the LoadPackageInternal() calls in the callstack; this will help you identify what all is introducing these dependencies.
Hope this helps!
answered Feb 24 '16 at 08:43 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here