(2021-07-14, 18:50)Roland Melkert Wrote: I still want to gather information on how the existing tools handle this, but most of them have only one open model to deal with so the big issue doesn't even concern them.
Did a quick test, and the proposed scoping is far from defacto.
LDView and brciksmith seem to ignore it altogether.
MLCad seem to apply the 'expected' scoping, but it crashes while opening another model afterwards. It's complaining about cross model references so I'm guessing it is trying to use the stud.dat from the previous loaded mpd.
Given this is far from defacto I see no real reason to make it the standard way of doing things.
I think we should keep the format as recursive as possible, only compromise might be to handle libraries different so .e.g a stud.dat in unooficial/p would be used for all bricks loaded but a stud.dat in a mpd should, imho, NEVER override a stud.dat in a library location.
Because that would mean bricks can look different depending on which models loaded. So when you want multiple modles to be loaded at once, you would need to keep track of a 'brick context' which is a whole lot of administration and requires lots of extra memory etc.
Not to mention the mess it would cause with large recursive models (e.g. datsville)
And I seriously wonder why anyone would want this behavior. Why not just use a unofficial library when working with new parts etc?
my 2cts, excuse the rant
