Sascha

Man sieht im Screenshot, dass der Code gespeichert ist.

Ah, aber du startest die Methode über das Testframework. Ich weiß nicht genau, was das Ding macht, aber irgendetwas sagt mir, dass deine Komponente sich nicht auf einem GameObject befindet. Tests packst du auch einfach nicht in MonoBehaviours. Nimm also die Superklasse da raus und baue dir für den Test ein GameObject. private GameObject gameObject; [SetUp] public void Setup() { gameObject = new GameObject("Test Object"); } Denke auch daran, das Ding wieder zu zerstören: [TearDown] public void Teardown() { Object.Destroy(gameObject); }

Da ist wohl ein Unlit-Shader auf den Wolken drauf. Vermutlich, weil die Wolken sonst tagsüber zu dunkel wären, da sie nicht von unten angeleuchtet werden. Schau dir also mal das Material von den Wolken an.

Ist halt ein super-exotischer Anwendungsfall. Probier's halt einfach aus. Über Performance sollte man sich sowieso immer erst dann richtige Sorgen machen, wenn sie zum Problem geworden ist. Sich darüber fertig zu machen, bevor man überhaupt angefangen hat, ist immer schlecht.

Viel interessanter wäre die Klasse ToolTipWindow_Test. Ich gehe einfach mal davon aus, dass das keine MonoBehaviour-Klasse ist und du daher die Variable "gameObject" selbst definiert hast. Stimmt das?

Unity hat ein eigenes Test-Framework, das teilweise auf NUnit basiert. Schau dir dazu einfach mal die verfügbaren Tutorials an. Warum da jetzt eine NullReferenceException kommt, ist schwer zu sagen. AddComponent sieht richtig aus (auch wenn die generische Version etwas schlanker ist). Fliegt die Exception denn in der "result = "-Zeile? Ansonsten könnte höchstens noch, je nach dem wie hier der Kontext ist, gameObject null sein.

Wenn man nur betrachtet, ob der Code am Ende funktioniert, dann ja. Aber Code-Qualität geht weit über "funktioniert" und "funktioniert nicht" hinaus. Code wie dieser ist schlecht wartbar, unmodular, nicht robust und damit eine potentielle Fehlerquelle und Auslöser für unnötige zusätzliche Arbeitsschritte wann immer am Code gearbeitet wird.

Danke für den Hinweis! Wenn du dazu auch eine Frage stellen willst, darfst du das hier gerne tun.

Das ist echt kein guter Programmierstil. Wenn du ein Objekt hast und je nach Typ oder Instanz unterschiedliche Dinge tun willst, dann packe die Unterschiedlichen Dinge in die Objekte. In diesem Fall kommt einfach der Schadenstyp in das Gen-ScriptableObject. Die Idee mit der Liste, in der alle Dinge stehen ist auch brandgefährlich, weil es dazu verleitet, Dinge aus der Liste zu nehmen anstatt eine direkte Referenz auf das Objekt von Interesse zu nutzen.

Es ist nicht mehr oder weniger sinnvoll (und vor allem nicht "weniger nötig") als in jeder anderen Situation. Du fällst im Unity-Kontext einfach nur schneller auf die Nase damit. Wenn du also ohne Unity spürbar öfter alles und jeden static machst, dann solltest du nochmal über deinen Programmierstil nachdenken Bevor das aber falsch verstanden wird: static ist nicht grundsätzlich böse oder so, aber man kann eigentlich in den allermeisten Fällen recht eindeutig sagen, ob static angebracht oder weniger sinnvoll ist. Und die allermeisten Leute tendieren dazu, erst mal auf alles blind static draufzuschmeißen, weil's damit erst mal funktioniert, und benutzen dann static viel zu oft in Fällen, wo es nicht angebracht ist. Dass static zu selten verwendet wird, kommt sehr selten vor. Wenn du also sonst mehr static benutzt, weil Dinge damit zu funktionieren scheinen, du aber in Unity merkst, dass das alles weniger gut hinhaut, dann würde ich mir eher um deinen sonstigen Code Sorgen machen, und nicht um den für Unity

Ist halt n Methodenaufruf. Wenn du das, was da passiert, jeden Frame machen willst, dann muss es halt jeden Frame gemacht werden. Ob dein Code hier oder da oder sonstwo steht ist dabei ziemlich wurscht.

