Instruction making rant

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