Jump to content
Unity Insider Forum

Sascha

Administrators
  • Content Count

    11,889
  • Joined

  • Last visited

  • Days Won

    603

Everything posted by Sascha

  1. Ich würde sogar empfehlen, ein Git-Repo zu erstellen, aber... eins nach dem anderen. Github hat auch eine nette "Gists"-Sektion, die sieht bei mir so aus. Sachen, die du nicht (oder zumindest: nicht ausschließlich) alle in einem Paket haben willst, können da sehr schön hin. Das geht auch mit einem Git-Repo sehr gut - du musst es ja nicht bei Github oder so hochladen, sondern kannst es lokal behalten. Namespaces sind nett, um den Scope etwas kleiner zu halten. Oder anders gesagt: Wenn du anfängst, zu tippen, dann ploppen dir da ja Vorschläge auf. Und diese Liste kann man etwas kürzer halten, indem man seine Sachen in Namespaces packt. Namespaces erlauben dir aber nicht, Code in dein Projekt zu importieren oder so. Der Code liegt entweder vor oder er tut es nicht. Eine using-Direktive hat darauf keinen Einfluss. Gerne! Was du haben willst, ist ein Paket, das der Paketmanager für dich importiert. Seit Unity 2018.irgendwas hast du ja zwei Hauptordner in deiner Project View: "Assets" und "Packages". Assets ist für alle Dinge, die für dein Projekt spezifisch sind, während Packages eben Pakete enthält, die nicht speziell für dieses Projekt sind, sondern generell eingesetzt werden können. Ein Paket erstellst du, indem du ein Paket-Manifest in einen Ordner voller Assets legst. Dafür will Unity afaik noch Editor-Support bauen. Laut Manual funktioniert das Manifest Window in 2019.4, tut's bei mir aber nicht. Also bastelst du dir im Moment einfach eine json-Datei in einem beliebigen Text-Editor. Das sieht dann etwa so aus. Die Datei muss dabei genau "package.json" heißen. Erstelle dir gerne eine Kopie von meinem Manifest und passe es an. Nette Falle: Die Versionsnummer muss dem Schema "x.x.x" entsprechen, "x.x" (z.B. "0.1" statt "0.1.0") ist nicht erlaubt. Dann müssen noch alle Scripts einer Assembly Definition untergeordnet sein. Dazu kannst du in deinen Assets rechtsklicken, "Create", und dann "Assembly Definition". Dem Ding gibst du einfach einen sinnvollen Namen - bei mir gibt's ein Paket namens "Unity-Essentials" (), und die asmdef-Datei heißt dann "ThirteenPixels.Unity-Essentials". Schau dir den Aufbau auch gerne genauer in meinem Projekt an, das ich verlinkt habe. Wenn das Paket so eingerichtet ist (klingt nach viel Arbeit, aber da gewöhnt man sich ganz schnell dran), dann kannst du in deinem Projekt, in dem du das Paket importieren willst, den Paketmanager dafür benutzen. Den findest du oben unter "Window", "Package Manager". Damit der auch richtig funktioniert, solltest du auf jeden Fall Unity 2019.3 oder höher benutzen, davor hatte der noch erhebliche Mängel und man musste per Hand Dinge in eine Textdatei eintragen. Sobald du den Paketmanager offen hast, kannst du das hier auswählen: Und dann im Dialog die package.json raussuchen und auswählen. Der Paketmanager importiert jetzt das Paket und packt es in den Packages-Ordner deines Projekts: Um da jetzt noch auf den Anfang zurück zu kommen: Du kannst wunderbar aus deinem Paket ein Git-Repo machen, dann hast du schon einmal Versionierung (was super ist). Optional kannst du das Repo dann auch noch auf Github oder sonstwo hinpushen, dann hast du direkt noch ein Online-Backup und kannst von überall auf das Paket zugreifen (wenn du mal an einem anderen Rechner sitzt oder jemand anderes mit dir arbeitet). Öffentlich kann so ein Ding auch super für dein Portfolio sein. Zu guter Letzt finde ich es irgendwie simpler, Updates von Paketen zu ziehen, wenn diese in einem Git-Repo sitzen. Statt "from disk" wählst du sonst im Paketmanager dann "from git URL" aus und fertig. Jedenfalls ist das dann auch nicht mit Kanonen auf Spatzen schießen Damit sage ich nicht, dass du das machen musst - wie gezeigt kannst du Pakete auch einfach von der Platte laden.
  2. Joa, Physik und eigentlich alles, was nicht streng linear ist und immer überall konsistent passieren soll, sollte in (einem) FixedUpdate passieren.
  3. "Mein Input wird manchmal nicht erkannt" klingt ganz stark nach Get(Button/Key/MouseButton)(Down/Up) in FixedUpdate. Denk dran, dass FixedUpdate mehrere Male oder kein Mal zwischen zwei Updates vorkommen kann und das Input immer in Update aktualisiert wird. Wenn du also den Knopf drückst und dann zwei FixedUpdates hast, dann ist GetKeyDown in FixedUpdate zweimal hintereinander true, weil es erst beim nächsten Update wieder false wird. Wenn du kein FixedUpdate zwischen dem Drück-Update und dem danach hast, in dem der Input wieder false wird, dann fällt der Input komplett flach. Daher: Down- und Up-Inputs in Update abfragen und bis zum nächsten FixedUpdate behalten; dann wieder auf false setzen.
  4. Woher weißt du, dass OnGUI benutzt wurde? oO
  5. Wenn du keine Fehlermeldung kriegst ist doch alles tutti. Falsche Farben können schon einmal Vorkommen, da würd ich mir jetzt nicht so den Kopf drum machen.
  6. 1. Tritt die Fehlermeldung auch in der Editor-Konsole auf oder nur in Visual Studio? 2. "using UnityEngine;" am Anfang hast du drin?
  7. Groß- und Kleinschreibung ist wichtig, das V muss groß.
  8. Warum ist ein Laser, der, wenn du nicht gerade astronomisch relevante Größenordnung im Spiel hast, nahezu gleichzeitig losfliegt und irgendwo ankommt, überhaupt mit einem Rigidbody definiert? Laser ist wohl das beste Beispiel für etwas, das man mit Raycasts modellieren möchte. Und dann den Rigidbody komplett weg lassen.
  9. Das ist richtig, aber es gibt halt die Grundregel dass Explizit besser als Implizit ist. Die Funktionsweise ist dieselbe, aber mit expliziten Modifikatoren ist's besser für die Code-Qualität Ich mach's daher immer so, werfe es aber niemandem vor, wenn es anders gemacht wird.
  10. Genau richtig: StartCoroutine startet eine Coroutine, aber wartet nicht, bis sie fertig ist. Das würdest du auch gar nicht wollen, denn deine OnMouseDown-Methode wird im Hauptthread ausgeführt. Wenn du da wirklich eine Sekunde warten würdest, würde dein Spiel eine Sekunde lang einfrieren. Allerdings passen deine Problembeschreibung und dein Code sowieso nicht ganz zueinander. Da musst du den Zustand deines Objekt ändern und nicht auf irgendetwas warten: private bool selected; private void OnMouseDown() { selected = true; } private void Update() { if (selected && Input.GetMouseButtonDown(0)) { // ... } }
  11. Ich kenne exakt eine Möglichkeit, vernünftige Folgekameras ohne Ruckeln hinzukriegen. Beide Teilnehmer (Spielfigur und Kamera) bewegen sich in FixedUpdate (Spielfigur über nicht-interpolierten Rigidbody oder per Script) und beide kriegen dieses Script. Für 100% Determinismus noch die Kamera auf einen späteren Zeitpunkt in der Script-Ausführungsreihenfolge setzen. Cinemachine ist, wie von @chrische5 erwähnt, genau für so etwas da, kann man sich natürlich auch anschauen.
  12. @chrische5 Wie das "Debug" im Namen sagt, ist das Ding nur für Markierungen für Entwickler beim Arbeiten da. Außerhalb des Editors wirst du damit nichts. @loui1337 Der LineRenderer ist wirklich sehr Leicht zu benutzen, man muss ihn sich nur einmal in Ruhe anschauen. Und er ist genau, was du brauchst.
  13. Ich würde sagen, EventTrigger-Komponente drauf, richtiges Event finden (Pointer Up oder so) und da dann die value von der Slider-Komponente setzen.
  14. Ja: Schau dir den Buitin-Sprite-Shader an [HideInInspector] _RendererColor ("RendererColor", Color) = (1,1,1,1) Die Komponente scheint exakt diese Eigenschaft ansprechen zu wollen. Ja, ist normal. Shader-Code kommt aus einer anderen Welt mit ganz anderen Ideen. Da hier anfangs keine Abläufe programmiert wurden, sondern nur das Aussehen von Oberflächen, ist die Syntax anders. Inzwischen werden Grafikkarten für alle möglichen Sub-Programme benutzt, aber die Ursprünge sind noch deutlich sichtbar. Und ja, die Lernkurve ist heftig. Deswegen ist es gut, dass Leute visuelle Shader-Editoren entwickeln.
  15. DAS ist ein sehr guter Grund Nein, aber das liegt eventuell auch daran, dass ich keine ShaderLab-Syntax im Pass benutze. Wenn ich einen Shader schreibe, dann nutze ich die Standardpackung ShaderLab für außenrum (Properties definieren und so) und im Pass kommt dann ein CGINCLUDE-Block, wo ich CG-Code schreibe. Diese ShaderLab-Syntax... SetTexture[_MainTex] { //Combine texture * primary DOUBLE Combine texture * primary } ...ist halt irgendwann mal von irgendwem bei Unity entwickelt worden und seitdem komplett vernachlässigt. Ist auch wesentlich weniger mächtig als standardisierter Shader-Code. Dieser ist initial schwerer zu lernen, schreibt sich dann aber wenigstens ungefähr wie C-Code, und es gibt einen Haufen Resourcen, weil das halt überall vorkommt und nicht nur in veralteten Unity-Shadern. Jau, hier und in den folgenden/untergeordneten Seiten. Da bin ich ehrlich gesagt überfragt. Ich verstehe die Funktionsweise und Syntax von Fragment- und Vertex-Shadern, aber mit so fancy Zeug wie Instancing in Shadern habe ich mich nie beschäftigt. Der Builtin-SpriteRenderer-Shader ist auch nicht sonderlich komplex. Der hat hauptsächlich noch ein paar Konditionale für den Compiler, um in verschiedenen Situationen leicht unterschiedlich funktionieren zu können. Ich kann nur empfehlen, dir den Source Code von den Builtin-Shadern runterzuladen und anzuschauen. Die Downloads gibt's hier. Einfach im Dropdown "Buit in Shaders" auswählen.
  16. Wie gesagt - weil deine Anwengungsgebiete völlig unterschiedliche Anforderungen haben. Du willst ja auch nicht ein Haus bauen und sagst "ich will das aber einfach halten, ich beschränke mich auf einen einzelnen Hammer". Wenn ich das richtig gesehen habe, kriegt Unity seit 2019.4 das mit dem Shader Build Caching vernünftig hin. Die Default-Shader werden so oder so mitkompiliert, durch hinzufügen eines neuen Shaders sparst du also keine Zeit Wir reden hier von Shadern. Das sind ziemlich kleine Dateien, wenige kilobyte. Jede einzelne Textur die mehr Pixel hat als man an der Hand abzählen kann, jede Sounddatei nimmt ein Vielfaches davon ein. Also mach dir mal wegen Shadern keinen Kopf.
  17. Warum willst du dafür einen einzelnen Shader haben? Das ist keine gute Idee und funktioniert auch gar nicht. Deine Anwendungsgebiete haben ganz unterschiedliche Anforderungen an einen Shader. Du hast doch einen ganzen Satz vorgegebener Shader zur Verfügung, benutz die doch einfach?
  18. Sieht für mich stark danach aus, dass eine der Exceptions fliegt, weil eine der GlobalTexture2Ds keinen Wert hat. @Zer0Cool hat Recht - versuche Mal, das Problem einzugrenzen. Entweder mit Debug.Logs oder dem Debugger.
  19. Hast Recht, darum geht's im Artikel, aber gerade der erste Punkt gilt auch im Play Mode. Wenn dein Objekt zusammen mit einem anderen Objekt zu Beginn der Szene existiert, dann ist unklar, wer von beiden zuerst Awake, OnEnable oder Start aufgerufen kriegt. Wenn du ein Objekt erst später instanzierst, dann ist klar, dass es später drankommt. In gefühlten 90% der Fälle ist diese nicht definierte Reihenfolge der Grund für unterschiedliche Ergebnisse unter mehr oder weniger gleichen Bedingungen. Hast du ansonsten irgendwelche Fehlermeldungen in den Momenten, wo es nicht funktioniert?
  20. Hab da was für dich: http://blog.13pixels.de/2019/things-that-can-make-a-difference-in-unitys-play-mode-compared-to-your-build/ Vielleicht ist da ja deine Antwort dabei.
  21. Gibt keinen wütenden Mob, wenn du's nicht tust, aber wäre schon gut Eins schon einmal vorweg: "Unity hängt sich auf" bedeutet eine Endlosschleife in deinem Code. Vermutlich ein unendlich oft gespiegelter Laser. Da solltest du in jedem Fall etwas Code posten.
  22. Sascha

    Object Drehen

    Weil du darin einen Beitrag geschrieben hast.
  23. Sascha

    Object Drehen

    Ich fang einfach mal ganz von vorne an, auch auf die Gefahr hin, dass ich Dinge sage, die du schon weißt Transform.Rotate kennst du dann ja sicherlich. Das dreht ein Objekt einmalig in eine bestimmte Richtung. Ist also eher wie ein Teleport als eine Bewegung. Das Objekt ist "so" ausgerichtet, Rotate wird aufgerufen, jetzt ist das Objekt anders ausgerichtet, fertig. Um ein Objekt kontinuierlich zu drehen, musst du diese Methode immer wieder aufrufen lassen, sodass es sich immer wieder ein kleines Stückchen weiter dreht. Das geht z.B. in Update. private void Update() { transform.Rotate(0, 10, 0); } Update wird ja jeden Frame aufgerufen, also bei 60 FPS 60-Mal die Sekunde. Das Objekt dreht sich also 60-Mal 10°, also 600° pro Sekunde. Hätten wir aber nur 30 FPS, dann wären es nur 30 kleine Drehungen und damit hätten wir eine Drehgeschwindigkeit von 300° pro Sekunde. Das ist nicht so gut, daher schmeißen wir Time.deltaTime drauf. private void Update() { transform.Rotate(0, 10 * Time.deltaTime, 0); } Time.deltaTime ist die Zeit seit dem letzten Update in Sekunden. Bei 60 FPS ist das 1/60, bei 30 FPS 1/30. Der Wert ist also doppelt so hoch wenn wir nur halb so viele Frames pro Sekunde haben. Man kann das daher als "pro Sekunde" lesen, sodass "10 * Time.deltaTime" als "10° pro Sekunde" gelesen werden kann. Jetzt müssen wir nur noch machen, dass Rotate nur dann aufgerufen wird, wenn die Taste gedrückt ist. Das machen wir mit einer if-Abfrage: private void Update() { if (Input.GetKey(KeyCode.Space)) { transform.Rotate(0, 10 * Time.deltaTime, 0); } } Zur Erinnerung: Update wird jeden Frame aufgerufen. Das heißt, dass jeden Frame geschaut wird, ob Space gerade gedrückt wird. Wenn ja, bewegen wir uns einen Schritt weiter, was, wenn wir die Taste über mehrere Frames am Stück halten, zu einer Bewegung wird. Wenn nein, passiert gar nichts, was Stillstand bedeutet.
  24. In der Hierarchie Rechtsklick auf die Prefab-Instanz, dann "Unpack Prefab".
×
×
  • Create New...