Enhancement: Multiple Multisteps per page

[TrueMylenium]

It would be useful to allow multiple multisteps per page. Repetitive small sub-assemblies often take up very little space on the page and it seems like a waste. Converting these mini-assemblies into callouts also often is not ideal, especially when the actual main model is relatively large and the callout may "drown" against the rendered main assembly and/ or there are other such elements that are neither here nor there, as they say, and would also call for plastering the page with callouts. I'm currently experimenting with BUFEXCHG to kinda munch things together, but it would be useful to have a native logical way to deal with this that also would be responsive to on-the-fly changes while working on the files. I would propose to expand the Meta with a NOPAGE method so you would end up with something like this:

0 !LPUB MULTI_STEP BEGIN
0 !LPUB MULTI_STEP NOPAGE

The prerequisite would of course be that this could only be used on a secondary, tertiary etc. multistep on a page and a primary one always has to exist for this to have any effect. This would of course also kinda require to implement all that divider/ separator stuff at the page level to visually contain the separate multisteps in columns/ rows and of course it opens up another can of worms with instance counts and all that...

[trevorsandy]

Thank you for your suggestion. The core behaviour of the multi-step page functionality is to fit as many steps on a single page as is appropriate. Horizontal or vertical dividers can also be utilized to further optimize the number of steps that can be placed on a single page.

I don't understand what would be gained with separate multi-step groups on a single page. Can you show an example, perhaps from and existing LEGO build instruction document that illustrates the layout you are seeking to achieve ?

Cheers,

[TrueMylenium]

Here's an example:

This dangly tentacle segemnt would benefit from being placed on the same page with similar pieces for a more efficient use of space and incidentally also perhaps making it easier for the user to build them in one go without having to go through multiple pages. A minor thing, for sure, but it would help, especially in this case as the element isn't connected to its parent tentacle and could not be converted into a callout therefore and even if it did, it would just look naff to have a long assembly at a relatively tiny scale plastered with tons of callouts for its constituting elements. it's all about optics.

[Landcross]

I agree it would be a nice new feature. +1 from me :)

[trevorsandy]

The example above shows a single PLI per step group, do you envision this enhancement supporting a PLI per step also ?

Should there always be distinguishing characteristics to visually determine the boundary between step groups on the same page - e.g. using a single PLI per step group seems most logical ? Of course the editor would be able to manually insert a divider between step groups which would add clarity if using a PLI per step.

Cheers,

[TrueMylenium]

Personally I don't care for per step PLIs in callouts and multisteps. I'm too much of a graphics guy and aesthetics are kind of a big deal to me, i.e. I don't like "visual noise" such as would be the case with separate PLI boxes disturbing the flow of aligned assembly steps. ;-) In such a case I'd rather create a separate page then. I also can't see the use case on a broader level due to that crammed space issue. To me it's really just about making more efficient use of space on small elements, not necessarily a completely new way to add yet another style of creating instructions for entire sub-assemblies. I would even argue that there should be a limit or a boundary size check so users can't even force too many multisteps and callouts on one page, but of course that's again perhaps part of a grander plan for making the automated layouts more beautiful without manual user interaction and might be worth filing a few separate issues...

[trevorsandy]

So if I well understand your position, you are saying, for you, no step group boundary characteristics are necessary - i.e. you are fine with a continuing list of steps and a single PLI per Page or you prefer to see a single PLI per step group ?

[Landcross]

Well, that's apparently a point where TrueMylenium and I have different opinions haha. I for one would like to keep a PLI per step. I could live with just a PLI per step-group too, but a PLI per page (with multiple step-groups) is a no for me personally.

[trevorsandy]

For me, the most sensible design is to inherit the current PLI per ... designation if not specified in the next step group to be added to the page.

Cheers,

[TrueMylenium]

As you put it, I don't care much for step group boundaries. Just having a single PLI per page, slamming all the elements in there and just incrementing counts of identical elements would be sufficient. As I wrote, I can't really think of a use case where per group/ per step PLIs would really makes sense, but that's of course just my little world. As usual: The more wholesome and versatile you can make this now, the less you may have to worry about revisiting this later

