Q: I ran the utility and it created the primary support files, but the figure takes forever to load. Why? A: Because ExP is based on the same includes (readScript) technology found in the Delta Injection/Removal (INJ/REM) system used by DAZ 3D in the 3rd generation Millennium figures, the same limitation that is imposed by Poser® for that system, where the support files must be located within the runtime directory structure of the application itself and not a supplemental content directory, is also a limitation of this system; if the files are not located in the folder that Poser expects to find them, [Poser] will spend an exorbitant amount of time searching the hard disk for them. While DAZ|Studio is not limited in the same way, one should still be mindful of the fact that in a mapped structure like the one that DAZ|Studio implements, the primary files for a given figure should exist in only one location; or you'll end up loading only the portions of the product listed in the first primary support file found (using the specified relative path) rather than the entire compliment.
Q: What is the purpose of the Primary files? Why are there so many? A: The Primary files serve as a middle man between the figure (cr2) and the Secondary files; which are provided by developers to extend a given figure. Because the Primary files are referenced by the figure, even if a Primary file contained no readScript statements, it would still need to exist in order to facilitate the addition of a product to that actor without need to update the figure itself. Each newly installed product that affects a given actor adds files to that actor's subdirectory. When the utility is run, it scans the contents of the actor subdirectories for that figure and generates the Primary files based on those contents; if there are two products for the actor, the associated Primary file will list two includes (readScript), and so on…
Q: Why are there separate Primary files for channels and parameter groups? A: This is due to the manner in which Poser processes the information in its files. Poser is destructive in its handling of the groups clause of an actor; meaning, each subsequent clause encountered for a given actor destroys all previously defined parameter groupings for that actor. To work around this limitation, we place the include (readScript) statement within a single groups clause for the actor and format the data in the Secondary file for in-line inclusion. Channels have their own files because they are declared in a different location within the figure (cr2), and they must be declared in the initial definition of an actor.
Q: So, if I want to create an add-on product for a figure that uses ExP, I just need to create the Secondary files for my product? A: Yes. See the Support Files (pz2) section of the ExP white paper for more information.
Q: What are linkParms? A: linkParms are a legacy construct for establishing a 1-to-1 relationship between one parameter and another, whereby the value of one parameter is identical to and displayed in another parameter, and vice versa. Either parameter of the relationship can be modified and the other will update. There is a limitation, however, in that the relationship can only be established between two parameters; creating a loop consisting of three or more parameters will cause Poser to hang - due to creating an infinite loop. Use of the construct appears as far back as the Poser 1 Man (June 1998).