Son-of-a-gun! I didn't even know that forum existed. thanks.

Quote - Within the scripts-menu there is a python console. You can use it to run an interactive python shell. For running the debugger, you would use (as usual):

 >>> import pdb

 You can use the execfile function to debug a script, i.e.:

 >>> pdb.run ("execfile ('myscript.py')")

 assuming the script is in the current directory (otherwise use os.chdir())

Great, I think that's going to do it, but I haven't had a chance to test it out much.

I also put this question to Ralf Sesseler at Diminsion 3D, and he said he just uses the "print" command for his debugger. Wow! That's the way I was debugging my COBOL code in the 1980s. Ralf does some of the best Python scripting for Poser that I know of, so I guess it works for him.

Acadia - Most programming environments these days have some sort of debugger built into them. A debugger lets the developer stop the code execution at a given point, shows the code, and lets the developer look at what some of the variables are set to, and all sorts of neat stuff. Then the programmer can step through the code line by line to see if it's behaving the way it is expected to.

OK. So in the mat file I'd be looking for something like this:

                nodeInput "ReflectionLiteMult"
                    {
                    name "Reflection_Lite_Mult"
                    value 1 0 1
                    parmR NO_PARM
                    parmG NO_PARM
                    parmB NO_PARM
                    node NO_NODE
                    file ""
                    }

Quote - On the subject of textures and so forth, there is absolutely no excuse to leave Reflect_Lite_Mult enabled.  Also, if you must provide fake reflections on surfaces like corneas, give us a way to turn them off.  If you provide a MAT with AO enabled, povide one without.

Hear-hear!!! Jeez, I wish more vendors came in here and read these basic things-to-do... alas, most can't be bothered. Diffuse_value of .8 too much to ask? I spend more time fixing this than anything else.

Hey SamTherapy and RobynsVeil -

Can you tell me more about this? I'm finding that I need to clean up the content files before I start using them, but I don't yet know all of the stuff I should be looking for.

I've found  a couple of tools* to be quite useful for doing this but they are limited in scope. Otherwise I do it manually. Eventually I'd like to be able to sweep through a runtime and fix everything, but I need to know what I'm looking for.

• FC2Fix by gsayers to clean up expression poses and CorrectReference by HogSoft to clean up references to textures.

Actually, this is a question I've had also. It happens with certain outfits also.

Lately I've been cracking open these Poser files (.cr2, .pz2, etc) just to try and figure out what's going on inside them, and I've gotta tell you - it's ugly in there.

When I saw this thread I thought I'd take a look inside some .fc2 files, and it's not any prettier there. There are so many inconsistencies, errors, and different approaches it's amazing they work as well as they do.

Here's what I've found out so far. As xpdev noticed some of these fc2 files change not just the expression but set the face back to Vicky (or whatever the base model is). This is just plain wrong and the vendors should correct them. An fc2 file that works as it should will be about 9K in size. If you see one that's around 28 - 33K you know it will set the face back to Vicky.

ErickL88's approach will work, but it's very cumbersome and prone to error. You have to go down the entire list of morph channels and set each one on or off. There's no way to select a range and set them all at once. That's not Eric's fault of course; it's just the way Poser works.

The better approach is to use gsayer's FC2FIX tool (thanks for the tip, cspear) which runs through fc2 files and drops any morph channels that aren't considered real expressions. The real expressions are maintained in a txt file called acceptable.txt and the user can modify it to suite their own purposes.

Finally, I noticed that some expression packages were actually in a pz2 format which is for the entire body, not just expressions. The FC2FIX tool can't fix those. I think the reason some vendors do this is because sometimes they bring the tongue and perhaps the neck into an expression, and I guess those are outside the scope of a fc2 file.

So, there you go. Hope it helped.

Quote - Read my signature.

Guess what???

The PoserPro manuals are here.
On my desk.
All the time.
Pretty soon I'll have to print a new set :-(

Yes, I understand that Poser has manuals. It's just that they are not very good.

