Instruction making rant

[Daniel R]

I made two instruction for reasonably complex (but not even too big) Technic models, and the process is needlessly painful. So I have a couple of questions and a rant about the future of instruction making software. This is a completely newbie post, so I hope it does not sound too offensive. As English is not my native language it is a little hard for me to write criticism correctly, but I do recognize the seniority of the forum members about these matters. I certainly do not know much about the whole Ldraw software, so I would gladly read explanation why things are done the way they are done. Also some of my nitpicks may be explained by me failing to find some features.

Questions

1. Is there a way to use buffer exchange without pain? How do you insert the BUFXCHG line? I know that you can insert it by dragging it from LDCad part bin (which usually inserts it in a wrong place) or write it manually in the source (which requires to reload the model). What is worse, if you apply buffer exchange to a submodel, you have to copy and flatten the whole submodel later (and also ignore it in PLI).
   
2. What is the relation between Studio part library and LDraw? Do they just copy it or do they contribute something?
   
3. Is there a way to show model from different angle easily? Currently the only way I know is copy the whole model as a subfile, ignore all the parts in the subfile and display it as a callout without arrows. This does not scale well: suppose you have to change something in the beginning of the model, then you'll have to change all the copies too.
   

Rant

In my opinion, if we want to keep anyone use open software and not Studio (which is also somewhat slow, buggy, closed-source and uses proprietary format), LPub3D and LDCad should be way better. My feeling is that now all new users come to Studio, as it is actually usable.

LDCad is really great, it works very fast, even with huge models and on weak computers, its GUI is really effective and documentation is good. I have only minor nitpicks about it:

• You can't pin compass window. I don't really need the whole compass, it is too big anyway. But I do need the the ASR/NSR switch because if ASR is enabled you can lose current orientation by switching steps, so I constantly check the switch.
  
• You need to go to the outer submodel to check the flexible part length
  
• Flexible nets are not supported
  
• I know you can make part bin with colors (even with counts, that is very cool, much faster than Studio), but it would be useful to quickly change color bin selection to only physically available colors for the part. Maybe even make such mode default, but quickly switchable to current mode.
  

At the same time, LPub3D experience is terrible, some of that is due to the current implementation and some is due to general design choices (IMHO).
The worst thing is speed. It usually take more than a full minute to render an new page after the next button click. Than is on a decent hardware IMO (quad-core i7-8650U, NVMe storage, more than enough RAM). "Convert to callout" can take several minutes, and even right mouse click can take several seconds to actually show the menu. LDCad is capable of displaying models in real time with reasonably high FPS, so that is definitely possible.

The whole thing is buggy, it crashes regularly, once it deleted a whole subfile. There are a lot of minor bugs in the current implementation, to name a few:

• Part annotations do not show in callouts
  
• Output depends on platform and environment
  
• Incorrect BOM with REMOVE GROUP
  
• BOM looks terrible compared to official ones (I tried many sorting options, it all looks wrong and unreadable)
  
• Export to rebrickable and bricklink works not flawlessly
  
• LPub crops images with small camera distance, so it is not possible to pan to specific part of a model
  
• LPub inserts another submodel preview on every page of multi-page submodel if the page is a multi-step
  
• Part annotations are only inserted once per part
  
• Submodel-level colors work not quite the same way as they do in the official manuals
  

The whole LPub3D automatic layout and margin management is hard to use. Even small movement makes several elements to change position, so it is very hard to place elements, especially with enormous redraw times. I end up using absolute (page) position. The whole relative element placement is very frustrating, it is hard to control.

