I could use some assistance beta testing my developement releases of the server daemon (PRPCd.py) and client modules.
I don't have Poser ProPack so I need help testing for that version in particular.
I also need more user input for the prpc project. Currently my only real feedback is from Dizzi and Yarp (P3dO).
For the most part I'm making this up as I go along and some up-front end user input would probably make it a better tool.
I started a project for prpc up on SourceForge;
http://sourceforge.net/projects/prpc
(my apologies for the banner ads they impose on projects)
All file releases (including test/beta) will be distributed thru SourceForge also.
http://sourceforge.net/project/showfiles.php?group_id=154670
The test and beta versions are generally very stable, I use them in production all the time.
I'll put a warning in the notes if I think they might be unstable.
The notes will also tell you the new areas of developement so you know what to look out for (and test).
Also, if anyone has experience in poser-python programming, it would be nice to get some more client modules developed.
Happy to do some beta testing for you, but I only use Poser 6. I'm surprised you haven't had more feedback!
Here's one issue for openers: The first time I run the PRPC Daemon in a session, the very first item I send to it from Advanced Library is ignored. I have to double-click it again to get it to load. After that, all is well. I've been meaning to report that before but couldn't work out if it was AL or PRPC doing it. (My config: Poser 6 SR2, WinXP Home SP2, Athlon XP 3400+, 1.25GB RAM)
Also, is there any way to auto-load the client plugins? Kind of like an "Autoexec.bat" for the PRPC daemon?
Oh, and can you add buttons to the Poser interface in Python, not the Python Scrtipt palette, but the UI itself? Then you could add a button next to the manipulation tools that launches the daemon, instead of having to call up the scripts window or use File->Run Python Script. (I currently use an external keyboard macro to pick Poser and send the keystrokes to "File Run" the daemon. I don't like leaving the daemon running all the time because it prevents user dialogues requiring confirmations from appearing, and that can actually get you into a lot of trouble!)
Quote
Happy to do some beta testing for you, but I only use Poser 6. I'm surprised you haven't had more feedback!
Thanks, I'll post more when I figure out how to take feedback.
I think I'll want people to report beta issues in the SourceForge forum for this project.
Quote
Here's one issue for openers: The first time I run the PRPC Daemon in a session, the very first item I send to it from Advanced Library is ignored. I have to double-click it again to get it to load. After that, all is well. I've been meaning to report that before but couldn't work out if it was AL or PRPC doing it. (My config: Poser 6 SR2, WinXP Home SP2, Athlon XP 3400+, 1.25GB RAM)
Have you tried testing this with the right-click 'Send To' method from windows explorer?
Have you used P3dO and does it happen there?
QuoteAlso, is there any way to auto-load the client plugins? Kind of like an "Autoexec.bat" for the PRPC daemon?
I'll have a beta up soon (I think tonight) with this feature and many additional options around this feature.
I plan to look in the 'runtime\python\poserScripts\pcpc' folder. So make that folder and put your client modules in there.
If a client module's name starts with 'auto', it will automatically load.
The beta will also support you specifing a default folder to look in at startup.
I'll put more instructions in the 'Notes' for the beta.
QuoteOh, and can you add buttons to the Poser interface in Python, not the Python Scrtipt palette, but the UI itself? Then (snip....
I don't think this is possible.
Anyone else have any thoughts?
QuoteI don't like leaving the daemon running all the time because it prevents user dialogues requiring confirmations from appearing, and that can actually get you into a lot of trouble!)
This is a known issue (it's mentioned on the prpc web page).
I've been waiting for e-frontier to respond to question on this. I've emailed them twice but never heard back.
I really really want to solve this.
I just posted the latest beta version of the server daemon at SourceForge.
http://sourceforge.net/project/showfiles.php?group_id=154670&package_id=172056
It has 'autoloading' of client modules completed and ready for testing and feedback.
Quote from: TromNek on December 15, 2005, 03:01:38 AM
I just posted the latest beta version of the server daemon at SourceForge.
http://sourceforge.net/project/showfiles.php?group_id=154670&package_id=172056
It has 'autoloading' of client modules completed and ready for testing and feedback.
Do you think you could put future releases up in ZIP files instead of the raw Python Script?
I use the Opera browser and it really *hates* non-standard file extensions that it doesn't know how to deal with :( In fact, it refuses to load that from Sourceforge; just gives me a blank page.
EDIT: To anyone downloading this with Internet Explorer, remember to use the file type "Text File" when you save it, otherwise you end up with an HTML document that will cause syntax errors if you try and run it.
Testing the Autoload now. One thought comes to mind straight away:
Instead of using the prefix "Auto" on the script filename, why not autoload all scripts that are present in an "Autoload" sub-folder below the prpc folder? Scripts for manual loading could be in a subfolder "Plugins". If there is anything in this folder, then prpcd would present a list and allow the user to select which, if any, they wanted to load.
So it would look like:
Runtime -> Python -> PoserScripts -> prpc (The daemon goes here, and any files specifically to support it)
-> Autoload (Anything in here always gets loaded at startup)
-> Plugins (Anything in here is shown in a list from which the user can select which ones to run)
As a bonus, this would not require the user to edit the prpcd script to change the autoloading behaviour. Maybe a button could be added to the prpcd main window that allows the user to call up the list of manual load plugins to run them at a later time?
Is it ok with you if I cross post this to the beta/test discussion forum for this project at SourceForge?
http://sourceforge.net/forum/forum.php?forum_id=519742
I'd like to consolidate these kinds of discussions there in separate threadst
(although it's a pretty primitive message board)
Yes, I can zip the files. I'll start doing that from now on.
Regarding autoloading;
Your suggestion is a good one for discussion.
I'm still considering how much user intervention is needed for autoload. Here are my thoughts at present.
I was actually very very hesitant to do any autoloading.
When the server daemon loads a client module, it doesn't really know if it's a client module or not. It just runs it as a normal python script.
If a script is autoloaded that contains a command like 'delete *', it could have a nasty side effect.
Thus,
The default (mode=1) will always pull up a list to pick.
Mode=2 (silent automatic autoload), requires that the file name start with 'auto' and contain 'prpc' somewhere.
Another reason for the 'auto' prefix is that the order of loading can be important, because client modules can process a file then release it for subsequent client modules get a chance.
For instance, prpcThumb2File.py changes the incoming file name so it should be loaded before others.
My autoload files might be named something like;
auto01prpcThumb2File.py
auto10prpcPoseFilter.py
auto11prpcConformTo.py (actually a post load module so it could also start with 'auto01')
prpcLoadMatSet.py
Thus the 'auto' prefix helps with two things, an extra sanity check for safety, and ording the load (and the list display).
Maybe, the user creating an 'autoload' directory is enough to make me comfortable. I'll think about it.
Like I said, I'm still thinking this thru and it's good to be able to discuss various options.
Quote from: TromNek on December 15, 2005, 02:36:52 PM
Is it ok with you if I cross post this to the beta/test discussion forum for this project at SourceForge?
http://sourceforge.net/forum/forum.php?forum_id=519742
I'd like to consolidate these kinds of discussions there in separate threadst
(although it's a pretty primitive message board)
Fine by me.
I put up a new beta (in a zip archive) at SourceForge.
http://sourceforge.net/project/showfiles.php?group_id=154670&package_id=172056
I combined acanthis's suggestion with my previous modes so that,
if autoload finds a sub-directory named 'autoload' in the prpcdir, then it will
silently load all python scripts found there (except server daemons).
Otherwise it will operate as it did in beta30.
Look at the bottom of the script for options on autoloading.
I did a major rework of the client module presentation.
They are now organized into separate frames according to type;
pre Load, post Load, pre Save, post Save.
You will only see one of those frames if a module of that type is loaded.
All of those frames display a count of modules loaded and enabled.
All the frames (including client module frames) can be collapsed and expanded
with a '-+' button.
When a client module is loaded it's frame is initially collapsed so as to save space.
Thanks for using ZIP files. Much less hassle.
I like the new layout.
Just tested the autoload folder with DelLights and PoseFilter and everything seems to be OK. In fact, that's the first time I've used the PoseFilter and I like it! Will be giving this version a hammering over the weekend.
On to the question about the very first time I try to load something through RPC. It's the same problem with P3DO Explorer, Windows Explorer and Advanced Library. The very first time I run the PRPC Daemon, I have to effectively send the very first object twice to get it recognised. After that everything works fine.
I see things have moved on with al and with prpc as well.
Well I shall install the latest and give it a whirl over the weekend.
acanthis,
I went back and zipped the other stuff too. Thanks for the warning.
I've been wanting to change the layout for a while, and I still don't like all the room it takes up.
Add the ConformTo module and you'll see another frame for 'post Load' modules.
Server Daemon stall;
When this happens with AL, does AL give you an message saying the server isn't loaded?
When you say the first time you run the server daemon, do you mean that if you exit the server
then start it again (during the same Poser session), you don't have this problem?
I haven't been able to reproduce this problem on my system.
Quote from: TromNek on December 16, 2005, 07:44:25 PM
When you say the first time you run the server daemon, do you mean that if you exit the server
then start it again (during the same Poser session), you don't have this problem?
same for me.
First time after boot up (computer not Poser ,-)), 1st call won't reach PRPCd. But after that it's working fine (you can close and open PRPCd and Poser) as oftern as you want.
Quote
same for me.
First time after boot up (computer not Poser ,-)), 1st call won't reach PRPCd. But after that it's working fine (you can close and open PRPCd and Poser) as oftern as you want.
Quote
I just tried it from a cold boot. No problems.
Are you getting a message from AL that the server daemon isn't loaded?
Attached is a version of PRPCd.py that will flash a 5 second message window every time
it gets an incomming connection. Run it from a cold boot and see if it's getting a connection
on the first shot.
I wonder if this is either a socket initialization delay on your system or a firewall issue.
The loopback interface (ip: 127.0.0.1) is a virtual device. Possibly windows is introducing a delay the
first time it's used and the connection times out before PRPCd picks it up. Maybe my system uses the loopback
for some purpose during boot up and thus it's already initialized.
However, I would think that AL would time out on the connection and give you that message saying it
couldn't contact prpcd.py.
Dizzy,
In the next level (1.35 series) of PRPC I hope to include at least a 'ping' command so an external app can get
some information on the if the server daemon is running and what version it is. Then you could send a couple
pings when AL first starts up.
Right now you could send a string that isn't a file or directory name. Starting with version 1.34, it would be silently ignored.
Earlier versions would put up a 4 second warning window.
However, I'd rather figure out why this is happening instead of kludging the problem.
Here's another test.
From a cold boot. Before you load Poser.
Start AL and try sending something (to the 'non running' server daemon).
Then exit AL, startup Poser, startup PRPCd.
Now startup AL and try sending something.
If it works the first time, then we might suspect a loopback interface initializatiion problem
stemming from Windows or firewall running on the local machine.
If this is the case, I could probably have the server daemon send a dummy message
to itself over the loopback when it first loads.
Here's a version of the server daemon that sends a dummy message to itself on startup.
Quote from: TromNek on December 17, 2005, 04:45:33 AM
Here's a version of the server daemon that sends a dummy message to itself on startup.
Hmmmn. Now that's interesting. This version doesn't fix the problem, but the version that you posted before, the one that pops up the highly useful connection message, does!!! btw Confirmed the issue is with the first connection after boot up, not the first connection after Poser start.
I actually like that message. How hard would it be to integrate that into a status bar for the PRPC control panel? (I wouldn't want to have to keep dismissing a popup dialogue) I like to know when things are happening, and as we all know, Poser is not the fastest kid on the block ;)
Here's another debug version. This one pops up the info window after data is completely recieved.
Tell me what it says.
re: status bar
I've been thinking about having various levels of debug/info messages.
A status bar thingy might be perfect. It could display the first 40 chars of a message like:
Info: Connection from IP:127.0.0.1 port 25234, data=c:\Program files\Curiou.....
And include a button that you can click to pull a window with the entire message.
Maybe I'll try and implement this in version 1.35.
Quote from: TromNek on December 17, 2005, 03:27:12 PM
Here's another debug version. This one pops up the info window after data is completely recieved.
Tell me what it says.
Booted, Started Poser & AL, sent to Poser without PRPC loaded. Loaded PRPC, sent from AL -> Message Size 0 on first try, correct size on 2nd try and it loaded the prop then.
Ok.
It gets the connection but not the data.
I'll need to think on this.
Gotta go now before the wife kills me.
Here's another try.
This one will make an extra attempt to read data from the connection if the first attempt returned nothing.
If this doesn't work, I can try to wait a half a second before the second attempt, but I'd rather not
introduce any delays.
Boot, Start Poser, run this script, start AL and send something.
Dizzy and acanthis,
Are you running a firewall on your local machine? If so, try disabling it and testing with the normal server daemon.
If that turns out to be the issue, I still need to find a workaround, but at least I'll know where the problem is comming
from. If so, send me a message (not a post) letting me know whose firewall you use.
Quote from: TromNek on December 18, 2005, 04:25:03 AM
Here's another try.
This one will make an extra attempt to read data from the connection if the first attempt returned nothing.
If this doesn't work, I can try to wait a half a second before the second attempt, but I'd rather not
introduce any delays.
Boot, Start Poser, run this script, start AL and send something.
No change. Is this perhaps an XP thing? Is it doing some kind of sparse resource allocation so that the loopback interface doesn't exist until the first time somebody tries to use it, and then there's a delay while the world's most powerful, performance-tuned operating system grinds into action? ;)
Couldn't you send yourself something on the LO to kick the thing off?
I tried that with debug02prpcd.... version.
I'll make another version with a delay. It seems like the 4 second window worked
so maybe we'll start with a one second delay.
Here's on that will introduce a 1 second delay then retry reading the data again.
It should pop up a quick window (the 1 second delay).
It should only introduce the delay if no data was received. Thus you should only
see this message the first time you send something to the server daemon.
Did work for me
Quote from: Dizzi on December 18, 2005, 06:35:50 PM
Did work for me
Confirmed. That works for me also. On the very first attempt, I briefly see the dialogue "Please Wait. Going to try again" then the object loads. And, as expected, susequent loads work fine.
OK.
Just but up another (hopefully last) beta with that fix at SourceForge.
I was shooting blind on this problem because I couldn't even simulate that problem fully.
Thanks for the help.
I'll be going on vacation next saturday, so I plan to make a public release after the new year.
Hopefully this will be the end of version 1.34 and I'll start work on 1.34.
Plans for 1.35.
Add logging ability to the server daemon in conjuction with a 'status bar' that displays
the last message (info, warning, error, exception) along with a button that will pull up
a list of the last 100 messages. This way I can get better diagnostics from people who
are having problems or helping me debug stuff.
Clean up the entire code base and isolate Poser specific stuff into a separate class.
This will allow me to use alot of the same code for a similar project for Vue Infinite.
I also want to do this with Shade 8 if e-frontier included tk/tcl in that version.
Begin two way communications with external applications. At least provide a 'ping' that will
return the server daemon version. Possible add some elementary query abilities.
Begin working on network animation rendering. I don't do animations so I'll need some people
who are interested in this to help me.
thanks again
Thanks. Downloaded and installed (confirmed: it still fixes the first time load problem)
I'll be using this version from now on and will report any problems I find, but so far everything seems to be working.
Just uploaded the general public release of the project, prpc version 1.34.33 at SourceForge.
I need a Pro Pack tester!
Can't say I am a beta tester, but I do use Pro Pack :)
Here is what I get when I run the py script..it runs..scrolls down a bunch of commands..but at the end it displays:
RuntimeError: Maximum recursion depth exceeded.. sooo I dunno.. and when I click a link in AL it asks if the script is running..I assume it looks for it..coz it IDs the script..????
I got a report two days ago that it wasn't working on Pro Pack.
Your description sounds like a tk/tcl incompatibility.
Could you please try the attached version to see if it works?
Could you also test the 'Run python script' and try changing to a different directory.
I fear that Pro Pack may also choke on that operation.
thanks
I replaced the one I had installed with the one you sent..and it works..and I didn't have to change anything else.. so looks like it will work with Pro Pack..nice job :)
Sorry guess I was vague..to review..I double clicked my V3 under Daz People in AL,,and she loaded just fine..no arguments..then I doubled clicked the Daz Environment ( a different directory) and it loaded also..and also the little option box thingy (RPC Call Daemon) came up too :)
Good.
Are you running the latest Pro Pack update/patch?
If so what is the version number?
I don't have Pro Pack and supporting it is a little difficult because there are some differences in quite a few areas.
I would like to get the latest patch for Pro Pack, but I don't have a Pro Pack license code to download it.
thanks for the report,
ken
Well my Poser version is 4.2.1.179, the Pro Pack Memory Update asi, and I am using Pro Pack Service release 3.. not sure if that is the latest because I got it quite some time back....if there is a newer one, I doubt I'll get it..what works don't need fixing :) Also I assume e-frontier won't be making any more updates, etc for pro pack because they now promote their "artist" version
I just released version 1.34.35 up at sourceforge.
http://sourceforge.net/project/showfiles.php?group_id=154670
This should fix the two Pro Pack incompatibilities that were created in version 1.34.33.