[trevorsandy]

Just having a single PLI per page, slamming all the elements in there and just incrementing counts of identical elements would be sufficient.

If I well understand, this layout requirement does not need an enhancement. For me, putting all steps expected to be on the same page into sequential order (alternatively, you may place said steps in their own ldr FILE to also mange instance occurrence display if needed) then render the 'group' with PLI per step set to false will achieve the layout you describe;

Unless I am missing something, this layout, in effect, creates a single step group which is what I originally understood to be the need; hence my remark:

I don't understand what would be gained with separate multi-step groups on a single page.

The necessity to update the current behaviour presents if there is a need to visually distinguish a boundary between step groups on the same page for which using a single PLI per step group seems most logical but a placed divider can suffice when PLI per step is specified.

Cheers,

[TrueMylenium]

Sorry for being snarky late in the evening, but it seems you're not really getting what I'm asking. First off, let me say that I'm already using redundant submodels a lot - some excluded from the PLI/ BOM to illustrate only the sub-assembly steps, then the "real" ones to get correct element counts and a few ones to deal with BUFEXCHG and model SUB scenarios plus some NOSTEPs. Enough to fry my brain, especially in this summer heat.

I understand the limitations of the program to some extend, I think, but I'm not really looking for more "hacks", as in the end one will end up constructing each page layout manually and the files get extremely large and unwieldy. Totally defeats the purpose. Having to wait 3 minutes or so for the program to comb through hundreds of submodels is not something I look forward to, anyway. That's also the flaw in your proposed use of standalone submodels and just letting it render assemblies, if I may be so bold. It really solves nothing.

I also don't see how making the steps sequential would help, as without using a lot of BUFEXCHG mumbo-jumbo and/ or actually building positional offsets into the source model file this wouldn't do anything useful, given that the model build sequence is cumulative and later sub-sequences, despite representing their own submodel, would be rendered on top of the previous submodel in place.

So for what it's worth, if it's not too much trouble and you can do it by reusing some existing code, it would be fantastic to get the functionality. If you slap it in my face, I promise I will help test the builds. If there's anything else I can do to help, just let me know. I've done Beta work on commercial programs in the past, I'm just not up to speed in LDraw/ LPub and don't quite yet understand its internal graph and how it determines where to render what. And again sorry for being a bit cranky...

[trevorsandy]

No worries, I appreciate the feedback; whatever the context. Having said that, I am inclined to think the source of the request and confusion is...

I'm just not up to speed in LDraw/ LPub and don't quite yet understand its internal graph and how it determines where to render what. And again sorry for being a bit cranky...

...so I'm pleased to take some time to ensure both you and I are in good understanding of the behavior you are asking for.

Let's use your remark as a starting point...

Just having a single PLI per page, slamming all the elements in there and just incrementing counts of identical elements would be sufficient.

I interpret the layout for this configuration, which is the same as the layout of the sample (image) you provided as simply a step group with four steps with the additional meta commands, 0 !LPUB ASSEM SHOW_STEP_NUMBER FALSE and 0 !LPUB ASSEM SHOW_STEP_NUMBER FALSE.

Here is a similar example:

0 Name: multisteps.ldr
0 multisteps
0 Author: LPub3D
0 !LPUB ASSEM SHOW_STEP_NUMBER FALSE
0 !LPUB MULTI_STEP PLI PER_STEP  FALSE
0 !LPUB MULTI_STEP BEGIN
1 4 0 0 0 1 0 0 0 1 0 0 0 1 3001.dat
0 STEP
1 5 -40 24 0 1 0 0 0 1 0 0 0 1 3001.dat
0 STEP
1 6 40 24 0 1 0 0 0 1 0 0 0 1 3001.dat
0 STEP
1 7 80 0 0 1 0 0 0 1 0 0 0 1 3001.dat
0 STEP
1 8 120 24 0 1 0 0 0 1 0 0 0 1 3001.dat
0 STEP
1 9 40 -24 0 1 0 0 0 1 0 0 0 1 3001.dat
0 STEP
0 !LPUB MULTI_STEP END

