I've been throwing stuff into the same runtime for over 12 years now, and I think it's time I started over.  Doing contract work showed me the benefits of separating runtimes on a project basis, but what to do with my 16.1GB runtime of figures, props a downloaded content?

So here's my main question:  Let's assume I point Poser at a runtime and load a figure.  Then I redirect Poser to another runtime (and it contains a folder with all of the same textures).  If I save the loaded figure to that runtime, will that runtime then contain everything needed to load that figure?  I know there are tools to gather associated files for redistribution, but I'm looking for an easy way to move multiple figures and props to a new runtime, as that seems simpler than trying to clean my current runtime of cruft.

If not, then what are the main folders I need to duplicate (geometries, textures etc.)?

Am I on the wrong track here?

From my experience, no it won't. I'm not certain, but I think what happens is if you load a figure from your generic runtime (say a clothing item for V4) and save it to a new V4 runtime, the save records where the data came from. If you then deleted the old generic runtime and tried to open that item from the new runtime, poser wouldn't be able to find it because the file has been deleted. In fact, when I have done something like that with multiple runtimes, it won't search other runtimes for mat files, it asks where it is.

I used to have something like yours (just called external runtime) but it got too big, so I started building separate runtimes for character groups and themes (locations, Gen 3, V4 has her own, so M4 does too... and one called 'stuff' for all the odds and ends). This means reinstalling everything. Over 4000 files (820 to go!). I still have the generic runtime until the new set up is finished.