Quote - why do you keep on about it? you've got the answer!

Because that's really not the question - well, not anymore. The reason I keep going on about it is because the conversation has broadened to the larger issue of Poser usability of which Andy is a small part.

Rats! Right now I really regret using the term "user hostile". I knew it was a bit over-the-top when I said it which is why I put it in quotes, but it seems to have been taken literally by some, and it has redirected the discussion in an unnecessary and non-productive direction. Sorry. My mistake.

So, let me try to get it back on  track. The question in the OP was not, "How do I delete Andy?", but "What are you supposed to use Andy for?" I imagine that most first time Poser users have much the same reaction that I did which was basically "WTF?" What are you suppose to do with him? Do you turn some dials to turn him into a human figure? No... Can you put some clothes on him? No... Is there a tutorial or a guide or something that talks about him? No...

When talking about Poser's usability issues, Andy - at least his use as the default character - is a pretty insignificant blip. It just happened to be the thing that started this conversation.

It's a shame that Poser is so "user hostile". They've obviously put an enormous amount of work into the technical side of it, and I stand in awe of the coders who make the magic happen. Alas, the interface, the content management, the manuals and all those other things that make an application usable to actual human beings are just terrible.

It's not unusual for coders to look down their noses at usability issues while they are building their cutting edge features into the product, but if their users can't figure out how to even get past step one, those bells and whistles are just going to sit there collecting cyber-dust.

I read in another thread that there was a major shake-up at SmithMicro. While it's unfortunate that someone may be losing their job, it gives me some hope that the new team will raise the usability issues to a higher priority.

Quote - Not even going to bother playing the quote cut and paste game with you. Nobody here suggested that the new user should read the manual from start to finish "Except for YOU". Everyone else merely said read the manual. IE: It's your reference book for the piece of software you just paid good money for. You want to play word games you can play with someone else.

Maybe you should do the quote cut and paste game because you‘re misquoting me all over the place. In your previous post you called me the guy "who said you shouldn't have to read the manuals.” Well, I never said that, and now you’re claiming that I said that new users “should read the manual from start to finish.” I never said that either. These aren’t word games. These are cases where you completely and totally have not grasped the substance of what I said.

Quote - At what point is it safe to assume a new user will know what something common like "A Practice Dummy" is for?

Actually that’s a good question and one that I alluded to in my previous post when I talked about knowing who your users are. Was it reasonable for the Poser developers to assume that users would figure out what Andy was about all on their own? Well, maybe, but obviously not in the case of the OP otherwise s/he wouldn’t have asked the question. My guess is that a lot of users have wondered about the same thing.

Finally, I feel I have to point out that you have abandoned your previous argument and are trotting out a new one. In your previous post you said that users should look to the manual to find out about Andy, but when I pointed out that he’s hardly mentioned in the manuals you switch to the argument that Andy’s purpose should be abundantly obvious to anyone – implying, of course, that the OP was pretty stupid to even ask such a question. Is this what you meant to say?

Quote - Well first off, as a "Technical Writer" you should know what a "Table of Contents" is and how to use it! If you had bothered to read your manual you would have seen "Chapter 9: Posing Figures where it explains just what you do with figures that are in your view port! Second, as a "Technical Writer" you know you don't have to "Read the whole manual" just to find out one aspect of the program. If the "Table of Contents" doesn't point you to what you need there is also an Index in the back where you can look up specifics such as "Figure" or "Figure Posing".

When dealing with usability issues it’s important to keep in mind who your users are. In this case we are talking about users who are new to Poser and are seeing it for the first time or maybe the first dozen times. As implied in the OP, their experience is that they keep seeing this Andy character and wonder what the deal is with him. Your suggestion is that they should turn to the Table of Contents and that would somehow point them to “Chapter 9: Posing Figures”. Well, how would that work? What would be the link in the user’s mind that connected “Andy” with “posing figures”?

