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...)

Generally that means there is a primary prop and this is a copy of it. copy _1, then _2 then _3 according to how many of the same props are in a scene.

"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."

Boni, I think Pete is referring to Poser's arbitrary use of underscore ( _ ) as space in some instances, and not in others. His post indicates that he's aware of the general use of numbering in Poser. ...perhaps opening up one of the original instances of a prop in a text editor and seeing if channels/actors are appended by a suffix (of either space type suffix) in their base state may have something to do with it? Often these numbers are hidden externally in the first loaded instance... As is often the case with loaded .cr2's and internal actor names being appended but not reflecting in the scene instance naming. This is all just long shot guessing for conversations sake on my part though, haven't tested.

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...

I've found that in figures that I've made that Poser usually appends the internal actor names with :1 when saved to the library. You would think there was some importance to this but I've noticed that deleting this numbering and : has no noticable ill effects on the figure's functionality (such as crosstalk or whatever). AFAIK it's just another one of those weird (and slightly irritating) things with Poser. Maybe somebody like Nerd or PhilC or NetherWorks would know? Maybe Snarly.

This also happens when you copy and paste node settings in the mat room.

Boni posted at 11:33AM Tue, 05 April 2016 - #4264153

This also happens when you copy and paste node settings in the mat room.

True, but there's no '_1' suffix - they start at '_2'. E.g. 'Image_Map' or 'Image_Map_2, or 'Image_Map_3', etc - never 'Image_Map_1'. Different programmer I guess ? ;o)

I've also noticed that copying and pasting a complete shader also replaces any manually modifed external name for the node - e.g. if I changed 'Image_Map' to 'Texture_Map' for my shader, then when the shader's copied it becomes 'Image_Map' or 'Image_Map_2, or 'Image_Map_3', etc - never 'Image_Map_1' though.

EldritchCellar posted at 11:43AM Tue, 05 April 2016 - #4264114

I've found that in figures that I've made that Poser usually appends the internal actor names with :1 when saved to the library. You would think there was some importance to this but I've noticed that deleting this numbering and : has no noticable ill effects on the figure's functionality (such as crosstalk or whatever). AFAIK it's just another one of those weird (and slightly irritating) things with Poser. Maybe somebody like Nerd or PhilC or NetherWorks would know? Maybe Snarly.

There is some importance/relevance to the :1, :2, etc, although it may be purely historical - I remember reading about it years back when I made my first Poser models. Something to do with avoiding crosstalk? That rings a bell, although I may be thinking of something else.

I also recall the advice that you should remove the :1, :2 from the internal names in the CR2 - at least for the sort of thing I was doing when I read the advice.

Also note that it's not saving things to the library that causes the ':1' etc to be appended. This little PoserPython script prints the external and internal name of every actor in a scene to the debug window, and you'll see that the :1 etc is there before you save the CR2... I think

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

Interesting - I think I've spotted something (thanks to a comment on another forum):

Compare this - no figure in the scene (printout is from the script in the previous post)...

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)

...with 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)

Still haven't got the bottom of this, but the SlicerSwords and IcyingLights are smartprops, and in the second example when they were loaded from the library they were automatically parented to Andy's hand. The PersianSwords aren't a smartprop and weren't parented.

So it looks as if parenting to a figure has something to do with it.

Also the :1 on the internal names seems to be something specific to figures, or props parented to figures.

I get this a lot as a creator & I don't think there's any rhyme or reason to it. When saving out props while working, Poser will often add the _1 suffix regardless of whether there is anything else in the scene or not. Even when it's a new scene, there's only a ground plane, & the prop's not parented to anything, Poser does that. I always have to end up editing the _1 & sometimes even a :1 out of the pp2 file by hand & it still shows up when I load the files. It's really rather annoying especially when I OCD out on making my props. I like consistency & Poser sure does like to be consistent with adding the suffixes.

3DFineries - I'm interested that you mentioned "When saving out props", much as EldritchCellar mentioned "when saved to the library".

Are you sure it's the act of saving that causes the _1 to be added, or is the _1 there in the external/internal name of the prop in the scene before you save? (and note that, as mentioned earlier, the 'Internal Name' on the Parameters tab doesn't seem to show the full internal name, specifically not the :1 suffix if it exists - you need to use PoserPython to see that)

