Sascha

Wenn man bei UnityScript nicht "private" dranschreibt, ist die Variable automatisch "public", wie es auch hier der Fall ist. Dadurch kann man den Wert der Variablen von außen, also aus anderen Klassen heraus, ändern; und im Unity-Kontext heißt das zusätzlich, dass man den Wert im Editor einstellen kann. Da hier nirgendwo eine Schleife zu sehen ist, stimmt das zumindest für den geposteten Code nicht. Siehe oben. Du kannst den Wert im Editor ändern und damit dieses Script für mehrere Objekte benutzen, die sich unterschiedlich verhalten; je nachdem, wie du die Einstellungen setzt.

Ja gut, wenn man das in jedem Frame prüfen will. Ist aber keine schöne Lösung.

Hmm... du hast nur einen Destroy-Aufruf, keine statischen Variablen... ich sehe irgendwie nichts, was dieses Problem auslösen könnte. Kann es sein, dass deine Granaten vielleicht gar nicht gelöscht werden, sondern durch AddExplosionForce einfach nur extrem schnell weggeschleudert werden?

@Damon93s Vorschlag ist schon genau richtig, dafür braucht man ein Observer Pattern. Aber, um die Frage nochmal direkt zu beantworten: Änderungen Monitoren ohne dass man die Variable in einen Wrapper packt ist nicht möglich.

Das sind Light Probes aus deiner Light Probe Group. Weiß gerade aus dem Stand zugegeben nicht, wo man die Visualisierung abstellt.

Das relevante Script, nämlich das auf der Granate, das die Granate löscht, hast du nicht gepostet.

Dafür musst du die lokale Rotation des Objekts verändern, und die Seiten, die an einer anderen Seite hängen, dieser unterordnen. Also... Blau ist Gold untergeordnet, Gold ist Lila untergeordnet, usw.

Du packst bitte auf jedes deiner sich drehenden Projekte einmal die gleiche Komponente. Auf keinen Fall eine Komponente schreiben, die mehrere Objekte auf exakt gleiche Art dreht. Und wie @Mr 3d schon gezeigt hat, geht das auch gut ohne Coroutine.

Du bist so an dem Punkt, an dem man sich überlegen sollte, ob man dafür überhaupt (ausschließlich) Collider benutzen möchte, oder ob ein eigener Check nicht vielleicht sinnvoller wird, z.B. mit Physics2D.BoxCast. Was meinst du mit hin- und herschieben? Bewegung durch Input steuern? Falls ja, kannst du direkt in FixedUpdate Rigidbody2D.velocity setzen, damit dein Objekt sich mit fest kontrollierter Geschwindigkeit bewegt.

Haben die Hindernisse auch Collider? Ist ein Rigidbody2D im Spiel? Wenn nicht, werden keine Kollisions-Events ausgelöst.

Du benutzt Get(MouseButton/Button/Key)(Down/Up) in FixedUpdate, das führt zu solchen Fehlern. Die Werte, die von diesen Funktionen zurückgegeben werden, werden im Update-Schritt jeweils einmal geändert. FixedUpdate kann allerdings mehrere Male oder gar nicht zwischen zwei Updates aufgerufen werden. Bedeutet, dass gerne Mal gar nichts passieren kann, wenn du klickst, aber eben auch, dass es mehrere Male mit nur einem Klick passiert. Deshalb diese Funktionsgruppe nur in Update verwenden.

Ein kleiner Zusatz: Nur, wenn "Collision Detection" auf "Continuous" ist, ansonsten interessiert sich der Rigidbody da auch herzlich wenig für.

Mit einer LayerMask beim Raycast gibst du nur an, womit der Ray kollidiert. Worauf der Raycast "reagiert" ist ja im Code danach definiert und hat mit dem Raycast nichts mehr zu tun. Der trifft etwas oder eben nicht. Du willst also nur zwei Layer treffen. Warum is "UI" dabei? UI-Canvase haben nämlich ihren eigenen Raycaster. Physics.Raycasts haben in der UI entsprechend eigentlich nichts zu suchen. Aber so oder so... warum funktioniert das jetzt nicht? hast du "mask" denn auch an den Raycast-Aufruf übergeben?

Das ist ne etwas komische Vorstellung. Deine Pixel haben einen Helligkeitswert zwischen 0 und 1. Was anderes kann dein Monitor nicht anzeigen. Wenn etwas noch heller als weiß aussehen soll, kannst du Bloom benutzen, um die Lichtintensität auf benachbarte Pixel "bluten" zu lassen. Davon wird dein Pixel natürlich nicht heller. Jetzt gibt es halt HDR, welches besagt dass deine Pixel eben doch außerhalb des 0-1-Bereiches liegen können. Auf dem Bildschirm kann nach wie vor nur zwischen 0 und 1 angezeigt werden, aber bevor die Farben auf dem Bildschirm landen, kann man damit halt rumrechnen. So kannst du z.B. deinem Bloom sagen, dass es erst ab einer Helligkeit von 1 anfangen soll, zu wirken. Wenn du jetzt ein Objekt hast, das durch Emission der Materials die Helligkeit 1 hat, und ein anderes, das mit Helligkeit 1 angestrahlt wird, dann macht das keinen Unterschied. Der Trick ist, dein leuchtendes Objekt heller zu machen als die angeleuchteten Objekte. Und das ist auch völlig realistisch so. Ein nicht selbstleuchtendes, sondern angestrahltes Objekt kann dich ja auch wunderbar blenden - und etwas anderes als "geblendet werden" simuliert Bloom ja auch eigentlich gar nicht.

@malzbie Das ist doch kein Unity-Bug...! Wenn man etwas - egal was - einem skalierten Objekt unterordnet, dann wird es mitskaliert. Wenn du das untergeordnete Objekt dann drehst, dann gilt nach wie vor die Skalierung des übergeordneten Objekts. Dadurch entsteht ein Skew-Effekt. Man nehme also ein Objekt A und diesem ordner man einen Würfel B unter. Wenn man Objekt A auf der Y-Achse nach oben skaliert, dann erhält man erwartungsgemäß einen vertikal skalierten Würfel. Dreht man diesen Quader B jetzt aber um 45° auf der Z-Achse, dann erhält man keinen gedrehten Quader, sondern das hier: Und zwar, weil es jetzt nicht mehr der anfängliche Würfel B ist, der vertikal skaliert wird, sondern das hier: Wenn man sich den Weg vom letzten zum vorletzten Bild vor Augen führt, ist hoffentlich klar, was passiert und warum. Die Lösung ist, einfach keine Objekte zu skalieren, die Kindobjekte haben. Das ist in der Regel auch eigentlich nie nötig. Schon gar nicht non-uniform, also nicht als Vielfaches von (x,x,x).