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

Sorry for the late reply. I have only encountered this problem a few times, but all my content resides under one of three 'runtime' folders so it's pretty standard. btw. When organizing your content remember that both my 'send2sock.exe' and P3dO will de-reference windows shortcuts (.lnk files). The problem with shortcuts is that you won't see the thumbnails. Maybe SenoSoft (P3dO) can make a change to associate those also. It looks like Dizzi's 'Advanced Library' handles this stuff nicely (based on his web page). Also, I'm now really frustrated using Poser's interface for saving library content. Over the next few weeks I plan to update my project support saving. I believe that P3dO will probably support it shortly after it's release. I'll include Dizzi's materials code in that release also.

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.

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 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.

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 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.

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.

Yes, server problems (kinda). My internet provider shut me down while I was away for the weekend (credit card had expired!). Sorry. It should be back up now.

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

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

wow! i like that alot.

Schlabber's huge volumes of pose sets is what actually got me started on this project.