LDraw.org Discussion Forums

Full Version: Standardize official search path
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
(2021-07-14, 15:00)Willy Tschager Wrote: [ -> ]Any progress on this?
I'm still having very big problems with the proposed (some say defacto) scoping rules as they will completely ruin the (beautiful) recursive nature of LDraw.

Not to mention they are a complete nightmare to implement in a multi document environment.

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.

That said I do think we could vote on the path order alone, like I wrote in post #8
(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.

[attachment=6680]

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 Smile
(2021-07-14, 19:45)Roland Melkert Wrote: [ -> ]Did a quick test...
This is how it looks in LDCad, thought it was already posted above but apparently that was in another thread.

[attachment=6681]

This is how I always understood the LDraw format to work, recursive at a per file level. So the embedded stud.dat is only used by models refering stud.dat inside the mpd file itself
(2021-07-14, 19:51)Roland Melkert Wrote: [ -> ]This is how it looks in LDCad, thought it was already posted above but apparently that was in another thread.



This is how I always understood the LDraw format to work, recursive at a per file level. So the embedded stud.dat is only used by models refering stud.dat inside the mpd file itself

I know this is old, but I'm replying to this before replying to another thread.

Two things:

  1. LDView behaves like you see only because you chose to use a primitive that LDView can substitute for your sample. When primitive substitution is enabled in LDView, it always ignores any data in the associated dat file of a substituted primitive. So, "stud.dat" is directly recognized by LDView as being a stud primitive, and it ignores any and all on-disk definitions for that when primitive substitution is enabled. Not all files in the <LDraw>\p directory are directly supported by LDView's primitive substitution, so some primitives could be included in an MPD and have that definition show up in LDView.
  2. If you turn off primitive substitution in LDView, I think you will see all the studs become yellow. I can change its behavior regarding MPD-embedded files to make them local to the MPD.
I hope you reach agreement on this.

w.
Pages: 1 2