Does anyone happen to know of a handy list of all the commands that take arguments on the following line or lines? Examples I know of are weld, addChild and all the valueOp commands, but I guess there are a few more, and I'd rather not sift through all of the available docs in search of them if I can avoid it. :blushing:

Thanks!

We're talking about Poser library files here, right? I can think of other keywords which introduce a parameter block, but I don't know of a list anywhere. I guess one might be interesting to us file hackers. :)

Where do you draw the line though? Does the figure section count, or is it part of the hierarchical structure? How about the materials section? Deltas? You may have opened a can of worms here. Or maybe I'm just being pedantic, in which case please ignore me. :)

Yes, I'm talking library files. I might be interested in scene files at some point, too, but not at the moment. I should have expressed myself more clearly, though: I'm interested in anything that has its parameters in the following line or lines, but not packaged into a pair of curly braces.

See, I've written some code that parses a cr2, pz2 etc and internally creates a tree structure, and an API to manipulate that tree structure, which I can then write out to a new file. Now I'm working on a script to refactor some JCM code for Antonia. For that I'd like to have the valueOpDeltaAdd commands as nodes with all their parameter lines as children to make it easier to move them around and such. While I'm at it, I thought it would be good to have the same structure for all the other commands with that kind of syntax.

If braces are present, that makes parsing easy. Likewise if the command and all its parameters are in one line. The remaining case is the tricky one because one needs to know which commands are affected and how many lines of parameters each takes.

Quote - I'm interested in anything that has its parameters in the following line or lines, but not packaged into a pair of curly braces.

Ah, gotcha. Sorry for adding confusion where none was necessary.

Somebody wrote (or claimed to be writing, which is nowhere near the same thing) a Poser file parser at some point; I can't remember the details and suspect it didn't get finished.

A Poser file validator would be a really useful tool, if such a thing were possible. ;-)

These file validating libraries are existing but due to the high amount of trial'n'error finding this out they are normally bound into software to be paid, e.g. Dimension3D's Poser File Editor.

I have tried such myself but even with known structures poser sometimes is very tolerant, e.g. :: in file specifications, and at other thing's absolute picky. So you need a lot of free stuff and paid stuff as trial resources to get (nearly) all.

The best ressource I know is the older book "Secrets of figure creation with Poser 5". Although this is not up to date with the latest versions stuff it's the best compendium at all.

A free trial of cr2 documentation can be found here www.kuroyumes-developmentzone.com/poser/poserfilespec/products_poser_cr2.html
Even not complete or up to date.

And for the structure of that ERC blocks this can help www.rbtwhiz.com/rbtwhiz_ERC.html
Also not on the latest stand.

It's a shame that even the poser developers are not able to deliver a mostly complete technical reference for the byte pushing people ...

Just looking through google I came across this page linux.ucla.edu/~phaethon/blender/cr2bone_import/
That poser-parser islooking very interesting although also not up to date ...

Thanks for the links, Jo! I've been perusing Kuroyume's unofficial spec on a regular basis and found it extremely useful. I've only heard good things about "Secrets of figure creation with Poser 5", but don't own a copy myself (yet?).

That Python parser definitely looks interesting, even though I'm not sure it is the most useful approach. The parser I'm using - implemented in 9 lines of Scala code - plays dumb and treats the file - syntactically - as a simple hierarchical structure. Everything else is then done via post-processing. If you want, you could say I'm using a multi-phase parser, with the second and subsequent phases operating on the tree structure produced by the first one. But I'm using a "lazy implementation" approach to this. I only add whatever functionality I find missing in my practical applications. That means that if I keep at it, at some point I will end up with the ultimate tool for all my (or your) Poser file manipulation purposes, with an API that perfectly balances expressive power with ease of use. :laugh: But until then, I'm afraid it's not going to be very useful for anyone but me.

For those "special" commands I asked about, I scan the structure for occurrences of these and then make the following lines children of the command node. Checks for correct parameter types and such could be done in a similar way. A lot of potential consistency issues in Poser files can't be expressed as syntax, anyway - or if they can, that syntax would have to be horrendously complicated. For example, look at the duplication of joint parameter channels and the addChild and weld commands.

I'm thinking about writing code to do some more rigorous checking of cr2 files, since I've had many problems related to inconsistencies or other bugs in Antonia's cr2 pointed out to me during the course of development, and I'm almost certain there are still quite a few hidden in there. If and when I do, I'll let you guys know.

There are several bits and pieces of code kicking around :-

adp001 -> http://www.poserprofis.de/python/scripts.xml (Python based poserfileOOPlib)
apu60 -> http://www.renderosity.com/mod/freestuff/details.php?item_id=47285 (C++ file parser)

Older stuff

Dodger let loose some PERL code -> http://www.renderosity.com/mod/forumpro/showthread.php?thread_id=1230388
see also -> http://rfi.elgeneralisimo.com/forums/index.php/topic,57.0.html

