I started thinking how wonderful it was going to be to set up my gigs of content into multiple Runtimes, but then my mind hit on a snag... Geometries. Now, I know that I can have P5 access my entire current Runtime exactly how it is right now, but I wouldn't want to do that. I hate the way content is organized in P4, so I certainly wouldn't want to just leave it as is. So that aside, I started thinking of creating Runtimes for categories, such as Fantasy, Modern, Sci Fi, Historical, etc. But I've already got this stuff installed and although I'm meticulous about where I put my textures and library files, I normally leave the geometries just where the creator specified. Currently my Geometries folder contains roughly 5,500 files in 900-ish folders with peculiar names. :) If I'm going to separate out my content into multiple Runtimes, wouldn't that mean I need to sort out those Geometries so that each Runtime contains only its relevant objs? I can't imagine a way to sort them out without taking ages. And if I have victoria-based chacters in each of my Runtimes, I'd then have to create duplicates of the obj, which would rule out using something like P-un or a script to collect the associates OBJs and simply move them. P-p-p-please... tell me when you say "multiple runtimes," you really mean multiple libraries, allowing me to keep just one big fat bloated Geometries folder for use with every themed runtime. Thanks for your insight, Phoenix

Gawd, I hope so, phoenixamon

Yeah... Exactly. :) "Geometries" resides within "Runtimes" so I really really really hope that "multiple runtimes" is a misnomer. Gak! ;)

I rather doubt it. But I'm sure that some coder will create a utility to move CR2 and their corresponding objects/textures/mat-files... between different Runtimes. Heck I could do it myself, if I wasn't so lazy. ;P

MadYuri... But what about the example of different "runtimes" each containing victoria-based characters? A script couldn't know that the CR2 in question uses an OBJ that is also used by other CR2s that are going to be moved to different Runtimes. It could prompt me about whether to move or copy every OBJ, but that would take ages, and again I'd often not be sure. Or it could just copy, taking up huge amounts of disk space and nothing could be deleted from Geometries until the entire sorting process was done. (I thought of writing a script myself, but flaws occurred to me.) Also (at least in Poser Pro Pack) Runtime contains memory dots, Reflection Maps which are called by many library files, and Python scripts. I wouldn't want to change to a new Runtime just so that I could use different content, and in so doing lose the use of my Python scripts. That'd be silly. (I'm just giving myself a headache.) Phoenix

This is why P-booost is so handy and why many people may choose to use it, even with the new multiple runtime capabilitys in P5. becouse the geomitry folder is in the runtime folder the only solution without copying multiple obj's would be to edit all your CR2s to point to a central runtimegeomitries folder. the other option and the one I will probably use is to seperate the runtimes by figure, ie; MIKERuntime, VICKIRuntime, P4Runtime...

I thought about that... organizing my runtimes by character... but then what of props? Hair that is used by every figure? Where do I put Vicky2P4 who uses Vicky MATs and MORs but P4 clothes? So I decided I don't like that option. I love P-Boost (won't spell it with 3 Os anyhow ;) for what it was created for... a workaround kludge to better organize P4. But it's still a kludge, and I'm really hoping P5's internally improved structure will allow me to stop using it. It's a good workaround, but not a good ultimate solution. grin All this has got me flustered. I really just want to organize my files the way I like them organized. Every other app lets me do that... hell, even Microsoft products (knock on wood). ;) I don't want hair objects under Figures and Hair and Props. Grumble mumble...

Obviously, I haven't touched my geoms yet. =)

I'm not sure in this, but I thought P5 was going to allow multiple subdirectories in the libraries? If that's the case wouldn't multiple Runtimes be unnecessary?

If that's not the case the only solution I can see to the multiple Runtime/Geometries problem is to move Geometries below runtime.

Of course this would not be a viable option for people who already have a large Runtime structure set up, unless there was a pretty good utility to change all the object references in the existing library.

Lets hope CL have thought this one through, and provided a solution.

