MLCad/LPub: buffer exchange issue - help sought

[Alexander Holroyd]

[Also posted on Eurobricks - hope this is OK]

Hi all, Some help/advice would be much appreciated.

Making instructions using MLCad/LPub I am trying to do the following:

1. Early in the build, a part gets partially inserted (specifically a Technic pin with bush 32054)


2. Then many steps (and submodels) later, it gets pushed in all the way.

I cannot be the first person to want to do this.  It is very common in official Lego instructions.

The only ways I can think of to achieve it are:

Either A. Buffer exchange STORE just before it is partially inserted, then just before pushing it in, RETRIEVE, and then repeat all the parts and submodels that were added in the interim, but with all STEP commands and LPUB stuff removed, and then add the part in its final position.

Or B. For every STEP between the initial and final insertion (including the first but not the last) add a new buffer excehange in which this part is redisplayed in its partially inserted position and then removed again after displaying the step.

Either option seems horrendously messy, and requires tricky adjustment of the parts list, and even more so if there are multiple such partially inserted parts to deal with.

My questions are: how do people do this?  Which way is preferred? Is there some better way I am missing?  Am I wanting something unreasonable?

Apologies if this is already answered somewhere, but I have looked and not found...

[N. W. Perry]

There is a newer protocol in LPub3D called "buildmod" that should improve this…but I'm not sure if development was ever fully completed on that feature. If I understand it correctly, once you define a modification (like a not-pushed-in part), you can then APPLY or REMOVE that modification in subsequent steps.

But you're definitely not the first to want this. For a long time I've envisioned a !FLOAT command—which actually turns out to be essentially the same as buildmod, with one critical exception: To me, a key feature of such a system would be that there is only ever one type 1 line per instance of a part in a model. With both buffer exchange and buildmod, you have two (or more) type 1 lines representing the same physical part—one for its position in the finished model, and another for each modified or temporary position in prior steps.

Unfortunately, while I'm very good at envisioning things  I don't have that necessary skills to develop tools to put them into practice. (I could write the instruction manual for the world's greatest LDraw program; I just couldn't even begin to write the program itself!) So for now, !FLOAT remains purely theoretical, while buildmod is at least real and—maybe somewhat—usable.

---

To actually answer your question, though…

What I usually do is your first method, but instead of re-adding a huge mess of parts (everything in the buffer when it was stored), I would probably put them all into a subfile and just add that along with the floating part in its final position. So only two lines of code in the step where the buffer is retrieved.

I actually never thought about using the second way (where the buffer is retrieved and the pin re-added in each step where its position is temporary), but I kind of like it. The problem is that it makes many copies of the same type 1 line, which will result in many duplicates of the part if the model is viewed in a program that doesn't recognize buffer exchange (like LDView or Studio). So you have to have a second version of the file if you want to use it in these programs.

Of course the same problem exists with both methods, it's just that the first way has only one duplicate per part—but for many more parts instead of just the one. I actually wrote a script for LDCad to disable any type 1 lines (by commenting them out) that should be hidden by buffer exchange, so it's easier to create that second file.

[Alexander Holroyd]

There is a newer protocol in LPub3D called "buildmod" that should improve this…but I'm not sure if development was ever fully completed on that feature. If I understand it correctly, once you define a modification (like a not-pushed-in part), you can then APPLY or REMOVE that modification in subsequent steps.

But you're definitely not the first to want this. For a long time I've envisioned a !FLOAT command—which actually turns out to be essentially the same as buildmod, with one critical exception: To me, a key feature of such a system would be that there is only ever one type 1 line per instance of a part in a model. With both buffer exchange and buildmod, you have two (or more) type 1 lines representing the same physical part—one for its position in the finished model, and another for each modified or temporary position in prior steps.

Unfortunately, while I'm very good at envisioning things  I don't have that necessary skills to develop tools to put them into practice. (I could write the instruction manual for the world's greatest LDraw program; I just couldn't even begin to write the program itself!) So for now, !FLOAT remains purely theoretical, while buildmod is at least real and—maybe somewhat—usable.

---

To actually answer your question, though…

What I usually do is your first method, but instead of re-adding a huge mess of parts (everything in the buffer when it was stored), I would probably put them all into a subfile and just add that along with the floating part in its final position. So only two lines of code in the step where the buffer is retrieved.

I actually never thought about using the second way (where the buffer is retrieved and the pin re-added in each step where its position is temporary), but I kind of like it. The problem is that it makes many copies of the same type 1 line, which will result in many duplicates of the part if the model is viewed in a program that doesn't recognize buffer exchange (like LDView or Studio). So you have to have a second version of the file if you want to use it in these programs.