Which will render this page...

As you can see, the layout you specified can be achieved with existing meta commands.

So regarding this remark...

I understand the limitations of the program to some extend, I think, but I'm not really looking for more "hacks", as in the end one will end up constructing each page layout manually and the files get extremely large and unwieldy. Totally defeats the purpose. Having to wait 3 minutes or so for the program to comb through hundreds of submodels is not something I look forward to, anyway. That's also the flaw in your proposed use of standalone submodels and just letting it render assemblies, if I may be so bold. It really solves nothing.

...and my proposal...

...you may place said steps in their own ldr FILE to also mange instance occurrence display if needed..

The "...if needed" is to say if the part elements captured in the multi-step page occur more than once in your model - a common occurrence for trivial assemblies - you may place then in their own submodel FILE. This guidance is neither a "hack" nor "flawed"; instead, its a best practice in transforming your "As Designed" model to an "As Built" representation/view which will afford consumers of your build instruction document an optimum experience and result.

So going back to your remark...

I also don't see how making the steps sequential would help, as without using a lot of BUFEXCHG mumbo-jumbo and/ or actually building positional offsets into the source model file this wouldn't do anything useful, given that the model build sequence is cumulative and later sub-sequences, despite representing their own submodel, would be rendered on top of the previous submodel in place.

Hopefully the notion of "As Designed" and "As Built" representations are clear enough to convey the fact that there are times when part elements and submodels must be repositioned and substituted to optimize the as-built view. It is with this understanding that I provided the guidance to put "all steps expected to be on the same page into sequential order". This statement also implicitly include elements within each step. Certainly the BUFEXCHG and repositioning offsets are useful capabilities in transforming your steps into an as built view but these capabilities are not the focus of your request or my guidance.

So to your inquiry...

So for what it's worth, if it's not too much trouble and you can do it by reusing some existing code, it would be fantastic to get the functionality.

