koobas.hobune.stream
How to address scripts without knowing their names?
I try to build a library of game objects of instruments that will, later on, be used in many different configurations to animate and simulate simple Flash builds.
The instruments, being interactive, will have a variable that can be set from the Inspector as, e.g. FROM or TO or both, depending if the object only inputs, outputs or both.
I know the name of the game object but I don't know the name of the script. How can I address that? The documentation writes about GetComponent but that requires to know the name of the script ... unless I missed something.
Alternatively, I can call all the scripts for e.g. "script" and place them in different folders, together with the object, textures, etc. But, is it wise?
My question is essential as what I try to organize now is what I will have to work with for the years to come. I want the architecture to be correct now, before I end up with a lot of objects that need restructuring.
Thanks in advance,
Michel
First of all, thank you, everyone, for your answers. You are very kind, especially when you write codes to help me, it takes time, I know!
Second, ... I am 65 years old and I barely understand. This should be done by someone younger in my company but ... 3D is so much fun that I want to do it myself, even if it takes all my evenings and week-ends! ;-)
Third, I am terrible at explaining what I want perhaps because I am not sure I understand it myself! ;-)
No, reflections won't work with Flash and that is also valid for most of the fancy stuff in Unity3D. Yes, I will look at Send$$anonymous$$essage that I already use in two occasions.
Perhaps I am making things more difficult than what they need to be. But, imagine a pump connected to a valve. I drag a pump on the scenery, give it a name. I drag a valve and also give it a name because I will need many valves and I must be able to identify them by name. So, I know the names of the GameObjects but I don't know the name of the script because next time I might not connect the valve to a pump but to a fuel tank. So, when I write e.g. the codes: var From:GameObject; and I have selected it in the Inspector window, I can do my business to read its variables if I knew the script name. One solution, though, is to have all the scripts of objects that can be connected, called e.g. mainScript.
Sen$$anonymous$$essage would work to send messages downstream of a flow. But then, it is often the object downstream that needs to look upstream to know what to do next.
Cheers,
$$anonymous$$ichel
PS: Am I answering in the correct window of the forum, to address everyone? Excuse an old newbie! ;-)
Send$$anonymous$$essage will work any direction, it is just sending a message to a particular object. Then the compiler goes through all the scripts of the object to find the matching function. That is why it is slow and should be avoided. I am just confused on why you should not know the name of the script, if you implement the program, you should know it. If you think you won't remember, make a documentation.
Yes it will go both directions and I use it already to find by a Raycast which instrument the user is trying to interact. But I find it simpler if I can directly read a variable if I know which script it is. The reason I may not know the name of the script is this:
I may have a valve object with a script named, valve. It can be connected to say, a pump. But perhaps I will need another valve that I will call rotaryValve, also being able to connect it to a pump. This may contain, in addition of the valve variables something like, maximumRevolution. If they all have a script called the same, I can then have the pump to read the valve script without bothering about the type.
The thing is: I am the art director of a company making online CBT for seafarers. In the future, the actual material will be made by our subcontractors in U$$anonymous$$, $$anonymous$$nd, India and The Philippines. But if something goes wrong, they'll blame me. I have to set the rules needed to build a library of maritime process objects that can be re-used for many years. Since my company doesn't sell but lease the CBTs, we must be able to update them easily on a yearly basis.
Thanks for your interest in my little problem! ;-)
Cheers,
$$anonymous$$ichel
There are many ways to go about this.
You can use **Interfaces**. If all your instrument scripts implement an IInstrument interface you can reference them like that, without having to know their specific names.
Interfaces allow you to ensure the script you're referencing has the defined behaviour and properties, such as input/output properties, and methods that are shared by all of your instruments, while each of them has it's own implementation of the interface's requirements.
Another way to go about it is with an **Abstract Class**. It's very similar to an interface, with the major difference being your script can't inherit from multiple abstract classes (note that Interfaces are implemented while abstract classes are inherited). From my experience they behave more nicely with Unity's serialization and inspector than interfaces, so it's a viable option.
Another way altogether is simply create a base class and have the scripts inherit from it and simply **override** it's methods with an implementation of their own. This allows you to define default behaviour straight in the class definition stage and doesn't force you to implement anything in the inherited classes, which is arguably worse practice than the previous options.
On another note, you may also want to take a look at **Generics**, another powerful feature of C# that comes in handy quite often. :)
Thank you very much but, with only experienced in Flash AS2, I started Unity3D writing JavaScript that I find closer to ActionScript. What you suggest is ... beyond my capacity of understanding. ;-(
@asafsitner, why is a base class with overrides "arguably worse practice than the previous options."
That's why it's arguably ;) If you develop all subclasses yourself it's not really a problem unless you can't remember your own implementation. When you provide the base class "as kind of an interface" and want others to write subclasses it might be a problem. But again, it depends on the case.
But this solution would mean that in the end you know the script name since you implemented it but for some reasons I cannot explain, he is not able to know the script name before hand. So the whole Interface/Abstract class is somehow not applicable here.
@fafase - While this solution doesn't answer the question in the header, it answers the actual question, in the body.
Ins$$anonymous$$d of calling all his scripts 'mainScript' and placing them in different namespaces, he could just as well make them all implement the same interface or inherit the same base class (abstract or not) and refer to that.
I think it's a better approach to what he is seeking - an architecture.
