(2018-12-22, 21:13)Roland Melkert Wrote:(2018-12-21, 2:19)Travis Cobbs Wrote: SNAP_INCL really needs the snap info to be in a separate file from the geometry, unless we have dat files that only contain snap info and nothing else. The spec itself, being based on LDCad, mentions "shadow library" in three places.Include will copy the (non recursive) snap info of the given file as currently merged in memory. But I was planning to extend it to (also) allow for generic include files in LDCad 2 so I'm open to do the same here.
What I meant is that if the snap data goes inside the dat files, then in order to include snap data from another file, the loader also has to load the entire other file's geometry, even if that geometry is never rendered. I understand that using SNAP_INCL wouldn't act like a #include for the whole file, just its snap data, but it still seems bad. You of course wouldn't have this problem in LDCad with the shadow library, because the shadow library files don't contain any geometry. But if this is used as an official spec for files in the official library, then I think that SNAP_INCL as it currently stands is very messy if the snap data is inside the existing dat files.
(2018-12-22, 21:13)Roland Melkert Wrote:(2018-12-21, 2:19)Travis Cobbs Wrote: I'm not sure I like the fact that many (but not all) of the meta-statements and parameters are heavily abbreviated. For example: SNAP_FGR instead of SNAP_FINGERS, an ori instead of orientation. The fact that "origin" (which is instead called position in this spec) also starts with ori further confuses things.This was mostly to prevent "code bloat". The same reason for the defaults, as only properties with non default values need to be given. Hence the split of position and orientation.
To be clear, I just used that as an example of how the abbreviations were confusing (to me, at least). I definitely don't have a problem with the position and orientation being specified separately, and I also don't have a problem with parameters have good default values.