Anton, There's a dilemma here, even though the idea is attractive. Readscipt injections (as implemented by Daz) will only work - i.e. inject - on the first figure loaded in a scene. So this would mean loading the clothes first, but then you couldn't inject the figure. So as RHasteltine suggests you'd need to build clothes with FII so they could still be injected if loaded after the figure, but then I'm not sure if they would conform. This would have to be tested. Only other way is the laborious load clothing item, inject, save out to library, close scene, open New scene, load figure, reload clothing. Yawn, yawn ;-) I'd have thought all this would be moot with Studio, and that you with your recent exposure to Studio are thinking along these lines would seem to confirm it. But as the rest of us haven't got any Studio exposure - yet - we can't really comment as to the usability in that environment. But in Poser I'm thinking it would be a wash: what you gained in memory savings you give up in usability.

Also a few months back Fry's had a dual-platform combo Poser4/PP pack for sale for much less that buying the 2 separately - not seen it anywhere else though. (FYI, Poser packages in Fry's stores other than Poser 5 seem to be displayed only with Mac software, even though they contain both.) Dunno if Poser Artist is still a dual platform package. Early Poser Artist download was reported, by Penguinisto over at PoserPros, to be 4.00 and required Poser 4 SR3 to be applied (although there was nothing to indicate this to the purchaser).

Bit out of step here - entered a long reply yesterday, but 'Rosity took a powder just as I clicked Post :-( Short version: M3's LM doesn't really need to conform, it loads into the correct position to just Parent to M3's Hip. ToolmakerSteve's idea for a Magic Utility is do-able, but problem is the acceptance for a stand alongside utility will be small, and a Python controlled one limits you to just ProPack which is a small market (Poser 5 version would be unecessary/different). Plus, I would expect Studio to have a work-around, given that it Daz's figures which have this problem. Migal's idea of FII and non-FII is a viable one, but it won't come from !Daz, esp. if Studio does have a workaround... Can be done by user by simply editing the readscript calls to a new directory structure in a separate copy of the CR2's. Perhaps if enough PBoost users want FII, then maybe instead we can persuade Howard to add !Daz folder to the swap-able list in the product, then you'd swap out the FII !Daz folder for the standard one, and vice-versa.

Had that happen once - the purple camera (the grey camera many times) - but could not reproduce. But mine does have a Foot camera :-) Since very first version of P5 (Billyware) a 4 camera view with Face camera in upper right window will, on loading a new figure, display the feet in the Face camera window! Any action in that window will cause P5 to get over it's foot fetish in a hurry and focus on the face. Usually this only occurs immediately after loading P5 and if it was last closed with 4 camera veiw selected, but being P5 it can happen other times too seemingly at randowm of course. Reported it during Pay-Beta, but CL felt it was low priority compared with other bugs - can't argue with that ;-)

Do you have anything set up for "Runtime"? The entry below the list of Libraries, just above "Switch Banks" button? PBoost will try to find these for itself when it first runs, but if you stop it, then you need to do it manually: Click the word Runtime and then click +Add, set up at least 1 Poser Runtime, close the popup windows, and then select a Runtime, if not already selected, by clicking on the field to right of the Runtime button. Exit PBoost - i.e. Menu > Shut down PBoost, not just click the close button (or right click the toolbar icon and select Shut down PBoost), and then restart it. The index of out bounds error shouldn't be absent. The error is non-fatal, BTW. Hope this helps, yell if it doesn't...

Most likely it's that gVim isn't "seeing" the file. Try the [Tab} trick of completing the filename that I mentioned. if even that doesn't work, then I'd suggest that the file isn't in one of teh 2 locations that gVim will search by default (as mentioned). ALternatively, enter the commands by hand. This is clearly going to be onerous for 400+ times, but at least if you try it on one, you can probably tell whether it's the actual editing that gVim is having trouble with, or the command file.

OK REPOST - Nothing changed here... Except I've put back in the characters which 'Rosity's old code removed :-O (Using square brackets instead of angle ones. Why no "No HTML code" option?)

