Talk:CreateFullActorCopy

Dragoon Wraith TALK 13:20, 5 July 2006 (EDT): Does this simply create a new Reference to the same Object, or does this create a new Object that is a duplicate of the original? (i.e. if I use Object-changing function on a copy, will it affect the original)

Also, anyone know a good way to copy over the factions and things that the base has, to create a true duplicate?

ShadowDancer 10:32, 6 July 2006 (EDT): Well short of writing a script that goes through all of the factions and does a GetInFaction & GetFactionRank/SetFactionRank on the CreateActorFullCopy I can't think of an easy way to do it. Interestingly enough, while the CreateFullActorCopy may not have AI Packages, they do have the combat packages and spells hardcoded into the specified actor. Leaving out that one tab on the actor is a bit odd if you ask me, though I suppose it had to do with what they thought they were doing when they made the game. If you need the dialogue, I haven't a clue as to how you would add that onto a copy since I don't see how you could find out the packages that the actor originally had.

Note - I have to add the following fact for just having tested it: I used CreateFullActorCopy on my own PC, then engaged into combat. After killing that copy, a message told me that I was thrown out of the Thieves and Mages guild as I killed a "guild brother". In conclusion: it seems that faction parameters are also copied. --HawkFest 23:19, 8 October 2007 (EDT)

The faction+factionranks get copied indeed. After a running around a while I checked the clone again and the faction rank was -1. This is strange because factions are considered to last on the target. Maybe this is the reason why at first it looks like factions and ranks don't get copied. (Tested this with casting a faction on the original and reading the faction with a spell from the clone - immediate result showed clone had rank, later clone had rank -1) --Scanner 15:00, 9 October 2007 (EDT)

Additionally, as long as you get a reference variable to the copy, you can pretty much do whatever to the copy without affecting the original from what I found by experimentation with this. Changing the name doesnt affect the base copy or the original in the game from what I have seen (I created an activator to duplicate an NPC reference though). Mileage might vary in a spell script since scripts sometimes have odd effects for no apparent reason. I did a SetActorFullName and a RemoveAllItems on the copy with no effects on the original in the same room. It essentially creates a new reference to the base object minus the dialogue and AI functions from what I can tell. I still have no idea why it wipes those other than possible questing conflicts that the dialogue may cause when talking to two copies of the same actor.

ScriptName Duplicate

Ref ActorRef
Ref DoOnce
Float Timer

Begin OnActivate
   If IsActionRef Player == 1
      Set ActorRef to PriorMaborelRef.CreateFullActorCopy   ;Creates actor copy
   EndIf
End

Begin GameMode
   If Timer >= 10 && DoOnce == 0
      ActorRef.RemoveAllItems                    ;Removes items only on copy
      ActorRef.SetActorFullName "Idiot Savant"   ;Changes name only on copy
      Set DoOnce to 1
   Else
      Set Timer to Timer + GetSecondsPassed
   EndIf
End

Design decision I suppose. When the copy has to be independent from the base (which is a very good thing) You either need a flag that determines whether to use the base or not and check for this flag in each command that modifies the base, or you simply create a copy that isn't linked to the base. GetIsID tests for the ID of the base-object and when the base object isn't the same, the dialogue won't apply.--JOG 12:40, 6 July 2006 (EDT)

ShadowDancer 12:53, 6 July 2006 (EDT): Pretty much what I figured towards the end. Although then the question becomes why bother to make a way to copy an actor in the first place? Still, I hope that what I found out is of some use to Dragoon Wraith TALK.

I'd say mainly for the Skull of Corruption. Also we now have the posibility to make scripted cutscenes that involve the player...--JOG 13:00, 6 July 2006 (EDT)

ShadowDancer 13:15, 6 July 2006 (EDT): OK, I would say that that is a good point about the Skull of Corruption. I don't know much about cut scenes so that thought never occured to me, although now that you mention it, it makes perfect sense. In fact, I never really thought much on how to produce a cut scene. Hmmm... so that is where you would use a look command I imagine... Now I have something else to work on LOL!

Dragoon Wraith TALK 15:13, 6 July 2006 (EDT): Thanks guys for looking into that for me. I've been scripting without Oblivion for a few days, and I'd written a few thousand lines before I read that SetActorFullName effects the object instead of the reference, and I kind of paniced. Nice to know that I can work around it... though it'll be a major headache, now. Thank you very much.

The possibility for cutscenes is intriguing. Cool idea.

