Attached Link: http://www.mort.net/users/krm/dist/poser/prpc

Thank you. I think this script is the greatest thing since sliced bread. I use it all the time now with P3dO. Good web page too.

(oops, deleted the wrong post, and I forgot what I had said, sorry).

Hi tromnek, Is it possible to add material loading to the script? That would make it fantastic. Thanks, Indoda

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

btw. I'm going to be away on holiday till the 31st, so you might not hear back from me till then.

Another interesting observation: Continuing on the intermittent KB functions... What I found out is if I stay in the Fast Track display mode I can select an item to delete and use the Enter key then the Delete key will work. This was not relable in any other mode. The editing tools are still hit and miss. I've ben seeing the same results using either PP or P6. Question: Does this script stop after the first initilization? Since it listens to a port I'm assuming not therefore I'm guessing that Poser has to fight to regain control. Without manually starting and exiting the script is there anyway I can verify this? rich

If the script's window is 'active' it will trap all keyboard input. Every 50 milliseconds it will do three things: Check the socket port for a connection. Release request Poser to process any pending Poser events. Make the script's window to the top possibly making it 'active'. You can stop if from trapping keyboard input if you 'minimize' it to the task bar. This is the way I typically run it and that seemed to fix the KB function delay you alerted me to. Here's another thing that I need to put into the usage notes. Don't start (initialize) the server daemon script while another python script is running. You can run other python scripts after the server daemon is running. Here is some questions/debug tests you might try. Do you experience the KB problem while running other python scripts (without the server daemon running)? Do you experience the KB problem if the server daemon is running 'minimized' on the task bar? Is this problem more acute when you have the autoconform.py script running (while the server daemon is running)? btw. I have never experienced a problem deleting items. I almost always am running in Fast Tracking mode. I'll test the other modes.

After I initialize I always minimize to the task bar. I never told you, I run XP home . Yes, I always run other scripts after starting, have to make sure the multitask is checked. So far I haven't noticed any difference in the KB whether prpc is running alone or with another script. The only thing speed wise, sometimes it takes longer than I think it should to load an item from p3do's interface. Now, I may have PhilC's Wardrobe Wizard script running. I've been doing a lot of experimenting with it and your script saves a lot of aggravation in locating and bringing stuff in. I don't quiet know how to state this so I don't know if it can be done. Assume everything is started corectly, The Open With Poser Command is used to bring an item in. At this point is there any way to give control back to Poser and still be able to recognize another external input command from p3do when needed? As you saw from the picture I posted, I use a lot of different elements and am constantly changing diplay modes, copying and pasting, deleting, changing the editing tools. I do 99% of my layouts in the Full Tracking Mode. That may be an issue because it's sure slower but I need the placement accuracy. Yes, I can always go up to the Command Bar and find the thing to click on with the mouse. KB much faster, especially changing the camer back to Main.

I just tested tracking modes. No problems in any of them. I haven't experienced any KB/Hotkey problems if the server daemon is minimized. Even when it is not minimized I have no problems if it is not 'active'. Maybe there is a conflict with the addtional scripts you are running. The autoconform.py works fine for me, unless it's window is active and thus taking all KB input. I don't have PhilC's Wardrobe Wizard so I can't test that. How many additional scripts are you running at a time? The more run the slower and more unpredictable things will be. I just don't understand why you are having such problems with the KB input and I don't have any. I'll try and see if Yarp can do a quick test for us on his system. I'm running XP Pro.

I only run two scripts at any given time,yours and maybe autoconform but mostly now Wardrobe Wizard. BTW it's a commercial package. If you don't need it, don't but it on my account. I'm not well versed in networks so is it possible that there might be a setting on my machine I should look at? I'm running a satellite modem if that's any help. No AV or anything else that I know of that could interfere.

I don't think this would have anything to do with network settings. It's also strange that for a while you were not able to reproduce the problem, but now it has come back. Also, if you have the problem even when no other scripts are running it kinda eliminates other scripts. Try testing with a fresh poser session and only the server daemon running. See if you can reproduce the problem under that (simplified) condition. It's possible that when you run another script, something gets confused. Even when that script is closed, the problem could persist. This can occur even if another script is run without the server daemon running. Often this can be solved by re-initialize python (but never do this while the server daemon, or any other script is running).

I just tested with Wardrobe Wizard beta1-09 (WW). I encountered some oddities. However, none of them affected the KB hotkeys. Oddities I saw were: The server daemon stall's after using 'Convert to Figure' and won't load additional items reliably. I also got a message from WW telling me that it was waiting for a current process to complete. I haven't done alot of testing with it, but initially it seems that you want to load WW's main menu BEFORE the server daemon. When I did this, the above oddities didn't occur.