I have transfered files and it does work, but it really depends on the vendor as to file structure. In most cases there is a geometry file, something in character, sometimes a pose file and a texture file. Some merchants put the .obj file (the geometry) into the character file and so have no geometry folder ( a pain if you don't know that)... similar with props. SOmetimes it's just a suck it and see approach. Best way I have found with things in the character folder is to use a text editor like wordpad and see where the .cr2 is lloking for its geometry and textures. Follow the breadcrumbs!

I have used the same external runtime since Poser 6, broken down into seperate Runtime folders.  V4 is the character I use the most so that there are seperate runtimes for V4, poses and expressions, seperate runtime for M4, then runtimes based on subject matter such as Space, Transport, Places and Plants ect.  In the standalone library sustem I use to track purchases I have category fields that match the runtimes names so that I can locate a product quickly.  I tend to convert and move any MAT poses from poses into materials just to keep everything straight.  With a new version of Poser I just install and point it at the main runtime.

So far I have 130Gb of data stored there, although that is small compared with other users, and I seem to find my way round quite well.  It is also easy to back up the complete runtime making data loss and recovery, hopefully, a simple process.

I did the same thing at first. Had a huge runtime. And I had the problem that due to a crash I lost many of my install files and could no longer get them. So what I did is just left the geometry and texture folders alone and moved the files in the library only. Most of the time this works. There are a few problems when an old file has a path setup using / instead of : . And Wardrobe wizard doesn't like it. When I need to convert something I have to copy it to the main runtime where most of my geometries are.

IMHO, it is time to reaccess the priority of the content files and start cleaning house of everything that hasn't been used in the past 6 months to a year.  I have never been a huge fan of bloating runtimes with every content files I acquire.  If it is used on a regular basis, then it stays.  Special project, the content is installed in an exclusive runtime and that runtime is archived for future consideration.  Content seldom used is uninstalled completely.  This is where a thoroughly, well kept database and archive system becomes critical for managing content.

Now, if you are seriously considering relocating files to other runtimes, keeping all associated textures and geometry folder/files together is a good start.  MATPose files should also be integrated along with them, as well as character/prop files.  However, if you have established pz2's depending on those files in their previous locatings, Poser will request that you relocate them when pz2's are reloaded.  Easier when everything is together, Poser just needs the one time manual redirection.  Downside is you will need to resave the scene. Also, another issue, if you separate folders into categories, you may need to edit cr2's, pp2's, etc relative paths to target relocated associated files.

The character, prop, pose, hand, face, light, camera, hair, material files are all just text files.There is nothing magical about then.

In those text files can be references to load geometeries and textures 9,999 out of 10,000 times that are located in your geometries and texture folder. Some freebees will place the obj file in the same folder as the prop or figure it self. Some pmd files can be also found in the same folder as the item. Some props will come with the geometry embedded in the pp2 file and not reference or point to an obj file located in the geometries folder.

Granted I 100 percent manually install all content. But 100 percent of all my geometry and texture files are located in 1 geometry and 1 texture folder located in latest version of poser I am running. I have no geometries for textures located under all the various runtimes for the various characters and say buildings or cars I have seperate runtimes for. Even all the moprhs files are located in a folder called mophs in my main runtime. Pmd files I place in the same path as the geometry folder. The later two do require editing the various cr2 or pz2 files from time to time becuase I changed the location of the morphs or the pmd files.

The advantages of what I do even if it takes a little longer to install content, is it eliminates multiple texture, geometry morph and pmd files and saves disk space and with everything in the same place I can find it easily if I want to modify a texture myself or load an obj file into say C4D to create my own morph. But the main benefit of my scheme is it allows me complete freedom to move, reorganize anything in my runtimes anytime I want so I can again find things easily.

Another thing I do is I drop all add on products for a main product in the same folder. So if I have a dress I purchased and a seperate texture add on. If you go to my pose file for the dress you will see the material or Mat poses that came with the dress and folder in the name of the add on product as a sub folder to the dress. Again easy to find everything that relates to that dress.

Everything loads as expected, with no issues of any kind for straight Poser use.

The are some add on programs that do look for the geometry file to be in the same runtime as the cr2. In those cases I just duplicate the Cr2 and move to the main runtime and run say WW2 and then move or delete what I don't need anymore (the duplicate file) and place the modified content into the appropriate runtime, again for easy location by me.

I run PP2014 Mac, and my PP2010 library at the top of the library prefs file you will see I have linked my PP2014 runtime so if for some reason I want to run PP2010 it can find the geometry files and textures files not located in it's main runtime but now all located in my PP2014 runtime.

When I start to build a scene I want to get the content into it quickly and spend my time on the composition (lighting, poses of the figure and the camera angle) not searching my runtimes looking for something I want to add to the scene. I have a boat load of small runtimes and or sub folders in my various runtimes that makes sense to me, so if I want to add more to the scene (fillers I call them) I can do it quickly and get back to the main task of fiddling with the composition.

Now that's the way my mind works and it works for me. Can take a little bit of time on the front end during content adding, but saves me a massive amount of time during scene creation. You and others will develop your own scheme based on what you are trying to do with Poser and the extent of your content and what you find works for you.

Quote - IMHO, it is time to reaccess the priority of the content files and start cleaning house of everything that hasn't been used in the past 6 months to a year.  I have never been a huge fan of bloating runtimes with every content files I acquire.  If it is used on a regular basis, then it stays.  Special project, the content is installed in an exclusive runtime and that runtime is archived for future consideration.  Content seldom used is uninstalled completely.  This is where a thoroughly, well kept database and archive system becomes critical for managing content.

Lol, that's what I wanna do...  Main thing that bothers me is having stuff I made mixed in with stuff I downloaded, "stock" items in the same rt as custom items.  I do want to "clean house", just in the simplest manner possible...

I'd like to have a "figures" runtime (Poser Daz etc.), and a separate "characters" runtime (customized figures)...  Then maybe two runtimes for props, separating those I made from those made by others...  Worst case scenario would be just copying the geometries and textures folders to each of those then deleting folders/files from each that seem unnecessary.  I know there is a program that can gather dependent files for redistribution, but I have so many odds and ends this would be quite time consuming.  Maybe in the long run that would be the best approach?

I would just put all your new content and any zips you still have into new runtimes but leave your old runtime attached in poser too.

Quote - I would just put all your new content and any zips you still have into new runtimes but leave your old runtime attached in poser too.

That was my plan for my downloaded content, but at least 1/3 of my runtime is custom props and figures.  I don't know whether to delete the downloaded content from my existing runtime, or try moving my custom figures/props to a new one.  It would be much simpler if I was only dealing with dl'd items packaged in install files. 

Ideally there would be a script or tool to batch move library items and their dependent files to a new runtime without gathering/packing each one individually (as when making them distributable).

I will likely keep the old runtime in its current form for archival purposes, but moving forward would like to have a number of smaller well organized runtimes separating things I have made from the items I have downloaded. 

Yes, I have a very very large number of smaller runtimes that contain just the content that is designed for those things eg a certain hair with it's mat files and styles and poses etc.

Quote - Yes, I have a very very large number of smaller runtimes that contain just the content that is designed for those things eg a certain hair with it's mat files and styles and poses etc.

I have a pretty good idea how I wished my items were organized in smaller runtimes...

I'm just trying to find the best/fastest way to separate my one large runtime into new smaller ones.  Re-installation is not a solution to dealing with the props/figures I have made myself within Poser.  I have bought just a handful of content over the years, but still have loads of stuff from installing versions 4-2014, creating original props and characters and the grabbing occasional freestuff download.

The main question is whether to copy items into a new (empty) runtime structure, or to copy my entire runtime and then delete stuff from it.  The former method has the risk of missing dependent files causing items to load partially/improperly, the latter runs the risk of duplicating unneeded files across multiple runtimes. 

I'd buy a program to do this if someone could recommend one.  The only thing that comes to mind is that I recall someone mentioning a program that would gather all of an item's dependent files for redistribution.  I was hoping there was a simpler way to separate a runtime into smaller ones, but all methods seem quite time consuming when one library item can have dependent files in many multiple folders. 

I have used P3dO Explorer Pro in the past to break out a new runtime.   For example I had a number of container props that were spread out in seperate runtimes such Space, Transport, contruction ect.  So I created an new runtime called Containers and moved all the props into that.  P3dO Explorer allowed me to use the 'runtime manager' to move each item from the present runtime to the new one in three or four mouse clicks.

Quote - P3dO Explorer allowed me to use the 'runtime manager' to move each item from the present runtime to the new one in three or four mouse clicks.

So it works on props, figures, and clothes?  The product description only specifically mentions moving scenes. 

What does it do with each prop's textures?  Does it create folders for each prop, dump them all into the textures folder or allow some user specified action?  Any info would be appreciated, but for just $25 it already seems a no-brainer.

If you use the runtime manager you are able to copy or move an item from that runtime.  For example if I click on a runtime and select a prop from the libraries menu then select the runtime manager I can copy or move to a different runtime.  I have the option to keep the tree structure or flat into the destination folder.

Keeping the tree structure means that the tree structure (geometry, props texture and so on) are moved to the destination runtime.  So the prop remains in the props folder, and texture in the texture folder within the new runtime. 

After the move there is a report of the total number of files moved and other infomation.  I have used this many times in the past and it just leaves an empty forder in the source runtime that can be deleted.

There is also a Scene manger with the same options but, in truth I have yet to use it.

There are many other functions of the program but the Runtime manager and the rsr to png conversion are the ones I have used the most.

Quote - If you use the runtime manager you are able to copy or move an item from that runtime.  For example if I click on a runtime and select a prop from the libraries menu then select the runtime manager I can copy or move to a different runtime.  I have the option to keep the tree structure or flat into the destination folder.

I've got the page open and am almost ready to buy, but had one more concern to clarify...  I suppose I should ask SENO Soft also, as their features description could be more clear.

If I move a file, say a custom figure into a new runtime, I expect that file to disappear from its current location and show up in the new runtime.  But what about that figure's dependent files (geometries, textures)?  Are they moved or merely (as I would hope) copied to the new runtime?

This is why the runtime structure is so confusing to users.  Not only is there no clear way to identify an item's dependent files, there is no way to see how many items are also depending on that file.  This is why manually organizing/splitting a runtime seems like a recipe for disaster...

Whenever I have moved a runtime it takes the dependant files with it.  I tried this again a few days ago and highlighted an item in the prop library.  The were about 10 items in the folder but, according to the report afterwards, 160 files were moved.  I check before and after and the textures disappeared from the source runtime and reappeared in the textures folder in the destination runtime.  If I had wanted to duplicate instead all I would have done is to use copy and not move from the Runtime manager.  The only thing I had left over in the source runtime was an empty folder in the prop library which i just deleted.

Quote - Whenever I have moved a runtime it takes the dependant files with it. I check before and after and the textures disappeared from the source runtime and reappeared in the textures folder in the destination runtime.

Thanks...  I guess that means I should just copy all of my files into new runtimes and leave my current bloated runtime intact until I can back it up.

To keep memory usage down I have a lot of textures (mostly grains, scratches and patterns) I use on most everything to modulate an items' diffuse or gloss or as bump maps.  I'd like it best if the program's behavior was to move the desired item, but only copy its dependant files... 

I suppose I'll go ahead and get it though, I don't know of any better way to organize everything.