Phoenixamon Ultimately the P5 solution is just a "kludge" as you say it, as well, unfortunately the situation is the same as web design, just like CR2's,and other Poser file formats there are many times that you have to edit hyperlinks and image locations with multi level websites, If you think of cr2 as web pages you can see the problem, move a file and you may change the relative location of it's Obj.

Les: I hope so too. As a last resort, it would be possible to take the entire Geometries folder and move it to a location outside of Poser's folder, and then use a multiple file search-n-replace tool to edit every single library file to point to the new location, structure preserved... icky, but doable. But then this would mean every time I download or buy anything I'd have to manually edit the Geometries path. :( Feh! Kiera: I wish my Geometries properties looked like that. ;) Yer better off than me. BTW, I just thought I'd take this opportunity to tell you I adore your products. Phoenix

Thank you Phoenix. ;) You ain't seen nothin yet! I am working on two projects (one freebie and one MP product) that I think you will really like. =)

Les, while multiple layer subdirectorys are concevably possable you run into the same problem as I stated above the cr2 would have to be edited to point to a new relative obj location. that's the problem with all interdependent file types when they arn't stored in the same folder.

wdupre, You're right... the P5 solution is still a kludge. A better solution would be to give us a preferences dialog that actually allowed us to HAVE preferences. Then I could define where geoms would be stored. Say [Geometries] were a variable the user could control. In the CR2 the path would read [Geometries]Subdirwhateverpath. On my path [Geometries] could point to D:Graphics3DPoserGeoms and on yours it could point to C:PoserRuntimeGeometries. That's how it ought to be. Let the user decide. ;) That said, I prefer using whatever features are buit in to P5 over using an external program to coordinate things. I bought P-Boost the day it came out, I wanted it that bad. But I'd rather not need it. Multiple layer sub-dirs in Libraries would not call for OBJ references to be changed, because the OBJ references are relative to the root, not relative to the location of the CR2. I'll use the sub-dirs, but even so, here's only so far I want to drill down through them, and separate libraries would ease things considerably. Kiera: Goody! :D Phoenix

I may be wrong but if the root were defined as a named file (such as 'poser4') then subdirectories would work in P4 and they don't, more likely the root is defined as relative to the current file (such as root=4 levels down) as I said it seems to work the same as html. perhaps that will be different in P5

The reason it doesn't work to have nested sub-dirs in Poser4 is that P4 is hard-coded that way. It's not that a CR2 in a nested folder can not find the path to the OBJ... Poser actually can't even SEE any content you might try to put in a nested dir. It's hard-coded to only look one level down in libraries. :( Bad. I'm assuming (ha! you know what that'll earn me) that when you set up an external Runtime in P5 you define the root, so this would not be a problem. OBJ references work just like an html link, as you said. If your CR2 points to Runtime:whatever.obj, the program should look forward in the directory tree relative to the CR2. If it points to ..:Runtime:whatever.obj that should look backwards in the directory tree relative to the CR2. But if you start with : that says go back to the root and look forward from there, losing all dependence on the location of the CR2. Similarly, if you have a web page www.me.com/contacts/index.html you can call up that page from any other page on your site no matter where it is located by using the URL /contacts/index.html. And I have no idea why I just typed this. :) I think I may be a tad obsessed. CL, it's daylight in California now. Come answer the question please. ;) Phoenix

I might be oversimplying the problem, but I think it would easy accomdate both the Poser 4 and 5 schemes. I think it would be a good idea is Poser 5 had a simple edit field where you place "fully qualified" (or relative) paths to one or more directories containing the files Poser would otherwise have to ask you to locate. I know that this "Search Path List" would no doubt get very long, but once you set it...you can forget it! Until, of course, you need to edit it again. This way you could create any number of directories, subdirs, etc and just tell poser where they are. It would then go through all the directory (and possibly the subdirectories) looking for the files it needs. If it still couldn't find something, you could help it out in one of two ways. 1. Point it to the right location. 2. Add the new location to the search path. Just a thought and my 2 cents worth.