Kannst du - unabhängig davon ob statisch oder nicht - aber 1 << 0 ist dasselbe wie 1.

Ja, dafür ist die Methode genau richtig. Jeden Frame die Abfrage ausführen ist okay, aber nimm halt einen gespeicherten Wert. Statt private void Update() { ...Physics.Raycast( ..., LayerMask.GetMask(...))... } machst du private LayerMask whateverCheckLayerMask; private void Awake() { whateverCheckLayerMask = LayerMask.GetMask(...); } private void Update() { ...Physics.Raycast( ..., whateverCheckLayerMask)... } Kann sein, dass du als Typ "int" statt "LayerMask" nehmen musst, bin mir gerade nicht sicher.

Nimm statt NameToLayer einfach GetMask Benutze das aber lieber einmal am Anfang und nicht jeden Frame immer wieder. Speichere dir das Ergebnis ab und stopfe es direkt in den Raycast-Aufruf. Da du aber danach gefragt hast, zur Erklärung: NameToLayer gibt dir den Index deines Layers zurück, also 0, 1, 2, 3, 4, ... Das ist aber keine LayerMask. Eine LayerMask ist, wie der Name "Maske" schon suggeriert, eine Bitmaske, wo bei einer Zahl (die ja aus einer Reihe Bits, also Nullen und Einsen, besteht) jedes Bit als ein Boolean (1= Ja bzw. 0 = Nein) gewertet wird. Das folgende ist mal aus dem Stehgreif vereinfacht, aber bezüglich der tatsächlichen Werte vielleicht nicht ganz exakt. Ist halt nur zur Veranschaulichung. Ich nutze auch einfach mal nur 8 Bits ohne Vorzeichen statt 32. Die LayerMask, die nur den Layer 0 beinhaltet, sieht also dann so aus: 00000001. Layer 1 wäre 00000010. Layer 2 wäre 00000100. Layer 3 wäre 00001000. Das X-te Bit von rechts sagt also aus, ob Layer Nummer X in der LayerMask angeschaltet ist. Deshalb auch das "1 <<". Die Zahl 1 sieht mit 8 Bits so aus: 00000001. "X << Y" shiftet die Bits der Zahl X um Y Bits nach links. "1 << 3" bedeutet also, dass die 1 um 3 Stellen nach links geshiftet wird, und es kommt heraus: 00001000. Das ist eine gültige LayerMask, wo das dritte (also entsprechend der 3, wenn man von 0 anfängt zu zählen) Layer an und der Rest aus ist. Wenn du das "1 <<" weglässt, dann passiert das alles nicht, sondern die Zahl selbst wird betrachtet. Und eine 3 sieht in Bits so aus: 00000011. Das Entspricht der LayerMask für Layer 0 und 1, und nicht Layer 3. Die LayerMask mit Layern 0 und 3 wäre jetzt 00001001. Um diese LayerMask zu bauen, müsstest du die LayerMasks für Layer 0 und Layer 3 bauen und diese dann mit | (bitweises Oder) kombinieren. | nimmt die Bits von den Zahlen auf beiden Seiten und rechnet für das Ergebnis-Bit 1, wenn eines der beiden Bits 1 ist, sonst 0. 0 | 0 | 1 | 1 | 0 1 0 1 - - - - 0 1 1 1 Wenn wir damit also 00000001 und 00001000 zusammenrechnen: 00000001 | 00001000 -------- 00001001 Und damit haben wir das, was wir wollen. Der Code wäre also 1 << LayerMask.NameToLayer("Eins") | 1 << LayerMask.NameToLayer("Zwei") | 1 << LayerMask.NameToLayer("Drei") | ... Aber zum Glück ist das genau das, was GetMask schon macht, und damit sind wir wieder bei meiner anfänglichen Aussage: Finger weg von NameToLayer. Da GetMask aber params benutzt, benutze die Methode nur einmal am Anfang und speichere dir das Ergebnis. Sie öfter aufzurufen erzeugt unnötigen Müll im Speicher.

Nicht nur im Prinzip. Bitbucket ist halt einfach ein Hoster für Git-Repos. LFS sollte man so oder so benutzen, aber man darf halt nicht vergessen dass das nichts weiter tut als Download-Zeiten zu verkürzen. Es findet immer noch eine vollständige Versionierung der Dateien statt - es wird halt immer nur die aktuelle Version heruntergeladen statt der gesamten Historie.