Jump to content
Unity Insider Forum

Über Script die RectTransform Komponente beschreiben


Sir_Mathew

Recommended Posts

Das ist etwas komplexer, aber da gibt's immerhin einen vernünftigen Grund für. Wenn du den Anker mal umstellst, sodass eine oder beide Achsen auf "stretch" stehen, dann stehen da andere Werte, weil bei "stretch" nicht mehr eine bestimmte Höhe oder Breite angegeben wird, sondern ein Abstand zur Seite hin. Die tatsächliche Höhe und/oder Breite wird dann immer daraus berechnet, weil das Element eben seine Größe an die Umgebung anpasst.

Prinzipiell musst du in solchen Fällen immer in die Dokumentation schauen: RectTransform

In diesem Fall findest du da die Eigenschaft anchoredPosition und die Methode SetSizeWithCurrentAnchors, die dürften vermutlich helfen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 2 weeks later...
Am 7.2.2021 um 18:07 schrieb Sir_Mathew:

Ach herrje ist das Kompliziert.

hab nun doch noch was cooles hinbekommen.


var varButton = buttonButton.GetComponent<RectTransform>();
        varButton.sizeDelta = new Vector2(200, 30);
        varButton.anchoredPosition = new Vector2(415, 480);

Danke für die Hilfe.

Hat leider doch nicht funktioniert. Hab noch Restcode rumhängen gehabt und mich dadurch getäuscht das es funktioniert.

Das sizeDelta muss in ein Script direkt im Button sitzen, damit das geht.

Ich hab im Script auf dem Button nun:

		public static RectTransform rectTransformButton1;

        rectTransformButton1 = GetComponent<RectTransform>();

und dann kann man rectTransformButton1 auch im anderen Script verwenden, da es public static ist

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 10 Stunden schrieb Sascha:

Ich hoffe du weißt, dass static nicht dafür da ist, Dinge zum Spaß leichter zugänglich zu machen.

Ist doch kein Spaß, sondern voll ernster Zugriff.

Wenn ich wüsste wie man ganz schwer Zugriff bekommt, würde ich es ja machen.

vor 2 Stunden schrieb Peanut:

Ich weiß leider nicht genau was du machen möchtest aber schau dir mal LeenTween an damit kann man UI ganz gut animieren bzw bewegen per Code :)

Lass mich Raten. LeenTween ist ein Asset? Ich will programmieren und nicht klicken, davon lernt man doch nix

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 3 Stunden schrieb Sir_Mathew:

Ist doch kein Spaß, sondern voll ernster Zugriff.

Wenn ich wüsste wie man ganz schwer Zugriff bekommt, würde ich es ja machen.

Joa Scherzkeks. Sag Bescheid, wenn du dir erfolgreich mit static ins Bein geschossen hast, dann kann ich das gerne nochmal erklären. Ansonsten habe ich hier was zum Nachlesen. Habe irgendwie keinen aktuelleren Post gefunden, obwohl ich mehrere Male pro Jahr einen mache :P

vor 3 Stunden schrieb Sir_Mathew:

Lass mich Raten. LeenTween ist ein Asset? Ich will programmieren und nicht klicken, davon lernt man doch nix

Wieso denkst du, das "Asset" automatisch Klickibunti heißt? Bei LeanTween musst du auch programmieren, um es zu benutzen. Wenn du anderer Leute Code nicht benutzen willst, solltest du aber bedenken, dass Unity auch in diese Kategorie fällt.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 3 Stunden schrieb Sascha:

Joa Scherzkeks. Sag Bescheid, wenn du dir erfolgreich mit static ins Bein geschossen hast, dann kann ich das gerne nochmal erklären. Ansonsten habe ich hier was zum Nachlesen. Habe irgendwie keinen aktuelleren Post gefunden, obwohl ich mehrere Male pro Jahr einen mache :P

Joa hab mal den Beitrag gelesen. Hört sich erstmal alles super an.

Aber beim zweiten hinsehen sieht Public static wieder gut aus.

um das umzuschreiben wäre das dann?

[system.NonSerialized] 
static int test=0;

Seh ich das so richtig?

Ja hört sich alles gut und schön an, aber richtige Erklärung wäre gut.

Ich pumpe mir all dein wissen ins Hirn und das tut schon weh:P

 

