I have used Chris Bartlett's rope_sys.inc object collection for several years,
and just discovered a subtle bug in the code.

I usually create ropes using the Rope_Array related macros, and then call
Rope_ArrayToSpline or Rope_ArrayToRope.  I was playing with the Rope_BreakSpline
macro so I could have a linear section of the rope followed by a natural spline
section.

The first thing I realized was that calling Rope_BreakSpline() sets the spline
type for the segment of the rope following that call.  You can get around this
to set the spline type of the first segment by calling Rope_BreakSpline
immediately after calling the first Rope_AddPoint()

In my test, I just did that:

Rope_AddPoint(MyPoint1)
Rope_BreakSpline("linear_spline")
Rope_AddPoint(MyPoint2)
Rope_AddPoint(MyPoint3)
Rope_ArrayToRope("")

However, the resulting rope used a natural spline.  I looked at the code for
Rope_ArrayToRope and discovered that there is a check for the number of spline
breaks found to be < 2.  If so, it calls Rope_ArrayToSpline("") which uses the
default natural spline, and then calls Rope() on the resulting single spline,
completely ignoring my first Rope_BreakSpline("linear_spline")

I edited my code to make the check < 1, forcing it to look at that first
Rope_BreakSpline and create a spline using that spline type and now it works.

If I had actually added some additional points and called Rope_BreakSpline() a
second time, the code would have worked as written.

I don't know if this code is being maintained in GitHub or if the library comes
back alive if there is a way to patch it.  It's not a huge deal, it just always
bothered me that I couldn't use Rope_ArrayToRope if I wanted anything other than
a natural spline.
-- Chris R.

Post a reply to this message