Your next suggestion about using the index to look up “figure” or “figure posing” has the same problem. There is no obvious link between the question, “What’s with this Andy guy?” and “figure posing”.

Actually with electronic formatted manuals people don’t use the ToC or index that much anymore. Instead they use the Find or Search feature, and searching on Andy will, in fact, take you to Chapter 9, the only place he is mentioned at all, but even then he is discussed in the context of IK and bone count, and that’s not really answering the user’s question.

Quote - The reason "Andy" is preloaded is because if there wasn't anything loaded at all, New Users would HAVE to pick up the manual just to learn how to load a figure. He's there to give said new user a jumpstart on that for people who refuse to read those technical manuals that you claim to write. They can load Poser and Zowie! There's already something in your scene to push and pull on and play with.

The way that’s typically handled – and has been since at least  Windows 3.1 and probably since the very first GUI - is to take advantage of the File->Open menu. The standard dialog box that pops up tells you what file types are associated with the application (the “Files of Type” drop down), and, for most well designed apps, it defaults to a directory where there are some good samples of whatever it is that the app does. This invites the user to open up a user-friendly, teachable object that they can explore. What is not typical is for some default object to persist in loading at startup long after the user has done their exploring and even saved a few objects of their own.

Quote - That being said, it wouldn't have hurt the technical writers of the Poser manual to put in a chapter all about Andy, but.... who would read it?

Well, the best place for that would be in the Poser Tutorial Manual, but oddly enough, Andy’s not even mentioned there.

Quote - And Miss Nancy, I wasn't "Chastising" the OP who asked the question. I was chastising the know it all "Technical Writer" who said you shouldn't have to read the manuals.

I’ll pass on the ad hominems and just say that I never said that “you shouldn't have to read the manuals.” I said, and then later restated, that you shouldn’t have to read the manual from start to finish.

So, ultimately, it looks like your “Stupid Comment of the Day” prize went to something that was never even said, but something you just misread or didn't quite understand.

No, really, Jax, I want to know. You took the time to declare the most Stupid Forum Statement of the day, so I'd like to know what made it so stupid. I've reread it a few times and I still see it as a rather obvious and ordinary statement, but you saw something especially moronic about it. So please, explain to me and anyone else who might possibly give a rat's *ss just what your thoughts were..

Quote - And the winner for the most Stupid Forum Statement today is.....

And the reason you consider it so stupid is...

Caveat: I'm a technical writer and this is an issue of near religious obsession with me, so I'm going to ask forgiveness in advance for being a bit over the top. 

Quote - What does it matter what his "purpose" is? Do like almost everyone else does - delete him and load Vicky...lmao.

I think it's a bit beyond the scope of most manuals to tell you what to "do" specifically with your program. The short answer is, you do what you want to do with what you've got.

Laurie

Harrumph!!!... I couldn't disagree more. Everything in an application should have a purpose. It should have an explicit reason for being there. In the parlance of MBAs it should address a "pain". Otherwise it's bloat.

I'm sure there was a reason why Andy was developed in the first place and why he was chosen as the default character, and I'm sure the Poser developers discussed that quite a bit during the process. My guess is that they wanted a human-like character with minimal features and minimal resource requirements so that new users could experiment and get a feel for the application in a quick and obvious way. Others have suggested that very thing, and others have suggested other things that Andy is good for, and that's an important point. Just knowing what his purpose is doesn't limit the users in what they can do with him. 

One of the reasons people don't read manuals is because they rarely tell users what they really want to know, and that is, at its essence, "What can this program do for ME? What can this feature do for ME?" Giving the PURPOSE of a program or feature answers that. Telling you what something DOES only hints at the answer. Of course, the Poser approach of just throwing stuff out there without telling you anything about it at all, is just downright rude to the user. It's like saying to the user, "Screw you, users. I don't have time to explain this stuff to you. Figure it out yourself."

Taking a "purpose-driven" approach to manuals doesn't significantly change their size or scope. It does, however, make them much more usable.