(2018-12-21, 8:11)Merlijn Wissink Wrote:(2018-12-20, 20:59)Chris Dee Wrote: Does the snapping data need to be in the .dat file for the part? This information will also be common to all patterned versions of a part and it does not make sense to repeat it in every file. Could the data live in a file for each part (design ID) in a sister folder to parts (and p)? That could be maintained without having to update the .dat file?
My personal opinion is that the snapping data should be in the .dat file itself. It's data that belongs to that part. Adding it in separate library would create so many unnecessary small files.
The patterned parts (reusing snapping metas) problem is not as big as it sounds. You can add snapping info to subpart, which will mean the same snapping info will carry over to all child parts. Many patterned parts have a shared parent submodel in which the snapping info can be defined. You can already see this working in LDCad's current snapping metadata library. Another example would be the stud: adding snapping meta to the few stud submodels and in one swoop you already have a huge part of snapping covered. Of course, there are edge cases. Parts that have non-standard studs that don't use a stud-submodel need manual correction and such, but that'll always be the case no matter the solution.
Plus I think that maintaining a shadow library has its own slew of headaches (you have to keep everything perfectly in sync).
You make some good arguments there - thanks. But at Orion said elsewhere "this discussion is for library policy, not the actual extension itself.". The proposed SNAP_INCL allows for shared connection metadata and the use of a common subpart for patterned parts does indeed save a lot of the potential duplication.
I am prepared alter my opinion, but I'd also like to see more active Reviewers, otherwise the Parts Tracker throughput could be a barrier.
Chris (LDraw Parts Library Admin)