Hi Geoffrey,

I have round 8,9 external runtime and know about goods and bads of that. So let me give some hints.

Ad1) I dn't know Semidieu's LM2 but use D3Dimensions Library Manager and there it is a little bit more expensive to change runtime than to change only directories. This is cause runtimes need to be read over all while the subs are just in memory after having read the runtime. So my suggestion is clearly make a RT Weapons and do the diversification of the weapons by subdirs. Only keep in view not to exceed the windows path length.

Ad 2) Either,or ... Neither, nor ... will say its a matter of personal taste. I for example have matching male and female figures and their stuff in one runtime, e.g. Posette/Poserman (P4), V1-2/M1-2, V3/M3, V4(+S4,G4,A4,...), M4 ... with V4 it was neccessary to split male and female cause V4's boudoire is suuuuuch big. In my opinion the clothes are the main point for the RT-split. These are mostly only suitable for one figure, so they incl. their mat-poses should be divided for easier finding and loading. But there are 2 themes that stand a bit out of this: hair and movement poses. Hair can fit slightly easy to more than one figure, so my suggestion have a separat runtime for all hair and sort it by figure named subd in this runtime. Poses f older figures, e.g. P4, fit with small changes to all figures and can be hold over all in a commons runtime. Poses of V3/M3 need to be hold with their figures due to a different geometry in neck area, they mismatch with all other figures. Poses of new figures like V4 disturb slightly often older figures. So they are best located in V4 runtime. To split generatin 4 poses by single variant (V,S,A,G,...) makes no sense. By the way the old P4 poses are anyway a everytime good base to start a new pose for every newer figure. But if you have hand poses for special props, e.g. weapons, I would hold them together with the prop in that runtime and not with the figure.

Ad3) In general no, may depend on the behavior of the used library manager. May be that the build in original Poser manager can run in trouble cause it's holding all the stuff in memory as far as I know and thyt with the tricky flash or air technology. With my D3Dimension Manager there is absolutely no problem cause only the actual used runtime is hold in memory and you can switch between the runtimes with a fingertip.

Ad4) As far as I know Poser is having no trouble with long paths but clearly not longer than the OS, e.g. Windows is allowing. But in a lot of internal windows on the poser desktop long paths are not well shown and so to have too long paths can be cumbersome. In this context be warned that poser is having trouble with identical filenames in a lot of situations even if these a placed in different named paths and/or runtimes. This concerns geometry objcts as also textures there this problem most often acures. And the search order in directories poserr is using is a big question mark. So if you get a texture not fitting to the figure but coming from a runtime not belonging to the used figure have a look to the filename and remember that poser not evertime is using the pathname to identify correctly. Though to be honest this is not a problem f external runtime. It will happen in one runtime similary but a bigger number of runtimes can complicate this trouble. This is one thinf from the category: It was/is a bug but now called a feature by marketing ... :-)

Hope this will help you a little bit. B.t.w 400.000 items in one runtime how did you handle this and find the things easyly ...

Regards

Jo