Difference between revisions of "Talk:CreateFullActorCopy"

From the Oblivion ConstructionSet Wiki
Jump to navigation Jump to search
imported>Scanner
m (inventory loss on guard copies)
imported>HawkFest
Line 42: Line 42:


::::::The possibility for cutscenes is intriguing. Cool idea.
::::::The possibility for cutscenes is intriguing. Cool idea.
:::::::--[[User:HawkFest|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. --[[User:Scanner|Scanner]] 07:22, 8 October 2007 (EDT)
: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. --[[User:Scanner|Scanner]] 07:22, 8 October 2007 (EDT)

Revision as of 02:14, 7 December 2007

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)