--HawkFest 02:14, 7 December 2007 (EST): Also for summoning creatures? Given that you verify/set the copied creature's faction depending of what you want to do with this new base. So instead of creating new static base refs from the CS, you can dynamically create a new base creature from an already existing base within the game itself. So if you'd like that Boss from this quest to be available for summoning in another scenario (under another name that you'd change as shown in this discussion)... I have a question although I am not sure of what I'm talking about : does it leaves a trace after a DeleteFullActorCopy (or a kill + game reset), cluttering the save game as does the PlaceAtMe command? I guess not since it will create a new base ID+ref (not only a new ref to an existing base) every time it is called...

I've tested SetLevel and SetAV on FullActorCopies against original actors and found out it wouldn't affect the original (although it should). So I assume a FullActorCopy has its own ObjectID and is persistent until you delete it. Moreover the FullActorCopy holds the true values for level, class, attributes and skills. Just don't try to use DuplicateNPCStats to get attributes and skills back. You'll have to copy them back step by step. --Scanner 07:22, 8 October 2007 (EDT)

Another test reveals that Essential Flags get copied too. Using SetEssential Tests on a few actors and clones reveals that the BaseActorID of the clones ist just one below the 1st-Clone's RefID. (SetEssential worked perfectly with this addressing scheme - although not tested massively) --Scanner 15:00, 9 October 2007 (EDT)

About Inventory on copies - using the GameDaysPassed I checked what happened to guard copies after a few days - they've lost all inventory they've got from the original. Might be true for all actors that auto-level. --Scanner 12:55, 16 October 2007 (EDT)

---

GuidoBot 17:02, 12 October 2006 (EDT) One reason to use CreateFullActor copy is so you can delete them later. This is a way around the (3-day) persistance created with PlaceAtMe <actorOID>.

Another related note is that although you can make a copy of the player this way, for the sake of saving stats for example, DuplicateNPCStats does not work for copying them back to the player at some later date. (Not that the command name implies that you ever could.)

Can't agree with that - DuplicateNPCStats recalculates the attributes and skills (using level and class) before it applies them. So you can only be sure for level and class if your target doesn't match the auto-calculation values. --Scanner 07:22, 8 October 2007 (EDT)

---

Anyone know why a "CreateFullActorCopy" creature does not do damage with physical attacks?Xilverbulet 16:27, 22 March 2008 (EDT)

Your creature wouldn't happen to be scripted and have a DeleteFullActorCopy function running on it under certain conditions?

I am currently trying to iron the kinks out of a combatant summoning activator where I can dispose of any corpses, its not going extremely well but for a bit of debug I coc'd to the dummy cell that they were in and they did no damage to me, but did to each other.

My complete script is as follows:

scn RSEntertainmentRoomSummonedActorScript

;applied to all summonable actors in the entertainment room
Ref Self

Begin OnActivate
Set Self to GetSelf

If Self.GetDead == 1
 MessageBox "You have disposed of the corpse."
  Self.Disable ;call this line an insurance policy, probably not needed but meh
   Self.DeleteFullActorCopy
endif
End

If any similarities exist between our scripts I would like to know of them.

--Antares 07:41, 14 October 2008 (EDT)

CreateFullActorCopy /= PlaceAtMe Discussion

Ok so at present we (I am, at least) are under the assumption that FullActorCopy's can be destroyed/removed/purged using the DeleteFullActorCopy function. What I am getting at is, what about the equipment of an FullActorCopy?
Say you make a copy of an NPC and kill it, they drop the weapon they were wielding. Would that weapon effectively be equivalent to one that was created using PlaceAtMe? Any thoughts/wisdom would be very much appreciated.
--Antares 23:05, 15 October 2008 (EDT)

Yes, the dropped item would have the same characteristics of a PlaceAtMe’d item. But, actually, it is worse: from what the page says, CreateFullActorCopy duplicates (creates new Base Records of) all items in the inventory.

OBSE 16 will solve the problem of removing the Reference Record created by PlaceAtMe or by a clone dropping its cloned weapon, but there is no way, AFAIK, to remove/destroy the Base Record of items created by CreateFullActorCopy or DuplicateAllItems. - QQuix 01:49, 16 October 2008 (EDT)

My worst fears have been confirmed! IMHO that is important information, I will update the article to include this information. I have an idea on how to remove such items though, before posting (as I wasn't sure that I really wanted to know an answer to my question) I thought about how it might be possible to purge them from the game. I remember seeing a beth employee post about the memory management code in the game clearing out disabled items and was going to use that as a reference (I posted the relevant parts of the conversation here.

Anyway onto my possible solution, if you could take any weapons that "fall" from a COPY and Remove them back to the COPY's inventory (using their ref as the TargetContainerID) as long as they are placed back inside the COPY's inventory before they are deleted they should be purged along with the COPY when DeleteFullActorCopy is called.

--Antares 05:27, 16 October 2008 (EDT) (^^really hoping that works^^)

I found the above method to be problematic in that I could not get the weapon to add itself to the copy to be deleted. However I bear extremely (I hope) good tidings. Another room in my mod is a library that has untakable versions of almost every literary piece in TES:IV, should the player use the grab key and really mess up the room, or cast spells at the books you can end up with books everywhere. To combat this I used a ResetInterior function from a remote cell to "clean" the library. I met with success in the implementation of this function and the books were all returned to their original locations.

Upon meeting my current problem I thought the answer might lie in my library - funny that. So I selected my FullActorCopy in the console window, coc'd to the library, moved him to my location, smote the FullActorCopy and selected his fallen weapon in the console window. I then proceeded to leave the cell and use the "Clean Library" Activator, upon returning to the cell the weapon was gone and its reference was not accessible in the console window.

This leads me to the conclusion that such objects are destroyable using the ResetInterior Function and to so merely requires that you set up a dummy cell, move all the junk there and then Reset the Interior. Can anyone confirm this?

--Antares 07:49, 16 October 2008 (EDT)

In this matter we have to make very clear whether we are talking about Base Records or Reference Records:

Reference Records are created every time a dynamic item shows up in the world, either dropped from an inventory or created with PlaceAtMe. These records should be removed when the item is moved back to an inventory, but, under some circumstances, they are not removed and will stay in your savegame forever. OBSE 16 will include a function to remove these records, so future modders can make sure their mods wont cause this kind of bloating. Note that the fact that the item disappeared from view and its reference is no longer valid DOES NOT guarantee that its record has been removed from memory.

Base Records are created dynamically by CreateFullActorCopy, DuplicateAllItems and CloneForm (any others??). There is no way to remove them from the game, AFAIK. So every time one of these functions runs, some bytes are added to the game. Any mod that runs these functions as a result of a player action will cause bloating if the player is allowed to do such actions unlimited times. Note that this has nothing to do with PlaceAtMe. PlaceAtMe does not create new Base Records.

Now, back to you example: the dropped weapon may be moved to any NPC inventory with “xItem.Activate xNPC 1” and the Reference Record should be destroyed. But there is little you can do about the Base Records created by CreateFullActorCopy. The most effective technique to prevent this bloating is by reusing the Actor/Items (instead of a create-destroy cycle), which requires a rather complex scripting (worth an WIKI article, btw).

Disclaimer: half of what I said is theoretical, as I have not reached this phase in my bloating tests. - QQuix 18:58, 16 October 2008 (EDT)

Ah, thanks for that, I was confusing the issue, I just realised that I don't have to worry about new base records for their inventories (and in part, I was already doing that in fact) as I can add them to the FullActorCopy as I see fit when I summon them. You'd think that complications such as these would warrant a patch from Bethesda. PlaceAtMe does not create new base records? So CreateFullActorCopy is in fact a much more malicious function?
--Antares 21:58, 16 October 2008 (EDT)

I understand you clone an NPC that has an empty inventory. That reduces the bloating potential. But if you devise a way to reuse the same NPC over and over, it would be much better. Or maybe a single CreateFullActorCopy to create ONE new Base Record, followed by PlaceAtMe to create new instances of it.

PlaceAtMe does not create new Base Records. It creates a new Reference to the given Base Record, e.g. , “PlaceAtMe Apple 1 0 0” just creates a new apple in the gameworld, not a new kind of fruit. And yes, in this sense, CreateFullActorCopy is worse: it does use more memory, as it creates both a new Base Record and a Reference to it.

But, actually, this is not the point. The point is whether you will do (or have the potential to do) a create-discard cycle repeatedly, so the bloating adds up to noticeable sizes. I suppose that’s why PlaceAtMe got so much attention: it seems that modders where using it indiscriminately in summon spells.

In other words: repeatedly creating useless data in the savegame is bad! It is bad if you add 150 bytes per cycle! It is also bad if you add 60 bytes per cycle! - QQuix 00:03, 17 October 2008 (EDT)

I am confused now. Are you saying that DeleteFullActorCopy doesn't work like it says it does in the article? And are you also saying that PlaceAtMe's are safe to use as they can be "cleaned" from the game more easily?

A whole element of my mod rides on being able to have an undefined (limited of course by common sense) number of actors in the given situation. Actually specifying a defined number of each potential actor and having my script use each in succession will be a mighty pain in the behind.

--Antares 08:23, 17 October 2008 (EDT)

As I said, some of it was theoretical and I was relying on reading many times that Base Records could not be removed from the game.

So I did some quick tests with Create/DeleteFullActorCopy: Created and deleted 100 copies of an NPC, empty and full inventory. Conclusions:

• DeleteFullActorCopy removes both the Base and the Reference records of the NPC >> No bloating copying+deleting empty NPCs
• DeleteFullActorCopy DOES NOT remove any/all/some (??) records of the duplicated items in the inventory >> bloating if the copied NPC has items in the inventory.

As for PlaceAtMe’d items, I had already done a lot of tests (reported here) and the conclusion is that the records can be removed with “xItem.activate xNPC 1” (and/or the new DeleteReference function included in OBSE 16).

So you should be fine with:

• Creating+deleting empty NPCs with Create/DeleteFullActorCopy
• Adding inventory items with AddItem
• Removing any dropped item with “xItem.activate xNPC 1” and/or DeleteReference. Note that xNPC may be any NPC, not necessarily the one that dropped the item.

QQuix 12:25, 17 October 2008 (EDT)

I found that when using this function on a NPC it does not copy the NPC's Aggression, Confidence and Energy. Instead, the NPC has Aggression 5, Confidence 50, Energy 50. Since I was creating a summon spell, I used ModAv to set the Aggression higher in the spell script. Note that for copying creatures, this is not necessary - probably because their default Aggression is higher than 5.--Limorkil 17:42, 19 October 2008 (EDT)

@ QQuix, that is really good news, the way I'm doing things at the moment should be entirely safe then. I really appreciate your research, I didnt like the prospect of removing that entire theme from my mod.

@ Limorkil, I too have noticed that those values don't get copied across, I think the article should make note of that. Seeing as how both of us have encountered this, I think we can say that this is fact and make a note in the article.

Well as I see it, the topic of discussion has been resolved, and has been quite the educational experience, thanks for all your input guys. Unless of course someone knows better on AI value discrepancies when using CreateFullActorCopy.

--Antares 02:52, 20 October 2008 (EDT)

---

About the changes I made - JGvardija

1. CreateFullActorCopy finds leveled item lists in the inventory of the actor and duplicates them together with everything else. This results in them showing up as <Missing Name> in the copied actor's inventory and as missing meshes if dropped on the ground. I'm not sure if this should be tested more? This post suggests that this also happens with items that are flagged as unplayable, that is not something I have gotten around to test yet.

2. The attack damage value on the copied actor is often wrong. This often results in creatures dealing no damage (Brown Bears for example). The tests I made using OBSE's GetAttackDamage:

• Actor: CreatureXivilai Original value: 15 Copied actor value: 0
• Actor: CreatureWolf Original value: 5 Copied actor value: 0
• Actor: CreatureBearBrown Original value: 44 Copied actor value: 0
• Actor: LL0VampireCrusader100 Original value: 0 Copied actor value: 0
• Actor: BanditMeleeMale4A Original value: 0 Copied actor value: 0
• Actor: VampireAgent2 Original value: 0 Copied actor value: 0

This suggests that this only happens to creatures and not NPCs (NPCs don't use the attack damage attribute?), but I guess more testing should be done before that conclusion could be reached.

Notes

Added a few notes about what happens when you use this on a creature or on the player. :P --Relax and Play 19:15, 5 January 2009 (EST)

Skeleton army mod

So, after reading this article and this one: http://cs.elderscrolls.com/constwiki/index.php/User:QQuix/On_Dynamic_Items_and_Savegame_Bloating#Adding.2FRemoving_items_to.2Ffrom_containers

i would wish to know if this way of doing is clean:

1) use the function createfullactorcopy on a skeleton with an empty inventory.

2) use the function additem weapdaedricsword 1 on the skeletoncopy so that he has a weapon.

3) use the function removeallitems on the skeletoncopy to destroy the weapdaedricsword.

4)use the function deletefullactorcopy on the skeletoncopy.

ps: sorry for my bad english feel free to edit :)

I'm not certain that Create/DeleteFullActorCopy have ever been thoroughly tested. That said, assuming they work correctly, yes, that should be fine. AddItem does not create a reference and therefore does not add bloat. And RemoveAllItems is a common way of getting rid of bloat (as documented by QQuix)

Dragoon Wraith TALK 13:48, 27 April 2009 (EDT)

A better option might be to simply use placeatme with a leveled list that contains the skeleton that has static equipment, instead of creating a copy. Although this may seem like a worse idea given the bad reputation placeatme has, calling removeme on placeatme'd actors, and not giving them any scripted items seems to alleviate all unusual bloat. Using a leveled list to create the skeleton, instead of the actual reference is just there for extra protection to ensure that the skeleton will be cleared upon next cell reset and to keep the skeleton from having any persistence. Createfullactorcopy is designed mostly for use with NPCs or instances where the type and appearance of the actor to be copied cannot be known beforehand.--Vagrant0 02:08, 7 November 2009 (EST)