To map poser content in D|S, you MUST target the equivelent of the poser root folder, the folder poser.exe is in, or would be in if the content you are mapping is not in your main runtime. This is because the pathing information in poser files are relative to that folder. Do NOT target "runtime", "libraries", "billy-bob's runtime" or whatever else, unless it is the equivelent of where poser.exe would be found, using the same structure used by Poser.

-Rob

P.S. Please feel free to quote this message anywhere you feel it will help.

"And have you looked at a .daz file? Nothing to see!"

I don't suppose you've stopped theorizing long enough to consider that binary is not only significantly smaller than ascii, but also loads MUCH quicker? Nevermind. That wouldn't fit well into a conspiracy theory, now would it? I forgot, I should be ashamed of myself, we are trying to build an evil empire... damn building a tool we would want to use in our own production.;)

-Rob

Ahhh - speculation and misinformation abound. Gotta love it.

"And have you seen Rob W's Xmas day statement on Daz Forums that Studio will not support injection as we know it?"

I suggest you read more carefully, you misquote me... what I said was "We are still working on dynamic morph loading... (which will render 'injection' obsolete). The UI is only partially there right now" and further explained, when Ratteler misunderstood my meaning, "please don't read that to mean that we will not support it. In fact, we already do... its just that the UI for the parameter pane isn't fully implemented yet, so you don't see them in all thier glory. Basically, what I'm saying is that there will be no NEED for it, as [native] D|S morph loading will be dynamic... as in, the morphs will be loaded on the fly (with no need for user intervention) as needed, vice consuming valuable memory better used elsewhere. Think of it sorta like 'injection', but under the hood." Quite a difference from what you would have people believe by misquoting me.

"Daz see Studio as a Poser replacement as they have said all along"... quite the contrary. DAZ has specifically stated the opposite.

-Rob

Joe, no harm, no foul... just being on the outside (of the inside joke), and seeing room for much speculation (which is difficult for passers-by to understand what the hell I'm talking about, with your post removed - though I understand why you'd want to remove it), I figured I'd squash that bug (bugs with freakin' lazer beams on thier foreheads ;)) before it made it into the walls. They are terribly hard to eradicate once that happens. ;) I usually steer far clear of these sorts of topic... I tend to observe more than post these last couple years as it is. Likely due to the fact that I'm an extremely passionate person, and it seems far too easy for "Rob's opinion" to be taken as "DAZ's position"... I'm sure you know the drill. Anyway, just makin' sure good people don't get a bad wrap. No disrespect intended.

Anthony, not a problem. You know how I operate.

Rob, glad to know you feel that way. Thanks.

-Rob

Joe, slow down. Anthony appears to be responding to the cookie comment... least the way I read it. FWIW, he works directly with yours truly on the docs, he has never bad-mouthed the CL folks to me, ever. In fact he is quite adamant about not discussing anything he was privy to as a CL employee. His integrity should not be in question. -Rob

"The FREAK" is an affectionate term, believe me. It is used to describe his freak-ishly large proportions and freak-ish strength. See, there are a few of us in the office who lift weights regularly... Most of which have goals of increasing strength and muscle development beyond that of a "normal" male... A few of those (of which Chris, Allen and I are included) aim for much more than that... 'freak'-ish even. ;)

If you call him anything other than his given name... I'd say "Chris" is appropriate, as [Chris] is affectionately called... Chris "the FREAK' Creek. Has a nice ring, I think. ;)

PheonixRising: "Actually Chris Creek did the Freak shape."

Actually, Anton... Fact is, like every figure/product we build in-house... we tag-teamed this one. Chris started a muscular base from Michael 3... along with a smaller head and longer limbs. We intended for him to be about 150% the size of Michael 3. We discussed where we wanted to go with him, along with the pros and cons... and I took that base, restored the head (for compatibility with Michael 3 head morphs), gave him broad shoulders, bulked him up to his freak-ish proportions and handed it back to Chris for the fingers, knuckles and some tweaking on the feet and toes. Once the base was finalized, I built the rigging and some of the morphs in the morphs and maps product. Needing to get back to work on DAZ|Studio, I handed the project to Tony for UV tweaks, beta testing, minor rigging tweaks based on beta feedback and a getting Eric and Greg in on a few more morphs/accessories.