Of course the same problem exists with both methods, it's just that the first way has only one duplicate per part—but for many more parts instead of just the one. I actually wrote a script for LDCad to disable any type 1 lines (by commenting them out) that should be hidden by buffer exchange, so it's easier to create that second file.

Thank you very much for the super helpful reply!

Try as I might I cannot get LPub3D to work. When I can get it to start at all it always crashes long before I can do anything. I admire the effort that has obviously gone into it, but for now it's LPub4 with all its quirks for me.

I had not thought of putting the extra stuff in a submodel. That makes a lot of sense. Also scripts to perform some of these tasks is very sensible - now that I have confirmation I am not being stupid I may do this too.

If we are getting into wishlists it seems that what would really help here would be a command called something like TEMP that would actually like a more general version of Ghost. You would put some parts between TEMP START A and TEMP END A, and they would display as normal. Then later you would say TEMP REMOVE A, and those parts would be permanently removed from the model. And by default such parts would be excluded from the parts list. This would completely solve my problem, and it seems to me it would also make buffer exchange redundant (by being an easier to understand substitute).

[Alexander Holroyd]

PS for my current situation I think I have now managed to find enough workarounds.  But it's still helpful to discuss the general issue.

[N. W. Perry]

Thank you very much for the super helpful reply!

Try as I might I cannot get LPub3D to work. When I can get it to start at all it always crashes long before I can do anything. I admire the effort that has obviously gone into it, but for now it's LPub4 with all its quirks for me.

You're welcome. The good news is, it looks like development has picked back up on LPub3D—for a while, it looked to have been put aside indefinitely. So maybe some of the kinks will continue to be ironed out. (I don't it myself, but I can it continues to fill a need that Studio's Instruction Maker doesn't yet.)

I had not thought of putting the extra stuff in a submodel. That makes a lot of sense. Also scripts to perform some of these tasks is very sensible - now that I have confirmation I am not being stupid I may do this too.

I'm not sure LPub is extensible with scripting the way LDCad is, but you might be able to use scripts in a text editor to modify the source file for some tasks.

If we are getting into wishlists it seems that what would really help here would be a command called something like TEMP that would actually like a more general version of Ghost. You would put some parts between TEMP START A and TEMP END A, and they would display as normal. Then later you would say TEMP REMOVE A, and those parts would be permanently removed from the model. And by default such parts would be excluded from the parts list. This would completely solve my problem, and it seems to me it would also make buffer exchange redundant (by being an easier to understand substitute).

That's essentially what buildmod does, and indeed, it's intended to replace the functionality of buffer exchange (which comes from MLCad originally) with something more intuitive and flexible. The main thing to consider, though, is that these functions are all unofficial extensions to the LDraw spec, meaning that programs don't have to recognize them in order to be fully LDraw compliant.

That's not a problem with the many unofficial meta commands used by LPub—any programs that don't recognize them can just skip them, and if all you need are the unique formatting features of LPub, that won't affect you as a user. But once you start adding valid LDraw code—i.e., type 1-5 lines—that depends on these unofficial commands to display properly, then you get files that don't work correctly in every case.

LDCad (and, for the most part, LPub) gets around this by encoding all of the modified parameters in the meta commands themselves; that way it gets skipped along with the command itself by any programs that don't recognize it. I would propose doing the same with FLOAT or TEMP or buildmod or whatever you want to call it, such as:

Code:

0 !FLOAT id=A ref=1 16 0 -20 0 1 0 0 0 1 0 0 0 1 3001.dat
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
0 STEP

So the modified position of the 3001 brick (just 20 LDU higher) is encoded in the type 0 line with the FLOAT command, and the final position is included in the same step as regular type 1 line. Later in the file, you'd have a command like:

Code:

0 !FLOAT_END id=A

That tells a FLOAT-compliant editor to stop displaying the brick in its temporary position and fall back to its permanent location. At the same time, a program that doesn't recognize FLOAT would only ever display it in its final position.

[Johann Eisner]

Wow, you are still using MLCad. I also started drawing with MLCad a long time ago. Another possibility is to use the “Group” command of MLCad.
The component(s) to be moved later are marked as a group in the first step. Later you can select this group with “0 LPUB! REMOVE GROUPE<“string”>” to remove it.  Then insert the component(s) at the final position and simply ignore them in the component list. I don't know which LPub version you are using, because in the past these meta commands were not supported in some versions. The latest DevOp version supports them, I have tested that.
I have attached a small sample file.
Here the group if defined:

  Define.png (Size: 9.26 KB / Downloads: 22)

Here the group is removed and the (new) part is placed to its final position and ignored in the parts list:

  Remove.png (Size: 9.7 KB / Downloads: 22)