MLCad/LPub: buffer exchange issue - help sought

[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.