LDraw.org Discussion Forums
Search path discussion - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Official File Specifications/Standards (https://forums.ldraw.org/forum-32.html)
+--- Thread: Search path discussion (/thread-24495.html)

Pages: 1 2 3 4


RE: Search path discussion - Travis Cobbs - 2021-03-17

(2021-03-17, 1:54)Trevor Sandy Wrote: Since LDraw.org does not author any applications why not define specifications in a manner that support both scenarios as they are both valid? This way, application developers can decide if to support either or both approaches and LDraw.org could focus on qualifying how unofficial file load/parse under each scope should be implemented, pros, cons etc...

Ideally we want the spec to fully specify exactly what should happen when loading any LDraw file. Having two possible results, where the file looks completely different depending on which program loaded it is bad.


RE: Search path discussion - Trevor Sandy - 2021-03-17

(2021-03-17, 2:01)Travis Cobbs Wrote: Ideally we want the spec to fully specify exactly what should happen when loading any LDraw file.

Indeed. This is precisely what LDraw.org's specification should state - for each scenario.

(2021-03-17, 2:01)Travis Cobbs Wrote: Having two possible results, where the file looks completely different depending on which program loaded it is bad.

Isn't this the case at this moment ? I believe valid use cases should drive the specifications. Otherwise the specifications will simply not be followed and you will most certainly continue with bad.

If two scenarios are specified, then it would be wise for application developers to respect both - this is what preferences are for. Doing so will ensure consistency across applications.

Cheers,


RE: Search path discussion - Orion Pobursky - 2021-03-17

I believe that local files (either embedded within the mpd or in the local directory) overriding library files is the de facto standard and has been since, at least, the early days of MLCad. Any default behavior the doesn't follow that standard would, in my opinion, result in unexpected output. Of course, any reasonable program can choose to allow the user to override this default with the caveat that unintended output could result.


RE: Search path discussion - Roland Melkert - 2021-03-17

(2021-03-17, 4:24)Orion Pobursky Wrote: I believe that local files (either embedded within the mpd or in the local directory) overriding library files is the de facto standard and has been since, at least, the early days of MLCad. Any default behavior the doesn't follow that standard would, in my opinion, result in unexpected output. Of course, any reasonable program can choose to allow the user to override this default with the caveat that unintended output could result.
That's ok, but the thing I'm getting from this discussion is the feeling there are different rules for parts and model's.

Also the examples given are all single model ones.

O would like to define the whole spectrum of behaviour.

Including references to another mpd (sorry Travis I think this should be supported, e.g. a city made out of several houses all contained in their own mpd's)

For example what does mlcad do if you load a different model also containing a stud.dat, will all parts change or will they retain the previous version.

I'll have to do some additional research to get a better insight on the 'de-facto' way of things.


RE: Search path discussion - Travis Cobbs - 2021-03-17

(2021-03-17, 7:08)Roland Melkert Wrote: That's ok, but the thing I'm getting from this discussion is the feeling there are different rules for parts and model's.

Also the examples given are all single model ones.

O would like to define the whole spectrum of behaviour.

Including references to another mpd (sorry Travis I think this should be supported, e.g. a city made out of several houses all contained in their own mpd's)

For example what does mlcad do if you load a different model also containing a stud.dat, will all parts change or will they retain the previous version.

I'll have to do some additional research to get a better insight on the 'de-facto' way of things.

I don't understand what you mean by different rules for parts and models. The rules are the same for all files, but the directory containing the top-level file is treated as being special (being the second entry in the path lookup right after mpd-contained files).

We can come up with rules for mpds inside of other mpds.


RE: Search path discussion - Roland Melkert - 2021-03-17

(2021-03-17, 19:27)Travis Cobbs Wrote: I don't understand what you mean by different rules for parts and models. The rules are the same for all files, but the directory containing the top-level file is treated as being special (being the second entry in the path lookup right after mpd-contained files).

I always assumed every ldraw file looks in its own mpd content and folder before diving into the search path (even files loaded from parts\s etc)

Then the above made me think this should only be done for models.

And now you write it should only be done for the top level file.

The one things made clear inside this thread: its about time we standardize this Big Grin

That said it would be very complicated and messy, imho, to enforce the proposed global approach in an editor which works with multiple open models etc.

I, for example, would need to completely rewrite the caching system of LDCad (Something I'm not looking forward to).


RE: Search path discussion - Orion Pobursky - 2021-03-25

In reply to the latest comment by Roland in the LSB forum:

I reallly don't think we should define an "unofficial" path. Instead of unofficial it could be "user defined paths" or simply left off.


RE: Search path discussion - Roland Melkert - 2021-03-26

(2021-03-25, 23:05)Orion Pobursky Wrote: In reply to the latest comment by Roland in the LSB forum:

I reallly don't think we should define an "unofficial" path. Instead of unofficial it could be "user defined paths" or simply left off.

That's why I added the "Given <LDraw> is a 'library', meaning you could have multiples of those. " bit.

So it only follows that order within a self contained library.

This way you can use multiple libraries and custom files like e.g.:

<myMainLDrawFolder>
<unoff-202100326>\p
<unoff-202100326>\parts
<unoff-202100326>\models
<unoff-202100326>\Unofficial\p
<unoff-202100326>\Unofficial\parts
<lib-2003>\p
<lib-2003>\parts
<lib-2003>\models
<lib-2003>\Unofficial\p
<lib-2003>\Unofficial\parts

It doesn't matter if the unofficial zip doesn't have the model folder etc, it's just another library and a program should search within it using the given 5 folders (if they exist).

LDView already does this but only for a single Library.
As I understand it some others (LPub?) also use the, by LDView created, Unoffical p and parts folder (hence the request to standardize it).
LDCad is easily adjusted to add the models and Unoffical/* ones.


RE: Search path discussion - Travis Cobbs - 2021-03-27

(2021-03-25, 23:05)Orion Pobursky Wrote: In reply to the latest comment by Roland in the LSB forum:

I reallly don't think we should define an "unofficial" path. Instead of unofficial it could be "user defined paths" or simply left off.

What about if we standardize everything except the Unofficial, but also note that some programs then add the two Unofficial paths to the end of their search path.


RE: Search path discussion - Roland Melkert - 2021-03-29

(2021-03-27, 1:54)Travis Cobbs Wrote: What about if we standardize everything except the Unofficial, but also note that some programs then add the two Unofficial paths to the end of their search path.

So just add 'Models' to the current p and parts folders?