As for whether there was any "Hulk" influence... need I really answer that? I think it goes without saying (even without pointing out that I had a 12" Hulk figure on my desk while I was building). ;)

-Rob

From what you describe, it sounds as if you are not selecting 'Michael 3' in the 'Figure' dialog (F2) prior to processing the face file. The default option is 'Victoria 3', as such IPB is using an internal dictionary containing file paths that are specific to the selected figure, Victoria 3. The resultant pose is likely injecting delta information as it should, the problem, however, is that it is information specific to Victoria 3. -Rob

RE: Routing issue. Problem noted. Likely something to do with shuffling of servers to accommodate the forum launch. Should be temporary... dns cache needs time to update. RE: Web Design. ScreamDesign is a web development company owned by DAZ Productions, Inc. We've recently made staffing changes that put Jeff Cemer, the developer responsible for the ScreamDesign site, into the DAZ [proper] web development mix. The design of the [DAZ] main site (which is in the process of migrating to all facets of the DAZ website) and the forums, love it or hate it, is by yours truly. The design implementation is by Ryan Bouche, Jeff Cemer, Jason Jones and Matt Wallace. -Rob

RE: Michael 3 support In order to result in a file that calls Michael 3 source files, you need to select 'Michael 3' in the figure dialog. Doing this changes which internal dictionary IPB uses to list references in the header. -Rob

In the install directory for IPB there should be a IPBOptions.cfg file. You have a couple options... one would be to delete that file (and lose any saved preferences), OR the other would be to edit it in a text editor (extremely simple).

If you open it in a text editor you should see something that resembles this:

[Main]
mGeomW = [#]
mGeomH = [#]
mGeomX = [#]
mGeomY = [#]

[Figure]
fDialog = [1 or 0]
fGeomX = [#]
fGeomY = [#]
who = [figure name]

[Processing]
pDialog = [1 or 0]
pGeomX = [#]
pGeomY = [#]
batchProcess = [1 or 0]
injRemBoth = [1 or 0]
injRemType = [1 or 0]
ignoreNonMaster = [1 or 0]
ignoreNonBody = [1 or 0]
ignoreNonHead = [1 or 0]
ignoreReadscripts = [1 or 0]
nonZeroed = [1 or 0]
roundEmUp = [1 or 0]
ignoreExpressions = [1 or 0]
expressOnly = [1 or 0]
ignoreZeroed = [1 or 0]
ignoreScale = [1 or 0]
readScriptOnly = [1 or 0]

[Add On]
aDialog = [1 or 0]
aGeomX = [#]
aGeomY = [#]
v3AnnaMarie = [1 or 0]
v3MorExpPak1 = [1 or 0]
v3HornPak = [1 or 0]
v3MalePak = [1 or 0]

Where you see '[#]' above, there will be numbers corresponding to the width(W), height(H), horizontal position(X) and/or vertical position(Y) of your screen (measured in pixels - 0x,0y being the top left corner). Deleting those lines will cause IPB to use default internal values. By default, the option dialogs appear with the title bar under your cursor the first time they are displayed (without specific coordinates being indicated - as they are in the config file). F2, F3 and F4 toggle the option dialogs. If a value is indicated in the config file or the dialog has been displayed since IPB was launched, the size/position of the main window and the dialogs will be dictated by the last value in memory.

Above you'll also notice the '[1 or 0]' next to many of the options. These are boolean values (1 = checked, 0 = unchecked) that set the editable options in the dialogs.

Once you have IPB configured the way you like, select 'Options -> Save Options File.' The next time you launch IPB it'll be the same size/position and have the same options selected as it did when you choose to save.

-Rob

;) Notice the "(Help -> About)" at the bottom of my post; If you go to the Help menu in IPB and select "About..." you'll see what I was hinting at. I mention it as insight on how I might be qualified to help... ;)

As for your question, it appears I wasn't clear enough in my previous post... so I'll try again. "! IPB Prep" is the correct file, it is distributed with the [1.2] update to IPB. Most REM files act very quickly and may appear to do nothing. "! IPB Prep" is a REM file that removes all delta [morph] information, including morphs that are not injected... like JCMs and morphs in the eyeballs... because to IPB that information is useless.

"!M3 IPB Prep", however, should NOT have been distributed with Michael 3, as it is specific to a product [IPB] that is not included as part of Michael 3. Will the file do the same thing? I'd have to check once I get back in the office in the morning, I didn't build it... so I can't be certain without looking at it, but I suspect it does. Will it be updated (if needed) as IPB is updated? No. In keeping consistent with what has been previously established (with Victoria 3), the "! IPB Prep" file specific to a particular figure is put into the equivalent "!DAZ's [figure name]". The source file (the one that would actually get updated if needed) is located in the associated directory in the "libraries!DAZ" directory of your runtime. This allows [you] to move the library file to any location [you] choose, but allows us to update the source, if needed, in a location that doesn't change.

Will IPB process the file without first applying the "! IPB Prep" pose? Yes... albeit slower. Because IPB parses [reads] input files line by line, if the delta information is still present in the file, IPB has to sift through that many more lines to find what it is looking for.

-Rob

The purpose of the "! IPB Prep" pose (located in "!DAZ's Victoria 3" or "!DAZ's Michael 3"), that accompanied the 1.2 update of IPB, is to remove ALL morph deltas from the associated [selected] figure (each pose is specific to that figure; due to internal channel names for the morphs). The pose only needs to be used when saving cr2's to be processed by IPB. By removing the morphs, the file size is decreased significantly and as a result IPB will process the file much faster. There should not have been any IPB specific files distributed with Michael 3, as IPB is a separate product.

-Rob (Help -> About)

Jeremy,

I've handed the reins of the [content] Production Department over, around March of this year, and began focusing more on the design and development side of things... so I'm not certain as to specific schedules for content production. I've pointed out a few concerns to the appropriate parties in the event that they were not aware of any particular issue and they appear to be on top of it already. I'm sure, much the same as it was when I was calling the shots, that the production folks will want to fix as many issues as possible in one go, and avoid as much confusion as possible. Remember, the problems need to be replicated before they can be repaired, and then a possible solution needs to be tested to prevent further complications... so I'm sure it'll take [at least] a little time.

To make a long story short, if there are actual problems (vice subjective opinions)... will we fix them? Don't we usually try to? Honestly? We put a lot of pride and hard work into the products we create. But despite our best efforts, we are human... Sometimes things slip and only someone who has faced the enormity of some of these projects would truly understand how things actually happen (vice how they theoretically 'should' happen). That said, we are continually trying to improve our processes and procedures and hope that we haven't caused too much discomfort. All I can suggest at the moment is a little patience to allow us to identify the real problems...

-Rob

IPB was last updated to include support for Michael 3 on August 29, 2003. Brokers used the updated version (1.2) to produce content for the Michael 3 release. Ealier this morning I noticed that the update had not been posted yet, and wondered why myself. I brought it up to our webmaster and was informed that he'd be posting the update installers on the IPB product page by the time he leaves tonight. -Rob

Don't mind at all... would've posted an image here myself, but I don't visit that particular forum unless someone directs my attention to it - and posting it in here would have almost certainly caused a ruckus. Regardless of how long I've been part of the community, what I've contributed to poserdom on the whole, whether I were responding to a request or not... I work at DAZ now (since March'02) and therefore play by different "rules" (spoken, unspoken, written or otherwise). So, I post (when I can; without compromising the confidentiality of the project) previews of projects I'm working on, on my personal site and let those who seem interested know by directing them there. Besides, got far too many big projects to work on to go round and round with some of the petty bickering of late. :) Sooo... to make a long story short, thanks! ;)

-Rob