- Home /
Copy a script from one gameobject to another?
At runtime I want to be able to switch an item between completely different behaviours, which I think is best done by swapping out a script (inherited from a master 'ItemBase' class, e.g. Item_Wood, Item_Stone, Item_Car). The items have custom methods, so they require their own scripts.
So to switch a gameobject from 'stone' to 'wood'...
I can add a script:
InputItem.AddComponent<Item_Stone>();
(after using Destroy to remove the existing 'Item_Wood' script).
But how do I do this when I don't know beforehand what the scripts specific types are?
I want to be able to dynamically copy an ItemBase script (of unknown type) from one gameobject to another, something like this (the following code doesn't work):
ItemBase ibase = ObjectA.GetComponent<ItemBase>(); // ibase could be any class inherited from ItemBase
ObjectB.AddComponent<ibase.GetType>(); // want to add a class of the same type as ibase
The script will always be inherited from ItemBase, but I would not know beforehand what the actual script type is (it could be one of dozens of scripts, so hardcoding a switch statement is not something I want to do.
Or am I going about this completely the wrong way? The main result I'm after is to morph objects by interacting with each other, but in a very dynamic way (e.g. an item could change in hundreds of different ways based on different interactions). I want to keep my game objects intact, but change their behaviours completely by switching scripts.
Answer by Aeron0 · Jul 01, 2014 at 03:22 PM
Instead of having scripts, couldn't you just make a base class and inherit the other classes from that? Then make the inherited class methods virtual so the inherited classes could have their own custom methods.
By setting it up that way you could throw any of those classes in a base class reference variable. Maybe something like:
public class Item
{
public GameObject myGameObject;
// Additional Variables
public virtual void Method1()
{
}
public virtual void Method2()
{
}
}
public class itemWood:Item
{
// Variables
public override void Method1()
{
}
public override void Method2()
{
}
}
public class itemStone:Item
{
// Variables
public override void Method1()
{
}
public override void Method2()
{
}
}
Thank you. This is sort of how I initially tackled it, then got lost when I wanted public fields for the inspector. But I can keep the public fields in a different script as they are generic to all objects. I think I overthought the problem! This solution should work.
thanks
You could also create an override method for each inherited class that would create the same class as it. In that way if you randomly created one of the inherited classes and referenced it and wanted another reference to have that same type of class but a completely different object itself you could and wouldn't need to know anything before hand or need a big switch statement.
// itemA is randomly itemStone but we wouldn't know that at runtime
// itemB wants to be the same thing as itemA but we dont know what itemA is
public itemB;
//If we have an override method that creates the same object then we don't need to know or have a switch statement.
itemB = itemA.CreateItem();
itemB is now the same type of object as itemA
Example
public class itemStone:Item
{
// Variables
public override void $$anonymous$$ethod1()
{
}
public override void $$anonymous$$ethod2()
{
}
public override Item CreateItem()
{
Item item = new itemStone();
return item;
}
}