In programming, the concept of an include is a way of statically linking library files into a program. For instance, let's say you wrote a function called in() to compare a string to the contents of an array and you wanted to use this in a lot of your programs. You could include this in your sourcecode instead of copyihg and pasting the source into the file. For instance, if you start learing C you'll find a lot of programs with lines at the top like: #include stdio.h Which means include the functions from stdio.h, the standard Input/Output library. (The '.h' means 'header file' and is used as a general way to delineate files that are generally intended to be included by other programs instead of programs themselves which usually end in '.c') In perl, you'll find stuff like: require 'cgi-lib.pl'; or use CGI; Both of which are forms of includes. The first includes the Perl 4 CGI perl library at runtime, while the second includes the CGI.pm perl 5 CGI OO module at compile-time. Even in some html, specifically SSI (Server-Side Includes, there's that word again), you can include things. Many .shtml pages contain things like: Which simply means 'Insert this file here as if it was part of the HTML code.' You can do this in Poser files using the readScript directive. readScript has been covered a lot lately because of it's extensive and exhaustive use in Victoria 3 from DAZ. I'm not going to go completely into its use, so here's a synopsis: readScript read and include the file located at and include it as if it were inlined into this portion of this Poser document. This has been used a lot, as I said, lately, but there's a level of potential that has not been quite hit on. One of the things I see a lot, as in V3, is the use of readScript to call entire other viable Poser files. V3, for instance, uses readScript to call in entire Poser PP2 pose files to load up injection morph deltas and so on (or remove them). The original use of readScript read in the default guy to the factory default P4 screen. Again, the default guy was a complete and viable CR2 that would be loadable by itself. However, readScript, as I've found, doesn't need a complete and viable file to load, just one that follows Poser's syntax requirements. To a bare minimum, at that. For instance, if you own the D-Bot you may have become frustrated, as did I, that the D-Bot has some seventy gajillion materials (not really, that's a slight exaggeration). Setting up exactly duplicate materials on all or most of these is a pain, even though it's perfectly conceivable that you might want most of the bot to be chrome with a few black accents or something. The common solution would be to create a MAT pose and copy-opaste the contents of one set material to the material blocks for everythign else you want identical. Though that's still a lot of copy-pasting, it's a workable solution. But it does make for a larger file, and one with repeated data making up most of the MAT pose file. Here's another solution: Open up D-Bot and set some easily-testable part of his body to look just the way you want it. Let's say we're doing chrome like I said above. Now save this D-Bot to a new figure in some temporary spot (or save a PZ3 file, it's all the same). Open this in a text editor. Find the mateiral you set (for instance, say you set 'Chest' -- find 'Material Chest'. Select everything INSIDE the curly braces for that block (the material settings, but not the 'material Chest' line or the curly braces*. Cut it. *Really, you are going to put the curly braces back, but I wanted this to be explained this way to show the reasons this works like this. Besides, if you sut the curlies you'd have to put them back. Open a news text file and paste this in to it. Save the file as something unique inside your runtime heirarchy. At this point, the file is NOT viable. It won't work. If you refer to it with a readScript directive, you'll get an 'The file is not a valid Poser file' error (or whatever it says). Now, in this new file, add curly braces before and after everything. This is to encpsulate the information. Just one pair around the whole deal. So the first line will have only '{' and the last line will have only '}' and the rest will be the normal contents found in a material block. Now make a MAT pose file as you normally would, stripping the CR2 or PZ3 file down to the version and figure block only, and remove everything in the figure block except for the materials. Now, remove the contents of each material block so they are empty blocks. Like so:

        material Head
            {
            }

Now, inside each of these blocks, add the readScript directive pointing at your file. Fo rinstance, if you named your file 'chrome.p4mat' and saved it inside the Runtime directory directly, it would look like this: material Head { { readScript :Runtime:chrome.p4mat }

Do this to all of them (or at least those you want to share chrome settings). Save the MAT pose as normal. When you load up D-Bot and apply the pose, everything you set to have the readScript materials will have the contents of the chrome.p4mat file set as the settings for the material in question. This can theoretically be used for anything. You could, rather than loading an entire INJ pose, simply make a normal Pose file that does a readScript for the contents of the deltas block. If you wanted to be really weird you could actually include external geometry using the geomCustom directive, by taking an OBJ file and adding the curlies to the first and last line thus making it a viable Poser document, then referring to it with a readScript in the contents of the geomCustom block. AFAIK, it doesn't even have to be a full block you do this with. For instance, lets say you wanted to save out light colours in a seperate file and load those colours up for the colour channels of lights, but not the other aspects of the lights (like their positions or even types). And hey, Nerd, this might possibly help you with your multi-figure problem, as you could, in theory, load up large chunks of channels from readScript includes and only keep the channels that refer specifically to a figure (via ERC or an otherActor directive) and save stating the same thing every time. Oh, yeah and it might be noted that if someone can come up with a way to reproduce the UNIX functionality of a named pipe, one could, in theory, point a readScript at a pipe from a program that listens to the current figure ID through pokes and peeks and supplies the correct figure ID. I don't have ProPack, but I imagine this could also be used in Python scripting, too.