You do know you can work on weight maps without going into the Setup Room, right? The setup room is for setting up a figure. If you're not creating a new figure you probably don't need to enter the setup room at all. You can edit weight maps in the Pose Room. In point of fact, that is where I edit all weight maps, do animated joint origin changes, insert new morphs,etc. leaving the setup room for bone creation in a new figure only. You should probably also not bring a morphed figure into the setup room - the warning message is there for a reason. The only reason to load a morphed figure into the setup room is if you are transferring a morph and rig from a figure in the library to a blank figure in the setup room. Do not take an already morphed figure into the setup room. 

Hello people.

I found out something interesting ... Maybe is already known, but I just discovered it.

If you have a figure with Subdivision activated for to be rendered/seen with one or more level of subd, exported morphs or morphed body parts will have the delta data duplicated.

I mean, when loaded the new obj file as a MT, in case you neeeded to export it for tweaking in a modeller, the morph data will be as in "2", not in "1".

Same happens when you export the obj as a new prop obj or new parts for a figure. Delta info is duplicated.

fabi

Hello Teyon, --- Yes I know, and I actually do edit my weight maps in the Pose Room all the time, using the Joint Editor. --- The reason for my heads-up: --- What if you need to create an additional Helper Bone in your already mostly developed figure?--- Dang!--- I understand the reason for the warning message when entering the pose room, but as long as I do not touch the present grouping, everything will be fine (all morphs still working) after I leave the Setup Room. Less the nuissance that ALL hitherto "hidden" parameter dials are now visible. --- I don't think that this is necessary, and probably only requires a very small change in the code: >> Remove ALL occurrences of "hidden 0"<<, and just leave the parameter dials' "hidden/not hidden" status as it was before.--- Not too difficult, I suppose.--- Cheers

I am having trouble with Victoria 4.2 in PP2014. It seems I cannot get her eyes to close. I've injected the morphs into her, moved her into the default runtime. tried her in an external runtime, and nothing seems to work. I've got all the updates, and I've also performed uninstall/install. Everything works as expected in other versions of Poser (P10, 2012, P9, etc)

Check that you don't have more than one RuntimeLibraries!DAZVictoria 4 folder. Make sure the RuntimeLibraries!DAZVictoria 4 folder isn't in a protected location (such as soemwhere in Program Files for Windows Vista or later). Try running RuntimeLibraries!DAZDzCreateExPFiles-v4 manually.

Bug/Caveat:

Texture caching is good for speeding up stuff when working on the same scene for days, but it is buggy: Poser (Pro 2014) doesn't check available disk space, which means that if you don't have heaps of space left on the partition your Poser temp folder is on, and try (for instance) a dozen different texture maps for the characters in your scene, Poser will happily fill up all available disk space (to the last bit!) and subsequently crash.

Some check on space availability needs to be added to Poser, or just a FIFO (first in, first out) feature, to keep the overall volume stable. No, the "texture cache" setting you set in preferences apparently is only for how much cached data Poser will keep when closing. Apparently, during a session, it will happily pile up dozens and dozens of GB of texture data, no matter the setting.

How did I discover that? Loading a basic V4 and trying on different textures (character set MATs) till Poser Pro 2014 exploded. My texture cache setting is 3 GB, and Poser ended up crashing after filling up the 20 GB partition its Temp folder is located on. No other harm done though, except I had to manually delete the temp files and restart Poser. Given it was just a series of tests the lost scene wasn't a problem for me, but YMMV, so beware.

agree that frequent defrag may be useful with these probs.  OS X: use iDfrag and DiskUtil.