Jump to content
Unity Insider Forum

Auf die Variablen eines Anderen Scriptes bei verschiedenen Objekten zugreifen?


Helishcoffe

Recommended Posts

Hi,

Wie kann ich auf die Variablen eines skriptes von einem GameObjektes zugreifen?

Da die Variablen sich verändern und bei jedem Objekt anders sind habe ich nun das Problem, dass ich nicht weiss, wie ich auf ein Ganzbestimmtes Objekt mit den Bestimten variablen.

 

gameObject.GetComponent("ObjectProperties").Health

 

klappt leider auch nicht. ICh habe nähmlich im Script "ObjectProperties" eine static variable "Heatlh".

Aber scheint nicht zu funtzen.

 

habt ihr da eine Idee?

 

lg timtrucker

Link zu diesem Kommentar
Auf anderen Seiten teilen

static klingt irgendwie falsch in diesem Zusammenhang, wieso static?

 

Der Übersich halber solltest du Übrigens Variablen nie mit nem Großbuchstaben beginnen lassen.

 

Dem wÜrde ich gerne wiedersprechen solange es sich um public Fields/Properties handelt, aber das ist eine Frage des eigenen Stils und ich bevorzuge da klar den MS Stil von C# ;)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Einige Dinge will ich noch ergänzen:

 

Vermeide möglichst häufig static Variablen zu verwenden. In deinem Fall werden dies evtl. die Health des Spielers sein, aber was wenn du es jetzt erweitern willst und lokal (oder Online) mehrere Spieler zulassen willst?

Bei static hättest du da dann ein Problem, denn static bedeutet, dass es es nur genau einmal gibt. Ich würde dir daher raten static zu entfernen, dann kannst du auch so wie in deiner Nachricht gepostet darauf zugreifen.

 

Des Weiteren würde ich public Variablen und Properties groß schreiben...weiß nicht was dagegen spricht, steht doch sogar in den Coding Conventions so, wenn ich mich nicht irre.

 

Aber Generell solltest du versuchen in deinem Code Properties zu verwenden und nur für Dinge die nach außen für den Editor sichtbar sind als public Variablen zu deklarieren.

Mit Properties hast du viel mehr Kontrolle und bist auf der sichereren Seite. Google wird dir behilfich sein, falls du Properties noch nicht kennst ;)

 

//Edit: Da kam mir der Marrrk wohl zuvor :)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Na dann lässt du halt die dahinterliegende Variable serialisieren...

 

private int test;
public int Test {
 get { return test; }
 set { test = value; }
}

 

Wieso sollte das nicht gehen? Ich kenne mich in Unity mit Serialisierung nicht aus, aber gibts da nicht genauso ISerializable bzw. das Serializable Attribut?

 

Properties gehören einfach zu guten Programmierstil dazu. Früher in C/C++, sowie in Java oder anderen Sprache schrieb man halt immer lästig eine get und set Methode. Doch da das in C# einfacher geht sollte dies doch die Hemmschwelle Properties zu nutzen sogar senken.

 

Mir fallen übrigens keine großen Nachteile von Propeties ein, die Vorteile überwiegen eindeutig (Mehr Kontrolle, Fehlerbehandlung bei falsch gesetzten Werten, einfacher zu Debuggen, etc.).

 

Ich sehe keinen Grund für nicht Editor spezifisches keine Properties zu verwenden.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich weiß, ihr meint es ja gut. Ich aber auch! ;)

 

Der Timetrucker fängt gerade erst an und programmiert mit JavaScript bzw. Unityscript.

In Unityscript sind alle Variablen die nicht extra deklariert werden eh public.

Natürlich kann man Variablen groß schreiben und wenns denn so ist, dass es in c# manchmal extra gemacht wird, dann ist das ok, aber kein muss.

Vielmehr will ich darauf hinaus, dass es leichter zu unterscheiden ist, ob dies jetzt eine Variable ist oder ein Objekt, wenn ich die Variable klein schreibe und das Objekt eben groß. Es erleichtert einfach die lesbarkeit. Nicht mehr und nicht weniger.

 

Static Varaiblen sparsam einzusetzen ist richtig. Aber auch da kommt es auf die Situation an. Ich nutze für jedes Projekt ein extra "Mind" Script, in dem alle Variablen Static sind und welches zum Austausch von Informationen da ist.

Wenn ich z.B. ein Spielstand lade, dann werden alle Informationen dort hinein geschrieben und von allen anderen Objekten nach wunsch ausgelesen. Ich tue es mir nicht an und überprüfe in jedem Code ob dies oder das Objekt da ist, und frage dann dessen Variable ab nur um meinen eigenen Status zu setzen.