vor 3 Stunden schrieb Sascha:

Wieso denkst du, das "Asset" automatisch Klickibunti heißt? Bei LeanTween musst du auch programmieren, um es zu benutzen. Wenn du anderer Leute Code nicht benutzen willst, solltest du aber bedenken, dass Unity auch in diese Kategorie fällt.

Fast jede programmier Umgebung hat sowas.

Als ich bei 3D Gamestudio war, sah ich ein Video wie jemand in 2min. einen Ego Shooter geklickt hatte mit vorgefertigten Asset´s.

Hab das selbst Probiert. In einen großen ebenerdigen Raum hat es funktioniert. In einen schmalen Flur oder auf einer Treppe funktionierte da gar nix mehr richtig.

Der Gegner hat einen entweder nicht gesehen oder beim Schießen hat die Figur immer um 90 Grad gedreht.

Danach hab ich nur noch alles selbst geschrieben.

Man muss halt bedenken, das wenn man ein Asset hat und es Probleme gibt, sucht man sich einen Wolf beim eigenen Code und beim fremden Asset.

Ein Asset ist doch nie, wie man es gern selbst haben möchte. Wenn man alles so haben will, wie man es haben will, muss man es selbst machen.

Alleine das neue Input System war ja eine Katastrophe.

Ich denke das Assets eher für Profi´s sind, die genau wissen was sie machen und auch wissen was im Asset passiert.

 

Ich nehme auch nicht

public int lives { private set; get; }

da ich es nicht verstehe.

Erst private und dann aber doch public.

Da könnte man auch sagen, hab ein Asset teil kopiert, wird schon etwas passieren. Bei einer Fehlersuche würde ich dann verzweifeln.

Aber die Logik dahinter versteh ich, aber richtig erklären könnt ich das nicht.

Lesen von überall aber schreiben nur Intern. So versteh ich das zumindest.

Aber das beißt sich mit der vorigen aussage das man public nicht verwenden soll.

Ein Buch mit sieben Siegeln. Hab alle schon aufgebrochen. Kann nur nicht Lesen:o

Fazit: KlickiAsseti ist für mich persönlich derzeit nix. Erstmal alles verstehen was ich mache.:blink:

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hallo

 

Etwas zu lesen, ist unproblematisch, weil es eben den Inhalt nicht ändert. Schreiben ist doof, weil es die Fehlersuche extrem erschweren kann.  Deswegen kann es sinnvoll sein, Variablen so zu machen, dass man sie lesen kann (auch außerhalb deiner Klasse) . Stell es dir wie ein Schaufenster vor: Schauen darfst du, anfassen nicht!

 

Zum Thema Klicki-Bunti: Das klingt doch alles schon sehr planlos. Es gibt für genau definierte Sachen sehr gute Assets. Natürlich muss man die nicht nutzen, aber am Ende des Tages musst du dich fragen, ob du am Ende ein Spiel haben willst oder Probleme lösen, die andere schon oft und gut gelöst haben. 

Grundsätzlich gegen Assets zu sein, aber Unity zu nutzen, ist irgendwie auch ein Widerspruch.

 

Christoph

Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 18.2.2021 um 18:32 schrieb Sir_Mathew:

Fast jede programmier Umgebung hat sowas.

Asset != Programmierumgebung. Gamestudio war halt nie für professionelle Entwickler. Ja, es gibt viel "Klick dir dein Spiel zusammen ohne Vorkenntnisse!"-Zeug, aber es gibt noch viel mehr Code, wo jemand schon was sinnvolles geschrieben hat und du es dann benutzen kannst. Tween-Bibliotheken zum Beispiel sind meistens (wenn auch nicht immer!) letzteres. Einfach ein paar Code-Dateien, die du in dein Projekt schmeißt, und dann benutzen kannst wie du willst. Wenn das Paket kein Müll ist, dann ist das auch eine abgeschlossene Sache und du musst den Code davon niemals anschauen, wenn du nicht willst.

Am 18.2.2021 um 18:32 schrieb Sir_Mathew:

Man muss halt bedenken, das wenn man ein Asset hat und es Probleme gibt, sucht man sich einen Wolf beim eigenen Code und beim fremden Asset.

Herzlich Willkommen in der Softwareentwicklung.

