29-09-2023, 12:38 PM
(29-09-2023, 11:56 AM)josemendez Wrote: Hi,Thanks for the detailed answer, yes absolutely, I don't disable ObiRope, I disable its Renderer, I apologize for the wrong translation. If I explicitly set the positions of the particles and disable their mass, making them kinematic, I will not be able to switch the lever with this rope (which is necessary in my game). It won't react to the rest of the ObiCollider, or it will react as a kinematic object, which is not exactly what I need. I need to keep the rope taut between the players, but if the players run in different directions, it should stay taut and not increase. This way we can grab the rope, and in a taut state move physical objects with it, hang on it, etc., which is unlikely to be achieved by explicitly setting the positions of particles and disabling their mass. On the other hand I could do it to just stabilize it before turning it on, I understand that this is the most stable and correct way?
Disabling the ObiRope component won't make it continue its life cycle, it disables it entirely. When you re-enable the rope, it will be re-enabled and its state copied from the blueprint data.
To keep the rope from rendering but otherwise keep simulating, disable its ObiRopeExtrudedRenderer instead (or whichever renderer you're using).
This is because changing the length of a rope does not actually change its shape (that is, it does not move particles around) - it only changes its length by adding or removing particles from the pool and placing them at the cursor's "source mu" position. Otherwise, the rope keeps its current shape. If you need the rope particles to be placed at a specific place (for instance in a straight line that joins both players), you need to do this yourself using the particles API.
See for instance the RopeGrapplingHook sample scene: when initially extending the hook, it does so in a straight line. This is accomplished by setting particle inverse masses to zero (to temporarily make them kinematic) and explicitly setting each particle's position.
This will only increase simulation accuracy (and negatively affect performance), but won't fix the flawed logic in your approach.
If the rope is disabled, attachments won't work because there's no rope to attach. When re-enabling the rope, particles will be re-attached causing the rope to jump. Again, the solution to this is to explicitly set particle positions.
kind regards,