Posting here so as not to fill up main Poser Forum with long How To messages. But if you don't understand what we're talking about please go to the link provided, read up and come back. We think this development is BIG if you use Injected figures like V3, etc, and so...

OK, after you've re-read my disclaimer in the post linked above, here's what I did to make these edits to my copy of Victoria 3. I repeat I'm not suggesting or encouraging anyone to do the same...

First go to www.vim.org and download a copy of the incredibly fast Vim (Vi Improved). Yes, Vi is a pain to learn, but there's a Gui, which helps hide much of the complexity, and it's surely the fastest way to edit multi-megabyte files. And it's scriptable, which is kinda important when there are over 400 files to edit... Then install it.

Now create the script file containing the 2 lines below, and save it in the root directory of your C: drive under the name c:fiiscript.txt. You can do this is Vim, but Notepad would work just as well. Note that there needs to be exactly 1 [Return] character at the end of each line - no more, no less. And yes that path looks funny, but it's because Vi being originally a Unix app doesn't like spaces in filenames and requires them to be preceded (escaped) by , which is rather confusing to us, but Vim will understand it just fine.

The contents of c:fiiscript.txt:

:args C:Program FilesCurious LabsPoser4Runtimelibraries!DAZVictoria 3BodyDeltasInjDeltas*.pz2[Return]
:argdo :g/valueOpDeltaAdd/ + | :s/ 1//g | + | :s/:1//ge | update[Return]

Note that if you've installed Vicky 3 in Poser 5, or you've installed Poser somewhere different, or if you've got a MetaCreations version, or a non-English version, you'll need to edit that path on line 1 to match your set up.

{If anyone is interested the first line tells Vim to find all files in that folder which match the wildcard name, and the second line instructs it to look for and change the patterns we need to fix and save it back to the hard drive if it finds anything to change.]

OK, here we go... NO - WAIT! Make a backup copy of your Deltas folders first! Using Windows Explorer locate each of the Delta folders with the path above as a roadmap, Copy the entire Deltas folder and save it as a "Copy of Deltas" folder. (Left click on Deltas folder icon in right pane of Window Explorer, Ctrl-C, right click on white space in right pane and select Paste, Win Explorer will generate the "Copy of..." name for you.) Now give it the once over to make sure the copy worked, and now youre safe(r) to proceed.

Start Vim in usual way (gVim from the Start Menu for Gui Vim). Type the following:

:so c:fiiscript.txt[Return]