Am 18.2.2021 um 18:32 schrieb Sir_Mathew:

Ein Asset ist doch nie, wie man es gern selbst haben möchte. Wenn man alles so haben will, wie man es haben will, muss man es selbst machen.

Gibt schon nicht wenig Quark, aber das stimmt so auch nicht. Versteh mich nicht falsch, ich weiß genau wovon du redest. Einige sehr populäre Assets sind eben so populär, weil sie damit werben, dass man sich da eben alles zusammenklicken kann und nichts dafür können muss. Und du hast absolut Recht und sagst dasselbe wie ich auch seit Jahren zu dem Thema: Sobald es dann minimal anders sein soll, hat man ein Problem.

Aber...

es sind bei weitem nicht alle Assets so. Weil ich das selber hasse sind meine Assets nicht so. Viele andere Assets auch nicht. Und wenn man mal mit professionellen Entwicklern redet, dann lernt man auch ganz viele solche Assets kennen. "Asset" heißt eben nicht "lustiges Fenster mit Funktionen", es heißt einfach nur "Asset" - "Bauteil". Und ja, viele Asset Store-Pakete sind stolz darauf, das Äquivalent zu Fertighäusern anzubieten, damit man nichts selber bedenken muss. Aber es gibt nicht weniger Assets, die einfach nur qualitativ hochwertig Stein und Holz und praktisches Werkzeug sind, mit denen du dann machen kannst was du willst.

Deine Kritik ließe sich halt auch hervorragend auf Unity selbst anwenden. Und das benutzt du trotzdem. Reißt du dir manchmal die Haare aus, weil du nicht verstehst, wie Unity Dinge macht? Aber hallo! Und trotzdem ist es insgesamt eine überaus valide Entscheidung, Unity nicht von Grund auf neu selber zu schreiben. Softwareentwicklung heißt halt auch, Tools kennen zu lernen und mit ihnen umgehen zu können, selbst wenn man nicht einmal reinschauen kann.

Am 18.2.2021 um 18:32 schrieb Sir_Mathew:

Ich denke das Assets eher für Profi´s sind, die genau wissen was sie machen und auch wissen was im Asset passiert.

Ganz im Gegenteil. Egal ob Profi oder Anfänger - wenn dein Asset gut ist, dann brauchst du überhaupt nicht über interne Abläufe des Assets Kenntnisse.

Und gerade Anfängern kann ein gutes Paket extrem weiterhelfen. Selbst weniger gute Pakete können das, damit man erstmal etwas hat, was funktioniert - später austauschen geht immer noch. LeanTween z.B. kostet auch nichts.

Am 18.2.2021 um 18:32 schrieb Sir_Mathew:

Aber das beißt sich mit der vorigen aussage das man public nicht verwenden soll.

Gegen public hat keiner etwas gesagt ;)

Am 18.2.2021 um 18:32 schrieb Sir_Mathew:

Ich nehme auch nicht



public int lives { private set; get; }

da ich es nicht verstehe.

Die Schreibweise ist nicht die intuitivste, da stimme ich zu. Hier geht es um eine Property, die man zwar von überall auslesen kann (public), aber dessen Wert nur innerhalb der Klasse, in der sie definiert ist, geändert werden kann (private). Die Schreibweise ist abgeleitet von der Basisform:

public int lives { get; set; }

Während das "public" hier bedeutet, dass andere Klassen diese Property benutzen können, schränkt das "private" beim "set" das "Setzen" eines Wertes ein.

Am 18.2.2021 um 18:32 schrieb Sir_Mathew:

Lesen von überall aber schreiben nur Intern. So versteh ich das zumindest.

Richtig. Nur dass "internal" wieder etwas anderes ist als "private" :D

Am 18.2.2021 um 18:32 schrieb Sir_Mathew:

um das umzuschreiben wäre das dann?



[system.NonSerialized] 
static int test=0;

Seh ich das so richtig?

Ja hört sich alles gut und schön an, aber richtige Erklärung wäre gut.

Ich versuch's mal ausführlich.

So eine Variable oder Property (was in vielen Gesichtspunkten dasselbe ist) kann einiges an diesen Schlüsselworten haben. Zum einen gibt's da eben die Zugriffsmodifikatoren:

public
private
protected
internal
protected internal

Diese geben an, welcher Code alles Zugriff auf das Ding hat. Wichtig sind erstmal nur public und private, die anderen sind erst bei komplexeren Konzepten interessant. Wenn man keinen davon hinschreibt, ist das übrigens dasselbe wie private.

Darüber hinaus gibt es noch einige weitere Schlüsselworte, die alle unterschiedliche Sachen machen (nicht so wie die Zugriffsmodifikatoren, die halt alle Zugriff machen).

static
const
abstract
virtual
override
sealed
readonly
volatile
extern

Auch hier sind die meisten für dich erstmal uninteressant. Genau genommen ist static das erste, das ein C#-Einsteiger in Unity sich anschauen sollte.

Ich weiß, sieht alles nach viel aus, aber mein Punkt ist, dass jeweils ein Zugriffsmodifikator mit keinem, einen oder gar mehreren der unteren Schlüsselwörter kombinierbar ist. Nur ein paar Beispiele:

public int
private int
public static int
private static int
protected override sealed int

Was du also lernen musst, sind zum einen die Zugriffsmodifikatoren, also erstmal public und private. public heißt, dass jeder Code, der die Variable überhaupt in die Finger kriegt (man muss die ja ggf. erstmal finden) auch damit arbeiten darf - z.B. Auslesen oder den Wert ändern. private dagegen beschränkt den Zugriff auf dieselbe Klasse (Achtung: Nicht "dasselbe Objekt"!). Damit signalisierst du, dass es nicht vorgesehen ist, dass irgendjemand, der woanders Code schreibt, mit dieser Variable arbeitet, weil z.B. eine unvorhergesehene Änderung des Wertes dazu führen könnte, dass dein Code nicht mehr richtig funktioniert.

Darüber hinaus hast du in Unity den Effekt, dass öffentliche (public) Variablen im Editor auftauchen, man kann einen Wert einstellen und der wird dann gespeichert ("serialisiert"). Das ist ein bisschen käsig weil Leute, die mit Unity C# lernen, das erstmal trennen lernen müssen. Von C# aus ist public nicht dafür gedacht, dass da irgendwas mit speichern oder so passiert. Würde auch heute nicht mehr so gemacht werden, wenn Unity heute neu geschrieben werden würde.

Als nächstes kommen die anderen Schlüsselworte, und wie gesagt - eigentlich muss man sich nach static eine Weile lang keinen mehr davon ansehen. Also: static.

Für jede nicht-statische Variable existiert einmal pro Objekt ein bisschen Platz im Speicher, sodass jedes Objekt für diese Variable einen Wert hat. Du hast zum Beispiel zwei Lichter; eines davon ist rot (Light.color = Color.red) und das andere blau (Light.color = Color.blue). Das kannst du auch im Editor so einstellen, muss nicht über Code sein. Jedenfalls muss man jetzt, wenn man die Lichtfarbe ändern will, definieren, von welchem Licht man überhaupt redet. Willst du das rote Licht grün färben oder das blaue Licht grün färben? Wobei das nur ein Beispiel ist - man kann ja auch zwei Lichter haben, die genau dieselbe Farbe haben und trotzdem genau festlegen, welches davon jetzt gefärbt werden soll. Man macht das eher selten über die Ausgangsfarbe fest. Dieser Schritt ist für ausnahmelos jeden Anfänger eine Hürde. Wie definiere ich, welches Objekt ich meine? Und ganz ehrlich: Zu diesem Thema lernt man auch nach 20 Jahren immer noch dazu.

