I tried to run some of python scripts in PythonWin 2.3.4 and got an error message

Traceback (most recent call last):
File "C:Python23libsite-packagesPythonwinpywinframeworkscriptutils.py", line 310, in RunScript
exec codeObject in main.dict
File "C:Program FilesCurious LabsPoser 5RuntimePythonposerScriptsLightPanel.py", line 23, in ?
import poser
ImportError: No module named poser

Any suggestion?

Message edited on: 01/06/2005 01:29

Gweb: The vast,vast majority of scripts submitted here are meant to be run from within PP or P5, so as you've already seen, they won't run in PythonWin or even the standalone production releases of Python. They're written specifically for Poser's Python interpretter, warts and all. Hope this helps.

Ok how do you write python in Poser? Maybe I missed something here?

Nope, you're not missing anything. I had the exact same reaction when I wanted to write a script.

Basically, you just have to write the script in the text editor of your choice, then try it out in Poser. IDE? What's that?

FWIW, I use IDLE, which comes free with the standalone Python production release. Nothing special -- keeps nice python indentation, automatically highlights reserved words, that sort of thing. When I'm organized, I try to stub out poser related stuff, so I can use IDLE to try out Tkinter routines outside of PP/P5. But you always have to do final development within Poser, because sometimes even the Tkinter widgets look different when created by the PoserPython interpreter. (Nothing significant, just the alignmnent is just a little off sometimes).

Thank you for your reply. Do you think it would benefit if someone make Poser.PY to import in Python standalone as an interpreter and remote to Poser standalone while it is active? I really want to see this to get released becuase many of us would benefit for many of other things.

That's a good idea GWeb. It might even open the possibility of a way for P5 Python on the Mac to act as a socket connected interface to Poser, allowing an external Python engine such as MacPython or wxPython, which support Tkinter, to access and control Poser functionality. Sounds like a big job to me and one I'm not sure I'll have time to take on, but if others are interested, and it looks like it will have payoffs for Mac Python users, I'm willing to give it a bash or cooperate with others' efforts.

Thats interesting gw.. very interesting. I'm just getting into poser-python myself, but I think what your describing would be possible and not really overly difficult to implement, not only for MacPython or wxPython but convievably for almost any programming language that could accept a socket connection. Only two questions would be does the poser internal python interpreter have the ability to deal with sockets and can it be setup to start a python script when poser starts?

trobbins2, from what the Poser Python manual says, a document or figure can have a startup python script associated with it which executes when the document (or CR2 file) is loaded. If a startup script was associated with the default document, then this would effectively start when Poser was launched. If poser is launched by opening a document without this startup script, the script would need to be manually run after Poser had started. Apart from the Mac Tkinter brokenness, the Poser Python implementation looks pretty standard, so I'd be surprised if it didn't support sockets, though that will need to be checked.

Poser's internal python does support sockets. I did some initial coding, in fact the server side is pretty much finished other than teaching it how to react to various commands being sent by the client. But the basic server works great, it recieves data and responds to the client software using UDP ports. The socket connection is a real cakewalk to interact with, so it should support almost any programming language that can create a socket connection - C++ and Visual Basic just to name a few :)

I'll have to take a look at how to edit the default .pz3 but I can't imagine that will be too difficult, then it's just a simple matter of finishing the client code, adding some error checking and writing up some docs on how to use the client code in your own applications. With luck, provided real life doesn't intrude to much that is, I might have something ready to test in a few weeks.

The first foray will include the necessary client code to interact with other versions of python, but I'll add support for other programming languages as time permits.

It would be extremely helpful (since I don't have a mac) if you could test the code on Mac. I'm one of those awful PC people, don't you know :)

The CR2 startup script setup looks as follows (from the P5 Barney character): figure { name Figure 1 ... allowsBending 1 figureType 1318 origFigureType 1318 canonType 8 conforming 0 pythonStartupScript 0 0 ":Runtime:libraries:character:Additional Figures:Cartoon:barneyStartup.py" material Skin ... } Check out barneyStartup.py for the for callback samples. I think I saw some discussion between Ockham and face_off in other posts in this forum regarding where the script reference has to go in the PZ3 doc section. I'd really love to look at what you have so far trobbins2. I'll contact you direct if you don't want to post the code here.

Well, I'd be interested in seeing poserpython horizon's expanded. Be sure to check out these threads re: socket programming: http://www.renderosity.com/messages.ez?ForumID=12390&Form.ShowMessage=2022288 (socket example) http://www.renderosity.com/messages.ez?ForumID=12390&Form.ShowMessage=2031170 (thread/socket problem)

Actually the socket programming is pretty much done - it's getting used to python's syntax that is giving me fits at the moment.. lol..

But not to worry, the first revision will probably be a bit kludgy but it should work once I'm through.

I've got the client talking to the server and sending it commands, and the server processing the commands and then sending data back to the client. Just need to get all the commands defined, and then come up with a code interface for sending/recieving commands. So far I'm just using a couple of small functions for it. So if you wanted, for example, to get the value of poser python variable for ActorType and store it in a local variable called ActorType for your program to use, all you'd have to do is enter the command:

Actortype = GetPoserData("ActorType")

That's it. The function sends the request to the server, the server processes it, gets the appropriate value and returns it to the function, in this case setting the variable ActorType equal to the result. This should allow for a minimum of rewrite on already written scripts, you don't need to change variable names, just call one function to get the data needed from poser.

Same with setting variables or running an internal command, each is just a single function, so the whole client consists of some rather minor (I think 30-40 lines of code so far) coding and 3 functions. One to get the value of a poser variable, one to set the value of a poser variable, and one to send it other commands like the Kevent codes or similar items. Any data output from these commands is then reflected back to the client, again trying to keep the functions as simple as possible so that if you've already written a script for poser python recoding it will be as easy as possible, just adding a few lines here or there to access posers internal python functions and variables.

Just drudging through this blasted syntax.. lol.. haven't done any programming in a while and learning python as I go. In other words the first revision might not be the prettiest thing, but it should be functional... lol..

Thanks for the info on startup scripts gwhicks, and not to worry, once the code is reasonably functional I'll be posting it here for download.

It will be free for non-commercial use, as long as your not charging for the programs/scripts you write that use it you can use it to your hearts content and even distribute it with your programs. All I ask in return is a minor blurb somewhere in your doc file.. lol..

Hmm.. scary thought just occured, I think it might be possible to make this nearly transparent, so almost no recoding of scripts needs to be done. It will require that the client do most of the heavy lifting rather than the server.. but I think it's doable.

Have to do some testing tonight and see if what I have in mind will work, but if it does I'd say the vast majority of the poser internal commands will work just as they do in posers internal python, little to no rescripting needed whatsoever.