followed by a (BTW, you only need to type :so c:fiis[Tab] and Vim will type the rest of the filename for you. If you didn't put the file in C: or VimVimfiles you'll have to update Vim's path environment to enable it to find it - Good luck! ;-)

As soon as you type the [Return] Vim will start processing the Inj files in Deltas folder. After it's filled a screen full of progress messages it will display -- More --, simply press the [Spacebar] to continue. Repeat. Repeat. Repeat. (Yes I could have run it in silent mode, but figured Id rather be aware of what is happening. Gives your hard drive a break too ;-)

The script is a bit heavy-handed in that it writes the file for each valueOpDeltaAdd group it changes, rather than once per file, but I figured the slightly longer run times were a good trade off for a short script file (Oh for a real shell in Windoze). A few Inj files do not have any valueOpDeltaAdd's in them and you'll see that they are not saved. Also you'll notice some on the Inj files don't have EOL and some are in Unix line-endings, but it's all good (enough ;-).

When it finally stops, simply close Vim and take a look at your files. Every file that's been updated will also have its previous version saved with a tilde (~) on the end, which you can clear out later when everything has tested out AOK (Display as List in Win Explorer and sort by Type column). The edited files should no longer have the " 1" and ":1" entries following the valueOpDeltaAdd lines. If they dont they are now Figure Independent Injection files!

Now, go back to c:fiiscript.txt, and edit the "...Body..." entry in the path to "...Head..." and repeat for that folder. Don't forget to make a backup copy of this new Deltas folder, NOW! if you havent already.

Finally you'll need to repeat for MalePak and/or any other 3rd Party folders under !DAZ that need fixing - sorry - updating.

Now you should be set, your V3 will no longer demand to be the first figure loaded in a scene.

This all worked under Windoze 2K, but should work under any Windoze version, and as everything tricky happens inside Vim, should work under MacOS/OSX too with the right copy of Vim, but Ive no way of knowing for sure.

lb

Not saying it was the cause in your case, just trying to correct my statement about needing to see the File Dialog. Which is what I had believe previously. Please let me know the outcome...

Sorry, Marque, I mispoke. I recreated a similar situation, and it locked (coincidentally) on the third attempted switch. But I'd seen no File Dialog, nor had the Windoze Explorer open on that drive. Retried, loading just the last figure that I'd loaded before and it lock immediately. Seems that Poser only needs to have to search INTERNALLY for a texture, and it goes into a sulk, forgets to release the directory, and the file lock issue is triggered. Ran Correct Reference on the figure's library and sure enough it corrected a few files. After that I repeated my steps with no file lock. In my case it was a prop (hair) loaded along as part of the figure's cr2 that had the misplaced texture.

If you get the File Dialog up in Poser to help it find 1 or more textures, then you'll hit the lock problem. Poser (at least 4, PP, & 5) has a memory leak or similar (surprise, surprise) in the area of code dealing with that file dialog. So if it opens up that dialog, Poser never releases it back to Windows, ergo when PBoost tries to access the directory to switch it encounters the OS lock. And Poser seems to open the search for the texture at the /Runtime level so the lock affects all directories in Runtime not just Textures. So if that's your cause, you'll need to correct those references to prevent the problem in the future. Correct Reference being the simplest way to check all files, Deep File Editor or any text editor might suffice for the individual case. Another simpler cause is that you have a directory open simultaneously in Windows Explorer or P3DO or similar. This affects just that single directory, so just re-direct the explorer-style app to another directory and try PBoost switch again. Why M$ implemented the lock this way in NTFS I'll never know, because it causes problems within the OS itself (e.g. "cannot copy file, it may be locked or in use"), but it affects W2K just the same as XP.

Attached Link: http://www.renderosity.com/messages.ez?ForumID=12356&Form.ShowMessage=1511637&Reply=1511807#7

I suspect that you'll find an improvement if you are prepared to remove the Content Paradise room. See PoserPros under General Discussions and/or FreeStuff for instructions. Removing Content Parasite returned near-linearity to mouse movements in P5. Still not as good as P4 but a lot closer. So it may well do same to graphics tablet. Speeds up load time too. Conjecture is that P5 Paratmeter Dial is a separate window to the OS, so much intertask communication is being wasted keeping them in sync. And if IE is linked in to service CP then it gets to stick it's nose in between each intertask communication to further delaying things. Note this solution only affects the dials on the Windows version of P5, OSX can still treat the Parameter Dial panel as part of the main application so it doesn't seem to suffer from the mouse/dial slowness problem. It also reportedly doesn't benefit all versiosn of P5, but certainly does seem to help the early versions that have been patched up to SR3.

Item 4 is important, but has 1 significant exception: If the product or individual item within product is known by design to be Poser 5 only, e.g. uses Dynamic Cloth, then and only then it should have version 5. That way the user's attention is drawn if they've picked the wrong one. Similarly if Poser AND ProPack MAT/MORs are present in the product, the ProPack-only items could have version 4.3 for similar reasons. Any discussion on where ReadScript Injection files should be stored? Some vendors are using !Daz folders, others are placing just about everywhere...

Momcat, Sorry, wasn't trying to ignore your questions, just missed them entirely. Seems that 'Rosity's ebot took a powder over the weekend. But I'm glad see Migal took care of your questions over on Daz Forum.

And per reports the download version is/was true Poser 4.0 - i.e. you have to add the Poser 4.03 patch to Poser Artist yourself. In fact you have to know that it needs patch 4.03 meant for another application!