This is a bit of advice that (like so much) isn't fully documented in the ProPack.

I have been trying to debug some Prop creation type scripts and have been plagued with the repeated problem that when I run a 'working' script a second time in the same poser session, the script hangs and Poser needs to be restarted unless I hit 'Reinitialise Python'.

I also discovered (no explanation as yet) that if I did File::Close then File::New at the outset, I didn't subsequently need to reinitialse Python between script executions.

Now I have just discovered that I had omitted the 'import poser' statement from the head of the script, and that it was this that was causing problems if the script was run more than once.

When I 'import poser' at the beginning of the script, I can execute it repeatedly without problems.

Granted, this is mentioned in the ProPack PDF, but its easy to ignore when it does not seem to be a requirement the first time a script is run. If anyone else has encountered similar repeated execution problems, this is something that may be worth checking. I saw a reference to the MK-Particles application requiring Python reinitialisation, and was wondering if this was in fact a manifestation of the same problem.

Bill

Hmmm ... I'm a bit surprised that you could get a script to run at all if you hadn't included an 'import poser' statement. I have on occasion forgot to include one and consistantly error out when I try to use any Poser Python method.

Yeah, but the point is that I could.

I suspect the cause is something to do with the poserStartup.py script which imports poser and Numeric for you. If this isn't always (or consistently) applied, it could go some way towards explaining the odd on/off behaviour.

BTW although the absence of the script didn't cause a reportable problem for Python's interpreter, the script did simply stop mid execution, so my guess is that there was an invalid (or possibly uninitialised) reference to a poser object. And, I'm using SR3 if that's of any relevance.

Actually, I am still intereseted in whether anyone has MKParticles and if the Python script(s) are missing the import poser statement.

Bill

I see your point about the poserStartup.py script. I never use the buttons, prefering to just load a script from the main file menu as needed. As such, poser doesn't get imported beforehand.

So do I, and it was when using the 'RunPythonScript' command that I encountered this behaviour.

I assumed that the poserStartup.py script was being run on poser initialisation, or when the default document was loaded (as in scene.SetStartupScript()). It invokes the main menu script, but that script actually sets the button members of the poser object, and doesn't necessarily display the menu window.

On a possibly related matter, I encountered some problems with the definition of polygons in geometry objects/props within a Python function, when the geometry/object was returned from the scope of the function. I thought I had fallen foul of the garbage collection, but it worried me because I couldn't see why the same thing shouldn't happen when the script terminates, and any prop geometries fall out of the script scope. This originally made me think that the poser Python object may have an application global lifetime (ie. it is only initialised on startup or document loading).

I'm still new to Python, but I'm an experienced enough programmer to know that I'm probably doing something stupid ;)

I haven't reproduced the problem, but I'll be keeping an eye out for anything similar.

Bill