Ein Problem, das ich hier immer und immer wieder beobachte, ist dass Leute irgendeinen Code oder Forenbeitrag oder Tutorial finden, derdiedas von jemandem kommt, der selber wenig Ahnung hat(te), in dem dann steht... "ich hab da einfach static hingeschrieben und jetzt hab ich das Problem gelöst". Der Käse ist nur halt: Static macht genau das weg, was ich gerade Beschrieben habe: Es hat nicht mehr jedes Objekt seinen eigenen Wert für die Variable, sondern es gibt die Variable nur noch exakt ein Mal im gesamten Programm, und alle Objekte teilen sich den Wert. Es kann also nicht mehr ein rotes und ein blaues Licht geben - es gibt nur noch lauter rote. Oder lauter blaue. Weil es nur noch "die eine" Lichtfarbe gibt, die für alle gleichermaßen gilt. Klar - in dem Moment muss man dann auch nicht mehr programmieren, von welchem Licht man die Farbe ändern will. Gibt ja nur noch "eine" Lichtfarbe. Der Schritt, zu definieren, welches der Lichter man meint, entfällt damit. Aber der Preis dafür ist hoffentlich jetzt klar. Wenn man also einen Knopf in seine Welt setzt, der eine Tür öffnet, und man definiert mit einer statischen Variable, welche Tür sich öffnet, dann können alle Knöpfe nur noch diese eine Tür öffnen. Es kann nicht mehr Knopf 1 Tür 1 und Knopf 2 Tür 2 öffnen.

Jetzt kann das natürlich genau das sein, was man will. Was, wenn alle Knöpfe immer nur eine bestimmte Tür öffnen sollen? Und wenn man irgendetwas macht, dann ändert sich, welche Tür das ist, und alle Knöpfe öffnen dann diese Tür stattdessen? Kann ja Teil des Spielkonzepts sein. In dem Fall ist static natürlich super. Eine statische Variable, die "die eine" Tür referenziert, so wie es "die eine" Lichtfarbe gäbe.

Wenn das aber nicht das ist, was du willst, dann ist es wichtig zu verstehen, dass der Sinn von "static" eben nicht ist, Zugriff auf Dinge einfacher zu machen. Ja, der eine Schritt entfällt, dass man definieren muss, welches Licht oder welche Tür man meint, aber dieser Schritt existiert halt nicht ohne Grund. Ihn mit static zu umgehen heißt, das ganze System zu umgehen, das erlaubt, dass verschiedene Objekte verschiedene Eigenschaften haben.

Wenn du jetzt wissen willst, was man in den Fällen, wo static doof ist, machen kann - hier ist ein Artikel von mir: http://blog.13pixels.de/2020/communicating-objects/

Der kratzt das zumindest an. Wenn du mehr wissen willst oder Nachfragen hast, immer her damit.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ohje sehr viele Infos.

Hab mich nochmal mit:


        var varButton = button.GetComponent<RectTransform>();
        varButton.sizeDelta = new Vector2(200, 55);
        varButton.anchoredPosition = new Vector2(222, 400);

versucht und es funktioniert ja doch.

Ich bin schon ganz schön kirre.

Warum das einmal aber funktionierte und dann doch nicht und nun doch wieder... keine Ahnung.

Dann schreibe ich einfach alles nochmal zum 100 mal oder so. Aber so lernt man....

Aber guter Artikel. 

Fazit: Ich liebe es Code zu schreiben, auch wenn es nicht geht:P

 

P.S. kann man raus finden was bzw. welche Typ das var Symbolisiert?

In mein Fall wäre das var ja eine RectTransform. Hab das durch rumprobieren rausgefunden. Dachte erst es wäre ein Integer aber da dies nicht ging, hab ich weiter gesucht. 

Im Debug.Log sagt er das es RectTransform ist.

aber bei

		var aa = 5;

        Debug.Log(aa);

 sagt die Console einfach nur 5.

Ist nur ein Bonus zu wissen, was man da hat...

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wenn du ne richtige IDE benutzt (Visual Studio, Rider, Visual Studio Code, ...) dann kannst du den Mauszeiger drüber halten und er zeigt es dir an. Wenn du aber nicht sicher bist, kannst du statt var auch einfach den Typ schreiben, also

int aa = 5;
RectTransform varButton = ...;

Wenn du es wirklich im Code über Debug.Log ausgeben willst, sollte das hier immer gehen:

Debug.Log(thing.GetType().Name);

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

wollte grad mal eine public static variable auf @Sascha ´s weiße testen und system wird rot unterstrichen.

  [system.NonSerialized]
    static int intStatTextÜberschriftBenutzerPosition = 0;

fehlt eine using .... dafür oder hab ich da was falsch verstanden?

die Variable brauch ich im anderen Script.

Hoffe das es dann mit ScriptName.intStatTextÜberschriftBenutzerPosition ich es dann drüben aufrufen kann.

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

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

×
×
  • Neu erstellen...