Dave-So, if it's getting slower, rather than always having been that slow, then it has to be something that's changed. NT does have better memory management than 9x, but Poser's is so bad, that even NT can't fully contain it. But likely cause is that your swap file is getting too large and/or too fragmented. As was noted above M$ Defragger on NT is nothing like their Defragger on 9x. It takes a minimalist approach. It attempts to free up larger contiguous areas for new file's use, but does minimal effort on already fragmented ones. You'll need to run a 3rd Party one - SpeedDisk - to really clean up already fragmented files - like your swap file. Also check that your swap file isn't unnecessarily big. There is a school of thought that there's little reason to go much over 2GB total INCLUDING your real memory (i.e. with 1GB real memory I keep my swap limited to 960MB). After all no single 32-bit Window's application can access more than 2GB of memory store - although that won't stop Poser5 trying, with predictable results.

Sorry, didn't have access to Poser directory before. I believe it's Runtime/prefs/preferredstate.pz3 and /Poser UI Prefs_yyyyxzzzz where yyyy and zzzz are your chosen screen resolution values. Should be easy to confirm though, as they'll have a current date. Mightn't hurt to save copy of Poser.ini too...

Momcat, If you haven't done the "Figure Independent Injection" then you can't do what you tried. Injection through readscript as implemented by Daz can only apply the ERC/FBM morphs to the FIRST character loaded in a scene (not just Figure 1, but the very first CR2 loaded). So all your ERC/FBM's for M3 got applied to V3. Basically you have 2 choices: the Daz recommended solution of pre-injecting your character and saving it to the Figure library and then using that for any character other than the first one loaded (after running Dial Cleaner on it). Or follow the FII route. If you really plan out your characters before you strat your scene, then the first option will be fine, but otherwise it removes all the advantages (for the user) of Injection. Fair bit of editing, but it's all explained - although I can't see why Daz can't do it as an update... To find the info on FII, look in Tech Poser forum, it's not far down in that one, and has links back to the discussion in main Poser forum.

After you get the preferred state back the way you want, consider making a backup copy of the file...

Sealtm2's were free. Try IM or emailing him?

Sealtm2 made a nice set for Vicki 1 - Vicki Smoking Poses. Don't know where it was originally posted, but his Freestuff sites here seem to all be down though...

OK ;-) But I want them to do the SmlShoulder morph first - which I can't do :-( No issue with you doing superheroes, it's a free world (well was ;-) BTW, shouldn't you have checked the Nudity flag to be RPC? After all there is NOTHING covering M3's face, he's NAKID, NAAKEED!, his face is as uncovered as the day he was born :-O *RPC - Renderosity Politically Correct

There's a lot of little things that they could have / should have done to M3 to bring it even close to the standard of V3 (muscle-based mesh, unique M3 morphs rather than transplanted V3 ones, e.g. shoulder morphs, especially after they changed teh defualt .obj shape), etc., etc., ...). But in this case perhaps the (oft-dreaded) Group Tool can come to your rescue (as Daz is unlikely too). Select just the part of the forearm that needs to be a glove and make a new material. You only need to do the foream, as you can use SkinHand for the rest. Select Forearm, choose a display mode that shows the polygons, open Group Tool, create New Group, select/de-select polygons to suit, then Assign Materials. Close Group Editor and lower part of arm should be a different color, and appear in Materials under your new name. Have to do for both forearms of course.

Attached Link: http://www.keindesign.de/stefan

An .rsr is an .rsr is a .rsr. All Macs (MacOS) have a good solid clean file structure with the instruction (code) part of the file separated from the data (image) part. (Whereas Windoze files muddle it all up - and if you want to see the potential outcome of that approach just consider your weekly pilgrimage to Windoze Update!) It's in all files. It's called the Resource Fork. If you just format a floppy on a Mac for a PC and read it on a PC you'll see the Resource Fork for the file system sat there as a hidden file. The .rsr is simply the home of the part of the file that was the Resource Fork on the Mac. Rather than "properly" porting Poser from the Mac to the PC, Metacreations just created a concept of a .rsr file and shoved everything from a file's resource fork into a file named with the same root filename stem, but with extension of .rsr. (This "quick port" from Mac to PC is IMHO the main reason why the PC version of Poser, PP and Poser 5 have so many legacy problems on the PC. These problems don't exist on the Mac, and because the code was never really ported to the PC, it can't be debugged on the PC using modern tools. Ergo we're stuck with an ever growing list of legacy bugs.) This .rsr approach is a cop-out for a number of reasons. The primary one being that we now have 2 files holding the data that originally was designed to be in one single file. And the code only expected one so there is no code to deal with half the data going AWOL, so if the info in the .rsr file ever gets out-of-step with that of its corresponding "master" file, we're in trouble. How much damage is done by deleting the .rsr file depends on how much valuable data is in the .rsr file in question. Delete one from a library and you lose all the image data - i.e. the pict image, so you get the shruggy fella. Delete one from Geometry and Poser has to rebuild it. Delete it from Poser.exe and there are no images available for the Poser application - can you spell NoGO ;-)

Nice one! Works fine. Thanks, Ed!

Gerald Day has one in his archives. A prop with an open/close morph. www.fast3d.co.uk As is the norm with geralday products it's a very small tight mesh.

EdW, thanks for your efforts on this. Perhaps you could try encoding against a different file, say the dogHiP3.obj, in case your copy of horseHiP3.obj got changed during the update process? AFAIK Mover just wants a file to encode against to confirm possesion of an identical file, the actual contents of that file are less improtant.

Maybe a coincidence, but it's now being reported that a BANNER AD (!) was infected with Qhosts trojan at FortuneCity last week. It was removed as soon as it was discovered, but that was at least a few hours later. It symptoms matched those referenced in this thread. The exploit was for that M$ security hole of August (MS03-032), patched again in Sept (same #), and that was still open until the lastest patch this week in Oct MS03-040 (828750). So if you haven't updated in last week, time to do it again... Qhosts infection is the only known exploit of the 3rd iteration of M$'s bug, and the websites used by it have all been taken down. So it's no longer a threat, but how long before a copy-cat or variant breaks loose... And yet another reason to run an ad-blocker.

Yep, that's the one downer with this solution (for Poser 4/PP users). The CR2 has to load the original character into Poser first then the new additional slots - otherwise you break the basic rule of providing Poser with access to the object before you modifiy/enhance/refer to it. And when you load the original, you obviously load all dials up to and including Rotate & Bend. But for what Insomniaworks was striving for - a way for newer Poser users to add morphs without requiring the user to get into Objaction Mover, Morph Master, etc. - it works quite well. And for Poser 5 users it works perfectly, as the Transform dials are always displayed separately at the bottom. For those Poser 4/PP users who want the morphs in a more logical place, I guess it's just a case of using Morph Manager - or your favorite editor - to move over the new slots permanently and replace the CR2. In other words more advanced users have lost nothing (beyond perhaps instructions on how to move the empty slot). One minor note, if you routinely store your original figures in folders of your own names (vs. the author's original name), you'll be looking at changing the path name in the readscript (in the CR2) before using it - although a readscript error is not fatal to Poser if you forget, as a invalid material file would be. Overall a big step forward.