Jump to content
Unity Insider Forum

Sascha

Administrators
  • Content Count

    12,359
  • Joined

  • Last visited

  • Days Won

    648

Everything posted by Sascha

  1. Sascha

    Timer

    Du kannst entweder ein statisches Feld in deine MonoBehaviour-Klasse machen oder du machst mehrere Klassen - eine statische und ein MonoBehaviour. Geht beides.
  2. Sascha

    Timer

    Du musst mal ein bisschen mehr schreiben, was du willst. Was für ein Zugriff? Eigene Klasse?
  3. Sascha

    Timer

    Ich weiß nicht genau, was du gerade machen willst, aber generell einfach public class Klassenname : MonoBehaviour
  4. Sascha

    Timer

    Bitte was... natürlich funktioniert das xD Und was dein Lehrbuch sagt... naja, genieße das mit ner Prise Salz. Statische Variablen sind globale Variablen und selbstverständlich unterstützt Unity die.
  5. Automatisiert geht da nichts. Wenn du dokumentieren willst, wie irgendwelche Prefabs funktionieren, dann sollten vor allem die Namen deiner Komponenten sprechend sein. Ansonsten nimmt man am ehesten ein Wiki.
  6. Sascha

    Timer

    Warum versuchst du, jetzt etwas ganz anderes zu machen? Statische Variable und los! Nur, weil da gerade noch ein Problem zu lösen ist, heißt das nicht, dass man gleich die ganze Idee verwerfen muss...
  7. Sascha

    Timer

    Ich weiß gerade nicht, welches Problem du meinst. Aber ob du Dinge in Klasse A oder Klasse B tust sollte, wenn nicht sowieso eindeutig ist dass das sein muss, keinen Unterschied machen.
  8. Sascha

    Timer

    Doch. Ich glaube, da ist vielleicht der Knackpunkt. Ein statisches Feld existiert nicht auf einem Objekt. Es wird also auch nicht generiert. Es existiert von Anfang des Programms bis zu dessen Ende. Ein stückweit heißen die Dinger auch deswegen "statisch". Der Timer wird also nicht generiert. Es sei denn, du meinst damit das Objekt, das den Wert des Feldes durchgehend erhöht. Die GameObjects, die in der Szene sind, werden gelöscht, ja. Aber eben nicht dein statisches Feld. Das existiert schon vor dem Laden der Szene und bleibt auch danach noch erhalten. Meine Vermutung is
  9. "Gehe vorsichtig mit X um, da Performance" ist immer eine... kritische Aussage. Wenn es etwas besseres gibt, das dasselbe macht, sollte man X gar nicht benutzen. Wenn es nichts besseres gibt, sondern höchstens Sachen, die nicht genau dasselbe machen, dann muss man den Preis halt bezahlen, damit das Ergebnis stimmt. Raycasts kann man ganz schön viele machen, bevor man sich damit in den Fuß schießt. Die Engine hat nicht umsonst eine dicke Beschleunigungsstruktur laufen. Und wie immer gilt: Erst probieren, modular bauen und sich dann erst um Performance Sorgen machen, wenn's Probleme gibt.
  10. Es gibt Situationen, wo es sehr nervig wird, nicht mit skalierten GameObejcts zu arbeiten. Animationen können da schon drunterfallen. Aber in dem Fall ist die Empfehlung, das Objekt in mehrere Objekte aufzuteilen: Parent: Hat Collider, Physik, Bewegungsscript usw. Ist nicht skaliert. Child: Hat Renderer, Animator usw. Ist bei Bedarf skaliert. Dann kann die Physik und dein Code gemütlich ohne Skalierung arbeiten, und den sichtbaren Teil der ganzen Sache kannst du dann skalieren wie du möchtest Diese Aufteilung würde ich auch Empfehlen, wenn du nichts skalieren musst. Da s
  11. Hallo und viel Erfolg bei deinem Vorhaben
  12. das kann man machen, aber auf lange Sicht will man - so lange es bei mir auch gedauert hat, das einzusehen - einfach vom Rigidbody weg. Ich hab mir inzwischen einen 2D-Character Controller geschrieben, der komplett die Kollionsabfrage mit der Umgebung über Raycasts macht. Also z.B. 5 nach oben, 5 nach unten, 7 jeweils links und rechts. Natürlich alles einstellbar. Und wie gesagt, Corgi macht das genauso. Bin zwar kein großer Corgi-Fan weil das Paket will, dass man sonst nichts anderes mehr verwendet... ich mag eher Lightweight-Pakete, die man dann beliebig mit anderen Lightweight-Paketen kombi
  13. Ich würde eher dazu raten, zu vermeiden, Objekte zu skalieren, die das nicht unbedingt brauchen. Je mehr 1,1,1 du hast, desto weniger potentielle Kopfschmerzen gibt's. Seit dem frischen Forenupdate geht das mit einem Klick auf die drei Punkte oben rechts in deinem Beitrag.
  14. Sascha

    Timer

    Dann hast du irgendwo Code, der das zurücksetzt. Vermutlich irgendeine Komponente, die das in Awake, OnEnable oder Start macht.
  15. @MichaelH Ich würde darauf tippen, dass dein Transform.localScale (also der "Scale"-Wert, den man im Inspektor einstellen kann) nicht gleich 1,1,1 ist. @chrische5 Ich habe einige Zeit in den letzten Jahren damit verbracht, 2D Character Controller richtig unter die Füße zu bekommen... und am Ende habe ich auch Raycasts benutzt. Corgi Engine macht das auch so. Ich kann dir oft nicht einmal richtig sagen, wo mit allen anderen Varianten das Problem ist, aber irgendwie läuft das schon darauf hinaus.
  16. Nene, du musst das so sehen: Jetzt hast du ein Gefühl für sowas und nächstes Mal findest du's schneller
  17. Prinzipiell kannst du davon ausgehen, dass das meiste im Build und im Editor gleich läuft. Insbesondere, wenn du in der GameView dieselbe Auflösung einstellst, die am Ende auch im Build läuft. Kannst du im Dropdown oben links im Game View-Tab ja machen. Wenn du im Kontext irgendwelcher Mathf-Funktionen Verhaltensunterschiede feststellst, dann bin ich mir zu 99,9% sicher, dass es an deinem Code liegt. Vielleicht hast du unterschiedliche FPS und dein Code berücksichtigt das nicht oder so.
  18. Sascha

    Timer

    NEIN! Also... doch. Aber bitte nicht. PlayerPrefs speichert Dinge auf der Festplatte. Das ist NICHT dafür da, dass du Dinge in mehreren Szenen zur Verfügung hast. Ist ein bisschen als ob du das Waschbecken abmontierst, um damit in die Küche zu gehen und Suppe reinzufüllen. Geht zwar, aber lass mal lieber. Wenn du Dinge szenenübergreifend machen willst, musst du dir bewusst machen, was ein Szenenwechsel ist. Es werden alle GameObjects gelöscht und die GameObjects der neuen Szene werden geladen. Es geht alles verloren, was auf einem der gelöschten GameObjects hockt... naja, theoretisch zumi
  19. 2019 ist die aktuelleste LTS, aber 2020 gibt's schon ne Weile. Wenn du kein LTS brauchst, ist eine aktuelle 2020er sehr empfehlenswert.
  20. Hm, kein Resources.Load oder so ein Quark, sieht imo eigentlich alles gut aus. Ich bin mir auch nicht sicher, ob das an der Textur liegt - Fuchsia-Oberflächen heißen eigentlich, dass der Shader fehlt oder fehlerhaft ist. Du machst auch sonst nix mit dem Material oder dem Shader in irgendeinem Code?
  21. Sascha

    Timer

    Korrekt. Du kannst entweder die Methode(n) aussuchen, die der Button beim Klick ausführen soll, indem du im Inspektor des Buttons Listeneinträge machst, oder du machst das über Code, mit mybutton.onClick.AddListener. Beides ist valide. Welches von beidem du eher nutzen solltest, hängt von der Situation ab. Richtig, du willst das immer wieder ausführen. Aber du willst nicht immer wieder den Button abfragen. Geht auch gar nicht. Was du tun willst, ist einen Schalter umlegen: private bool timerIsActive; public void StartTimer() { timerIsActive = true; } public void PauseTimer
  22. DAS sollte auf keinen Fall gehen 🤔 Naja, Dinge laufen schlechter und brauchen länger, aber letztenendes sollte es immer gehen. Gerade, wenn es vorher auch ging. Der Editor braucht beim selben Projekt eigentlich nicht mehr Leistung als früher.
  23. Das ist zwar mehr Denkarbeit, aber der übliche Weg ist da (nicht ohne Grund!), eine Flag einzubauen - also ein bool-Feld, das angeht, wenn die Bedingungen zum kaputt gehen erfüllt sind (wird geworfen, fällt von der Kante). Und bei einer Kollision wird geschaut, ob die Flag gesetzt ist und wenn ja, geht's kaputt. Aber für's Erste, nicht zuletzt um da ein Gefühl für zu kriegen, kannst du auch relativ problemlos™ bei der velocity-Variante bleiben. FixedUpdate ist genau dafür da, dass die Framerate egal wird. Deshalb passiert die gesamte Physik auch auf dem FixedUpdate-Zyklus. Hier hast d
  24. Wenn ich dich richtig verstehe, dann möchtest du das zu 100% von der Geschwindigkeit der Box abhängig machen und ignorieren, wie schnell das Objekt ist, das getroffen wird? Scheint mit ein koimischer Umweg zu sein, anstatt zu sagen "wenn die Kiste geworfen wird, ist sie automatisch schnell genug, dass sie immer kaputt geht"... aber deine Entscheidung Ich würde dafür jedenfalls ganz einfach die Geschwindigkeit des Rigidbodys nehmen, denn um die geht's ja. Sie ist nur halt in OnCollisionEnter2D bereits durch die Kollision abgewandelt. Deshalb musst du sie dir im vorherigen FixedUpdate spei
×
×
  • Create New...