Ne, dafür sind Static Variablen da! Für alle zugänglich, nur einmal vorhanden und von allen anderen Objekten beschreibbar.

Natürlich müssen diese Variablen gezielt zurück gesetzt werden, was zu Fehlern führen kann. Aber die Vorteile solcher Variablen überwiegen, wenn man weiß, was man tut.

Link zu diesem Kommentar
Auf anderen Seiten teilen

In den meisten Fällen stimme ich dir durchaus zu und was ich als negativ betrachte ist auch eher ein Grenzfall, aber hier mal die Nachteile die ich meine:

 

Aus der Unity Doku:

 

- CAN serialize public nonstatic fields (of serializable types)

- CAN serialize nonpublic nonstatic fields marked with the [serializeField] attribute.

- CANNOT serialize static fields.

- CANNOT serialize properties.

 

Nun meine Nachteile:

 

- extra Funktionsaufruf wenn es nicht wegoptimiert wird (inlining unterliegt vielen bösen Beschränkungen)

- können nicht als ref oder out an Methoden übergeben werden

- Member von Structs können nicht direkt verändert werden (in US geht es mit einem damit verbundenen overhead)

- getter/setter von structs rufen ziemlich oft den CopyConstruktur auf (bis zu 2x bei einem setter) wenn nicht wegoptimiert

 

Ich kenne die Vorteile von Properties, nicht dass wir uns da falsch verstehen, ich nutze Properties auch gerne, nur machen sie nicht immer Sinn.

 

Edit:

 

Ne, dafür sind Static Variablen da! Für alle zugänglich, nur einmal vorhanden und von allen anderen Objekten beschreibbar.

Natürlich müssen diese Variablen gezielt zurück gesetzt werden, was zu Fehlern führen kann. Aber die Vorteile solcher Variablen überwiegen, wenn man weiß, was man tut.

 

Das finde ich bedenklich, gehe aber grade nicht weiter darauf ein da mir momentan die Zeit fehlt, von daher gerne ignorierbar ;)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Also ich finds ja toll, dass ihr euch solche mühe macht, aber ich weiss immernoch nicht wie ich genau auf die Variablen eines GAMEOBJECT zugreifen kann. Wenn ich nähmlich jedem GameObject das gleiche script gebe, und die Variablen sich ändern, ändern sie sich ja nur für das eine GameObject und nicht für alle. z.b. Wenn ich Character 1 und Character 2 habe, und jeweils das selbe script auf den Beiden habe, sind z.b. die "Health" Variablen bei beiden Charactern unterschiedlich wenn ich sie verstelle, jedoch haben sie beide das Selbe Script. Wisst ihr was ich meine? und jetzt möchte ich gerne wissen, wie ich z.b. auf die "Health" Variable von Character 2 in einem Anderen Script zugreifen kann.

 

lg timtrucker

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wir haben dir schon geholfen. Denn du weißt jetzt, dass eine static Variable in deinem Fall so nicht funktionieren kann.

 

Ich versuche mal was Anderes. :)

Ich gehe davon aus, dass dein RaycastThread hier auch zum Tragen kommt.

Du könntest den Charakteren je einen anderen Tag geben. Über den Raycast (wahrscheinlich vom Charakter 1) erfährst du welchen Tag das getroffene Objekt hat.

Jetzt suchst du nach dem GameObjekt mit diesem Tag und sendest den Treffer.

 


var enemy=GameObject.FindWithTag( "der vom hit");
enemy.SendMessage("BinGetroffen");

 

BinGetroffen ist eine Funktion in irgendeinem Script vom Enemy (Das script muss nicht namentlich bekannt sein). Dort wÜrde dann das Script sich selber die Punkte abziehen.

Diese Variante wird funktionieren, aber das ständige Suchen nach den getroffenen gegnern braucht etwas performance.

Auf einem normalen Rechner wirst du nicht viel merken. Auf einem iPad merkst du das!

 

Du kannst auch direkt in eine Funktion eines festgelegten Scripts springen um etwas auszufÜhren.

DafÜr musst du nach dem finden des GameObjects noch die Componente finden.

 

script=enemy.GetComponentInChildren(enemyscript); // mÜsste so gehen. nicht getestet
script.BinGetroffen();

 

Auch diese Sucherei ist nicht performant.

Gut wäre es dann, wenn du zu Beginn der Szene schon alle Suchereien in der Start Routine machen könntest.

 

Ein anderer Weg, der wesentlich performanter ist, wäre in Marrrks Augen bedenklich, deswegen lasse ich ihn jetzt einfach weg. ;)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...