Double-Scoop

[adamsdv]

Allows scoop to be defined as vector to specify 'back' scoop separately, otherwise it is exactly like usual. Scoop can still be a scalar for 'front' scoop only.

Addressing issues #264 & #251

Light modifications to gridfinity-rebuilt-bins.scad to allow configuring scoopB as well as scoopF (which was previously just 'scoop'. 'scoop' then becomes a vector passed to cutEqual and on down through the various included calls.

in gridfinity-rebuilt-utility.scad:
updated the comments documenting "module cut" to match the pre-existing code
slightly modified code to properly handle the existing 't', 's', 'tab_width' & 'tab_height' parameters to use default if undef is passed. (this can help if using the customizer to optionally provide values)

Also, "module cut" now allows double-scoop definition (set scoop to a vector with two values if you want to specify both front and back scoop weights) 'front' and 'back' scoop can be independently set.

Using a scalar scoop, or vector with one value, provides the previous behavior of setting the front scoop only.

"module profile_cutter" is also modified, accommodating scoop weight being a scalar (like previously) or a vector with one or two values for front and possibly back scoop weights.

It now also constrains the profile_cutter's volume, even if scoop weights exceed the normal range.

The attached animation shows a bin cross-section with 1) normal scoop in increments, 2) back scoop in increments, 3) both scoops together in increments, 4) normal scoop to extreme values, 5) both scoops together to extreme values, and a repeat of the same steps with a bin with tab.

[adamsdv]

I was very careful to analyze the module profile_cutter under the various configuration options before making any changes.

[thomasneuberger]

@adamsdv I just tested your branch, ist works like a charm. Love it.

[adamsdv]

I'm glad you found the branch helpful. I'm torn between re-doing all the fixes and feature additions I had done previously, which are now really stranded in 'never-getting-merged-land' since one of the maintainers has decided to overhaul the project. I have a working branch so I think I'm busy enough that I'm not going to work through re-inventing all the fixes and features for the new structure, probably to have them sit for many months waiting again.