koobas.hobune.stream
Making script object without declaring script name
I want to access a non-specific script. That script's name depends on the object's tag;
for example if the tag of the object that holds the script is "Door1", script's name will be "interactScriptDoor1" and if the tag is "LockedDoor", the script's name would be "interactScriptLockedDoor". Note that these scripts are already made and named.
I'm attempting to call these scripts from another script on another object, which works fine. The problem is that I have to make them all separately: I always have to declare the type by the name of the script: For example:
private interactScriptDoor1 launchItem1;
private interactScriptLockedDoor launchItem2;
...
and then:
launchItem1=targetedObject.GetComponent<interactScriptDoor1>();
launchItem2=targetedObject.GetComponent<interactScriptLockedDoor>();
The point is that every object has only one interact script; What I wish to achieve is something like
private Script launchItem; //script not being any existing script(only type)
and declare it with:
launchItem=targetedObject.GetComponent("InteractScript"+targetedObject.tag);
The problem is that I can't declare launchItem without declaring it with specific script in the first place. If anyone wonders why would I want this, it's for avoiding constantly updating interaction script when new types of object appears. Please help.
You cannot get where you want to go with this approach. That is, it is possible to accessing objects generically as a Object class or perhaps more useful, a MonoBehaviour. And you can use the string form of GetComponent() of get the component. The problem is that the string from returns something of type Component. So you would need to cast the resulting reference to some type. To make that happen, you would have to know the type. And that kinda defeats the purpose of what you are trying to do. Here are the commonly suggested (on UA) approaches to solve the problem I think you are trying to solve:
Having a base class and deriving the individual enemy behavior by overriding.
While technically possible, this is a bad idea.
Consider alternative ways to structure your code.
Use inheritance. Have a parent script called interaction and have door1 and locked door inherit from it. Implement any common functionality on the interaction script. Then you can use get component on the interaction script, and get the appropriate script.
Use interfaces. Result is almost identical, though you have to do some trickery with GetComponent
Use send message to achieve the same functionality on different components. Main downside here is typos are really easy