LPub multi-step layout and margins look very wrong (compare https://imgur.com/5DYF5Cx and https://i.imgur.com/kYRTVWf)

Lack of full spec does not help (https://trevorsandy.github.io/lpub3d/ass...mands.html is partially incorrect)

I believe if I had such problems with LPub it is hard to maintain so big thanks to Trevor for doing this. I opened several issues and made some minimal contributions on the Github and Trevor provided very quick answers and edits. But I spent some time even figuring out how to build it to make minimal changes to the code. I think simpler build process and more instructions would be helpful.

Future

As for the future of LPub and LDCad, I have some thoughts about features which would make the process easier and make some competition with Studio possible.

LPub3D default settings should follow current Lego visual language (colors, fonts, margins, rotation icon look, BOM sorting order, line width, which parts use annotations and which don't). The default output should look like 42111 instruction, not like some adhoc script output.

LDCad, preferably, should have ability to store zoom and pan steps and display them in same way in does with ROTSTEPs

Rotation icon should be inserted automatically if the next step is a ROTSTEP (with an option to suppress this default)

I'd like to make callouts with complex shape (see https://imgur.com/ixTDV8b) and more complex callout arrows (https://imgur.com/41eIKeo) easier. Also it would be nice to allow to have submodel last step and its application on same page with a divider, (see https://imgur.com/QGdf5kb)

Maybe subfile header should include part substitution info. As usually you don't need the whole flexibility of PLI BEGIN SUB, as you don't replace arbitrary subsets of a model with arbitrary parts, you only need to replace a submodel with bent part with it's original state. Moreover, even if the said submodel is used multiple times, it is always replaced with the same part. I know that LDCad has partName and partDescr metas (which are not used anyway), but this could also be used with universal joints, shock absorbers, hinges and other parts.

Both current possibilities to change assembled model, BUFEXCHG and REMOVE GROUP are hard to use (unless I am missing something) and limiting. Official instruction use them all the time, see the beginning of 42082 manual (https://imgur.com/jgzpMnd), it is quite time consuming to replicate such steps. Also sometimes you need to rotate parts of a model, move pins or connect cables or tubes. I don't have any ideas of a new syntax for this. Maybe the problem is that the current mechanism is too generic, as you really don't replace random parts with some other random parts, you only substitute the same parts with different positions, and you very rarely need to actually remove parts. I'm not saying saying it shouldn't be supported though

LDCad should have arrow generator, similar to current path generator, so that such arrows (https://imgur.com/bOJdK71) could be made easily.
Generally, there should be two kinds of arrows, "real arrows" and "sprite arrows" (I am not sure whether it is a correct name).
Real arrows should be parts, maintained and distributed officially by LDraw. As LDraw aims to make an official Lego part library with all (and only) official parts produced by Lego, it is reasonable to also maintain official design elements. Instruction designers will have a unified set of them, so they don't have to ship their custom arrows with the instruction. Big yellow arrows used to move parts of a model (https://imgur.com/D6iyDpb) should also be included as parts. Highlighting frames and circles such as https://imgur.com/Ag5Te9E could also be included.
Sprite arrows should be generated by LDCad (they could be straight, maybe aligned to relative grid or curved, exactly the same as paths like cables and tubes) and rendered by LPub in such way that the arrow always faces the camera and always has the same width.

[Roland Melkert]

It's kinda late here, so I'll look into the whole post tomorrow.

1. Is there a way to use buffer exchange without pain? How do you insert the BUFXCHG line? I know that you can insert it by dragging it from LDCad part bin (which usually inserts it in a wrong place) or write it manually in the source (which requires to reload the model). What is worse, if you apply buffer exchange to a submodel, you have to copy and flatten the whole submodel later (and also ignore it in PLI).
   

You writing "which usually inserts it in a wrong place" makes me suspect you're not yet discovered the source window which allows inserting and moving of otherwise invisible content.

You open one with "views/new source window", and if needed dock it by holding down the ctrl key while moving it around.

[Philippe Hurbain]

Is there a way to show model from different angle easily? Currently the only way I know is copy the whole model as a subfile, ignore all the parts in the subfile and display it as a callout without arrows. This does not scale well: suppose you have to change something in the beginning of the model, then you'll have to change all the copies too.

If I understand correctly what you want, you need to use ROTSTEP to change viewpoint of your current view. Note that ROTSTEP is to be placed at the END of the step you want to display with another viewpoint.

ASR/NSR switch because if ASR is enabled you can lose current orientation by switching steps, so I constantly check the switch.

That's something I almost never use... but there is a defined keyboard shortcut (b) that you can customize if needed.

Flexible nets are not supported

Tough problem, this has been asked for several times...

I know you can make part bin with colors (even with counts, that is very cool, much faster than Studio), but it would be useful to quickly change color bin selection to only physically available colors for the part. Maybe even make such mode default, but quickly switchable to current mode.

This needs a properly updated database of available colors for a given part. Possible by tapping in external inventories websites, but it create a dependancy to that website...

The worst thing is speed.

I definitely agree with you, but have you tried to use LPub3D native renderer? Not a panacea as it comes with some other issues (scaling management), but it's definitely faster. Still, it's still not that fast in some cases, I'm currently struggling with it for a model that includes large Technic baseplate: takes a while...

[Daniel R]

I discovered the source window but as I already had a text editor with the model file opened, I didn't see value in it. It indeed does not reload the whole model when you reorder lines so thank you! It makes life better

[Daniel R]

If I understand correctly what you want, you need to use ROTSTEP to change viewpoint of your current view. Note that ROTSTEP is to be placed at the END of the step you want to display with another viewpoint.

No, I failed to explain what I want. See this page from 42082 instruction

The only way of producing this I know is to make a separate submodel with this view and display it as a callout without arrows. This is a very bad pattern, as it requires copying all the parts, making it hard to make changes in that part of the model.

That's something I almost never use... but there is a defined keyboard shortcut (b) that you can customize if needed.

That shortcut is partially the reason of my problem. I use it all the time, and, as I don't open the compass window to use it, I sometimes don't remember the current state of this switch. Because if it is on, you can lose your carefully chosen orientation by switching steps.

This needs a properly updated database of available colors for a given part. Possible by tapping in external inventories websites, but it create a dependancy to that website...

That is not a problem at all. What this needs is API support from LDCad, namely an ability to change color bin contents based on current selected part and external configuration. Also this should be quickly enough not to annoy the user by high latency but with the configuration file loaded and preprocessed in advance (on LDCad start) it should not be hard. The configuration file itself does not need to change more often than three or four times a year and its current version could be shipped with LDCad the same way the shadow files are shipped. The data itself can be easily grabbed from Rebrickable. Because this would be a plain text configuration file (as all LDCad configs are), the users can make updates themselves.

I definitely agree with you, but have you tried to use LPub3D native renderer? Not a panacea as it comes with some other issues (scaling management), but it's definitely faster. Still, it's still not that fast in some cases, I'm currently struggling with it for a model that includes large Technic baseplate: takes a while...

Yes, I use the native renderer. I used LDView previously as I couldn't use the native one due to some bug, but the bug was reported to Trevor and fixed. It still sometimes requires more than one full minute to show the next page

[Philippe Hurbain]

The only way of producing this I know is to make a separate submodel with this view and display it as a callout without arrows. This is a very bad pattern, as it requires copying all the parts, making it hard to make changes in that part of the model.

Got it. For this I make a snapshot of the needed area (generally with LDView) and insert the image in LPub3D. But that also duplicates data and also make changes tricky...

Yes, I use the native renderer. I used LDView previously as I couldn't use the native one due to some bug, but the bug was reported to Trevor and fixed. It still sometimes requires more than one full minute to show the next page

I solved my large technic baseplate (39369) problem by temporarily removing all of its subparts from Lpub3D library archive. This makes editing possible again, I'll restore these files for final rendering... and report the problem to Travis!

[Johann Eisner]

The worst thing is speed.

I think the speed problem is more of a graphics card problem.  I use a slightly older notebook, and I don't care whether I use Native or LDView.  Both are equally fast (slow).  The only difference is that I have LDView running much, much more stable.  I also don't like the auto-zoom behavior of the native renderer.

[Philippe Hurbain]

Both are equally fast (slow)

For me, (and a friend who makes BIG Technic BIs) native renderer is MUCH faster (or should I say much less slow? )

I also don't like the auto-zoom behavior of the native renderer.

I hate it!!!

[Jaco van der Molen]

Hi Daniel, I see you are new here, so welcome to the LDraw community!

To answer some of you questions, here goes.

Buffer exchange is a pain, no way to soften that. Surely if you are depending on it heavily like in technic model instructions.
It originated from MLCad and was implemented later in LPub(3D) and LDCad.
To work with it and understand fully, please refer to one of the many tutorials that are out there, like mine:
https://sites.google.com/view/workingwit...r-exchange

Maybe you can study my showcase Technic set 42061 - Telehandler model too.
https://sites.google.com/view/workingwit...d/showcase

These instructions feature some of your wishes and might answer some of your questions too, I think.

As for the software development: you know this is done by hobbyists and comes as is.
I do agree that there are missing features and some could be improved or added.
But we are dependent on the authors of the software and the amount of time and effort they are willing to put in to it.

Development of LDCad is still going strong.
Development of LPub3D has come to a hold it seems.

What version of LPub3D do you use? I do not experience that many crashes. In fact, almost none.

You say "LPub3D default settings should follow current Lego visual language". Why? If you want to mimic exact LEGO instructions you can make your own "template".
I have a whole set of standard settings I just copy in the LDraw file before I start editing in LPub.
But most of the time I try making my own style for instructions though.

Render speed: I start going through the whole model using the native renderer, not creating any callouts, multi step pages, etc. Just go through it to see if the whole building process seems logic. I try to make as much instruction logic while modelling.
Once that is done, I start thinking of callouts. I add the metacommands for those manually to speed things up. Much faster than directly in LPub.
Once happy with the way things look, I start using LDView as rendere and finish instructions. Then often edit the PDF or PNG's manually.

Callouts with complex shapes like your example won't be done any time soon. This is too complex. Again: we depent on the developer of LPub3D and like said that has come to a hold it seems.
Complex callout arrows can be done.

Submodel last step and its application on same page with a divider should somehow be possible, but I haven't figured that one out.

You state that BUFEXCHG and REMOVE GROUP are hard to use. You are right about that. These are very complex and advanced features and hard to learn techniques.

IMHO I think you expect too much of the software. We could never make official LEGO like instructions, but can get very close.

Still, your wishes and ideas are very good.

[N. W. Perry]

Buffer exchange is a pain, no way to soften that. Surely if you are depending on it heavily like in technic model instructions.
It originated from MLCad and was implemented later in LPub(3D) and LDCad.
To work with it and understand fully, please refer to one of the many tutorials that are out there, like mine:
https://sites.google.com/view/workingwit...r-exchange

There's something I wonder about in that tutorial—you mention a couple of times that the BUFEXCH_STORE command is used to "store" the hovering parts in the buffer. But isn't it true that what's actually being stored is the view up until that point—in other words, everything before you start to add hovering parts?


So the sequence goes like this:

• You build your model up to a certain point, then "store" that building state in the buffer, like a save point in a video game.
  
• You add some new parts that you plan to change in some way later—move them, or not display them at all, etc. These are simply added to the building state you had so far.
  
• You then "retrieve" the building state that you stored—essentially, you "revert" to the save point (losing all changes made since then).
  
• You continue building from your saved state, first by adding those same new parts in their changed condition (moved, or just not shown, etc.).
  

Is that an accurate understanding of the process?

I see why it makes sense, though, to think of the hovering parts themselves—everything between the STORE and RETRIEVE commands, essentially—as being the "buffer". But maybe there are other use cases where it helps to go by the "save" and "revert" concept instead.

[Jaco van der Molen]

...but isn't it true that what's actually being stored is the view up until that point—in other words, everything before you start to add hovering parts?

I have absolutely no idea. I've never fully understood how it works.
The way I describe it is my interpretation.

Only recently I discovered the usage of other letters the A for a buffer (see my showcase model for the Telehandler)

So I guess you can put it the way you say too. No clue however.
Maybe someone can enlighten us?

[N. W. Perry]

I have absolutely no idea. I've never fully understood how it works.
The way I describe it is my interpretation.

Only recently I discovered the usage of other letters the A for a buffer (see my showcase model for the Telehandler)

So I guess you can put it the way you say too. No clue however.
Maybe someone can enlighten us?

Yep, buffer exchange and rotation matrices—the two holy grails of LDraw. ;-)

I have a specific use case in mind for buffer exchange, in fact, based on a recent convention in official building instructions. The habit these days is to show a sub-build of a model as part of the main step sequence, rather than a series of sub-steps. So for several steps in a row, the main model will be hidden while the sub-build is constructed, then the last step in that group will be placing the sub-build where it belongs in the main model.

So I'd like to work out how to achieve this in buffer exchange, which I assume is just a matter of using the CLEAR meta right after the first STORE command. (I should note that I don't actually create instructions; rather, I try to replicate the build process in the model file itself.)

EDIT: Actually, I guess not—LDCad doesn't seem to recognize the CLEAR meta. Instead, you'd put the STORE command at the very top of the model, before anything's added. Then once you get to the sub-build, you'd first STORE the build so far into a second (B) buffer), then insert a RETRIEVE A command to bring back that first (empty) build state.

[Philippe Hurbain]

Is that an accurate understanding of the process?

This is exactly how my mind sees Bufexchg process...

[Merlijn Wissink]

Over the years I've made many instructions, small and large and I agree with most of your points. Yes, making (large) instructions can be a (needless) pain sometimes.
I think most of them stem from endless backwards-compatibility and a lack of organized teamwork between LDCad and LPub3D.

LDraw is an old format, and lots of things work, no offense, kinda old-fashioned. And a lot of things stem from concepts made 15-20 years ago. LDraw is very focused on backwards-compatibility and that's a good thing, don't get me wrong. But sometimes, it becomes too much and there just has to be drawn a line somewhere. For example, in the case of buffer-exchange: just throw it out the window and start with something new. Thing is, it takes ages to draw that line, if at all. I mean, how long did it take to finally get texture-mapping spec fully done and working   Not to mention that an 'LDraw 2.0' discussion pops up every now and then for years I feel like, but it never leads to anything except discussions. We still don't have any official snapping-metadata right?

So, everything just goes along as it used to. And now it's getting passed by newer initiatives like stud.io or mecabricks. They're more modern, easier to work with, have a lower learning curve and have all kinds of fancy new features. Sure, it's certainly not as flexible as LDCad + LPub3D and that's the reason I still use that combination for everything I do, but it's not hard to imagine that with time there will be more feature-parity.

I've used LDraw for instructions for years and I see no reason to stop doing that for the years to come. But, I am used to it. I don't know any better. I know all the ins and outs, my workflow is 'perfected'. But it's also not hard to imagine that, as things currently go, it'll end at some point and I just have to move on to something else if things don't change.

But it's certainly not all hell and damnation. There is great improvement too. LPub3D has made some great progressions last years when Trevor took over the code. Compared to the old LPub4 it's miles better and I can't imagine using LPub 4 nowadays. LDCad brought new life into the LDraw CAD world, with fancy features and good support. This is not meant as a rant or anything, don't get me wrong. I love LDraw and it's all volunteering work of course and I have nothing to complain. The work that everybody puts into it is amazing.

[Roland Melkert]

EDIT: Actually, I guess not—LDCad doesn't seem to recognize the CLEAR meta. Instead, you'd put the STORE command at the very top of the model, before anything's added. Then once you get to the sub-build, you'd first STORE the build so far into a second (B) buffer), then insert a RETRIEVE A command to bring back that first (empty) build state.

I never seen a CLEAR meta used with bufxchg, it isn't mentioned in MLCad documentation ether.

Is there any documentation available on its goal/usage, so I might add support for it in 1.7.

[Orion Pobursky]

For example, in the case of buffer-exchange: just throw it out the window and start with something new.

Well, none of these META commands are official. Buffer exchange, for example, came from MLCad. Nothing is stopping someone from creating a new instruction language using LDraw as a base. The problem is that you have to do the legwork and actually create the program to go along with it and this is where things fall apart. I look forward to the day that another Kevin Clague comes along, has a need, and creates the successor to LPub.

[N. W. Perry]

I never seen a CLEAR meta used with bufxchg, it isn't mentioned in MLCad documentation ether.

Is there any documentation available on its goal/usage, so I might add support for it in 1.7.

All I know of it is what's in the official File Format, which is, in its entirety:

Clear

Clears the screen

Format:
0 CLEAR

This command causes all previous drawn sub-files and line types to be cleared (erased). Any following line types are drawn as normal.

But it seems like it should work, as:

Code:

<some building steps>
0 BUFEXCHG_STORE
0 STEP
0 CLEAR
<some new parts>
0 BUFEXCHG_RETRIEVE
<building continues…>

But my other way seems to work fine, too (storing the empty model and retrieving it when isolating a sub-build).

[Jaco van der Molen]

Well, none of these META commands are official. Buffer exchange, for example, came from MLCad. Nothing is stopping someone from creating a new instruction language using LDraw as a base. The problem is that you have to do the legwork and actually create the program to go along with it and this is where things fall apart. I look forward to the day that another Kevin Clague comes along, has a need, and creates the successor to LPub.

The development of LPub3D indeed has come to a hold.
Has anyone heard from Travor Sandy lately?

[Roland Melkert]

All I know of it is what's in the official File Format, which is, in its entirety:


But it seems like it should work, as:

Code:

<some building steps>
0 BUFEXCHG_STORE
0 STEP
0 CLEAR
<some new parts>
0 BUFEXCHG_RETRIEVE
<building continues…>

But my other way seems to work fine, too (storing the empty model and retrieving it when isolating a sub-build).

O wait it's just 0 CLEAR I was thinking about 0 BUFXCHG CLEAR.

0 CLEAR is a very old (pre 3d card) meta.

It seems in LDCad you can also just use a BUFXCHG Z RETRIEVE (or some other unused latter). Not sure if that's standard behavior though. So I could probably add support for CLEAR by making it an alias for that using a 27th 'letter'

[Daniel R]

I think the speed problem is more of a graphics card problem.

I assumed it is not a graphics card problem, as the task is quite simple and it is clearly possible to display models in real time. LDCad does it. But indeed, I currently do not have a proper video card (intel-whatever in 8650U does not count), so I would be glad if someone with one confirms that LPub3D can display 1000+ part models quickly

[N. W. Perry]

So, everything just goes along as it used to. And now it's getting passed by newer initiatives like stud.io or mecabricks. They're more modern, easier to work with, have a lower learning curve and have all kinds of fancy new features. Sure, it's certainly not as flexible as LDCad + LPub3D and that's the reason I still use that combination for everything I do, but it's not hard to imagine that with time there will be more feature-parity.

With Studio at least, there's a serious caveat to go along with this assessment. When I started using it, I also thought it was the panacea it's often said to be. But before long, I ran into a pretty firm wall where I just couldn't go further with the program, because I'd either reached the limits of its capability, or needed a feature that simply does not work (*ahem*flexible parts*cough*). Combining those things with Studio's essentially closed-source nature, I just wasn't able to do enough poking around under the hood the way you can with a true LDraw program.

There seems to be a good-sized community of people using Studio who are in a similar boat. Many of them are not computer experts or developers at all and are attracted by Studio's robust feature set and user-friendly interface. They're often vaguely aware of LDraw but understand it to be a rather arcane, inaccessible system. But the problems and questions with Studio that arise are almost invariably ones that LDraw has already solved, and solved powerfully. So a lot of these users begin, reluctantly at first, turning from Studio to LDCad or LPub, rather than the other way around. And I think a fair number start to see that LDraw actually can be accessible, perhaps much more so than Studio, especially if you need to solve a problem yourself rather than waiting for someone else to do it.

But, your point is well taken that, if Studio does get an influx of interest and effort in its development, with the intent of making it a really top-tier piece of software, it could be better positioned to "corner the market" than trusty ol' LDraw.

[Daniel R]

To work with it and understand fully, please refer to one of the many tutorials that are out there, like mine:
https://sites.google.com/view/workingwit...r-exchange

Maybe you can study my showcase Technic set 42061 - Telehandler model too.
https://sites.google.com/view/workingwit...d/showcase

I did study your tutorials, thank you very much for them! They are the best I could find. In fact, I used your arrows you shipped with your instruction package. I am not sure whether it would be of any interest, but the two instructions I mentioned in my first post are https://rebrickable.com/mocs/MOC-41774/G...herr-l550/ and a bigger Technic crane (2500+ parts, power functions, not published yet to Rebrickable, I hope it will be soon). I can share both of them with forum members if for some reason you would be interested

What version of LPub3D do you use? I do not experience that many crashes. In fact, almost none.

I used the latest CI build from Github. It is true though that it crashes more than builds from some time ago.

You say "LPub3D default settings should follow current Lego visual language". Why?

Because it would make our generated instructions look more professional as they would look closer to the real thing. Studio currently doesn't do this. I also have a set of settings which (almost) achieve this goal, I am just saying it should be the default. It is a minor point though

... I add the metacommands for those manually to speed things up...

I also converged to a similar process, after doing all the ROTSTEP's in LDCad, which is fast, I try to add callout, rotation icon and other metas in a text editor not to wait for the LPub to render the page.

You state that BUFEXCHG and REMOVE GROUP are hard to use. You are right about that. These are very complex and advanced features and hard to learn techniques.

I am not saying they are hard to learn. I am saying the require a lot of manual work and lead to bad patterns. For example, if you need to attach a cable from a motor to a battery box, you need to remove the whole motor subassembly and flatten it in the step the cable gets connected. Same goes for rotating parts of a model. I think this is due to poor design of these functions (I know they are about a century old, nevertheless).

IMHO I think you expect too much of the software

That is my problem indeed

[Daniel R]

I have a specific use case in mind for buffer exchange, in fact, based on a recent convention in official building instructions. The habit these days is to show a sub-build of a model as part of the main step sequence, rather than a series of sub-steps. 

While you can replicate this with BUFEXCHG, LPub3D now has a setting to enable continuous step numbering, so you can use submodels as usual. I think it is much easier

[Daniel R]

Only recently I discovered the usage of other letters the A for a buffer (see my showcase model for the Telehandler)

I think you are referring to this fragment

Code:

1 71 0 0 -150 -1 0 0 0 0 1 0 1 0 92907.dat
0 BUFEXCHG A STORE
1 71 -40 -20 -130 1 0 0 0 1 0 0 0 1 4519.dat
1 71 -40 0 -130 1 0 0 0 1 0 0 0 1 4519.dat
0 STEP
0 !LPUB MULTI_STEP DIVIDER
1 72 0 0 0 0 0 -1 0 1 0 1 0 0 18942.dat
0 BUFEXCHG B STORE
0 !LPUB PART BEGIN IGN
1 4 -30 -20 -102 0 0 -1 -1 0 0 0 1 0 a4.ldr
0 !LPUB PART END
0 !LPUB PART BEGIN IGN
1 4 -30 0 -102 0 0 -1 -1 0 0 0 1 0 a4.ldr
0 !LPUB PART END
0 STEP
0 !LPUB MULTI_STEP END
0 BUFEXCHG B RETRIEVE
0 BUFEXCHG A RETRIEVE
0 !LPUB PLI BEGIN IGN
1 72 0 0 0 0 0 -1 0 1 0 1 0 0 18942.dat
1 71 0 0 -130 1 0 0 0 1 0 0 0 1 4519.dat
1 71 0 -20 -130 1 0 0 0 1 0 0 0 1 4519.dat
0 !LPUB PLI END
1 72 -25 60 -130 0 1 0 0 0 -1 -1 0 0 32250.dat
0 STEP

I think it doesn't make any sense here to use buffer B, it has no effect. Could you please explain this?

In fact, I cannot think of any reasonable use of multiple buffers

[N. W. Perry]

LDraw is an old format, and lots of things work, no offense, kinda old-fashioned. And a lot of things stem from concepts made 15-20 years ago. LDraw is very focused on backwards-compatibility and that's a good thing, don't get me wrong. But sometimes, it becomes too much and there just has to be drawn a line somewhere. For example, in the case of buffer-exchange: just throw it out the window and start with something new.

You know, I've often wondered why buffer exchange was such an awkward system. But then, I'm not a developer, so I don't always understand what it takes to do some of these things. Maybe it had to be this way, at least back then?

But yeah, it's not hard to envision something new. I can imagine a fairly simple set of commands that are easier for the user to grasp, and perhaps more targeted to specific use cases.

For the common problem of hovering parts, I feel like you'd just need something that affects the next line only, like:
0 !FLOAT [0 -20 0 1 0 0 0 1 0 0 0 1]
1 15 0 0 0 -[font=Courier New]1 0 0 0 1 0 0 0 -1 3001.dat

[/font]So the FLOAT command would provide a temporary pos/ori matrix, which would be applied to the part in the following type 1 line, up until the next STEP command. After that, it would be drawn in its normal position.

For parts that need to hover for more than one step, you could either devise a BEGIN and END system, or just add a parameter [n] to the FLOAT line, telling it to use that matrix for the next n steps. (And maybe a negative [n] could mean to hover until step number n is reached.)

You could also include a color reference in the FLOAT line, to allow the part to temporarily be shown in a different color, or even reference a different subfile—in short, an entire type 1 line to be used temporarily. And a good editing program could allow the option to automatically draw arrows or lines from the float position to the fixed location.

---

Now, for the other use case, of hiding the main model while focusing on a sub-build, you could use the existing CLEAR meta, and then add an UNCLEAR command, which would re-draw everything that had been erased by the previous CLEAR command. (Or you could use different names for these commands, like HIDE_ALL and UNHIDE_ALL.)

Again, it's easy to envision, but maybe hard to put into practice. I wouldn't be surprised if the way to do this behind the scenes is exactly what buffer exchange already does. But the syntax on the front end might be something a little more meaningful for the less-experienced user…or the ambitious MOCer who just want to create some kickass building instructions for his latest mecha or NCS masterpiece! 

[Daniel R]

IMHO I think you expect too much of the software. We could never make official LEGO like instructions, but can get very close.

Perhaps I do expect too much of the software. But I'd like to have a usable and open alternative to Studio and I'd like to make the instruction making process easier and more appealing to new users.

LDraw is an old format, and lots of things work, no offense, kinda old-fashioned. And a lot of things stem from concepts made 15-20 years ago. LDraw is very focused on backwards-compatibility and that's a good thing, don't get me wrong. 

Maybe I am wrong here, but I think we can allow more breaking changes than other areas (see python2), as instructions mostly do not have any dependencies and I think mostly are started as new projects. So it is more acceptable to introduce some new syntax. Again, maybe I am wrong here.

I tried reporting all the bugs to LPub3D github and suggesting minor edits but I think there are some design flaws which have to be addressed first. I would love to contribute to LDCad code but it is closed and I respect this Roland's decision. Still, if this changes I would gladly contribute there (for instance, I can do some minor features which are thought to be necessary).

When I read Roland's suggestion to support all LPub metas, I immediately pictured a new edit mode in LDCad, similar to view or nested mode, where steps represent instruction pages and you can combine 2d editing by dragging inventory and callout baloons, arrows, dividers and labels with 3d editing of the actual model and camera position. But then I thought that supporting all LPub3D commands would not be a good idea. Some of them are frustrating (see my comments about auto layout and relative element placement above) and some are leaky abstractions.

So I came to this forum because, as I understand, this is the place where the LDraw and LDCad development is planned. I think it would make sense to discuss this new syntax as I am not sure about the best design.

So while some parts of my first post are suggestions for the next LDCad version, namely

• Some way to make the ASR/NSR indicator always visible
  
• Make flexible part length visible inside the nested submodel
  
• Support to change color bin contents based on current selected part and external configuration
  
• Arrow generator
  

and some parts are suggestions to LDraw community, namely

• Include arrows in the official library
  
• Make convention to include the substitute part name in the subfile header (see arguments for this in the first post)
  

most of them are suggestions to discuss some new syntax.

The ability to store zoom and pan steps could be implemented as an extension to ROTSTEPs. Also this could be thought not as pan and zoom but as camera center and camera distance. For instance

Code:

0 ROTSTEP 23 45 0 ABS CENTER 1 2 10 ABS DISTANCE 200 ABS

or

Code:

0 ROTSTEP 0 0 0 REL CENTER 0 0 0 REL DISTANCE 20 REL

just to zoom in a little. Maybe this is a bad suggestion, but I think it would make sense to edit this things in a true 3D editor, not in some kind of instruction generating program (whatever that would be).

As for buffer exchange and remove group alternative, I think it should be less flexible.
Maybe it should reuse existing LDCad grouping capabilities, maybe like this

Code:

0 !LDCAD MOVE GROUP "group name" x y z a b c d e f g h i

This would not create any new parts but would move existing (which is what we do in real life).

In fact, I am thinking about new LDCad mode, let's call it provisionally "move mode", in which moving parts would not move them in the model but instead would insert these line in the current step and also would add GROUP_NXT and GROUP_DEF lines automatically should one attempt to move parts which were not in group. For clarity, you can prohibit adding new parts in this mode. Some kind of REMOVE GROUP statement should also be supported and interactively displayed by LDCad but the necessity for it would be much less with the ability to move groups.

With this suggestion it is not quite clear how multi-part groups should be handled. Perhaps they should be moved and rotated as a whole, using group center.

Ideally, if a group is a flexible path start, MOVE GROUP statement should regenerate the whole path. But what should happen to the fallback code in this case?

Of course, for this to work flawlessly it should be possible to move and remove groups in subfiles (for instance, you have a subassembly with a flexible part and later you want to connect its end somewhere). So a "nested move mode" is also needed.


Maybe all this was already discussed (could you please refer me to that discussion?). Otherwise, what do you think?

[Daniel R]

For parts that need to hover for more than one step, you could either devise a BEGIN and END system, or just add a parameter [n] to the FLOAT line, telling it to use that matrix for the next n steps. (And maybe a negative [n] could mean to hover until step number n is reached.)

A very minor nitpick: I don't think [n] would be a good idea, as it is hardcoding, which we are trying to get rid of.

[N. W. Perry]

So while some parts of my first post are suggestions for the next LDCad version, namely

• Some way to make the ASR/NSR indicator always visible
  
• Make flexible part length visible inside the nested submodel
  
• Support to change color bin contents based on current selected part and external configuration
  
• Arrow generator
  

Note that I did make the suggestion in the LDCad thread about displaying flexible part length. I'd been thinking of it for a few days before you mentioned it, so I thought the time was right. :-)

[N. W. Perry]

A very minor nitpick: I don't think [n] would be a good idea, as it is hardcoding, which we are trying to get rid of.

What would be a better way?

[Johann Eisner]

I have long considered writing anything here.
I am personally very satisfied with the programs.
Of course there are always improvements and I think
every programmer has his own way of writing programs,
but don't forget that this is a page,
where all users sacrifice their free time and make everything free of charge.
The other way around, not even the multi-million dollar Micro.... Corporation manages to write software,
which enables all users to work efficiently because everyone has a slightly different approach.
Improvements or changes are not always a step forward.
If really so many "new" commands should be programmed in LDCad,
then LPub3D must also be adapted to support it.
I've seen MLCad and LPub evolve into LDCad and LPub3D,
and at the beginning I couldn’t imagine changing at all.
Old school MLCad/LPub user.  
So I get along very well with the BUFEXCHG command,
because let's face it, how often is it really used in a model?
I'm currently drawing a Technic MOC with about 14,000 parts, (yes 14 thousand)
and maybe needed the command 5 times.
And I still believe that the MOC is buildable.
There are always ways to solve problems.

[Daniel R]

What would be a better way?

I described my vision (which is similar yours) in the following message. I am not saying it is the way, but I think it is easier to implement in LDCad and applies to more situations. On the other hand, it requires more boilerplate (all these group definitions) and maybe it is a bit less logical (because it requires first to place part in a wrong (temporary) location and only then move it to the correct location).

Specifically, I dislike the number of steps suggestion because steps order and count can change and you would need to correct all these numbers.

[N. W. Perry]

I described my vision (which is similar yours) in the following message. I am not saying it is the way, but I think it is easier to implement in LDCad and applies to more situations. On the other hand, it requires more boilerplate (all these group definitions) and maybe it is a bit less logical (because it requires first to place part in a wrong (temporary) location and only then move it to the correct location).

The MOVE GROUP meta, you mean? Yes, I do see how that could apply to the same situation. But one of things I was thinking of with FLOAT is that it very simply addresses the common need to hover a single part. I actually took the presumption the "applies to more situations" would be objectionable rather than desirable, because as you note, it leads to fairly convoluted syntax situations, which is something we want to get away from with buffer exchange.

That being said, if you wanted to float multiple parts, you could always place a submodel in the following type 1 line. Or to make use of LDCad groups, perhaps there's a way to reference a group in a type 1 line—but another presumption I made (and didn't say out loud) is that we'd want to limit ourselves to one ref line per part used (to avoid having to adjust the parts list/BOM, etc.). With buffer exchange, you have to reference each part twice (or more).

