LPub3D 2.0 Released

[Trevor Sandy]

I think I found a bug in LPub3D (and Lpub4 as it does the same).

given this ldraw fragement:

Code:

1 14 0 0 -90 1 0 0 0 1 0 0 0 1 3005pt1.dat
1 14 40 0 -90 1 0 0 0 1 0 0 0 1 3005pt2.dat
0 BUFEXCHG A STORE
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 STEP
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 BUFEXCHG A RETRIEVE
1 14 80 0 -90 1 0 0 0 1 0 0 0 1 3005pt3.dat
1 14 120 0 -90 1 0 0 0 1 0 0 0 1 3005pt4.dat
1 14 160 0 -90 1 0 0 0 1 0 0 0 1 3005pt5.dat

LPub will display 4 bricks for the 2nd step. But (imho) it should exclude  3005pe5.dat

I'm not sure about this though, I ran into this when validating the new LDCad 1.6 bufexchg stuff.

Yep - I agree. The PLI should display 3005pt3.dat, 3005pt4.dat and 3005pt5.dat.

I'll take a look.

Cheers,

Roland, I took a look. Basically the issue is if you call BUFEXCHG RETRIEVE after inserting parts in the step, those parts will be overwritten with parts from the buffer.

So here is what happens with each meta command:
  0 BUFEXCHG A STORE: put all parts in the step up to the pont of the command into a buffer.
  0 BUFEXCHG A RETRIEVE: overwrite the current parts list (csiParts) with the parts from the buffer.
If I use your sample:

Code:

1 14 0 0 -90 1 0 0 0 1 0 0 0 1 3005pt1.dat
1 14 40 0 -90 1 0 0 0 1 0 0 0 1 3005pt2.dat
0 BUFEXCHG A STORE
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 STEP
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 BUFEXCHG A RETRIEVE
1 14 80 0 -90 1 0 0 0 1 0 0 0 1 3005pt3.dat
1 14 120 0 -90 1 0 0 0 1 0 0 0 1 3005pt4.dat
1 14 160 0 -90 1 0 0 0 1 0 0 0 1 3005pt5.dat

We can expect for step one three parts will be in the CSI and PLI (3005pt1.dat, 3005pt2.dat and 3005pe5.dat). Two parts are stored in the buffer (3005pt1.dat and 3005pt2.dat)
   

For step 2 we can see the parts from the buffer have been retrieved in the CSI (3005pt1.dat and 3005pt2.dat); however, they correctly do not show in the PLI. We can also correctly see step 2's parts in the PLI (3005pe5.dat, 3005pt3.dat, 3005pt4.dat and 3005pt5.dat) but part 3005pe5.dat is not displayed in the CSI.
   

 That part 3005pe5.dat is missing from the CSI, I believe, is the problem in your example. As stated earlier, this behaviour is because retrieving the buffer overwrites any parts in the CSI list so because BUFEXCHG A RETRIEVE in your example is after the declaration of part 3005pe5.dat; we see this part in the PLI but it is not in the CSI image.

If we move BUFEXCHG A RETRIEVE to be the first declaration in step two. The behavior is as designed.

Code:

1 14 0 0 -90 1 0 0 0 1 0 0 0 1 3005pt1.dat
1 14 40 0 -90 1 0 0 0 1 0 0 0 1 3005pt2.dat
0 BUFEXCHG A STORE
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 STEP
0 BUFEXCHG A RETRIEVE
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
1 14 80 0 -90 1 0 0 0 1 0 0 0 1 3005pt3.dat
1 14 120 0 -90 1 0 0 0 1 0 0 0 1 3005pt4.dat
1 14 160 0 -90 1 0 0 0 1 0 0 0 1 3005pt5.dat

   

You can see above, part 3005pe5.dat is now visible in the CSI. 

If it is your intention to hide a part. You can use the ignore commands as in this example: 

Code:

0 !LPUB PART BEGIN IGN
1 14 490 0 -110 1 0 0 0 1 0 0 0 1 3005pe5.dat
0 !LPUB PART END

I could include logic to check if any parts are declared in the step before the BUFEXCHG A RETRIEVE command but this could get complicated if multiple buffer commands are declared within a step. I think it is ok to just advise that, in a step, one should declare the BUFEXCHG A RETRIEVE first or before any parts are declared.

What do you think?

Cheers,