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.

When I looked at the way V3 was done, I noticed V3's empty dial slots are utterly identical. When I went to do something similar to V3, I replaced all the code from those empty slots with the same readScript line, calling a single script, and reduced my cr2 from 8.5 to 3 meg. It reminds me of the old dBase do/Procedure command. It's excellent for killing repetitive code. When I call my REM poses, they in turn call the exact same script used by the cr2, which puts the dials back into the empty state. I've nested up to 3 readScripts on JCM injections, but haven't had a reason to attempt further nesting and possibly find a limit. I haven't tried it yet, but I was wondering if anyone had used it to call a crosstalk shield. Hey dodger! Thanks for contributing the exe hack a while back. I've found it very useful. :-)

Ohh, the strings dump of the binary?

Yeah. I saw pickActor in there, which led to Point At Poses, and part of that method Les recognized as solving MATs for unparented props. I think you might have been away while we were having that conversation. It went on in both technical and regular forums. And then VK, the human math machine, figured out various ways to make Point At dials automate rotations and such. It was a brief discovery spurt, I suppose. A good time for all. Wondered where you were. Did you see that thread where VK successfully tested the other valueOps -- plus, minus, multiply, divide?

Thanks Dodger, this is a very informative thread. At the risk of sounding stupid, I must admit that for one mad moment I thought this technique might accomplish the imposible and add a new channel to a cr2 in play. My logic ran like this; you can use a read script in a cr2 to read in a channel, you can put a read script statement into a pz2 and the contents of the script will be inserted into the cr2 when the pz2 is applied. So put a channel into the script file and use the same technique as you outlined for MATs to inject the contents of the script. I have tried this and it does not seem to work. Looks like a pz2 can only inject the things that a pz2 can inject, whether they are in a read or not. Oh well the imposible is still imposible, never the less this read script looks like it has interesting potential.

solving MATs for unparented props Oh, what was the solution? Did you see that thread where VK successfully tested the other valueOps -- plus, minus, multiply, divide? Nope. Got a thread ID? Looks like a pz2 can only inject the things that a pz2 can inject, whether they are in a read or not Yup. I consider Poser to have only two filetypes, despite all the extensions. There are different 'rules' with some of the extensions (like hair) but overall there are two core types of file: Load files (pz3, pp2, cr2, hr2) Pose files (pp2, fc2, hd2) Cameras and lights seem to be a sort of hybrid, and don't perfectly follow form. They act like pose files except as regards lights and cameras. Anyhoo, pose files do not add to the scene they work as control scripts for the dials and settings already in the script. Load files, on the other hand, do add to the scene but do not (generally) affect the existing geometries in the scene. When you call a readScript from a pose file, it works like the contents are a pose file. When you call a readScript from a Load file, it works like the contents were a Load file. Thus my concept of pm4 materials above could be applied to CR2 files and MAT poses equally.

MAT props: Just previously refer to the prop as an actor instead of a prop, then continue treating it as an actor. actor ball_1:1 } { I learned that certain commands only function if they are previously declared within the same script: pickActor, useCamera, pointAtTarget... I've been too busy to find out everything else requiring this prior declaration, but I suspect it is the key behind some of the commands we haven't gotten to work.

Attached Link: http://www.migal3d.com/Downloads/Mil_Eyes_Pap.zip

Attached Link: http://www.renderosity.com/messages.ez?ForumID=10139&Form.ShowMessage=1228987

Attached Link: http://www.renderosity.com/messages.ez?ForumID=10139&Form.ShowMessage=1258117

certain commands only function if they are previously declared within the same script: pickActor, useCamera, pointAtTarget... Yep, of course. Anything that takes an object reference as an argument would do that. If the object referenced in the asrg is not valid, the directive is also not valid as it points at nothing. Have you played with the possibility of pointing these arguments at valid but null objects, like UNIVRSE or relational references like PARENT? Thanks!

so, what I'm getting from this is that valueOpPlus == valueOpDeltaAddn deltaAddDelta 1 valueOpMinus == valueOpDeltaAddn deltaAddDelta -1 valueOpTimes creates a tangent and the valueOpDivide* directives open up an unhandled /0 runtime error. (that's really irritating, too) and no args for these, it seems. They are void functions.

on my UNIVERSE suggestion above, that won't work with useCamera. Has anyone tried to see if camWithNoName works?

I haven't tried camWithNoName. One of the pose files in that zip sets pointAtTarget to UNIVERSE, so it works with some things. I doubt pickActor would work, because UNIVERSE isn't an option in the selection menu. Everything else in the selection menu (except cameras) works with pickActor. I'm also using pickActor statements inside INJ files instead of defaultPick, because pickActor actually shifts focus. I'm currently trying to find a way to delete a figure with a pose file. Your take on the new valueOps stuff looks about like it to me. heh... Yeah, VK warned us about the divide by zero, depending on how you use it.

