• Announcements

    • Lars

      Allgemeine Forenregeln   03/13/2017

      Forenregeln Nimm dir bitte einen Moment um die nachfolgenden Regeln durchzulesen. Wenn du diese Regeln akzeptierst und die Registration fortsetzen willst, klick einfach auf den "Mit der Registrierung fortfahren"-Button. Um diese Registration abzubrechen, klick bitte einfach auf den "Zurück" Button deines Browsers. Wir garantieren nicht für die Richtigkeit, Vollständigkeit und Brauchbarkeit der Nachrichten und sind auch nicht dafür verantwortlich. Die Beiträge drücken die Meinung des Autors des Beitrags aus, nicht zwangsläufig das, wofür die Forensoftware steht. Jeder Nutzer, der denkt, dass ein veröffentlichter Beitrag unzulässig bzw. störend ist, ist aufgefordert uns unverzüglich per E-Mail zu kontaktieren. Wir haben das Recht störende Beiträge zu löschen und bemühen uns, das in einem realistischem Zeitraum zu erledigen (sofern wir beschlossen haben, dass die Löschung notwendig ist). Du akzeptierst, durchgehend während der Nutzung dieses Services, dass du dieses Forum nicht dazu missbrauchen wirst, Inhalte zu veröffentlichen, welche bewusst falsch und/oder verleumderisch, ungenau, beleidigend, vulgär, hasserfüllt, belästigend, obszön, sexuell belästigend, bedrohlich, die Privatsphäre einer Person verletzend oder in irgend einer Art und Weise das Gesetz verletzen. Des Weiteren akzeptierst du, dass du keine urheberrechtlich geschützte Inhalte ohne Erlaubnis des Besitzers in diesem Forum veröffentlichst. Mit dem Klick auf den "Mit der Registrierung fortfahren"-Button, akzeptierst du zudem unsere Datenschutzerklärung und stimmst der Speicherung deiner IP-Adresse und personenbezogenen Daten zu, die dafür benötigt werden, um dich im Falle einer rechtswidrigen Tat zurückverfolgen zu können bzw. permanent oder temporär aus dem Forum ausschließen zu können. Es besteht keine Pflicht zur Abgabe der Einwilligung, dies erfolgt alles auf freiwilliger Basis.   Zusatzinformationen Der Forenbetreiber hat das Recht, Nutzer ohne Angabe von Gründen permanent aus dem Forum auszuschließen. Des Weiteren hat er das Recht, Beiträge, Dateianhänge, Umfrage, Blogeinträge, Galleriebilder oder Signaturen ohne Angabe von Gründen zu entfernen. Mit der Registrierung verzichtest du auf alle Rechte an den von dir erstellten Inhalten, bzw. treten diese an das Unity-Insider.de und Unity-Community.de ab. Dies bedeutet im Klartext, dass das Unity-Insider.de und Unity-Community.de frei über deine Texte verfügen kann, sofern diese nicht wiederum die Rechte anderer verletzen. Es besteht weiterhin kein Anspruch von registrierten Nutzern bzw. ehemaligen registrierten Nutzern darauf, dass erstellte Inhalte und/oder die Mitgliedschaft (User) wieder gelöscht werden (Erhaltung der Konsistenz dieses Forums).   Einwilligungserklärung Wenn du mit der Speicherung deiner personenbezogenen Daten sowie den vorstehenden Regeln und Bestimmungen einverstanden bist, kannst du mit einem Klick auf den Mit der Registrierung fortfahren-Button unten fortfahren. Ansonsten drücke bitte Zurück. Stand: 07.03.2011

Zer0Cool

Members
  • Content count

    532
  • Joined

  • Last visited

  • Days Won

    35

Zer0Cool last won the day on June 17

Zer0Cool had the most liked content!

Community Reputation

117 Excellent

4 Followers

About Zer0Cool

  • Rank
    Advanced Member
  • Birthday 01/04/1974

Contact Methods

  • Website URL
    http://https://www.facebook.com/huginmuninstudios
  • Skype
    zer0f0rce

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

