Why Does the External Name For A Prop SOMETIMES Have An '_1' Suffix

3dcheapskate

I know it's an incrementing suffix for multiple copies of the same prop, but it's the 'sometimes' that puzzles me...

For most props that I load Poser (9) adds an '_1' suffix to the external name of the first one I load, '_2' to the second, etc.

However, I've noticed that for some specific props Poser doesn't add any suffix to the first one, it adds ' 1' to the second, ' 2' to the third, etc.

Examples:

• Poser primitive - ball_1, ball_2, ball_3, etc
• DAZ H4 Slicer sword - SlicerSword_1, SlicerSword_2, SlicerSword_3, etc
• Aery Soul weapons collection - IcyingLight, IcyingLight 1, IcyingLight 2, etc

It doesn't seem to be related to whether the geometry's internal or external. It doesn't seem to be related to the external name specified in the PP2.

So what's the cause of this ?

 

(I'm jus' fishin' on various Poser forums... ;o)

SpottedKitty

I think it's due to how the content creator originally saved the file, and whether it had an increment suffix then.

3dcheapskate

That would be reasonably logical, but I don't think it's the case.

Here's a selection showing the relevant bits of the PP2 where internal/external names are specified plus the internal*/external names for the 1st, 2nd, and 3rd copy of that prop that's loaded into the scene from the library**

{version    {    number 4.01    }prop icyinglight:2    {    storageOffset 0 0.3487 0    objFileGeom 0 0 :Runtime:Geometries:aerysoul:weaponscoll:icyinglight.obj    }prop icyinglight:2    {    name    IcyingLight

• 1st: icyinglight / IcyingLight
• 2nd: icyinglight 1 / IcyingLight 1
• 3rd: icyinglight 2 / IcyingLight 2

{version    {    number 6    }prop SlicerSword:1    {    storageOffset 0 0.3487 0    objFileGeom 0 0 :Runtime:Geometries:VaL_Slicer:SlicerSword.obj    }prop SlicerSword:1    {    name    SlicerSword_1

• 1st: SlicerSword / SlicerSword_1
• 2nd: SlicerSword 1 / SlicerSword_2
• 3rd: SlicerSword 2 / SlicerSword_3

{version    {    number 5    }prop Persian_Sword    {    geomCustom         {        ...        }    }prop Persian_Sword    {    name    Persian_Sword

• 1st: Persian_Sword / Persian_Sword_1
• 2nd: Persian_Sword_1 / Persian_Sword_2
• 3rd: Persian_Sword_2 / Persian_Sword_3

As I hinted in the OP I can't make out any pattern or logic to it, although I'm sure there is some. If anybody can see it please let me know. Maybe I need more examples ?

*the full internal name (as obtained from PoserPython) has an additional ':1' suffix added for all instances of the icylight and SlicerSword

**using Edit >Duplicate 'whatever' to make a second copy gives slightly different results, which may confuse the issue...

 

3dcheapskate

A response on another forum indicated that parenting has something to do with it.

This simple script displays external/internal names for all actors in the scene:

import poserscn = poser.Scene()actlist = scn.Actors()for act in actlist:	print "External Name = "+act.Name()+" (Internal Name = "+act.InternalName()+")"

With no figure in the scene when I load the props it gives me this...

External Name = SlicerSword_1 (Internal Name = SlicerSword)
External Name = SlicerSword_2 (Internal Name = SlicerSword 1)
External Name = SlicerSword_3 (Internal Name = SlicerSword 2)
External Name = IcyingLight_1 (Internal Name = icyinglight)
External Name = IcyingLight_2 (Internal Name = icyinglight 1)
External Name = IcyingLight_3 (Internal Name = icyinglight 2)
External Name = Persian_Sword_1 (Internal Name = Persian_Sword)
External Name = Persian_Sword_2 (Internal Name = Persian_Sword_1)
External Name = Persian_Sword_3 (Internal Name = Persian_Sword_2)

But if I have a figure in the scene before I load the props (SlicerSword and IcyingLight are smartprops, Persian_Sword isn't) I get this...

External Name = SlicerSword_1 (Internal Name = SlicerSword:1)
External Name = SlicerSword_2 (Internal Name = SlicerSword 1:1)
External Name = SlicerSword_3 (Internal Name = SlicerSword 2:1)
External Name = IcyingLight (Internal Name = icyinglight:1)
External Name = IcyingLight 1 (Internal Name = icyinglight 1:1)
External Name = IcyingLight 2 (Internal Name = icyinglight 2:1)
External Name = Persian_Sword_1 (Internal Name = Persian_Sword)
External Name = Persian_Sword_2 (Internal Name = Persian_Sword_1)
External Name = Persian_Sword_3 (Internal Name = Persian_Sword_2)

3dcheapskate

Got it ! And it's so simple!

It's all down to whether or not there's an underscore in the 'name' and/or 'prop' field of the PP2

INTERNAL name

If the 'prop' field of the PP2 has an underscore in it then the suffix sequence is 1st = '_1', 2nd = '_2', 3rd = '_3', etc
If the 'prop' field of the PP2 does NOT have an underscore in it then the suffix sequence is 1st = no suffix, 2nd = ' 1', 3rd = ' 2', etc

EXTERNAL name

If the 'name' field of the PP2 has an underscore in it then the suffix sequence is 1st = '_1', 2nd = '_2', 3rd = '_3', etc
If the 'name' field of the PP2 does NOT have an underscore in it then the suffix sequence is 1st = no suffix, 2nd = ' 1', 3rd = ' 2', etc

That's not the whole story, but it's a good start.Here's a  couple more observations:

• Any ':1' type suffix on the 'prop' field in the PP2 is ignored when the prop is loaded
• A ':1' type suffix will be added to the internal name when the prop gets parented.. (But you WON'T see this suffix in the internal name on the Parameters tab). The number matches the ':1' suffix forall actors in the parent figure
• If the 'name' or 'prop' field in the PP2 ends with e.g. _4 then this is the number that the suffix sequence will start with.

3dcheapskate

Same query was posted
- on the DAZ Poser forum - http://www.daz3d.com/forums/discussion/77836/why-does-the-external-name-for-a-prop-sometimes-have-an-1-suffix/p1
- on the CGbytes Poser forum - http://www.cgbytes.com/community/forums.aspx?g=posts&m=125261
- on the RDNA Poser forum - http://forum.runtimedna.com/showthread.php?104756-Why-Does-the-External-Name-For-A-Prop-SOMETIMES-Have-An-_1-Suffix
- on the Renderosity Poser forum - https://www.renderosity.com/mod/forumpro/?thread_id=2901360

A couple of unrelated observations that other folks made on some of those threads inspired me to try a few tests, which are documented on the Renderosity thread