Suggestion / Idea Problem with the Obi Solver Structure

[Bill Sansky]

Hi,

First of all congratulation on releasing the 5.0 version: the edition of ropes definitely got much easier, I like it!

I must, however, come with a major concern when it comes to the project structure: the fact that actors need to be children of an obi solver is a big problem, for a few reasons:

• It makes it impossible to create rope prefabs and to edit them in prefab mode, which is now core in production for unity 2019+: the ropes do not have a solver in this, so it can't be edited properly. But most of my work, and I suspect most of the users will be in the same scenario, revolves around nested prefabs.
  
• It makes it hard to link to a solver when being in a multiscene scenario, which is I think very common in current Unity's workflow
  
• It forces a hierarchy logic that is often not desirable, especially so when the solvers are not colliding with each other.
  

Would it be possible to have an architecture that would link the solver through a scriptable object reference for instance? This way it's compatible with both a proper prefab workflow, a multi-scene project architecture, and makes the hierarchy free?

I have another similar problem concerning the new attachment system: because it must be a component on the same game object as the obi actor, it makes the architecture not very flexible and not easy to use with the classic drag and drop for fields. If I have a custom component that wants to activate or deactivate that attachment in runtime, linking them in the editor becomes an annoyance. 
Would it be possible to make it a component that can be added anywhere with a reference to the obi actor it constrains? this would be much more flexible.

Except for those two points, thanks for the awesome work!