Instruction making rant

[N. W. Perry]

I think no matter the implementation or how it works, there must be an explicit end to whatever 'store' command is being used. Implicit ends are just too vague and keep too many edge cases open. For example, what *if* you actually want to hide/move all parts placed in multiple previous steps?

I agree. I think it's clear by now that an END is necessary to allow nesting across submodels, etc. The question remaining is simply what the fallback behavior would be if a START is added without an END, and/or what the default location of an END would be for programs that automatically generate the pair.

I feel like people are overthinking it a bit. What does buffer exchange (or, at least a replacement for it, whatever you wanna call it) need to do?

• Simply put: it needs to place parts in temporary positions, with the ability to either hide them (arrows, helper parts) or place them in a final position.
  

What are the major limitations that the current implementation has (without hacking or abusing the system of course)?

• It doesn't work through multiple steps.
  
• It doesn't work through submodels.
  
• A part has only two states: start and end (you can't have a part go through multiple positions until final position).
  

Well, I'm not sure whether I believe in the concept of over-thinking. But what is possible is that some of our previous thoughts can now be dismissed. I can say that your list of considerations is pretty much identical to mine. I would also add the following two requirements for what the replacement would need to do:

• There should only be as many file references (type 1 lines) as are actually used in the model
  
• It should be easily understandable to the user what the syntax is and how the commands work in the code
  

What other avenues have we considered that can now be discounted?

How can this be solved? Simply place both all positions of the part(s) together in the same command and give the command an (optional?) name to call. This takes care of all the above points and is much more robust (assuming good software implementation of course).

Yes, again I fully agree. This is how my idea of FLOAT works.

Let's make an example. I'm just using semi-random terminology here, probably can be improved, but it's not about the specifics here

Code:

0 BUFFER DEF START "Name"
// parts
0 BUFFER POS
// parts
0 BUFFER POS
// parts
0 BUFFER DEF END

Same example using my envisioned syntax:

Code:

0 !FLOAT [id=x] [color] [matrix] [file reference]
1 [file reference line-part or submodel]
…
0 !FLOAT [x] [new color] [new matrix] [new file reference]
…
0 !FLOAT [x] [new color] [new matrix] [new file reference]
…
0 !UNFLOAT [x]

No reason it couldn't be done your way, where the arguments to FLOAT are a separate, commented line rather than command line parameters. And the parameters could be mutually optional, so you provide only what's changed (position, or color, or file reference) instead of the whole line.

The idea here is, a BUFFER command (I still don't like the name, but I can't come up with a better one)…

Why not FLOAT? Possible conflict with the mathematical meaning?

…has a required START and END. If there are no POS arguments within the buffer, this means that once the BUFFER is 'retrieved' all parts disappear, e.g. for using arrows or helper parts. The POS commands are used to place bricks in their next or final position. There can be multiple POS commands for various positions. There is also a name for the buffer definition. I guess this can be either an explicit string name, or just an integer ID or even A/B/C... like current buffer exchange.

How to use it further on the model? I can think of various options. For example, simply:

Code:

0 BUFFER "Name" NEXT

This moves the previously defined buffer to its next position (the next POS command, if any).

For my system, you'd just call a new FLOAT command on the same id, and provide whatever has changed in the arguments to that new command (new color, new rotation matrix, etc.). I would think you can even hide a part by specifying an invisible color.

This takes care of all the above defined points:

• Parts can be placed in temporary positions, and they can be moved to another positions, or disappear.
  
• It works through multiple steps, because there is an explicit start and end and a name to call the buffer.
  
• It works through submodels, because there is a name to call the buffer and the next positions are stored within the buffer (no need to rely on any meta-steps within the submodel that then need to be hidden or whatever)
  
• A part can have multiple states instead of one or two.
  
• And as a bonus, because all positions are defined together, it's very simple (relatively) to edit any of the parts within the buffer because they are grouped together.
  

This is good, we seem to be on the same page. My idea and yours work almost exactly the same way, the only difference is in our names for things.