new RenderManager.SpawnSafe for better icons

[bid-soft]

now also renders particle effects

[MSchmoecker]

Thanks for the PR. I agree cloning the whole prefab instead of spawning a transform clone and copy components has it's benefits, like being able to use ParticleSystems. It comes with a lot more considerations for unknown behaviour of the clone tho, so we have to be extra careful.

A few notes before this can be merged:

• Please rather use for/foreach loops instead of Linq, for consistency with the current code base. Linq has it's use cases and is not forbidden but especially for side-effects (like destroying components) loops are more clear IMO
• Instead of iterating through MonoBehaviour, Component seems like a better option. Not only custom scripts should be destroyed but also physics components and the second loop for Animator won't be needed as well. I think only IsVisualComponent and Transforms components should not be destroyed
• Only catching CharacterDrop isn't enough, other vanilla scripts, components like Joints or modded scripts may have dependencies. Building a DAG (Directed Acyclic Graph) by getting class attributes would be one implementation option. Cycles should be detected and those components skipped destroying, together with a warning
• Disabling particle systems should explicitly happen with values less than 0. Particles can be assigned initial bursts, so 0 may has a different meaning.
• The default for particle time should probably be more like 5 or 10? Not too sure but 2 seems a bit low
• Maybe SpawnSafe should be renamed to SpawnRenderClone, since the spawning is not necessarily safe anymore
• SpawnOnlyTransformsClone and associated methods should be removed if they are not accessed anymore. Dead code usually isn't helpful

[bid-soft]

Addressed all points from the comment.

• Could not use IsVisualComponent as it includes renderers that are problematic in some cases
• also determining size only includes MeshRenderer and SkinnedMeshRenderer, otherwise some icons get too small.
• I was not able to test all possible situations for the DAG (like cycles), please double check the implementation

[MSchmoecker]

Thanks for the changes, they look good overall.

However, the DAG doesn't seem to archive an order of components based on their required components but rather something like a reversed order of components. This may work in many cases but for a different reason than thought and can fail.
Instead, something like component.GetType().GetCustomAttributes<RequireComponent>() can be used to get all RequireComponent of the class and order them. Not even sure a DAG is the best implementation option for this case, it was just my first idea.

Also, the ordering is only required on each GameObject itself and not the whole list in one. Component relations are only valid on the GameObject and not across the hierarchy. Not sure if this makes a difference but might be more performant in case there are some performance issues.

[bid-soft]

Thanks for pointing out the dependencies introduced by RequireComponent (was not aware of that, still know little about Unity itself).

Changed it the way that dependencies are now only considered of one gameobject, not the whole hierarchy.

DAG with depth first search and recursion stack is usually a good option to resolve dependencies. As the topological sort order can already be determined during parsing, I removed the DAG class in favor of two static methods.