Instruction making rant

[N. W. Perry]

Moreover, if I understand correctly that the first (and only) type 1 is describing the part in its final position, while all the FLOAT lines describe intermediate positions, this syntax solves the problem of compatibility with other editors which do not support this meta (that is a problem for BUFEXCHG, REMOVE GROUP and two other suggestions in this thread). I didn't think about it before, this is cool.

Yes, exactly. With only one type 1 line per instance of the part, then with editors that don't support the meta, the worst case scenario is your model just displays as finished. It bothered me about buffer exchange that it hardcodes parts into the file that don't actually appear in the model.

I support making them optional. Also it would be a good thing to discourage users from actually changing reference and color. By the way, I can't find any reasonable use for change of color. Is there one? I am not saying it should not be supported.

I haven't thought of a reason for color, but somebody someday might want to be able to, and as it's just a single integer, it's not any trouble to include the possibility. And I can't immediately see a reason to specifically exclude the possibility; what would it break?

(Actually, there is one reason I thought of: use an invisible color to temporarily hide the part. But there are probably better ways to achieve this.)

After some thought I understood that it sometimes necessary to replace the reference: this is needed for flexible parts. Because moving path points by some FLOAT/MOVEGROUP would work only in simple cases, in more complex cases you would need different number of path points, therefore, new submodel. It is still not clear how the fallback code should be handled in case we allow to FLOAT individual path points.

Yes, flexible parts was the use case for changing the reference. I hadn't thought about using FLOAT commands inside flexible path subfiles, but I suppose you could. My first thought is that you would just have different subfiles for different states of the flexible part, but if we follow on to Roland's suggested structure, perhaps you could allow path caps and path points as possible target types for FLOAT.

As for the fallback, I think it would just continue to describe the part in its finished state. If you're using an editor that doesn't understand FLOAT, then you're already ignoring all but the final positions of things, so there'd be no need to provide fallback code for interim states of flexible parts.

Inventing new metas might be fun, but these kinds of metas (begin end etc) are a nightmare to parse while reading LDraw content.

It is mentioned above the new meta should be able to reference groups, but personally I think it should be an extension on existing existing group mechanics.

This will make parsing the meta alot easier, even more so if you limit to a single one using a submeta.

That's helpful to know, since as I say, I don't necessarily understand all that goes into making these things work. I'm just able to picture how I'd like them to be. :-) But it did seem to me that having a single command would be easier to parse than keeping track of possibly-nested pairs of commands (like with multiple buffers currently).

It makes sense to build off the existing groups structure; since they are recursive, then FLOAT would be, too—you would still be able to have different float states across submodels, no? But I didn't want to assume that it would be directly based on LDCad, so I imagined the syntax as a similar but separate system.

The first float 'overrides' position, color and rotation. Just use the parameters which are needed all others initialize with the current values.

The second float uses all default parameters, so it returns the group to its original place, color and rotation.

"Override" is a good term to describe the purpose of the meta. Perhaps that could be its name?

I like the elegance of just omitting all parameters to return everything to its default. That supports the idea of making them optional; just include what you want to change. It also keeps the code tidy.

This discussion may be confusing but I think it arrived to a one or two new metas (depending on whether to support only groups or groups and simple references too) which do not behave like a begin and end but only affect one next line.

I had one other meta in mind, to handle the HIDEALL scenario (where the main model is temporarily hidden to isolate a sub-build that is not a submodel). That doesn't necessarily have to be part of this line of inquiry, although perhaps it could exists as a second submeta to OVERRIDE.