So perhaps that could be another parameter in the FLOAT line itself—i.e., "float the next part referenced and any group it's part of"?

Specifically, I dislike the number of steps suggestion because steps order and count can change and you would need to correct all these numbers.

Yes, of course either the software or the user would have to keep track of that. Of course, the parameter would be configurable, so at the end of your workflow you could easily adjust a part's float settings. Anyway, I think the general preference would be towards including an option and letting the user disable it if need be, rather than just denying the option in the first place.

To be sure, perhaps the parameter argument is not the best solution. Would your MOVE GROUP command have some way to handle multi-step hovering, or would it just not allow for this possibility?

[Daniel R]

I actually took the presumption the "applies to more situations" would be objectionable rather than desirable

That is correct. Nevertheless, there should be some mechanism for all use cases. Maybe there should be different mechanisms, I don't know. These use cases are:

• Simple hovering of parts used in this step
  
• Movement of parts attached some time ago 
  
• Connection of flexible parts ends
  

Unfortunately, sometimes you need to rotate of move several parts which were not a submodel and we not attached in a single step. I am not saying that this should be done using group. In fact, maybe my suggested solution should not support multi-part groups at all. Indeed, this can be done by creating (automatically) one single-part group per part being moved. I only suggested LDCad groups as a way to reference previously added parts.

