Jump to content
Unity Insider Forum

Sascha

Administrators
  • Content count

    11,204
  • Joined

  • Last visited

  • Days Won

    521

Everything posted by Sascha

  1. Sascha

    Collider buggt sich durch Terrain

    Nö, machen wir bei uns nicht.
  2. Sascha

    Collider buggt sich durch Terrain

    Nein. Zum einen ist das wie gesagt nur die letzte Variante, wenn alle anderen wirklich nicht in deiner spezifischen Situation funktionieren, weil alle drei ganz hervorragend sind. Zum anderen ist der Kern von Variante 4, dass es da eben nicht "den Weg" gibt, wie man das macht, sondern man eben eine ganz eigene Lösung baut. Die Basis ist, sofern man bei der Standard-Physik-Engine bleibt, die Physics- (bzw. die Physics2D-)Klasse. Aber ab da wird jede Anleitung sinnlos, weil es hier im Kern um eine maßgeschneiderte Lösung geht.
  3. Sascha

    Collider buggt sich durch Terrain

    Transform.Translate ignoriert sämtliche Physik und bewegt das Objekt stumpf so, wie du es ihm sagst. Wenn dein Objekt in bestimmten Situationen nicht durch die Collider bugt, dann liegt das einzig daran, dass Rigidbodys in jedem Physik-Update einmal schauen, ob sie irgendwo drinstecken. Wenn ja, dann bewegen sie sich aus dem anderen Collider heraus. Dabei wird natürlich nicht mehr berücksichtigt, aus welcher Richtung das Objekt ursprünglich gekommen ist, um in dem anderen Collider zu landen. Wenn du also nur weit genug in irgendetwas reingehst, geht der Rigidbody einfach auf der anderen Seite wieder heraus, weil's der kürzere Weg ist. Lange Rede, kurzer Sinn: Niemals Transform.Translate benutzen, wenn du Kollisionsabfrage haben willst. Es gibt eine Reihe von Möglichkeiten, die tatsächlich direkt Kollisionsabfragen integriert haben: CharacterController benutzen. Der ist genau für humanoide Charaktere da und sehr einfach zu kontrollieren. Statt Transform.Translate benutzt du CharacterController.Move. Einen Rigidbody bewegen lassen. Anstatt deines Scripts kontrolliert der Rigidbody deine Position. Die Geschwindigkeit des Rigidbodys kontrollierst du dann mit AddForce oder über velocity. NavMeshAgent benutzen. Wenn der Spieler nur auf einer vorgegebenen Fläche laufen können muss (und nicht z.B. von Plattform zu Plattform springen kann), dann kannst du ein NavMesh bauen und da einen NavMeshAgent drüberschicken. Geht auch recht einfach. Eigene Kollisionsabfragen. Ist eher was für Fortgeschrittene, aber wenn keine der anderen drei Varianten dir das gewünschte Ergebnis geben kann (heißt nicht, dass du beim ersten Problem sofort aufgeben solltest ), dann kann man auch sein ganz eigenes System bauen.
  4. Klingt ganz stark nach "Scripts übernommen, ohne zu verstehen, was sie tun". https://library.vuforia.com/articles/Solution/ground-plane-guide.html
  5. Joa, keine Fehler (siehe 0 neben dem Achteck oben rechts). Dann sind da irgendwelche anderen Dinge am Werk, die sich gegenseitig beeinflussen. Völlig ohne Grund passiert so etwas selbstverständlich nicht. Da heißt es: Szene zerpflücken, Teile löschen und alles immer weiter reduzieren, bis alles irrelevante weg ist und man ein Minimalbeispiel hat, in dem das Problem aber immer noch auftritt. Damit isoliert man die Fehlerquelle und kann sie genauer untersuchen.
  6. Sascha

    [Gelöst]Tree Editor Errors

    Okay... das Ding ist lange nicht mehr mit Beachtung beschenkt worden. Wenn da solcherlei Fehler sind, kannst du höchstens versuchen zu reproduzieren, welcher eigentlich-völlig-normale Arbeitsschritt das auslöst und den meiden. Wenn du sogar genau feststellst, woran das Problem liegt, kannst du einen Bug Report schreiben. Ansonsten halt Fehler ignorieren so gut es geht, oder das Ding nicht benutzen.
  7. Ja, wegen Geschmackssachen rate ich nicht dringend con Dingen ab Genau deswegen. Unsauberes Programmieren ist halt keine Erfindung irgendwelcher Code-Gourmets, es gibt reale Nachteile, wenn man unsauberes Zeug schreibt. Beim Beispiel von GameObject.Find ist eine der möglichen Probleme, dass der Name des GameObjects irgendwann einmal geändert wird (z.B. weil du einen Rechtschreibfehler korrigierst oder merkst, dass ein anderer Name besser wäre). Oder du stellst fest, dass die Komponente auf einem anderen GameObject viel besser aufgehoben wäre und verschiebst sie. Und zack, funktioniert dein Script nicht mehr. Und noch viel besser: Dein Compiler sagt dir nichtmal, dass etwas nicht stimmt. Du hast da halt ne lächerlich mächtige Rechenmaschine, deren Programme in der Lage sind, dir ganz genau zu sagen, wo in deinem Code etwas nicht stimmt - aber bei GameObject.Find geht das nicht. Wenn's da kracht, dann krachts einfach während das Spiel läuft. Und zwar nichtmal unbedingt in der Zeile, in der der Fehler tatsächlich sitzt. Sowas zu bauen ist so das Programmier-Äquivalent zu Antibiotika-resistenten Bakterien.
  8. Hm, vielleicht ist das Konzept noch ein bisschen zu weit gegriffen. Nimm stattdessen sonst GameObject.Find. Ich kann nicht so ganz fassen, dass ich das sage, weil ich sehr viel Zeit damit verbracht habe, Leuten zu erklären warum man diese Methode niemals nutzen sollte private void OnMouseDown() { var playerStats = GameObject.Find("Name des GameObjects auf dem die Komponente ist").GetComponent<PlayerStats>(); playerStats.GetXP(); }
  9. "Nicht verwendbar" ist halt nicht richtig. Du kannst es nicht mehr als Komponente auf ein GameObject ziehen, richtig. Aber wie du an dem kleinen Beispiel merkst, funktioniert's auch ohne.
  10. Sascha

    [Gelöst]Tree Editor Errors

    Wäre ne nicht ganz unwichtige Information, womit die die Bäume gemacht hast. Warum muss man eigentlich immer raten? Ist das dieser Vanilla-Tree-Editor?
  11. Mit Youtube arbeiten ist, wie man hört, alles andere als spaßig. Aber generell geht das, auch wenn ich nicht sicher bin, ob du vernünftig gegen Verstöße vorgehen kannst. Hierzu ein hervorragender Talk: Ich empfehle wärmstens, sich den einmal komplett anzusehen. Das empfehle ich ganz generell jedem, weil dieser Talk wirklich einzigartig ist. Zu deinem Thema sagt er bei Minute 33 etwas, und dann bei 38:38 nochmal. Das so genannte "Review Embargo" oder "Press Embargo" hat bei denen nämlich nicht funktioniert. Aber das Konzept gibt es.
  12. Ne, nimm mal nur die drei Scripts von mir oben, sonst nichts. Mach dir auch gerne ein neues, leeres Projekt auf. Nur um das mal auszuprobieren und zu lernen.
  13. Sascha

    Shared Assets

    Unity hat inzwischen einen Package Manager, den kann man auch für eigene Paketquellen benutzen, auch wenn das nach meinem letzten Stand immer noch nicht so komfortabel ist, wie es mal sein soll. Ansonsten sollte man sowieso für alle Projekte Versionskontrolle benutzen, und da gibt's dann auch sowas wie Submodule. In meinen Projekten gibt's einmal "git submodule add <repo-url>" und dann hab ich das Paket im Projekt, fertig.
  14. Komponenten werden von Unity nur dann aktiviert, wenn in ihnen eine unbehandelte Exception während eines MonoBehaviour-Events (Start, Update, ...) fliegt. Schau also mal die Konsole, was du für Exceptions hast.
  15. Sascha

    Bäume und Pflanzen für Unity

    Nein.
  16. Wenn du damit meinst, dass du die Klasse "PlayerStats" aus meinem Post nicht mehr als Komponente benutzen kannst: Das ist gewollt und völlig richtig so. Vergiss mal alles, was du bisher gemacht hast, und kopiere diesen Code in dein Projekt: public static class PlayerStats { public static int xp = 0; } // Das hier kommt auf ein GameObject mit Collider, dein Button auf den du drückst public class IncreaseXPButton : MonoBehaviour { private void OnMouseDown() { PlayerStats.xp += 10; } } // Das hier kommt einen anderen Button (auch wieder einfach nur ein GameObject mit Collider public class DisplayXPButton : MonoBehaviour { private void OnMouseDown() { Debug.Log("Gerade haben wir " + PlayerStats.xp + " xp!"); } } Den zweiten Button (drittes Script kannst du benutzen, um dir anzusehen, wieviel XP wir gerade haben. Der andere Button (zweites Script) fügt jedes Mal 10 XP hinzu. Das erste Script wird nirgendwo draufgezogen, weil es eben statisch ist und daher nicht Instanzen davon erzeugt werden (und genau das tut man, wenn man ein Script als Komponente auf ein GameObject zieht).
  17. Sascha

    Bäume und Pflanzen für Unity

    Eigene Shader kosten nicht mehr Performance als eingebaute. Oder wenn du Backface Culling meinst - das auszuschalten kostet auch nixht wirklich irgendetwas.
  18. Du kannst entweder mit dem Package Manager Text Mesh Pro aus deinem Projekt nehmen (solltest du tun, wenn du es nicht brauchst), oder aber in den Project Settings unter Player deine .NET-Version hochstellen (solltest du so oder so tun).
  19. Sascha

    Bäume und Pflanzen für Unity

    Wenn ich mich nicht irre, braucht man dafür immer noch einen eigenen Shader. Ein Cull-Off-Standard-Alphatest-Shader ist eher noch einer der einfacher zu bastelnden Sachen, aber ist eben trotzdem noch ein eigener Shader.
  20. 1. Installationen von Programmen werden nicht gelöscht, wenn man ein anderes Programm Installiert. Und du machst ja keine Updates, du installierst eine neue Unity-Version. Nicht Unity Hub zu benutzen ist aber auch einfach keine gute Idee. 2. Unity hat seit einiger Zeit einen Package Manager. Der installiert einige Sachen, die man sehr oft braucht, einfach mit. Kannst unter Window > Package Manager mal schauen und Sachen aus deinem Projekt nehmen. Die Library braucht man sehr wohl, und alles darin ist. Unity stellt fehlende Sachen nur einfach wieder her, wenn sie plötzlich fehlen.
  21. Sascha

    Bäume und Pflanzen für Unity

    Du kannst wunderbar eine Plane nehmen und da eine Textur mit Blättern draufpacken, und wo kein Grün ist ist die Textur halt transparent. In Unity musst du dann nur beim Material auswählen, dass es bitte nicht opak, sondern Transparent sein soll. Am besten mit Alpha Test. Kannste einfach im Dropdown-Menü auswählen. Backface Culling machen die meisten Shader von ganz alleine. Es bedeutet: Backface = Rückseite, Culling = Herausfiltern. Die Rückseite einer Fläche (in der Regel: Die Innenseite des Modells) wird dann nicht gerendert. Wenn du eine Fläche von beiden Seiten sehen willst, musst du Backface Culling ausschalten.
  22. Du darfst nicht einfach Code übernehmen, ohne zu verstehen, was er macht. Ein Pseudo-Singleton besteht aus zwei Teilen: Einem statischen Feld und der Zuweisung in z.B. Awake. Ein statisches Feld ist eine Variable, die nicht an Objektinstanzen gebunden ist. Wenn du z.B. eine Lichtkomponente hast, kannst du das auf drei GameObjects packen und jedes deiner Lichter kriegt eine andere Farbe. Weil eben die Farbeigenschaft nicht statisch ist, sondern per Objekt existiert. Ein statisches Feld dagegen existiert nur einmal im gesamten Programm. Während du bei einem normalen Feld dem Programm sagen musst, welches Objekt du meinst (also, die Farbe welchen Lichts), kannst du bei einer statischen Variable einfach so darauf zugreifen, weil sie nur einmal existiert. Das kannst du jetzt benutzen, damit Dinge, die es eben nur einmal gibt, sich selbst in einer statischen Variable anmelden. Und genau das macht public static Level singleton { get; private set; } private void Awake() { if (singleton == null) { singleton = this; } else { Destroy(gameObject); } } Dein Fehler ist jetzt, dass du das auf die GameObjects geschmissen hast, auf die man klickt. Aber die Idee hinter diesem Pattern ist, dass du das für die Dinger benutzt, die nur einmal existieren (z.B. dem Spieler), sodass andere Objekte es finden können. Nur so nebenbei... Es scheint fast so, dass deine beiden Komponenten "Motivation" und "Level", also die beiden, die Pseudo-Singletons sein sollten, nicht einmal Komponenten sein brauchen. Benutze einfach dein neues Wissen über statische Felder und mache: public static class PlayerStats { public static int xp = 0; } und dann gibt's ganz einfach: PlayerStats.xp += 10;
  23. Gibt halt die ganz schlechte Varianten, aber mit denen will ich gar nicht erst anfangen. Also, wenn du den Artikel in unter acht Minuten durchliest, brauchst du nich nicht zu wundern wenn's nicht ankommt. Aber fangen wir mal ganz am Anfang an. Was eine statische Variable ist, weißt du?
×