[Bf-python] Bug in CurNurb.setFlagU() and setFlagV()

Gergely Erdelyi gergely.erdelyi at gmail.com
Thu Sep 8 19:56:23 CEST 2005


Hello,

On 08/09/05, Ken Hughes <khughes at pacific.edu> wrote:
> I caught the tail end of a conversation on IRC between stivs and antont
> this morning about setFlagU() making curves cyclic when it shouldn't.
> We looked at the code and found that setFlagU() and setFlagV() are
> setting the wrong bits:
> 
> flagu and flagv:
>     bit 0:      CU_CYCLIC
>     bits 2-1:   uniform=00, endpoint=01, bezier=10
> 
> See do_curvebuts() in source/blender/src/buttons_editing.c for the code
> handing the UI buttons for the three curve types.

I just had one of those "Ah, of course. Damn." moments. ;) I wrote
that code in kind
of a hurry and remeber wondering why the flag was shifted to the
right... Oh well...

> So should the BPy documentation be corrected or should the functions be
> fixed (and setCyclicU() / setCyclicV() be added)?  I can upload a patch
> to the bug tracker, just need to know which way we should proceed.

I think those two are quite separate and from a user script it would
be quite a pain
having to first getFlagU(), tweak the bits then setFlagU(). It's much
easier to just
set the knot mode directly. However, in that case setFlagU() does not
really set all
the bits of flagu so it might make sense to rename the function for consistency.

We could have something like setKnot{U|V}() and setCyclic{U|V}()

I am not sure if we even need direct (c[0].flagu = xx type) access to
those variables
after that.


Gergo



More information about the Bf-python mailing list