pilzchen -> http://www.renderosity.com/mod/freestuff/index.php?user_id=142359

Cool links, nruddock!! Thanks!

While we're at it, you can find my code at http://github.com/odf. The Poser file parser and manipulation API is called pfool. There's not a lot of documentation as yet, but I'm happy to explain if anyone is interested. I have quite a few example scripts that are not on github yet, but which I'll be happy to add if anyone's adventurous enough to install Scala and try them out.

There's also a Python version within the same project, but I haven't touched that one for quite some time.

I don't know of any list. One example of  augments I can think of: linkParms head:4 scale jaw:4 scale

Not really sure what qualifies as an augment. Some stuff naturally goes together like: forceLimits 1 min -100000 max 100000

But I don't know if you could call min and max augments to forceLimits.

Quote -
I don't know of any list. One example of  augments I can think of: linkParms head:4 scale jaw:4 scale

Not really sure what qualifies as an augment. Some stuff naturally goes together like: forceLimits 1 min -100000 max 100000

But I don't know if you could call min and max augments to forceLimits.

Yes, linkParms should definitely be on the list.

My criterion is this: if it only makes sense in the context of some preceding line, then it's an argument. If the limits set-up looked something like

    limits
      on
      -100000
      100000

then I would regard the three lines following "limits" as arguments. But the way it's actually done, the "min" and "max" lines could in principle be anywhere in the channel code with the same meaning (and least that's what I think is - and hopefully will keep being - the case).

Another example I thought of in the meantime are the inclusion/exclusion spheres in JP channels.

Quote - But the way it's actually done, the "min" and "max" lines could in principle be anywhere in the channel code with the same meaning (and least that's what I think is - and hopefully will keep being - the case).

Ooh, you wanna be careful with that. :-) I only have anecdotal evidence - as far as I know, nobody has attempted to document this - but Poser can be fussy about the order in which things occur sometimes. Other times it doesn't care, as mentioned above. This may (or may not) vary from one version to another.

The fall-off curves in a magnet's sphere are something else to add to the list, BTW.

I guess I'm not that concerned about the limit settings so much because I regard them as fixed parts of every channel definition. The valueOp stuff is different because one could have any number of those, and it's important to know how many lines have to follow the initial command. Same thing with falloff zones. I need to know what falloff zone instructions look like and how many lines belong to it. Same thing again with weld, addChild and linkParms instructions.

But I take your point. Poser files are complicated, and there are lots of subtle, non-obvious rules. There's probably no point in trying to understand them all at once.

Quote - I need to know what falloff zone instructions look like and how many lines belong to it. Same thing again with weld, addChild and linkParms instructions.

In my experience. Weld is always two lines of code, addChild is always two lines, linkParms is always four lines.

With the fall-off curve in a Mag Zone the number of lines is variable.

        buildSphere
        newFalloffCurve
        falloffCpt 0 1
        falloffCpt 0.2 0.93
        falloffCpt 0.8 0.07
        falloffCpt 1 0
        endFalloffCurve

The first two lines and the last line are always the same, however the the number of 'falloffCpt' lines is variable and user defined. The falloffCpt lines correspond to nodes (or "Control Points") in the Falloff Graph (AcmSplineWindow). Nodes can be added to the spline curve by clicking on it with the mouse, they can be deleted by clink-dragging the mouse over the node to select, then hitting the delete key. The minimum number of nodes a FalloffCurve can contain and still function correctly is 2, the maximum is not known, the default number of falloffCpt lines when a new magnet is created is always 4, and they always contain the same values as in the above example. The number of nodes can only change by user intervention, either by editing the falloff graph, or by injection of a new FalloffCurve via a pz2. I think the two values in a falloffCpt line represent distance from origin and amplitude.
Similar to the Mag Zone, is the spline curve in a Walk Path:

        numControlPts           6
        pt      -0.040000 0.000000 -0.200000
        pt      0.000000 0.000000 0.000000
        pt      0.200000 0.000000 1.000000
        pt      -0.200000 0.000000 2.000000
        pt      0.000000 0.000000 3.000000
        pt      0.040000 0.000000 3.200000
        calcCurve

The default number of control points is 6, but again it can be varied by user intervention. The 3 values in a pt line are x, y, z coordinates relative to the prop's origin. The y value is not available through the Poser interface, though it will work if the prop is edited in a text editor. Other examples of parameters that take augments which have come to mind are from JPs, 'sphereMatsRaw' and 'doBulge'.

With the valueOp stuff, valueOpDeltaAdd is of course 5 lines. To the best of my knowledge none of the other value operators can take a deltaAddDelta line, so all the others are 4 lines of code.

Thanks Les! I just keep wondering what the people that cooked up Poser's file format were smoking.

I always regret not being invited to the party the night added 'indexes', which means "number of deltas", and 'numbDeltas' which means "number of vertices".