LDCad 1.7 Alpha 1 (win+linux)

[N. W. Perry]

I'm revisiting this issue as I'm double checking my todo list.

Doing so I noticed an issue with step part counts which isn't really a bug (I think) but probably very weird to an end user.

In your 8448.mpd?suspFront.ldr from above:

step 13
part cnt in step 21, part cnt in model: 486
step 14
part cnt in step 353, part cnt in model: 834
step 15
part cnt in step 353, part cnt in model: 486
step 16
part cnt in step 5, part cnt in model: 486

This 'feels' wrong but I guess it's actually correct, because:

Step 14 -> you clear the model and add the suspRear model to it.
Step 15 -> you restore step 13 and add the suspRear model to it.

So from the context of step 14 there are two suspRear instances active in the model resulting in the higher model part count.

Just looking for some thoughts about how this should act/work.

Here's how I count these steps:
Step 13: part cnt 19
->less than yours because I count the u-joint as only 1 part
Step 14: part cnt 0
->because I count only parts that exist in the final model
Step 15: part cnt 345
->340 in the suspRear submodel, plus the 5 new parts
Step 16: part cnt 5
->now we're just back to normal, non-buffered building

These are all step part counts. The model count should be always static, in my opinion (but perhaps this could be user-selectable). Likewise, when I count parts per step, I'm only interested in those that contribute to the final total, so I don't count any that will be hidden by buffer exchange. (But I don't think it's wrong for LDCad to count them; obviously if there are parts in a step, you don't want to call it zero!)

As for the static model count, that's what LDCad does currently, and I think it's fine as long as it doesn't double-count parts that should be hidden in a buffer exchange. But I also don't feel it's wrong to do the variable model count as you have it now. Only thing is, shouldn't the model count in step 14 also count the double instances of the five new parts added in that step?