To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.devOpen lugnet.cad.dev in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / 10445
10444  |  10446
Subject: 
Re: MPD file loading search order
Newsgroups: 
lugnet.cad.dev
Date: 
Tue, 25 Jul 2006 23:24:24 GMT
Viewed: 
2211 times
  
In lugnet.cad.dev, Travis Cobbs wrote:
As you have pointed out, the spec is indeed ambiguous.  Consequently, there's
probably no correct answer as to how things {should} work.

Well, if you read all postings on MPD through the last seven years you should
be able to piece the correct answer together :-)

I believe the L3 parser (used in L3P, L3Lab and "ldglite -l3") reflects that information.

> However, I can tell
you what I do in LDView, so that you have an idea of how at least one
MPD-compatible program {does} work.

Thanks for your thorough explanation.
I'm happy to see that the functionality is the same as that of the L3 parser!

L3 also uses two passes, but parsing happens in the first pass.
Each part entry in the global cache has two flags, FileRead and Resolved.
LoadPart is called with the first entry which is the model file.
If the part entry has FileRead false (which the model has)
the DatName is searched and the file is parsed.
All lines read are attached to the part entry.

Whenever a linetype 1 is encountered, the referenced part is registered
in the global cache. In case it wasn't found it will created
(FileRead and Resolved set to false).

Whenever a 0 FILE is met that new part is registered in the global cache
(FileRead true and Resolved false) and following lines will be attached
to the new part.
In the rare case the part was already in the cache it should be skipped
(hm, currently it just appends to existing part!)

When done reading and parsing the file is closed and part is marked FileRead.

The second pass begins.
It is a loop through all lines attached internally to the part.
If the part entry of a linetype 1 is not Resolved, recursion begins
calling LoadPart with that part entry.
Finally the part entry is marked Resolved.

Only one file is open at a time.
Subfiles of unused parts in an MPD will not be loaded.


LDView doesn't actually have any special MPD-recognition routines.  So LDView
doesn't care at all what the file extension is.

Same here.


It was stated back in 2000 that files in an MPD are public:
http://news.lugnet.com/cad/dev/?n=4188&t=i&v=a

/Lars



Message has 2 Replies:
  Re: MPD file loading search order
 
(...) Wow, that's impressive. I'm pretty sure it's accidental, too. (Accidental on my part; your L3P parser was obviously there first.) (...) LDView only has one file open at a time also (unless I'm mis-remembering my implementation), since the (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
  Re: MPD file loading search order
 
Lars C. Hassing wrote: [snip detailed explanation] Thanks for the insight of you're L3P ldraw reader routines. (...) If you mean by public, public to all children and not the whole world, this fits perfectly in Anders Isaksson vision. See my reply (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)

Message is in Reply To:
  Re: MPD file loading search order
 
As you have pointed out, the spec is indeed ambiguous. Consequently, there's probably no correct answer as to how things should work. However, I can tell you what I do in LDView, so that you have an idea of how at least one MPD-compatible program (...) (18 years ago, 25-Jul-06, to lugnet.cad.dev, FTX)

29 Messages in This Thread:








Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR