prpc beta tested needed

[TromNek]

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.

[acanthis]

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!)

[TromNek]

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.

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?

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

Oh, 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?

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!)

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.

[TromNek]

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.

[acanthis]

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.

[acanthis]

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?

[TromNek]

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.

[acanthis]

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.

[TromNek]

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.

[acanthis]

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.

[doppelganger]

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.

[TromNek]

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.

[Dizzi]

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.

[TromNek]

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.

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.

[TromNek]

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.