Started PP in Fast Track Mode Initialized prpc opened p3do Brought in a shrub prop via the Open with Poser command. Used the KB Ctrl+shift 7 to change the shrub to cartoon mode due to the transparency, easier to see where it is. Now this time it worked. Brought in another shrub and used the KB with no problem. Decided to get rid of shrub 1, deleted with no problem. Maybe my mistake here.... I wanted to duplicate the relative position of the shrub so I hit ctrl+c then went back to p3do and brought in another shrub. Hit ctrl+v, the shrub didn't move where it should have. Tried to change to the cartoon mode, no go. It took three attempts before it finally changed It would allow me to delete a shrub. Another copy test. This time I brought in a shrub then selected the first and hit ctrl+c. Then selected the second shrub an hit ctrl+v which should have placed the shrub in the same location as shrub 1. NO. This time it took two try to change to cartoon mode. Doesn't like the KB copy function. Brought in three more shrubs. Now the KB response does take at least two attempts to change modes. For some reason the Edit tools are still responsive. Shut down prpc, PP, p3do Started PP and changed to Full Tracking Mode initialized prpc Opened p3do Brought in a shrub and repeated the above procedure and it worked Repeated everything I has just done for the FT mode with the same results. Brought a morphed Laura from the Figures Library and changed to Texture Shaded Mode. Moved a shrub so I could see it and when I tried to change it to cartoon IT Failed. All KB functions are now failing. I tried going back to Smooth Shading Mode, didn't help. Changed back to FT mode selected a shrub, hit Enter then I could change to cartoon. I have to hit Enter if I want to delete anything. The only pattern I can see is the more textures that are loaded the worse the response is. I'll do that with WW.

Perhaps when your scene gets to heavy in memory utilization, the server daemon gets swapped out and in to the virtual memory file, thus creating a severe lag in response time. You might be able to tell if this is the case if you have a led for hard disk activity.

I think my HD LED gave out. I maybe happening too fast for me to hear any activity. Sounds like you're narrowing it down, timing. Wish I knew more about Python then maybe I could offer a more intelligent response.

OK. I'll get on this shortly and let you know what happens.

Yes!!! I think this one does the trick. I repeated everything I did before and this time all of the KB shortcuts, including the copy/paste funtion was flawless. It is a tad slower importing but if it keeps the KB good I can live with that. Now the only thing that was a lot slower was my figure loading. I've been using Laura with Netherworks morphs applied. I'm afraid to try my modified V3...117mb. Takes close to a minute and to load her normally. Now, I started WW, after checking the MultiTasking option and had no problem importing Nerd Amazon Palace prop. All functions are still working. for the first time I could delete a shrub with no difficulty. OK. I tried. Took, as far as I could tell, two minutes. The shortcuts were a little sluggish but seemed to settle down. Very good job, tromnek!! Where do I send the cheque?

With prpcx10 I wasn't having much problem running both scripts. I even had to run Mason's hidechildren script, no adverse effects noted.

Back in a bit with the esults of the new script.

Not too good. The other versions initilized right now, this one the hourglass kept going , and going... When I was finally able to import a shrub, yes I've been using the same props for all of these test so nothing changes, I tried to bring in the second and wait, and wait, and right now I'd say it's locked up. When I shut down the script, poser finally woke up.

O well. Guess you'll have to put up with the sluggishness of prpcdx10.py. Here what I think is happening. When we write python scripts for poser we typically run an event loop that keeps our scripts user interface (UI) up to date. In this event loop we schedule a periodic function to run (prpcd runs it every 50 milliseconds). In that function prpcd does three things. 1) Check for a tcp/ip socket connection. 2) Tell Poser to process some of it's pending events. 3) Lift the UI window to the top of the window stack. Number 2 is the one I think is the problem. The original version of prpcd.py told Poser to process the default number of events (which is 1 event). The prpcdx10.py told Poser to process 10 events. If you want to play around with the number of events processed, search prpcdx10.py for a line that says;

if self.scene: self.scene.ProcessSomeEvents(10)

it should be around line 472. Try play with the number, like see if 5 events works better. Hope this helps. Thank you for the debugging, your comments and detail have been very good.

Thanks for the timing suggestion. Outside of being a might sluggish, on my machine, prpcx10 appears to be the most stable. Glad I wasn't too long winded for you.