Hi Larry, so for losing the object name - it looks like that's happening because on the result of a boolean where the new object has pieces in it that come from multiple objects, the new object's name will be inherited from the ancestor object that was first selected.

That's so there is a way to control which object will take precedence for keeping the top level name when doing boolean union.

In your script the thing that is different compared to the regular boolean difference command is that the cutting objects are "loose objects" generated inside the script and haven't been added into the geometry database and haven't ever been selected. It happens in that case that it gets the default selection order value of 0 and that makes the "assign top level object name from earliest selected original object" function think that the cutting objects have the priority.

I'll see about using some other method for this situation where some objects have never been selected before, but for the time being if you insert this line indicated with >>> <<< into the script does it clear it up?

    var factory = moi.command.createFactory( 'booleandifference');
    factory.setInput( 0, baseObjs);
>>>    cutters.setProperty( 'selected', true );  <<<
    factory.setInput( 1, cutters);
    factory.setInput( 2, false); // Don't keep objects 
    factory.commit();

- Michael

Hi Michael,

Indeed, selecting the loose cutting objects prior to the boolean difference clears up both the loss of the name as well as the Undo/reload behavior.

I really appreciate your time and insight, but at the same time appreciate that it diverts you from your other objectives. Clearly my hunch that there was some state data leaking and causing unexpected behavior was off base, but it looked to me like there might be an issue worth reporting. To be clear, I don’t want to put you in the position of having to support something I wrote, but I also get that you potentially wind up in that situation regardless of my intentions. I suppose it is part of the blessing and the curse of providing the opportunity for users to contribute to your environment. As I’ve said before, I think that the scripting capabilities are one of MoI’s many stellar attributes.

Thanks again for your willingness to explain and provide background information!!

--Larry

Hi Larry, I'm glad that solved it for the time being! I think I'll update this so that if any of the contributing source objects has never been selected before (which only happens with scripting) it will use the order that the objects have been set on the factory. That should then give a way to control it with boolean union for scripts and also boolean difference will automatically give priority to the base objects over cutting objects since that's in a lower factory input.

Thanks for reporting the problem.

- Michael

Here’s an example of why I wrote this script. I have a modeling project for an old house which has a bunch of windows and doors, many more than I wanted to cut one at a time. So after I created the interior and exterior walls, I drew 2D curves on one side of each wall where there was to be a window or door. The curves were named Windows and Doors and the walls were named Ext. Walls and Int. Walls. I then ran the CutWalls script, selected Int. Walls and Ext. Walls as the base objects, and selected Windows as the objects to subtract, chose 0.75” frames named Window Frames, and Glass for the glass. The script then cut, framed and glazed 39 windows. Next I ran the script again, selecting the walls again as the base objects, but this time selected Doors and didn’t have it put the glass in. The script made 13 door frames. So, all the doors and windows were done in less than a minute. :-)

--Larry

Here’s the before and after:

Excellent!

Hi Pilou,

I added CutWalls-009_fr.zip to the first post in this thread. No changes to the UI, but several fixes to the code from the 0.7 version you've got on your site.
https://moiscript.weebly.com/portes-et-fenecirctres.html

--Larry

Done! :)