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

Can anyone describe how Poser 6 goes about finding geometries when external runtimes are in use?

When Poser sees a geometry call of the form figureResFile :Runtime:Geometries:dir:mesh.obj it must know to rearrange the path to suit an external runtime. I had assumed that if you were "logged in" to an external runtime, Poser would use that runtime's Geometries folder as the source for your mesh. However it doesn't necessarily seem to be the case.

I'm asking because I'm setting up my new Poser 6 installation to use TromNek's Poser Remote Procedure Call (see link for details). This enables you to pass a Poser library file directly to the scene via Python, so you don't need to use the library palette at all. My plan is to arrange the library folders in my own way, and completely discard the normal Poser folder hierarchy (with the exception of injection files, probably).

This leaves the question of how Poser is "told" where the geometries are, if it receives a geometry call via PRPC and not via the library. As I say, I switched the library to the runtime which contains the geometries I want to use, but I still get the message asking me to locate the OBJ file.

Good question... I think it search in all geometries folder, beginning with the main runtime (the one in the Poser6 folder). Then it should look in the external runtime, in the same order than in LibraryPrefs.xml The first matching geometry found is the one used...

Thanks semidieu. I don't think it can be searching (not completely, anyway) because the geometry is definitely there in a runtime that Poser knows about; and if I navigate there manually when asked, all is fine. I plan to do some more experimenting tonight.

I've tried various combinations of things, with consistent results. Whenever an item called via PRPC includes a call to a geometry in an external runtime, Poser asks for the OBJ to be located. It doesn't seem to matter which runtime you're in according to the library palette. Thereafter, that same item can be re-loaded without an OBJ request. Poser "remembers" the geometry folder. If I then call something which has its geometry in a different folder in the same external runtime, Poser again asks where it is, and that's remembered, along with the original item. I haven't experimented to see if this geometry folder memory is infinite, or whether it has limits. Calling things which are in the main Poser runtime always seems to be fine. I've IMed TromNek to see if he has any ideas. I should have done that straight away, I suppose, but I was interested to see if anyone else had the same trouble.

Here's the structure of my new runtime. As you see, although it has the Geometries and textures in the usual places, I haven't put the library folders in the traditional structure. I assumed that it wouldn't matter if I wasn't going to use the library palette at all; everything was going to be done from P3dO Explorer via PRPC.

Actually, I think I just answered my own question. If I try to PRPC something from the Poser 5 Runtime, which is still conventionally structured, it appears to work without queries.

That doesn't make sense to me. Here's a new question, then: why should this be? Why should Poser care where the library files are kept? I assume it's Poser that's getting confused, and not PRPC.

-EB the Confused Edit: the Runtime2libraries folder you can see above has the usual Poser subfolders in it, but they're all empty. I thought it might be happier that way. :)

Message edited on: 09/07/2005 16:04

I think it expects "Runtime" to be the top level directory in any folder you connect as a Runtime.

When you connect a Runtime, Poser does creates empty folders for any in the standard structure that aren't present.

I think you'll get away with putting all files other than geometries and textures outside the standard hierarchy.
Geometries will need to be under RuntimeGeometries
Similarly textures under Runtimetextures With attached as a Runtime. It may even be that just files that Poser searches that have to be in known Runtimes.

I've found the safest and easiest way is to let CRPro set all directory to full path. I then break the common runtime:libraries: structure to ie D:PoserTexturesDaz D:VictoriaBodies etc. It works fine with PRPC and either P3D or Advanced Library Beta from Dizzi

Thanks people, I think we're getting close to it now. nruddock, I also suspect it's something to do with the folder structure. I tried putting my folders under Runtime2:libraries as opposed to directly under Runtime2, but that didn't do it. I wondered if absolute paths would fix it, but didn't want to buy CRPro without being sure. Thanks for the confirmation, Indoda. I guess I could manually alter one or two CR2s to have absolute paths - that would prove it one way or the other for my installation.

Attached Link: http://www.neocron.lunarpages.com/library/installer/

@EnglishBob

I use CRPro and it certainly is a useful program if you want to re-arrange your runtimes and take advantage of PRPC. I now put characters with their poses, mats, etc in the same directory. Keeping Vicky, Sara, Maya Doll, etc all separate makes finding their clothes, mats, poses so much quicker. For some reason the Poser runtime never did make sense to me ;) I haven't used the library palette since Tromnek wrote his script. Dizzi has added the ability to use materials to the script, see link above.
Indoda (displaced Englishman) 8-]]

Could you try what happens if the structure starts with Runtime2Runtime instead of Runtime2? Oh, and it doesn't matter where your Library files are placed. I've placed all my content below Runtime_original{Storename}{Daz/Zipname} and then added shortcuts to Posers Library. That easens updating existing stuff, i can have the same stuff linked from different folders and it still works with poser's library (although i don't use it anymore, too).

Message edited on: 09/08/2005 12:29

Dizzi, you cracked it. I put in an extra Runtime folder between Runtime2 and Geometries, and that's fine now. The libraries folder you can see there is the empty one that Poser put in; my actual libraries are in My Documents (where they stand a better chance of being backed up...) Thank you! :-)

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.

Thanks tromnek. As I've said in other places, and ought to repeat here, this problem was my fault. If I'd thought for a minute, the structure of a standard figureResFile line -

figureResFile :Runtime:Geometries:dir:mesh.obj

• makes it obvious that a Runtime directory is required. In my defence I would say that I was seduced by the freedom PRPC offers and went too far in the rearrangement of my Runtime. :)

"Over the next few weeks I plan to update my project [to]support saving."

Excellent news. Then I really can ditch the library palette for ever. :)

Message edited on: 09/12/2005 03:22

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

I posted a new beta of prpcd.py to the poser python forum (see attached link). There are a few more things for me to do to clean it up and add some more functionality. I'll detail them in the new thread. btw. I need some help with saving material collections.