Just wanted to let people who may have been interested in this know: The Poser Parser module has finally gotten far enough I can say it exists! I'm not releasing it yet. Right now, I have it parsing Poser files. Sort of. It's intelligently reading them into a data structure. That's the first and hardest part. It's got some work to go, of course. Right now it treats the declaration/geom loading block as a seperate Poser object then the definition block (for reference, objects in a Poser doc appear twice: once to declare them and load geometry where applicable, and once to define them and set all their properties, channels, etc. Well, one of the basic problems with parsing Poser's syntax is that it's not terrifically constant. For instance, just to start with you have no statement delimiter -- many programming languages have the equivalent of a 'period' in English -- some character that says 'this si the end of this line'. In Perl and C it's a semicolon. Some languages treat a carriage return as a delimiter. Javascript uses both (and treats an escaped carriage return as just a space). This sort of thing makes things much easier to parse. Poser's syntax doesn't have one. Usually a carriage return ends a statement, but there are things like weld and addChild that break that rule and must be specifically looked out for. Then there's blocks. Most programming and markup languages (of which Poser's file format is the latter) have some way to define a block. In HTML it's with < and >. In Perl and C and Javascript it's with { and }. In Lisp it's with ( and ) and indentation. VB uses certain keywords as block delimiters (If and EndIf, etc). Again, poser doesn't have a constant one. usually a block is defined by { and }, but some things aren't done the same way -- for instance, valueOpDeltaAdd (the ERC keyword) contains block-type properties that apply to the valueOpDeltaAdd declaration but aren't enclosed in blocks. Same goes for sphereMatsRaw. And to make matters worse on the statement delimiter thing, at least with addChild you know there's an additional argument to the keyword on the line under it. With the Map keywords in materials, that's not always true. There's a 0 0 on the next line UNLESS the value is 'NO_MAP' Just to make things a pain in the butt. So this has been an interesting experience, to say the least. If you look at http://www.dodger.org/ttt/poserParser/test3.html you can see a parsed result of one of my CR2s suspended in HTML format as an HTML dump of the data structure thus parsed. The hash keys beginning with an underscore are used for internal tracking and such: _fh is the open filehandle passed back and forth, _lastkey is the name of the last key encountered in case a block begins, _debug should be obvious -- it's a flag to determine the debugging status, and _seq is the order in which the keys of the current object were read in to enable them to be put back out in the same order (perl hashes don't keep track of their order implicitly). Oh yeah, and _rotseq parses the rotation order as it would have been specified in the PHI if one was used (and only appears in channel sub-objects). Right now this isnt' useful to anyone except other Perl hackers like me -- this is because it doesn't really parse the file but it does sort it into a Perl data structure. I'm adding parsing as I go. I think useCustomMaterial is a boolean (true/false) and just has a non-1 value for true because Poser is weird (same as how forceLimits uses a 4). If anyone knows for a fact otherwise, can you please correct me before I go a lot farther? Anyway, by the time this is done, I'll have all sorts of convenience methods including being able to add, drop, and replace material blocks from material library files (I'll call 'em .pm2 files, I think, though Perl won't care what extension they have). You'll be able to extract geomCustom geometry to an external file with a single command. You'll be able to traverse the tree or access subparts with some simple syntax. And so on. And it will actually PARSE the stuff. B^) Due to the spproach I'm taking, I can make this wotrk without necessarily knowing how everything works -- for instance, to this day I have no clue what sl and spl in a keys block mean. That's why it can parse into a data structure without me having to define what everything means. Just thought those f you who may have heard me mention this project might be interested in the status of things. Isn't it nice to know I can at least do something right? B^)