we'd want to limit ourselves to one ref line per part used (to avoid having to adjust the parts list/BOM, etc.). With buffer exchange, you have to reference each part twice (or more)

I don't quite understand you here, sorry. Perhaps you could elaborate a little bit? 
But yes, my suggestion implies that parts are only moved not added, so no new parts appear in the PLI of the step with movement and the BOM counts should be correct.

Would your MOVE GROUP command have some way to handle multi-step hovering, or would it just not allow for this possibility?

Yes. My suggestion is that you first add you part in the hovering position (and it is counted for that step's part list), then you add a step or a number of steps (maybe even finish this submodel and go to the outer one), then you decide that part should be moved, then you switch to "move mode" of LDCad and move the part as if you were just adjusting its original position. LDCad then would add a group definition to the step the part originally appeared and a MOVE GROUP meta to the current step. When you would go to some following steps, LDCad would keep track of all MOVE GROUP metas and display the part in its correct (updated) location, very similar to the way it currently handles buffer exchange.

Yes, of course either the software or the user would have to keep track of that. Of course, the parameter would be configurable, so at the end of your workflow you could easily adjust a part's float settings

Maybe you could explain how that interface could look?

[Roland Melkert]

I would love to contribute to LDCad code but it is closed and I respect this Roland's decision. Still, if this changes I would gladly contribute there (for instance, I can do some minor features which are thought to be necessary).

I'm not sure if people would be that happy working on LDCad code as I like to do things the hard way.

Meaning I wrote my own support library (strings, lists etc) minimizing std usage as I kinda hate bloat-y templates.

Also when I started the project (in C++) I came from years of Delphi programming so there are noticeable programming style differences along the way as I picked up some new c++ tricks etc 

0 ROTSTEP 23 45 0 ABS CENTER 1 2 10 ABS DISTANCE 200 ABS

I kinda like this idea, I'm just wondering if some existing (strict) parsers might reject these lines breaking backwards compatibility. But you are right about it being a nonissue when only using it in new projects.

Maybe it should reuse existing LDCad grouping capabilities, maybe like this

There could be all kinds of meta data added to groups as the current group meta uses a forward compatible format ([prop=value] list)

[Daniel R]

Where all users sacrifice their free time and make everything free of charge.

Certainly. I understand this and do not ask anyone to implement some changes for me. I am sorry if I have sounded this way.
Nevertheless I personally would rather spend my free time on improving this software than doing something utterly meaningless such as waiting for LPub to display new page, correcting wrong callout arrows or moving parts manually with buffer exchange.

I'm currently drawing a Technic MOC with about 14,000 parts, (yes 14 thousand)

That is very cool! Do you use LPub3D to make callout arrows? What is your typical wait time to display next page?

And I still believe that the MOC is buildable.

That may be true, but the question is not how many times BUFEXCHG is unavoidable, but how many times you would like to use it because it is appropriate. For example, how many times it is used in a official instruction. And the answer, for example for the beginning of 42082 instruction, is that there are more buffer exchanges than pages.

Moreover, I think we limit ourselves and change the way we produce instructions due to technical difficulty of some commands. At least I do. So I think I would use it much more often if it was an easier process.

[Jaco van der Molen]

• Movement of parts attached some time ago
  
• 
  
• Connection of flexible parts ends
  

This can be done with REMOVE GROUP using MLCad Group meta.

See my old tutorial on that:
https://sites.google.com/site/workingwithlpub/general/advanced-techniques/metacommands/remove-group

And thread here: https://forums.ldraw.org/thread-22216.html

[Daniel R]

I'm not sure if people would be that happy working on LDCad code as I like to do things the hard way

Okay. Feel free to make a private Github repo if you change your mind about this

I also would be very glad if you post your opinion on some of the other suggestions above.

[Daniel R]

Thank you

[Daniel R]

This can be done with REMOVE GROUP using MLCad Group meta.

I know of that command and I did use it in my instruction (once again thank you for your tutorials!). The problems with REMOVE GROUP are that it is not supported in LDCad, it is not possible to remove a group from a submodel and you are required to copy all the parts after you remove something. All in all, REMOVE GROUP requires too much manual labor, so that you try to avoid it if possible (at least I do), that's why I am suggesting to design some alternative

[Merlijn Wissink]

I proposed a BUFFER END a long time ago already: https://github.com/trevorsandy/lpub3d/issues/43
Never really led anywhere.

[Roland Melkert]

I also would be very glad if you post your opinion on some of the other suggestions above.

I would very much like to add support for (a subset of) LPUB metas in LDCad 1.7, maybe add a special "Instructions" mode to the top right session panel as suggested elsewhere in this thread.

But as I don't make instructions and have very little experience with LPub myself, I would need some pointers on which metas to support first.

Also documentation on the lpub meta spec seems to be very fragmented / hard to find.

Once supported some of the more common tasks (adding callouts etc) can be handled with macro's (technically they already can) while seeing the result without having to use LPub.

You would still need LPub(3d) to generate the final pdf.

This is all some distance in the future though, as I fist want to do some fun things with interactive animation (the main reason I started a 1.7 version).

So maybe 1.7 Alfa 3 or even the first beta at the earliest.

This said nothing is set in stone, I tend to change direction quite often while working on the project

[N. W. Perry]

That is correct. Nevertheless, there should be some mechanism for all use cases. Maybe there should be different mechanisms, I don't know. These use cases are:

• Simple hovering of parts used in this step
  
• Movement of parts attached some time ago
  
• Connection of flexible parts ends
  

Yep, all of these would be handled by my imaginary FLOAT command. :-) Let's say that we allow a complete type 1 line to follow the meta, plus an optional step parameter, and is followed by another type 1 line; so:

0 !FLOAT <color> x' y' z' a' b' c' d' e' f' g' h' i' <file> (n)
1 <color> x y z a b c d e f g h i <file>

For simple hovering, you'd just change the x'y'z' triplet in the float line (the position).

For movement of parts attached earlier, change the position (x'y'z') or orientation (a'…i') matrix in front of each such part. To un-rotate them at a certain step, enter a negative number for n, so if the parts are moved into position in step 32, then enter -32 for n.

(A disadvantage is that this only allows for parts to be moved or rotated once. Assigning some kind of ID to each FLOAT command could be a way around that.)

For connecting flexible part ends, you'd provide a different file reference in the FLOAT line. So if you wanted a 12L flex axle, you'd reference 32200.dat in the FLOAT line, and in the following line use your LDCad path reference (say, "technicFlexAxle-1.ldr").

Unfortunately, sometimes you need to rotate of move several parts which were not a submodel and we not attached in a single step. I am not saying that this should be done using group. In fact, maybe my suggested solution should not support multi-part groups at all. Indeed, this can be done by creating (automatically) one single-part group per part being moved. I only suggested LDCad groups as a way to reference previously added parts.

Yeah, as you see above, this would be handled by putting the same -n in front of each part wherever it's added. A good editing program could recognize all parts with the same -n and allow you to change them all at once.

I don't quite understand you here, sorry. Perhaps you could elaborate a little bit?

With buffer exchange, you add each hovering part to the model twice: once in its hovering position, and again in its final one. As you've noted, this throws off the count for that part in the PLI/BOM, requiring further commands to offset it. With FLOAT, you add the part only once, and just modify its position (etc.) temporarily.

Yes. My suggestion is that you first add you part in the hovering position (and it is counted for that step's part list), then you add a step or a number of steps (maybe even finish this submodel and go to the outer one), then you decide that part should be moved, then you switch to "move mode" of LDCad and move the part as if you were just adjusting its original position. LDCad then would add a group definition to the step the part originally appeared and a MOVE GROUP meta to the current step. When you would go to some following steps, LDCad would keep track of all MOVE GROUP metas and display the part in its correct (updated) location, very similar to the way it currently handles buffer exchange.

Got it. That's similar to how FLOAT could work, if you put in some kind of ID. Maybe not as complex as "move mode", but perhaps also not as powerful.

Maybe you could explain how that interface could look?

Well, if we take the existing part properties dialog in LDCad, imagine a new "float" panel (or tab) in that dialog. You'd have a checkbox to enable "float", which inserts the meta command. That could invoke a new matrix, color reference, and part reference field in the dialog, where'd you enter the floating values. Also, imagine two additional checkboxes, either "Float for next _ steps" or "Float until step number _", which adds the n parameter.

At the same time, you'd probably want some way to visually edit the float position/orientation, perhaps by invoke "float" mode with a hotkey or menu command, or from the editing compass, or perhaps up with normal and nested modes. Maybe the part would show in a sort of transparent, "ghost-like" way as you move it around in float mode.

Now of course, let me be clear that I'm going about this completely backwards by thinking about the end result rather than how it's actually achieved, so I really don't know how easy this would actually be to pull off.  But the main thing here is to look at the problem of buffer exchange and how it could be made more understandable by the user. Theoretically, you could just keep using the exact buffer exchange method "under the hood" and just change how the user interacts with it, but I feel like FLOAT has the advantage of requiring far fewer changes in the code.

[N. W. Perry]

While you can replicate this with BUFEXCHG, LPub3D now has a setting to enable continuous step numbering, so you can use submodels as usual. I think it is much easier

Yes, you're right. I should add that I don't actually use LPub at all, so I'm looking at ways to do this in the model editor.

[N. W. Perry]

I proposed a BUFFER END a long time ago already: https://github.com/trevorsandy/lpub3d/issues/43
Never really led anywhere.

I'm having trouble understanding the problem as described. It says "everything after the start command is placed in the buffer"—but really, it's everything before the start (STORE) command that's buffered, no? Then when you RETRIEVE it, that's basically like the end command already. Or am I getting something mixed up?

[Merlijn Wissink]

I'm having trouble understanding the problem as described. It says "everything after the start command is placed in the buffer"—but really, it's everything before the start (STORE) command that's buffered, no? Then when you RETRIEVE it, that's basically like the end command already. Or am I getting something mixed up?

It's been a little while since I last used buffer exchange, but I'm pretty sure everything after the STORE command is what is buffered.

In any case, an example for the problem described there. Imagine you're making instructions for which need a part in a temporary positions for a certain number of steps. Everything after the STORE command will be removed once RETRIEVE is called. So, if you add temporary part in step 20, then in steps 21-24 you add other ('normal') parts and then call RETRIEVE in step 25 to place the temporary part in the final positions, all the other parts in steps 21-24 will be removed too, because the STORE command never ends (until RETRIEVE).

Due to this limitation, buffer exchange cannot work through multiple steps. If you want to do that with the current implementation, you'd have to repeat the same STORE/RETRIEVE over multiple steps.

[Philippe Hurbain]

Due to this limitation, buffer exchange cannot work through multiple steps. If you want to do that with the current implementation, you'd have to repeat the same STORE/RETRIEVE over multiple steps.

As you say, it does work but you must "re-add" all parts between store and retrieve after the retrieve (tedious I agree). What really annoys me is "submodel wih moving parts" (eg. submodel where you must push pins after attaching to the main model), I have no other solution than to make two different submodels

[Johann Eisner]

As you say, it does work but you must "re-add" all parts between store and retrieve after the retrieve (tedious I agree). What really annoys me is "submodel wih moving parts" (eg. submodel where you must push pins after attaching to the main model), I have no other solution than to make two different submodels

I also only know this way.

[Johann Eisner]

Certainly. I understand this and do not ask anyone to implement some changes for me. I am sorry if I have sounded this way.

It shouldn't have been a reproach from me either.

That is very cool! Do you use LPub3D to make callout arrows? What is your typical wait time to display next page?

In the meantime, I need about 20 - 30 seconds only if I change an arrow. To load a page with the main model (e.g. a new page), It takes about 3 minutes. This could be due to the special LDView render metas, or my very old notebook.

Moreover, I think we limit ourselves and change the way we produce instructions due to technical difficulty of some commands. At least I do. So I think I would use it much more often if it was an easier process.

I agree with you.

[Daniel R]

Assigning some kind of ID to each FLOAT command could be a way around that.

Exactly. That is what I was aiming for with groups.

Well, if we take the existing part properties dialog in LDCad, imagine a new "float" panel (or tab) in that dialog. You'd have a checkbox to enable "float", which inserts the meta command. That could invoke a new matrix, color reference, and part reference field in the dialog, where'd you enter the floating values. Also, imagine two additional checkboxes, either "Float for next _ steps" or "Float until step number _", which adds the n parameter.

At the same time, you'd probably want some way to visually edit the float position/orientation, perhaps by invoke "float" mode with a hotkey or menu command, or from the editing compass, or perhaps up with normal and nested modes. Maybe the part would show in a sort of transparent, "ghost-like" way as you move it around in float mode.

The only thing you did not address is that the number n needs to be (manually) changed if you insert a step in the middle. Therefore, perhaps, instead of hardcoding the step number one should insert some kind of marker in the target step... And here, after this change, we would be describing roughly the same system, with differences in whether to use a new meta for ID or reuse the group meta and where to describe modified part position. Both of them are very minor ones

[N. W. Perry]

It's been a little while since I last used buffer exchange, but I'm pretty sure everything after the STORE command is what is buffered.

And of course, the fact that it's not clear to a bunch of us which way it works is exactly why the topic's come up. :-)

For whatever it's worth, the MLCad spec is a bit vague, but describes it this way:

The buffer command either stores an image or retrieves a stored image. The image is taken from the actual view and when restored put in there.
[…]
You first create the model completely without the [hovering part]. Then you save an image of the current view, and after that you put the [hovering part] above the model. When the user continues drawing you retrieve the previously saved image and redraw the [hovering part] in it’s[sic] final position.

In his tutorial, which I'm pretty sure is where I first learned about buffer excahnge, Willy says:

MLCad allows to save up to 26 display states during the View Mode and to retrieve them at a later moment. Selecting A from the drop-down box [to insert the STORE command] and hitting OK will save the display state up to this point in an internal memory named A.

But, I should add that I've never used either MLCad or LPub, and other programs might process the buffer exchange commands a different way than by placing a saved view state into a memory buffer. And of course, from the user's perspective, the real action is what happens between the commands, and it is the user's experience that we're exploring, after all!

In any case, an example for the problem described there. Imagine you're making instructions for which need a part in a temporary positions for a certain number of steps. Everything after the STORE command will be removed once RETRIEVE is called. So, if you add temporary part in step 20, then in steps 21-24 you add other ('normal') parts and then call RETRIEVE in step 25 to place the temporary part in the final positions, all the other parts in steps 21-24 will be removed too, because the STORE command never ends (until RETRIEVE).

Oh yes, I see what you mean now. I agree that it would be nice not to have to re-insert any parts, including the ones that are being moved. My FLOAT method would do that, since it only affects the next line. And it works similarly to your END idea, except that FLOAT automatically lasts for just a single step, unless you specify otherwise with the n parameter.