Certainly I would be pleased to enable any reasonable solution, (as I have done for your requested enhancement #298); however, as your requirement is...

Just having a single PLI per page, slamming all the elements in there and just incrementing counts of identical elements would be sufficient.

...there simply is nothing more for me to do regarding the step group behaviour as I have illustrated with the provided model sample file and associated page output. Consequently I can only repeat...

The necessity to update the current behaviour presents if there is a need to visually distinguish a boundary between step groups on the same page for which using a single PLI per step group seems most logical but a placed divider can suffice when PLI per step is specified.

Lastly, I can also say that one behaviour modification that does present when the meta command 0 !LPUB ASSEM SHOW_STEP_NUMBER FALSE is used is to create flags that:

• make visible the step number of the first step in the group as the step number for the entire group of steps and place the step number relative to the page then place the PLI relative to the step number as is done for single step pages.
• continue the step numbering from the last visible step number.

So instead of this...

We should have the option to enable something like this...

As there is nothing to do on this ticket, I will close it.

Do not hesitate to request reopening it if you come up with a scenario and example that will require more than one step group on a page to produce the expected layout.

Cheers,

[Landcross]

Trevor, I think you're not understanding the requested feature. Or, at the very least I understood it differently. I think the discussion went way to deep into PLI behaviour details, while not everyone was even on the same understanding about the actual feature request. Or I'm just the one misunderstanding everyhing, that's also possible haha.

In any case, how I understood the initial feature request is as follows:

Suppose you have a model.mpd with 2 submodels, subA.ldr and subB.ldr. Both submodels are rather small. Both easily fit on a single page with all steps. In fact, both fit so easily on a single page that both could fit together on a single page... And that's the requested feature.

As they say, an image says more than 1000 words. Instead of 2 pages like this...

...create some thing like this:

(Just imagine it being 2 different submodels and it having step numbers, it's a crude photoshop).

[TrueMylenium]

Nah, sorry, you completely misunderstand/ do not understand. Please reopen the issue. I'm going to furnish some mockups throughout the day and upload them. Perhaps that clarifies my intent.

[TrueMylenium]

Ooops, got beat. Still going to do those mockups.

[trevorsandy]

Suppose you have a model.mpd with 2 submodels, subA.ldr and subB.ldr. Both submodels are rather small. Both easily fit on a single page with all steps. In fact, both fit so easily on a single page that both could fit together on a single page... And that's the requested feature.

Merlijn - I believe I understood, from the beginning, what you have written to be the request (see here). This is precisely why I asked the questions...

The example above shows a single PLI per step group, do you envision this enhancement supporting a PLI per step also ?

Should there always be distinguishing characteristics to visually determine the boundary between step groups on the same page - e.g. using a single PLI per step group seems most logical ? Of course the editor would be able to manually insert a divider between step groups which would add clarity if using a PLI per step

Clearly the layout depicted in your new images reflect the elements of my questions. However, @TrueMylenium also returned a clear layout specification - also supported by the original graphic - asserting that s/he is not interested in multiple PLIs or criteria to visually determine the boundary between step groups...

Just having a single PLI per page, slamming all the [part] elements in there and just incrementing counts of identical elements would be sufficient.

So I will say, again, with regards to achieving the layout requested by @TrueMylenium in the above specification, there is nothing to do in LPub3D.

It is also clear to me that we have 2 different behaviour requests. The view of @TrueMylenium (for which there is nothing to do) and that of Merlijn as indicated by his remark...

Well, that's apparently a point where @TrueMylenium and I have different opinions haha. I for one would like to keep a PLI per step. I could live with just a PLI per step-group too, but a PLI per page (with multiple step-groups) is a no for me personally.

So Merlijn, I suggest you to open a new ticket with your multiple multi-step specification and I will address that accordingly. It does not make sense to me to implement your specification in this ticket as it is clearly not what is expected by @TrueMylenium.

@TrueMylenium, do not hesitate to request reopening this ticket when your new mockups are available.

Cheers,

[TrueMylenium]

You are taking this all too literally, Trevor. Unless this is an utter graveyard because too few people use LPub and everyone has moved on to Stud.io, I'm but one voice amongst a seemingly silent larger crowd. My personal preference likely does not reflect other people's needs and I've learned the hard way to not to take my own wishes as too important. So if you can, make it as flexible and versatile and make everybody happy. I'm not getting into any of your other arguments. TL;DR. Find below some examples of possible use cases - with per page PLI, per column/ row PLIs and per step PLIs. the latter is of course the one I would never practically use, but the others might be perfectly acceptable depending on the scenario.

[trevorsandy]

Excellent, patience and fortitude are indeed virtues.

@TrueMylenium, your new layout mockups clearly show what I, and I think Merlijn, would expect from this enhancement. I believe we are all on the “same page” at this point 😉. Thank you for taking the time to produce them.

The first layout is already available in LPub3D using simple steps and range dividers.

I’m interested to see your suggestions on how step numbering should behave for the layouts where step numbers are suppressed - particularly before and after the page.

UPD: The second layout mockup is also currently achievable in LPub3D with the exception of the step numbering scheme. At face value this layout looks more like an enhancement to step numbering than to step groups. What do you think ?

Cheers,

[Landcross]

The first layout is already available in LPub3D using simple steps and range dividers.

How is that possible if I may ask? There's no way to put multiple submodels on the same page right?

[trevorsandy]

The meta commands will be a single multi step block encompassing all the steps plus 2 range dividers (3 columns), show step numbers set to false and pli per step set to true.

How is that possible if I may ask? There's no way to put multiple submodels on the same page right?

For sub models, I’ll have to check if it’s already possible to add a next step if the step is in a different submodel.

Note: my solution is focused on achieving the layout versus a dogmatic view of having multiple multi step groups.

Cheers,