Ack… now am feeling very stupid… Was on the 2.79 tag, not on the trunk of /lib/tests :(

I can't reproduce this. I've been updating bevel_regression.blend pretty regularly (last time Feb 11) and it passes for me.
This is what I do on MacOs:
(with Debug build)
build with lastest master
test with latest svn revision of tests
in the build directory run:
ctest -C Debug -R bevel
and it runs that bevel test and shows it passing.
Similarly if I "make test" on Linux.

Thank you. I'll find time to test. Are you prepared to maintain this long term?

Updated addon to work with latest API changes.

OK, I finally found time to look at this. Unfortunately, I am going to close this as "working as intended". The workaround cited above (turn off Loop Slide) should be satisfactory in cases like this.

Rohan's GSoC fix did indeed fix this particular case and is now in master, so closing this bug.

Clearing out old bugs. Clamping is currently working as intended, even if not ideal. The long term fix is to actually have the geometry merge and/or otherwise do intelligent things when collision happens, and then remove 'Clamp' completely. I hope to get to that as my next big bevel improvement project, though it is some time off.

Closing this now that Bevel has a user editable keymap, so users can map spacebar to confirm if that's what they want.

Artifacts from overlapping faces are not currently considered a bug.

Can no longer reproduce the crash and modifier appears to work correct after binding. Considering it solved.

Hi, It would be very useful for me to have the vertex group or any other way, to affect bevel size per vertice, something like this:

More than a week without reply or activity. Due to the policy of the tracker archiving for until required info/data are provided.

The Bevel and Curve Resolution are basically akin to U and V resolution on a UV Sphere. So I think yes, it does make sense to add both here.

I split the properties between edit and object mode using a custom interface.

Thanks for the response. Good to see the curve default changes are pretty much ready to go. Feel free to commit those.

I would leave out resolution from the add operator regardless, it should just have some reasonable default.

I think this change makes sense.

I am not sure whether I did anything in particular to fix the mouse sensitivity to percent, but it seems fine to me. Maybe this also had to do with the scale issue that my commit did fix. If the original reporter of this bug thinks it is still not ok for percent, please give more details (a .blend, and details about what you did -- I'm assuming adjusting by mouse movement, but maybe that was a wrong assumption).

Fixing in 2.7x requires porting more changes then just this fix, closing.

Sorry for the late followup.

Ok Thank you .
Regards.
Pierre

It seems the issue stems from the fact that Curves are added as primitives which can be created in both object and edit mode. So a fix to this might require some unwieldy code duplication.
Unless someone can suggest a potential fix or is okay with this bit of UI inconsistency. I'm thinking of leaving out the extension to the add curve menu and make my only change a default to full fill mode/bevel resolution.

I've been made aware that the extra add curve options only make sense in the context of object mode (creating a new curve).