koobas.hobune.stream
Adding score to GUI Text via another script/variable.
I'm a little confused as to how the GetComponent works in terms of accessing a variable and changing its' value.
What I need is seemingly quite simple, the idea is the following.
I have a GUI text called "GUiScore". It has a "Text" field which I want to be able to access from another script. So far I made it so that this GUiScore is linked to a reference script and it works if I code something within that script (Script A). Script A also has a public variable, which is the GUIText variable.
Now on another script (which is a system I made to count score) (Script B), I want to send the information of a variable within Script B, into that variable called GUIText from Script A. How can I access GUIText variable from Script A and change its' value/text?
I don't know the code for it... I tried things like: GetComponnent(ScriptA.referenceVariable) = scoreVariable; and so many other weird things that I'm sure aren't correct, because I keep getting errors.
Thanks.
First you need to find Script A. You can either do this by setting it as a public variable on Script B, like you did with the GUIText on Script A, or you can find its GameObject and then the script by first using the built-in Find() method, e.g.:
GameObject scriptAGameObject = GameObject.Find("Name of Game Object which has Script A");
So, now you have Script A's Game Object, and now you need to find the Script A component on the GameObject, like this:
ScriptA scriptA = scriptAGameObject.GetComponent(ScriptA);
Now you have a reference to Script A, and you want to change a GUIText attached to this script. You do this by accessing the name of the attached GUIText (I assume that's what you were trying to do in your question):
scriptA.referenceVariable = scoreVariable;
I didn't know how to properly utilise the "Find()" method you showed, nor did I know how to do the first suggestion being to make Script A as a public variable within Script B. I don't know how to assign it, for example:
public var ScriptA : String;
Is the above correct?
Either way, I simply placed Script B onto the GUI Text object, and declared the variable within that one script.
Thanks for your help.
All right, maybe you should take a look at some basic Unity tutorials then, e.g. here: http://unity3d.com/learn/tutorials/modules
However, you would assing it like this:
public var myScript : ScriptA;
Then you can use myScript to access stuff in ScriptA. Either way, if your question is solved please accept an answer or close the question.
If I understand this correctly the textfield is in the GUI and when you access it, it should already be shown on screen starting with probably a score of 0.
in ScriptA I would make the public variable static.
public static GUIText GUITextVariable = 0;
so in ScriptB I would have
ScriptA.GUITextVariable = score;
I'm not sure I agree with this because then you would not be able to use ScriptA on multiple game objects. I know it might be unlikely to use a score script in two places, but it depends what's in the script. (thinking split screen, mutliplayer..)
I agree with @hamstar, you should not make a variable static just to make it easier to access, that's not why you use the static declaration.
Score can only be used once so it might as well be some kind of singleton.
For multiplayer use Score1, Score2, etc.
I know static should not be used lightly. But this would be a case where I would use it and not for the easy to access part.
@matt don't make assumptions that easily.
There's no reason not to re-use such a script several places.
In a single player game I'd like to have my score variable as a singleton.
For multiplayer, as I mentioned, Score1, Score2, etc. comes to $$anonymous$$d as a solution there.
Everyone is free to agree or disagree to this solution.
I agree to the fact that this solution only works in specific cases and that people should not use static just because it's easy to access.
A game should be able to execute without a gui at all - that is, all of the logic and variables that control game execution should have zero awareness of a GUI.
The smallest exception to this are actions that are fired from a GUI of course, but even then, the actions should be called from GUI, but not need data from the calling.
If you can write your game like this, it means that each object that "owns" some piece of data, like the health of a player, the ammo reserve in a weapon, the name of a level, etc, will expose some method to retrieve that information and will update that information in its own container.
Using ammo as an example, it means that there (likely) be a "Weapon" class that contains information about the weapon, along with something like:
public int GetCurrentAmmo(){
return this.ammoCount;
}
Then, in the GUI, all you do is when it's time to display the ammo, you call the appropriate method, such as: Player.CurrentWeapon.GetCurrentAmmo() and put the result on the GUI as appropriate.
A GUI is a "peek" in to variables belonging to the runtime execution of the game. No part of the game should be modifying the GUI directly unless that part of your game is part of the GUI. That means if you want to say - pause the game from input, you should change some state to "Paused" and the GUI should be able to see that state and show the appropriate paused gui.
By maintaining this level of segregation, you will greatly ease your debugging and be able to more easily change GUI elements as your game matures and you realize changes in scope of your game.
Thank you for the heads up, I didn't know about this before hand.
I'm new into the program$$anonymous$$g field, and want to make my own indie-game via Unity. This kind of information is great, and I suppose it'll take much longer than I thought (with my little to no skills).