I think there's a logical pattern emerging, but it needs more examples and I'm not there yet...

Default scene with Andy, loaded four SlicerSwordLH's (smartprops, same sword as my earlier examples). My script gives this data for the 4th Slicer:

External Name = SlicerSword_4 (Internal Name = SlicerSword 3:1)

I saved the prop both as smart and non-smart:

Saved as non-Smart:

{
version
    {
    number 9
    }
prop SlicerSword 3:1
    {
    storageOffset 0 0.3487 0
    objFileGeom 0 0 :Runtime:Geometries:VaL_Slicer:SlicerSword.obz
    }
prop SlicerSword 3:1
    {
    name    SlicerSword_4

Saved as Smart:

{
version
    {
    number 9
    }
prop SlicerSword 3:1
    {
    storageOffset 0 0.3487 0
    objFileGeom 0 0 :Runtime:Geometries:VaL_Slicer:SlicerSword.obz
    }
prop SlicerSword 3:1
    {
    name    SlicerSword_4

Not conclusive, but a good indication that the :1 internal-name suffix and the _1 external-name suffix when you save a parented prop are what was present in the scene.

My current guess on when the :1 suffix appears is that it's added when you parent a prop to the figure, and the value of the suffix will probably be the same value as the suffix for every actor on that figure. Time for a test.

(Of course, we mustn't forget that different versions of Poser may do different things... ;o)

Loaded the P9 default scene, deleted Andy, loaded 4 Slicers, loaded Andy, loaded another Andy. Parented the 4th slicer to the 1st Andy Parented the 3rd slicer to the 2nd Andy

Here's what my script gave me

External Name = SlicerSword_1 (Internal Name = SlicerSword)
External Name = SlicerSword_2 (Internal Name = SlicerSword 1)

External Name = Body (Internal Name = BODY:2)
External Name = GoalCenterOfMass (Internal Name = GoalCenterOfMass:2)
External Name = CenterOfMass (Internal Name = CenterOfMass:2)
External Name = Hip (Internal Name = hip:2)
External Name = Waist (Internal Name = waist:2)
...
External Name = SlicerSword_4 (Internal Name = SlicerSword 3:2)

External Name = Body (Internal Name = BODY:3)
External Name = GoalCenterOfMass (Internal Name = GoalCenterOfMass:3)
External Name = CenterOfMass (Internal Name = CenterOfMass:3)
External Name = Hip (Internal Name = hip:3)
External Name = Waist (Internal Name = waist:3)
...
External Name = SlicerSword_3 (Internal Name = SlicerSword 2:3)

Saving as non-smart props:

{
version
    {
    number 9
    }
prop SlicerSword 3:2
    {
    storageOffset 0 0.3487 0
    objFileGeom 0 0 :Runtime:Geometries:VaL_Slicer:SlicerSword.obz
    }
prop SlicerSword 3:2
    {
    name    SlicerSword_4

{
version
    {
    number 9
    }
prop SlicerSword 2:3
    {
    storageOffset 0 0.3487 0
    objFileGeom 0 0 :Runtime:Geometries:VaL_Slicer:SlicerSword.obz
    }
prop SlicerSword 2:3
    {
    name    SlicerSword_3

That seems to confirm that theory, although of course further tests may change that. But it seems a good start.

3dcheapskate posted at 7:02AM Tue, 05 April 2016 - #4264260

3DFineries - I'm interested that you mentioned "When saving out props", much as EldritchCellar mentioned "when saved to the library".

Are you sure it's the act of saving that causes the _1 to be added, or is the _1 there in the external/internal name of the prop in the scene before you save? (and note that, as mentioned earlier, the 'Internal Name' on the Parameters tab doesn't seem to show the full internal name, specifically not the :1 suffix if it exists - you need to use PoserPython to see that)

I think there's a logical pattern emerging, but it needs more examples and I'm not there yet...

I've opened PP2014. Nothing is in the scene except the light & the ground. When you import an object file, it imports with the name exactly the same as the saved object file.

Then, I add it to the prop file. Now, I start a new scene so there's no confusion in Poser. Now when you load that prop file, the _1 is automatically there.

Then when you manually edit out the _01 from the pp2 file & edit out the embedded geometry (in the case of a file for distribution), reopen Poser & then load the prop again.... It magically reappears.

Okay, I follow - and I can confirm that I get the same results. So yet another example to throw into the pot !

# File 'TheCube.obj'
# Blender v2.77 (sub 0) OBJ File: ''
# www.blender.org
o Cube
v 0.100000 -0.100000 -0.100000
v 0.100000 -0.100000 0.100000
v -0.100000 -0.100000 0.100000
v -0.100000 -0.100000 -0.100000
v 0.100000 0.100000 -0.100000
v 0.100000 0.100000 0.100000
v -0.100000 0.100000 0.100000
v -0.100000 0.100000 -0.100000
s off
f 1 2 3 4
f 5 8 7 6
f 1 5 6 2
f 2 6 7 3
f 3 7 8 4
f 5 1 4 8

PP2014(32bit) default scene, deleted Andy, imported TheCube.obj

External Name = TheCube (Internal Name = TheCube)

'When you import an object file, it imports with the name exactly the same as the saved object file.' - confirmed.

Saved this prop as 'TheCube.pp2'

{
version
    {
    number 10
    }
prop TheCube
    {
    geomCustom 
        { 
        ...
        } 
    }
prop TheCube
    {
    name    TheCube

Started a new scene, deleted Andy, loaded 'TheCube.pp2' three times

External Name = TheCube_1 (Internal Name = TheCube)
External Name = TheCube_2 (Internal Name = TheCube 1)
External Name = TheCube_3 (Internal Name = TheCube 2)

I also tried exporting one of my original test props as an OBJ, reimporting that, saving that as a new prop, and loading that.

Exported one of the Slicer swords as an OBJ, reimported it:

External Name = SlicerSword_3 (Internal Name = SlicerSword_3)

Saved as PP2

{
version
    {
    number 9
    }
prop SlicerSword_3
    {
    geomCustom 
        {
        ...
        } 
    }
prop SlicerSword_3
    {
    name    SlicerSword_3

New scene, deleted Andy, loaded 3 of theses

External Name = SlicerSword_1 (Internal Name = SlicerSword_3)
External Name = SlicerSword_2 (Internal Name = SlicerSword_4)
External Name = SlicerSword_3 (Internal Name = SlicerSword_5)

New scene, loaded 3 of these (not smartprops!), parented each to Andy,

External Name = SlicerSword_1 (Internal Name = SlicerSword_3:1)
External Name = SlicerSword_2 (Internal Name = SlicerSword_4:1)
External Name = SlicerSword_3 (Internal Name = SlicerSword_5:1)

Took a copy of 'TheCube.obj' and renamed it 'TheCube_7.obj', Imported that into PP2014 in a new scene with Andy deleted

External Name = TheCube_7 (Internal Name = TheCube_7)

Saved as 'TheCube_7.pp2'

{
version
    {
    number 10
    }
prop TheCube_7
    {
    geomCustom 
        { 
        ...
        } 
    }
prop TheCube_7
    {
    name    TheCube_7

New scene, deleted Andy, loaded TheCube_7.pp2 3 times

External Name = TheCube_1 (Internal Name = TheCube_7)
External Name = TheCube_2 (Internal Name = TheCube_8)
External Name = TheCube_3 (Internal Name = TheCube_9)

Hypothesis 1: A ':1' type suffix is added to the INTERNAL name of a prop when the prop is parented to the figure. The value in the suffix is the same value as the suffix for every actor on that figure. (I'm fairly confident about this one now)

Hypothesis 2: When a prop is loaded into the scene unparented its EXTERNAL name is the 'name' field from the PP2 minus any '_1'-type suffix (if present) plus an '_1'-type suffix following the sequence '_1' for the first prop of that name, '_2' for the second, '_3' for the third, etc. this seems to be true for every UNparented example so far, but needs more testing

Hypothesis 3: When a prop is loaded into the scene unparented its INTERNAL name is the 'prop' field from the PP2 minus any ':1'-type suffix (if present) minus any remaining '_1'-type suffix plus... and then it gets a bit more convoluted

I tried making TheCube_7 use an external geometry as I thought perhaps internal/external geometry may play a part. But it doesn't seem to make any difference

{
version
    {
    number 10
    }
prop TheCube_7
    {
    storageOffset 0 0.3487 0
    objFileGeom 0 0 :Runtime:Libraries:props:TheCube_7.obj
    }
prop TheCube_7
    {
    name    TheCube_7

External Name = TheCube_1 (Internal Name = TheCube_7)
External Name = TheCube_2 (Internal Name = TheCube_8)
External Name = TheCube_3 (Internal Name = TheCube_9)

Enough of that diversion for the time being. I'll return to that later (i.e. the PP2 'prop' field having an '_1'-type suffix, causing the incremental count on the internal name to start from a different number)

Back to my initial three test props (SlicerSword, IcyingLight, and Persian_Sword) to try and work out why the suffix on internal names of the first two follows the 'no suffix', ' 1', ' 2' sequence, while the Persian_Sword uses an underscore instead of a space.

What's different?

a) The Persian_Sword uses internal geometry,the other two use external. b) The 'prop' field of the Persian_Sword PP2 doesn't have a ':1'-type suffix, the other two have one. c) The 'prop' field of the Persian_Sword PP2 has an underscore in it,the other two don't. d) The 'prop' and 'name' fields of the Persian_Sword PP2 are identical, for the other two they aren't.

But also consider the tests with 'TheCube.obj'and 'TheCube.pp2'. It's internal name follows the pattern of the SlicerSword and IcyingLight. But in cases (a), (b) and (d) it matches the Persian_Sword...

So what happens if we add an underscore into the 'prop' and 'name' fields of our cube PP2 ?

{
version
    {
    number 10
    }
prop The_Cube
    {
    geomCustom 
        { 
        ...
        } 
    }
prop The_Cube
    {
    name    The_Cube

External Name = The_Cube_1 (Internal Name = The_Cube)
External Name = The_Cube_2 (Internal Name = The_Cube_1)
External Name = The_Cube_3 (Internal Name = The_Cube_2)

And as a reminder here's the original cube results from the earlier post:

{
version
    {
    number 10
    }
prop TheCube
    {
    geomCustom 
        { 
        ...
        } 
    }
prop TheCube
    {
    name    TheCube

Started a new scene, deleted Andy, loaded 'TheCube.pp2' three times

External Name = TheCube_1 (Internal Name = TheCube)
External Name = TheCube_2 (Internal Name = TheCube 1)
External Name = TheCube_3 (Internal Name = TheCube 2)

It looks like it's simply whether or not there's an underscore in the the 'prop' (and/or 'name'*) field in the PP2 !

*I'd guess just the 'prop' field

Looks like I've answered my own question.

With several nudges in the right direction from other helpful people. :)

...except of course that I haven'tanswered the original question,which was about the EXTERNAL name.

The presence/absence of an underscore in the INTERNAL name of the prop in the PP2 determines the format of the sequence of suffixes on the INTERNAL name:

• No underscore: 1st=no suffix, 2nd = ' 1',3rd = ' 2', etc

• Underscore: 1st = '_1', 2nd = '_2',3rd = '_3', etc

However, there doesn't appear to be any similar relationship for the EXTERNAL name...

Due to that little bit of confusion I'm going to restate the problem(images are from earlier posts).

Here are the relevant bits from the PP2 of three props:

Here are the results when I load three copies of each prop from the library: left - without any figure in the scene (i.e. all props unparented);right - with Andy in the scene, so smartprops parent to him.

The problem in the unparented (left) results, which I didn't notice, was that the internal names use two different suffix sequences. That's the answer I just found - it's down to whether there's an underscore in the 'prop'field of the PP2.

The first problem in the parented (right) results, which I also overlooked, was the :1 and :2 suffixes.I found the answer to that on the previous page - they appear for parented props, with the value being the same as the :# suffix for every actor in the parent.

The second problem in the parented (right) results is the fact that the EXTERNAL name for IcyingLight uses a different suffix sequence from the other two props. This was the original problem for which I started this thread.

It now seems to me that the best approach is to start with the IcyingLight PP2 and change it bit by bit until it's the same as one of the others.At some point the suffixes should change,and I should have the answer.

It's so obvious now - it simply depends whether or not the 'name' field in the PP2 has an underscore in it. Exactly the same logic as the internal name, despite what I said a post or two back.

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 ** (if a moderator decides that those URLs aren't permitted just let me know and I'll delete them. Note: it's only Renderosity where I have to say that)**

Since importing an OBJ and saving that as a PP2 seems to set the 'prop' and 'name' fields to the same value (which is basically the name of the OBJ file, but with lots of provisos, as indicated below...), and prompted by EldritchCellar's comment on another thread...

Importing two copies of various OBJs with the specified names into PP2014 with no figure in scene gives me these results:

The_Cube 1.obj
--------------
External Name = The_Cube1 (Internal Name = The_Cube1)
External Name = The_Cube1_1 (Internal Name = The_Cube1_1)

TheCube 1.obj
-------------
External Name = TheCube1 (Internal Name = TheCube1)
External Name = TheCube1 1 (Internal Name = TheCube1 1)

TheCube.obj
-----------
External Name = TheCube (Internal Name = TheCube)
External Name = TheCube 1 (Internal Name = TheCube 1)

TheCube_1.obj
-------------
External Name = TheCube_1 (Internal Name = TheCube_1)
External Name = TheCube_2 (Internal Name = TheCube_2)

TheCube1.obj
------------
External Name = TheCube1 2 (Internal Name = TheCube1 2)
External Name = TheCube1 3 (Internal Name = TheCube1 3)

TheCube3.obj
------------
External Name = TheCube3 (Internal Name = TheCube3)
External Name = TheCube3 1 (Internal Name = TheCube3 1)

TheCube 5.obj
-------------
External Name = TheCube5 (Internal Name = TheCube5)
External Name = TheCube5 1 (Internal Name = TheCube5 1)

TheCube_7.obj
-------------
External Name = TheCube_7 (Internal Name = TheCube_7)
External Name = TheCube_8 (Internal Name = TheCube_8)

TheCube_9876.obj
----------------
External Name = TheCube_9876 (Internal Name = TheCube_9876)
External Name = TheCube_9877 (Internal Name = TheCube_9877)

The Cube With Spaces 6.obj
--------------------------
External Name = TheCubeWithSpaces6 (Internal Name = TheCubeWithSpaces6)
External Name = TheCubeWithSpaces6 1 (Internal Name = TheCubeWithSpaces6 1)

The Cube With Spaces and an _ Underscore 8.obj
----------------------------------------------
External Name = TheCubeWithSpacesandan_U (Internal Name = TheCubeWithSpacesandan_U)
External Name = TheCubeWithSpacesandan_U_1 (Internal Name = TheCubeWithSpacesandan_U_1)

TheCubeWithQuiteARatherLongInterestingName_78.obj
-------------------------------------------------
External Name = TheCubeWithQuiteARatherLongInte (Internal Name = TheCubeWithQuiteARatherLongInte)
External Name = TheCubeWithQuiteARatherLongInte 1 (Internal Name = TheCubeWithQuiteARatherLongInte 1)

TheCu_8_beWithQuiteARatherLongInterestingName.obj
-------------------------------------------------
External Name = TheCu_8_beWithQuiteARatherLongI (Internal Name = TheCu_8_beWithQuiteARatherLongI)
External Name = TheCu_8_beWithQuiteARatherLongI_1 (Internal Name = TheCu_8_beWithQuiteARatherLongI_1)

It looks as if Poser takes the OBJ filename, truncates it to 31 characters if it's longer, and removes any spaces to get what I'll call a 'baseName'. if you save the imported OBJ as a PP2 this is the text it saves as both the 'prop' and 'name' fields (I haven't thoroughly tested that, but observations to date seem to confirm this)

I'm assuming that loading multiple PP2s created this way has the same results as importing multiple OBJs this way (once again not extensively tested, but observations to date seem to confirm this)

N.B. I think that using 'Edit > Duplicate' adds an extra level of confusion...