If you find a way to delete (all) lights with a pose file, I'll name my first born after you (well, maybe not, but maybe someone will ;). I know that there's a python script to do it, but Poser 4 standard doesn't do Python.

I'd like to think anything is possible, Spanki, but I seriously doubt the light killing can be done without python. I think of Poser files similar to what dodger was saying. Two kinds of Poser files: Files that load things and files that change the settings of things already loaded. I believe it may be possible to delete a figure, if we know the figure is in the scene. The problem with lighting is; we have no idea what is in the scene. There could be 200 lights in there, various types, with all kinds of weird names. Now, if it is possible to whack a figure, for instance, it stands to reason that a pose file could be made to whack lights, but only the lights known to be in the scene. IOW, people could make lighting packages that included removal of lights, because they'd know what lights their package makes. That's one of the many big advantages of python -- it's ability to return information to the programmer about the Poser environment. It can ask Poser questions. Spanki, have you ever considered selling Pose sets? I use your Mia lights and poses all the time. Good stuff. :-) Oh... And I forgive you for not making those stockings for V2 and Steph.

I'm currently trying to find a way to delete a figure with a pose file. You can't. You can't delete anything with a pose file. You can turn it off. If your'e concerned about memory usage and want to free geometry memory, you can also give the figure hidden alternateGeom channels in everything and replace them by pointing at a blank OBJect with a pose. That is definitely worth testing, but it depends on Poser's geometry caching mechanism -- whether it memoises (tech term, not a mis-spelling) geometry in an alternateGeom or not. Even deleting the figure on one of my omnilights (or Les') woon't remove the lights, it'll just set them free. And those lights are body parts. Technically speaking, Python doesn't ask Poser questions, it just has a pointer to the same data stucture with read/write permission. Hrm -- can Python call external executables in the Poser environment or is it restricted? If it can, then I could get python to use Perl. I spose I should look into just figuring out how to make a Perl plugin for poser -- though I don't know if this is possible.

Thanks for the correction, dodger. I thought Python opened its mouth, spoke out the questions, and the Poser environment responded in kind.

Migal, actually, one of my first products was going to be a 'partial pose' set (a bunch of lower-torso and separate upper-torso poses) - which would have been a first. The problem is, I procrastinated too long and Whitney came out with a similar (but better) product ;). I'm not ruling it out, but I'm more into modeling these days. Thanks for the comments though.

Thanks for the correction, dodger. I thought Python opened its mouth, spoke out the questions, and the Poser environment responded in kind. Nice. That was rather pointlessly rude to inject into a technical discussion, wasn't it? I am unhappy with the seemingly arbitrary facetiousness. What I was indicating was that Python had access to the same data structure that poser was using, rather than querying Poser and getting a response, mouth or no. There's a difference in the way things work that's actually rather integral. Put it this way, if Python asked Poser, Poser could lie under some circumstances. To my knowleddge, it can't. It's the metaphorical difference between asking someone to read you the newspaper and reading it over their shoulder. one of my first products was going to be a 'partial pose' set JICC comes with partial SET poses. I thought about the partial poses, but wasn't sure what the demand would be.

You're a smart guy, dodger. But, I've got a funny feeling we aren't going to be friends.

I generally leave that up to the other person.

Hey come on guy's, kiss and make up! Whilst I suspect that Dodgers statement that "You can't delete anything with a pose file." is true for figures, and in deed for almost everything else, I'd just like to point out that there is at least one exception:

                targetGeom RoundFace
                        {
                        indexes 0
                                {
                                }
                        }

This will delete all the deltas from the targetGeom channel. Of coures this is only because Poser provides a specific mechanisam to do so, "indexes 0".

Yup yup. I didn't think of that case simply because of the way I think about things. I think of delta removal as replacing a set of deltas with a new, empty set. Similarly, you can also remove frames from an animation using a related technique.

Too Much Information or Why Dodger is Extra Bitchy: Don't Read if you're squeamish: I'm probably extra cranky -- I apparently slept through 90% of yesterday thanks to paracetemol with codeine (AKA Tylenol 3). That's not what is making me cranky, though -- it's the reason I'm taking the T3. It involves staphylococcus aurelius, a pustule, the absolute completely worst place a male can have such a pustule, and Way Too Much Information if I go any further. Just trust me, there are tortures the Nazis never even thought of, and on rare occassions they occur completely naturally, especially when it's hot out and you walk a lot.

Note to leukocytes: Kill anything that looks like this

did you put eyes on that thing?