1,991 profile views
  1. Ich sehe immer noch keinen Grund, warum dein Gebäude aus kinematic RBs bestehen muss. Entweder dein Gebäude ist von Anfang an ein Gebäude das aus mehreren non-kinematic RB und Collidern besteht (die einfachste Lösung), oder (wegen der Performance) dein Gebäude besteht einfach aus mehreren statischen Meshes mit Triggern und diese wandeln bei einer Kollision die getroffenen Teile des Gebäudes in Meshteile mit non-kinematic RB und Collidern um. Der anspruchsvolle Teil ist dann noch, nach der Umwandlung die Kräfte auf die neu erzeugten Gebäudeteile korrekt zu übertragen oder die Umwandlung findet statt, kurz bevor z.b. der Panzer in die Nähe der entsprechenden Gebäudeteile kommt (Trigger). Bei einem Projektil würde man die Umwandlung beim Einschlag des Projektils stattfinden und danach würde man eine Explosionsforce am Einschlagspunkt erzeugen. Alle non-kinematic RB sollten dabei eine Masse haben die einem Gebäude entsprechen.
  2. Vermutlich betritt "etwas" den Trigger mehrfach. Ergänze mal den Code um die Methode OnTriggerExit() und setze da mal eine Debugausgabe hinein. Kann auch für OnTriggerEnter() nicht schaden. Zudem kannst du dir auch einmal ausschauen, wer da eigentlich deinen Trigger betritt: void OnTriggerEnter(Collider other) { Debug.Log("OnTriggerEnter: " + other.gameObject.name + "("+ Time.time +")"); } void OnTriggerExit(Collider other) { Debug.Log("OnTriggerExit: " + other.gameObject.name + "("+ Time.time +")"); }
  3. Ein schneller "Fix" wäre, du solltest es aber noch sauberer implementieren. Hintergrund: Du setzt die "shards" ja erst später innerhalb der Coroutine und deshalb kommt es zu der NPE in der FixedUpdate. private void FixedUpdate() { if (shards!=null) { foreach (var shard in shards) { shard.AddForce(Vector3.down * 20); } } } Zudem brauchst du noch eine Abbruchbedingung, du möchtest ja nicht bis in alle Ewigkeit den Splittern in der FixedUpdate eine Kraft hinzufügen... Beispielsweise könntest du abbrechen, wenn sie den Boden erreicht haben. Zu dem seltsamen Bug, prüfe die OnTriggerEnterEnter-Methode, sie darf nur 1x aufgerufen werden.
  4. Ich verstehe nicht, warum du überhaupt eine Umwandlung von kinematic auf non-kinematic machst (d.h. warum ist es nicht gleich non-kinematic). Kinematic würde ich nur im Einzelfall verwenden, aber auf jeden Fall nicht bei Objekten die statisch sind und sich nicht bewegen. Zu dem anderem Problem, ich würde das getroffene Objekte nur dann zerteilen, wenn das Projektil mit einer gewissen Beschleunigung auf das getroffene Objekt einschlägt, ist es unterhalb des Grenzwertes, bleibt das Objekte erhalten und es wird ggf. nur Kraft auf den RB des Objektes übertragen. Als Beispiel: - ein Projektil trifft auf ein Fass, ist der Beschleunigungsvektor < 1 (velocity.magnitude), dann wackelt das Fass nur leicht, da der RB des Projektil's Kraft auf den RB des Fasses überträgt - ist der Beschleunigungsvektor > 1, dann wird das Fass zerteilt und die Bruchstücke des Fasses werden instanziiert (RB's non-kinematic + useGravity).
  5. Soweit ich weiß ist "OnTriggerEnter" eine Methode der Klasse "MonoBehaviour" (seltsamerweise finde ich sie aber auch unter der Klasse "Collider"). Mich wundert, daß er ohne "MonoBehaviour" als Basisklasse seiner Klasse anzugeben überhaupt auf die Methode zugreifen kann, aber wenn Unity hier per Reflection sucht wäre das eine Erklärung. Ich hätte eher gedacht - im Sinne einer sauberen Lösung-, daß man den Inhalt in einer eigenen Methode kapselt und dann am Ende der Vererbungshierarchie diese Methode referenziert.
  6. Ansonsten werden bei mir Partikel durch normale Meshes verdeckt, so daß ich kein Problem sehe, wenn ein Nebel durch ein Objekt hindurchzieht. Ein "Fließverhalten" der Partikel um das Objekt herum wird sich kaum realisieren lassen. Partikel sind da eher "dumm".
  7. Es gibt auch eine "Art von Nebel" über die Szene selbst. Dieser ist erreichbar über "Lightning" / "Scene" und "Fog". Im Deferrend Rendering Path muss man aber zusätzlich einen Kamerafilter "Global Fog" verwenden um diesen zu erzeugen. Dieser Nebel taugt aber zumeist nur dafür, um weit entfernte Objekte sanft auszublenden, ist sozusagen eine Art atmosphärer Nebel. https://docs.unity3d.com/550/Documentation/Manual/script-GlobalFog.html Vermutlich wolltest du aber Nebel auch im Nahbereich, wo du dann leider zu Partikeleffekten greifen musst. Wenn du einen Partikeleffektnebel verwendest, dann kannst im Kollisonsmodul einstellen, was passieren soll, wenn die Partikel auf ein Objekt treffen: https://docs.unity3d.com/ScriptReference/ParticleSystem.CollisionModule.html Beispielsweise wenn du Kollision auf "World" und "Lifetime Loss" auf 1 setzt, dann werden die Partikel bei einer Kollision vernichtet. Mir ist nicht bekannt, ob es auch einen Kameraeffekt für Nebel im Nahbereich gibt, wäre halt schneller als ein Partikeleffektnebel.
  8. Ah interessant, dieses Verhalten konnte ich bei meinem Controller auch reproduzieren, aber nur indem ich die Bodenhaftung des Spielercolliders extrem erhöht habe. Dann fängt der Gegner an zu sliden, wenn er versucht gegen den Spieler nach vorn zu schlagen. Seltsamerweise verhält es sich anders, wenn ich die Masse des RB des Spielers erhöhe und damit der Gegner eine geringere Masse hat, dann fängt der Gegner an gegen den Spieler zu laufen und "bumped" dann wieder zurück, also er slided nicht nur sondern er wird auch zurückgestoßen, letzteres sieht natürlich extrem unnatürlich aus. Naja, das mein Spieler weggeschoben wird (wenn der Gegner und der Spieler die gleiche Masse haben) liegt wohl an dem Rigidbody-Character-Controller (von Opsive) den ich verwende. Dieser Controller besteht aus einem Capsulecollider und einem Rigidbody. Da hast du einen klaren Vorteil beim normalen CC. Hier beeinflussen sich die CC's nicht gegenseitig, bzw. sie verhalten sich dann eher wie eine statische Wand.
  9. Mhh, wegschieben kann dich der Gegner wohl nicht, da du ein CC verwendest, aber wenn der Gegner genau vor dem Spieler steht und die Schlaganimation einen Schritt nach vorn beinhaltet, dann muss die Animation ja durch den Spieler hindurch, der CC kann die Animation ja nicht verhindern. Ich habe mal einen Test gemacht und den Spieler künstlich fixiert, dabei prallt der Gegner bei der Schlaganimation (mit Schritt nach vorn) gegen den fixierten Collider des Spielers und wird wieder nach hinten versetzt nachdem er geschlagen hat, das sieht auch extrem komisch aus. Es sieht dabei so aus, als wenn der Gegner gegen den Spieler prallt und wie ein Gummiball wieder nach hinten geschleudert wird. Wie man es dreht und wendet, entweder clippt der Gegner bei der Vorwärtsbewegung durch den Mesh des Spieler oder er prallt gegen den Collider des Spielers und wird dabei nach hinten versetzt / geschleudert. Aber vielleicht ist das Ganze auch ein Problem des RB-Charactercontrollers den ich verwende. Hier wirken sich alle Kräfte auf den Gegner und den Spieler aus und eine Rootmotion ist ja auch eine Kraft.
  10. Ja, das schon, aber ich glaube eben der Schritt nach vorn sollte vom Navmesh (und dann von der Laufanimation) kommen, wenn wieder Platz zwischen dem Spieler und dem Gegner ist. Überlasst man das der Animation, dann achtet sie eben nicht auf genügend Abstand und überrennt quasi den Spieler (oder schiebt sogar den Spieler weg), was dann eben auch unrealistisch wirkt.
  11. Und ich bastele gerade weiter an einem Schwertnahkampf mit Schild in einer Testszene. Der Ritter hat sich gerade einen Treffer eingefangen.
  12. Ich habe gerade ein Problem mit einer Schwerhieb-Animation. Bei dieser Animation geht der Charakter einen Schritt nach vorn und ich vermute hier liegt auch das Problem. Wenn der Gegner exakt vor dem Spieler steht und der Gegner den Spieler dann angreift und dabei einen Schritt nach vorn geht clippt er natürlich in die Geometrie des Spielers hinein. Ich habe nun diese Animation gegen eine Animation ausgetauscht wo der Gegner auf der Stelle bleibt. Entfernt man bei der Originalanimation die Rootmotion nach vorn verschlimmert sich das Problem sogar noch, dabei clippt der Gegner sogar gnadenlos in den Capsulecollider des Spielers hinein und verlässt dabei seinen eigenen Collider! Ich denke Animationen können recht gnadenlos sein und sämtliche Collider um einen Spieler herum ignorieren. Würde mich mal interessieren was ihr so für Erfahrungen damit gemacht habt.
  13. Ich habe mir gerade einmal die Goblinszene angeschaut. Du machst sehr gute Fortschritte, vor allem bei den Kampfszenen. Die Gegnermodelle gefallen mir sehr gut, sind das Eigenentwicklungen oder eine Mischung aus "Kauf" und "Anpassung"? Wie hast du das eigentlich bei dir gelöst, daß die Gegner nicht in das (hervorgestreckte) Schild des Spieler hineinclippen? Wobei das Problem bei dir wohl nicht ganz so kritisch ist, da das Schild etwas seitwärts und dicht am Körper positioniert ist. Hängt natürlich auch sehr stark von der Mechanik des Controllers ab. Hast du den Spielercapsulecollider mit um das Schild gelegt (damit könnte ein Gegner ja auch nicht ins das Schild hineinclippen)? Bei mir liegt der Collider des Schildes außerhalb des Spielercolliders und ich musste explizit dafür sorgen, daß wenn das Schild in einen gegnerischen Collider hineinclippt, das der Spieler diesen wieder verlassen muss.
  14. Ansonsten kann man über die Logs nur sehen, das Unity auf irgendwas wartet also hängt... da das Log nicht fortgeschrieben wird... Sonst kann ich dir noch einmal raten, deinen PC auf Viren und Adware zu checken und mal deine Virenscanner (oder sonstige Programme die im Hintergrund Unity stören könnten) einmal temporär auszuschalten. Zudem würde ich mal in das Ereignislog von Windows schauen. Das geht über das Tool: eventvwr Hier würde ich dann nach Fehlern ausschau halten. Du kannst hier anhand des Zeitstempels nachvollziehen was auf deinem PC passiert ist. Beispielsweise wenn du einen Fehler auf der Festplatte hast:
  15. Hast du deine Unity-Userdaten zur Hand? Du kannst die Unity Logindaten mit in der Commandozeile angeben, da du ja meintest er hängt im Logindialog: (in einer Commandshell) cd \Unity\Editor Unity.exe -password <password> oder Unity.exe -username <username> -password <password> oder über eine Verknüpfung Teste mal aus, ob es was bringt, ob nun vielleicht nun ein anderer Dialog kommt (keine Passwortabfrage mehr)