Jump to content
Unity Insider Forum

malzbie

Moderators
  • Content Count

    5,070
  • Joined

  • Last visited

  • Days Won

    350

malzbie last won the day on January 10

malzbie had the most liked content!

Community Reputation

1,552 Excellent

2 Followers

About malzbie

  • Rank
    Moderator
  • Birthday 10/30/1968

Profile Information

  • Gender
    Male
  • Location
    Kassel, Hessen, Deutschland

Recent Profile Visitors

20,978 profile views
  1. Ja, es ist bei uns halt so, dass wir sogut wie keine Themen löschen. Der Sinn eines Forums ist ja, dass sich Informationen anhäufen und somit anderen Leuten helfen können. Es wäre schön gewesen, wenn du uns deine selbst gefundene Lösung mitgeteilt hättest um eben anderen Leuten, die später vielleicht ein ähnliches Problem haben, helfen zu können. Jetzt ist es egal, denn die Fragestellung sieht ja auch keiner mehr. Trotzdem löschen wir nicht.
  2. malzbie

    Sound

    Schau dir mal die Soundeinstellungen an. Da gibt es einen Bereich für 3D Sound. Ja und da stellst du dann die Entfernung ein, ab wann du den Sound hören willst. Mit dem Grafiksystem kannst du dann noch einstellen, wie der Sound beim näherkommen seine Lautstärke verändert. Schau hier: https://docs.unity3d.com/Manual/class-AudioSource.html
  3. Also als aller Erstes solltest du immer alle bekannten Fehler beseitigen, bevor du auf die Suche gehst. Ich sehe in deiner Konsole, dass irgendein Objekt nicht bekannt ist. Wenn du keine Fehler mehr angezeigt bekommst und dein Problem immer noch da ist, dann schau, ob sich evtl. 2 Objekte an der selben Position befinden. Könnt eja sein, dass dieses Gebäude 2 Mal vrohanden ist oder zur Laufzeit nocheinmal erstellt wird. Da die Texturänerung immer bei den selben Kamerawinkeln auftritt, könnte es ein Z-Buffer Problem sein, was gerne auftritt wenn 2 Objekte am selben Ort sind. Vielleicht ist da aber auch ein Problem mit LOD. Keine Ahnung ob ihr LOD nutzt.
  4. So wie ich das sehe, ist dein "greifbar" machen ein lösen aus der Hierachie. Der Bone verliert also seinen Parent. Warum gibst du dem Bone nach seiner Bewegung nicht einfach wieder den alten Parent? Scon wäre er wieder in der hierachie drin. https://docs.unity3d.com/ScriptReference/Transform-parent.html
  5. malzbie

    Backup

    Im Prinzip wäre es möglich. Du müsstest dir aber Images deiner Festpaltten erzeugen und die dann auf den neuen Rechner, der genausoviele Platten hat, schreiben. Dafür brauchst du eine Backupsoftware, die dann auf dem Neuen Rechner z.B. per USB Stick startet UND die Möglichkeit hat über eine Netzwerkverbindung deine Cloud einzubinden. Du könntest natürlich auch einen anderen Rechner nutzen um die Backups runter zu laden und z.B. auf eine Externe Platte zu schreiben. Da Windows nicht einfach die Programme von einem zurückgespielten Image einbindet (Windows bindet nur ein wenn du auch installierst, weil dann die nötigen Daten in die Registry und diverse Ordner geschrieben werden), musst du halt von allem ein Image haben, auch von der WIndowsplatte. Und da könnte es zu Problemen kommen. Denn dein neuer Rechner in den USA wird ja nicht die gleiche Hardwarekonfiguration haben, wie der bei dir zuhause. Windows könnte dann dicke Backen machen, weil ja kein Treiber mehr stimmt. Windows 10 ist relativ gutmütig und sollte die Probleme erkennen und versuchen sie selbst auszubügeln, sodass du wenigstens eine Minimalkonfiguration hast und dann gewisse Treiber selber nachinstallieren kannst. Das muss aber nicht sein. Ich gebe dir ne Chance von 85%!
  6. Ja! Alles was wichtig ist, sollte auch erwähnt werden. OK. Da du mit Box Collidern besser zurecht kommst, als mit dem Meshcollider, gehe ich davon aus, dass eine der Wände, die der Meshcollider umspannt, wirklich sehr dünn ist. Und da du nicht über die Physik bewegst, kommt es eben zur Durchtunnelung. Ich sehe da eigentlich nur die Möglichkeit, das du Fixed Timestep reduzierst. https://docs.unity3d.com/Manual/class-TimeManager.html Geh mal auf 0.005. Geht auch noch tiefer, aber irgendwann kostet das so viel Performance, dass du den Zyklus nicht mehr erreichen kannst. Dieser Timestamp ist der Intervall, den die Physik durchfährt. Je kleiner der Wert ist umso öfter wird überprüft. Kostet aber jedes Mal Prozessorleistung. Merke dir auch: Je dicker ein Collider ist umso eher wird eine Kollision erkannt. Wenn von der einen Überprüfung zur anderen Überprüfung ein Objekt die Dicke eines Kolliders überwinden kann, ist der Kollider zu dünn oder das Objekt zu schnell. Dickere Collider können da Abhilfe schaffen. Genauso kannst und solltest du beim Rigidbody die Collision Detection auf auf "Continuous" oder "Continuous Dynamic" schalten. Um schnelle Bewegungen noch besser zu erfassen.
  7. Willkommen! Der Typ des Colliders hat nichts damit zu tun, ob du ihn bewegen kannst oder nicht. Auch ein MeshCollider bewegt sich mit dem Objekt mit, wenn das Objekt bewegt wird. Damit etwas kollidiert, also nicht durch andere Objekte duchflutscht, müssen diese Objekte jeweils einen Collider haben. Das sollte ja klar sein. Außerdem muss mindestens eines dieser Objekte einen Rigidbody haben, denn nur mit einem Rigidbody wird auch eine Kollision ausgewertet und die ganzen physikalischen Eigenschaften wie Reibung, Masse, Federung und Bremswirkung auf die Rotation oder Bewegung werden mit einberechnet. Ob jetzt alle Objekte einen Rigidbody haben oder nur der Ofen, hängt davon ab, welche Objekte physikalische Eigenschaften haben sollen. Das kann man also nicht so ohne Weiteres sagen. Man sollte aber an RB's sparen, denn jeder RB berechnet ja etwas und das kostet Leistung. Dinge, die nicht bewegt werden, brauchen keinen RB. Wenn du dann ein Objekt mit einem RB bewegst, dann soltest du das mit physikalischen Befehlen machen. Also nicht mit Transform-Befehlen arbeiten, denn die Physik wird in einem anderen Zyklus berechnet, als der Rest, der ja abhängig von der Framerate ist. Somit könnte es bei schnellen Bewegungen schnell zu Durchtunnelungen kommen. Nutze also die Force oder die Velocity um den RB zu bewegen.
  8. Ich habe mir das mal angeschaut. Die Figur hat ganz viele Materialien und für jedes Material auch eine Polygonselektion. Und wie du siehst, ist das erste Material mit der ersten Selektion in der Hierachie genau das, was bei dir nur eingefärbt wird. Ich habe das jetzt nicht in Unity getestet und ich weiß jetzt auch nicht aus dem Stehgreif, wie man per code die Selektionen bestimmen kann. Aber ein Tipp: Versuch doch mal die Figur ohne Texturen zu exportieren. Da sollte dann auch die Selektionsinfo weg sein. Es könnte auch an dem Haken Collapse UV Maps liegen. Der Exporter hat nämlich wirklich eine einzige UV Map raus, wo alle Selektionen übereinander liegen. Also mach die Haken für die Textures und die UVMap mal raus.
  9. malzbie

    Objekt bewegen

    Tja, da sind viele Dinge, die fehlen können und viele Dinge, die auf jeden Fall falsch sind. Hast du die Variable Target auch mit einem GameObject bestückt? Heissen deine Wände auch genauso, wie du die Namen abfragst? Hat dein Speed auch einen Wert? Hat denn deine Kugel einen Rigidbody, oder wenigstens beide Wände? Wenn 2 Dinge kollidieren sollen, muss mindestens ein RB dabei sein, denn nur darüber wird überhaupt eine Kollision erfasst. Aber das Hauptdingen, wenn jetzt alle Werte, Objekte und Namen richtig sind, ist das was du da bei der Kollision machst. In dem Moment, wo du mit einer Wand kollidierst, führts du Vector3.MoveTowards aus. Entweder in die eine Richtung, oder in die Andere. Aber eben nur in diesem einen Moment!!! In der Update hast du aber ein transform.Translate nach rechts, welches ständig ausgeführt wird. So kann das nicht gehen.
  10. Sach ma. Kann es sein, dass du da 2 UV Maps auf der Figur hast?
  11. Im Build sollte alles so funktionieren, wie du es im Editor siehst. Es sei denn du hast deine Prefabs in einem Ordner Namens Editor. Das da drin wird nicht mit exportiert. Schau außerdem, ob du irgendeine Fehlermeldung (rot) in der Console siehst, wenn du das Game im Editor testest. Gerade fehlende Zuweisungen oder IndexOutOfRange Fehler führen zu den dollsten Ergebnissen.
  12. Dafür, dass ihr ganz am "Anfang" seid, ist es echt nicht schlecht! Daumen hoch!
  13. Ich kann dich voll verstehen. Auch zu meiner Zeit gab es noch kein Informatik Studium. Ich habe aus Interesse von alleine mit Basic auf dem VC20 angefangen. Alles ohne Internet! Ich habe damals, vor 35 Jahren, schon viel gelernt, bin aber regelmäßig gescheitert. Und trotzdem bin ich heute in der Lage komplette Spiele zu erstellen (Grafik, Sound, Musik, Objekte, Logik), weil ich an all den Dingen interesse hatte und im Lauf der Zeit immer mehr gelernt habe. Was dir jetzt helfen könnte, ist Folgendes: Geh einfach einmal davon aus, dass du nicht ein Ding baust, um ein Spiel zu erstellen, sondern viele unterschiedliche Dinge, die miteinander Kommunizieren können und als Ganzes dann ein Spiel ergeben. Dei Puzzlespiel besteht aus vielen Dingen. Da ist der Ablageort, der 25 Bereiche hat, und da sind 25 Puzzleteile. Muss jedes Ding jetzt alles von den anderen Dingen wissen? Nein! Dem einzelnen Puzzleteil ist es doch total egal, was mit den Anderen Puzzleteilen ist. Es muss auch nicht wissen, wo es aufgehoben wurde und wo es hingelegt wird. Es muss aber wissen wenn es aufgehoben wird und wenn es hingelegt wird. Es sollte außerdem eine Identifikation haben und das Script kennen, welches die Auswertung macht, wo das Script auch immer liegt. Alle 25 Puzzleteile sind von der Art her also gleich und haben somit alle das gleiche Script. Sie unterscheiden sich eigentlich nur in der Identifikation, also von der Puzzleteil-Nummer. Wird jetzt eines dieser Puzzleteile mit der Maus angeklickt, weiss es, dass es etwas mit ihm passiert. Das Puzzleteil wacht also auf und könnte jetzt z.B. immer der Mausposition folgen, oder einfach nur seine Identifikationsnummer an das Auswertungsscript übergeben, oder, oder, oder. Wird dieses Puzzleteil jetzt wieder gehen gelassen, dann wird es auf jeden Fall dem Auswertungsscript sagen, dass es so ist und wo es sich gerade befindet. Es könnte also in eine Methode oder Funktion des Auswertungsscriptes rein springen und die wichtigen Daten gleich mit übermitteln. In dieser Funktion würde dann überprüft, ob das Teil nahe genug an seinem Soll-Ort liegt. Tut es das, dann würde das Teil an die exakte Position geschoben und sich irgendwie gemerkt, dass ein Teil richtig liegt. Das Puzzleteil macht also nur dann etwas, wenn es aufgehoben wird bzw. ist oder wenn es abgelegt wird. Sonst macht es eigentlich nichts. Das Auswertungsscript macht immer nur dann etwas, wenn das Puzzleteil in die Funktion oder Methode rein springt. Einmalig überprüft es, die richtige Position des Teils. Passt die Position, wird sich gemerkt, dass ein Teil richtig liegt und es wird zusätzlich überprüft, ob nun alle Teile richtig sind. Wenn ja, wird ein weiteres Ereignis gestartet, wobei der Erfolgstext angezeigt wird und dann auf beenden des Spiel gewartet wird. Wenn nein, passiert nichts. Eine andere Möglichkeit wäre, dass jedes Puzzleteil seinen Bestimmungsort schon kennen würde. Dann würde das Teil beim Ablegen selber überprüfen, ob es richtig liegt und dann eben einfach nur den Erfolg an das Auswertungsscript senden. Das könnte etwas einfacher zu handhaben sein. Wie dem auch sei. Du solltest dir einfach überlegen, was ein Ding alles können und wissen sollte um zu funktionieren. Welche Information ist für welches Ding wichtig und welche nicht. Sind viele Dinge nahezu gleich und unterscheiden sich nur in wenigen Bereichen, dann sollte man sie so aufbauen, dass sie wiederverwendbar sind. Ein Puzzleteil beommt einfach nur eine eigene Nummer, evtl. einen Zielort und eine entsprechende Grafik. Alles Andere ist bei allen Puzzleteilen gleich. Ein Informationsaustausch von einem Objekt zum Anderen sollte nur Ereignisgesteuert sein. Nur bei einer entscheidenden Änderung muss das andere Objekt etwas darüber wissen. Und auch nur dann, muss etwas ausgewertet werden. Ob jetzt ein Objekt eine Sache an ein anderes Objekt übermittelt, also z.B. in eine Methode rein springt, oder ob ein Objekt einen Variablen-Wert eines anderen Objektes zu gewissen Zeiten abfragt, ist eine Frage der Vorliebe, des Aufbaus und der Häufigkeit des Informationsaustausches. Beides geht und beides macht Sinn.
  14. Du darfst nicht im Check hochzählen, sondern da, wo du das Puzzleteil richtig platzierst. Das sollte ja für jedes Teil nur einmal passieren. (Sollte, denn diese Positionsabfrage sollte nur dann kommen, wenn du das Teil loslässt. Also bei OnMouseUp, oder so.) Aber es führen viele (alle) Wege nach Rom! Versuche jedenfalls gewisse Sachen immer nur bei einem Ereignis auszuführen, nicht ständig in der Update. Wenn ein Puzzleteil einmal liegt, also an die entsprechende Position gebracht wurde, ist das Ereignis da. Aber eben nur dann. Und nur dann erhöhst du den Zähler. Du kannst natürlich auch mit einer Liste oder einem Array arbeiten und dort etwas hinzufügen oder einen Wert einer Stelle ändern. Aber niemals immer wieder duch den ganzen Code fahren, denn das kostet Leistung! Das wäre nämlich so, als würdest du ein Buch lesen und bei jedem neuen Wort immer wieder von vorne anfangen, bis du beim nächsten neuen Wort bist, und dann wieder von vorne anfangen, usw. usw. Nur weil ein Rechner das irre schnell kann, heisst das nicht, dass es keine Zeit oder Leistung kostet.
×
×
  • Create New...