Jump to content
Unity Insider Forum

Sascha

Administrators
  • Content Count

    11,889
  • Joined

  • Last visited

  • Days Won

    603

Sascha last won the day on July 2

Sascha had the most liked content!

Community Reputation

2,418 Excellent

7 Followers

About Sascha

  • Rank
    Community Manager
  • Birthday 08/13/1990

Contact Methods

  • Website URL
    http://13pixels.de

Profile Information

  • Gender
    Male
  • Location
    Hamburg
  • Interests
    Programmierung

Recent Profile Visitors

47,690 profile views
  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.
×
×
  • Create New...