(2020-05-26, 20:26)Merlijn Wissink Wrote: 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!
