In our production, we used to rely on the ProcessorVisualizer to check processor dependencies and scheduling. Early on, I also implemented an internal dependency check in-editor using MassProcessor CDOs. Everything was working fine until we updated to 5.6.
I had to fix the removal of CDO support (i.e., resolving requirements at editor time). I also just discovered that the entire ProcessorVisualizer widget is now missing—and because I forked it early on, it now crashes.
We are quite disappointed, as the system is production-ready (Runtime folder), yet there is no mention of these significant changes in the release notes.
First question: I understand the need for subsystem dependency checks, but why remove CDO support entirely, and with it the ability to inspect archetypes in-editor? Archetypes don’t depend on subsystems.
[Attachment Removed]
What support for CDO are you finding has been removed? Mass still uses CDO and in fact, we had some recent code changes to support Game Feature Plugins containing Mass processors so we can toggle things on/off at runtime without crashing the system as GFPs are toggled.
I also did a quick search through the code back to 5.4, but I did not see “ProcessorVisualizer” in our code base? What version were you using that included this? You can inspect archetypes and entities in the editor using the MassDebugger including seeing fragment values for selected entities that update in realtime.
-James
[Attachment Removed]
I mean, with the introduction of UMassProcessor::CallInitialize, which explicitly ignores CDO.
if (ensure(HasAnyFlags(RF_ClassDefaultObject) == false
&& GetClass()->HasAnyClassFlags(CLASS_Abstract) == false))
With all the checks added along the new bInitialized attribute, to make sure the code crashes when trying to request AddRequirement to CDO processors.
About the ProcessorVisualizer It was a widget displaying a node for each processor with their dependencies. You may have removed-it long time ago, I did Fork Mass with the 5.2.
[Attachment Removed]
Looking at our P4 history, I believe the change that may be responsible was when we did a complete overhaul of the MassDebugger. That work was done around the end of 2024.
As for the change to initialization patterns, that was done to support some larger Mass processing changes. We are using Mass in Lego FN and other internal projects but have not seen the ensure tripping in our code. Conceptually, we did not believe that CDOs of processors would be getting initialized. Can you elaborate a bit on what you are doing and your use case? It could be something that we overlooked or did not consider. Alternatively, we may have some ideas for how to do it within the updated Mass framework to keep with our current vision.
We also have been working on Mass processing and a better dependency solver. Work is still ongoing, but I am hopeful it can make it into 5.8.
-James
[Attachment Removed]