Jump to content
Unity Insider Forum

Sascha

Administrators
  • Content Count

    12,074
  • Joined

  • Last visited

  • Days Won

    618

Everything posted by Sascha

  1. Ich sehe da nichts, was irgendwie schief gehen könnte. Schau mal hier: Könnte auch hier eine Exception sein. Ansonsten: http://blog.13pixels.de/2019/things-that-can-make-a-difference-in-unitys-play-mode-compared-to-your-build/
  2. Hm, schade. Dann läufts jetzt wohl auf manuelles Eingrenzen hinaus. Also so lange Scripts von GameObjects runternehmen, bis der Fehler nicht mehr auftritt und dann schauen, welches der Dinger schuld ist. Wenn du keine Versionskontrolle nutzt, mach dir einfach eine Kopie von der Szene zum Zerpflücken.
  3. Das ist okay, aber ich kann dir versprechen: Diese Fähigkeit ist unglaublich wichtig für Softwareentwicklung. Aber keine Sorge, da wirst du unweigerlich besser drin, solange du dabei bleibst. Ich glaube (!), hier ist ein Denkfehler. Ein Array ist ein Objekt, das mehrere Variablen gleichartigen Typs hat. Wenn du ein Vector3-Array hast, dann hast du damit eine bestimmte Anzahl von Vector3-Variablen. Wenn ich das richtig verstanden habe, sind Ziel1 und Ziel2 beides einfach Positionen in der Welt. Die kannst du dann nacheinander in dein Array packen. Ändern musst du dann nur den Index. Ich denke allerdings, wenn ich mir deinen Code so ansehe, dass du das eigentlich schon weißt. Kann also gut sein, dass ich das Problem nur nicht verstanden habe. Hmm... kann es sein, dass du mehrere ganze Pfade haben willst? Und dann unter verschiedenen Bedingungen unterschiedliche Pfade abgehen willst? In dem Fall wäre es schon sinnvoll, wenn jeder Pfad ein Array wäre und du entsprechend mehrere davon hättest. Merke dir aber in jedem Fall als Grundregel: Wenn du mehrere Variablen hast und die heißen bis auf die Nummer am Ende alle gleich, dann ist da auf jeden Fall etwas falsch Falls du das meinst, ist der wichtige Hinweis: Arrays sind Objekte. Sie haben damit Referenzsemantik und du kannst in einer Variable erst das eine Array und dann das andere referenzieren. Ein Kopieren von Elementen ist nicht nötig. Ich glaube, das hast du in deinem Ansatz auch irgendwie schon drin. Was du zum Beispiel machen kannst ist, ein Array von Pfaden zu machen, und jeder Pfad hat dann wiederum ein Array von Punkten. Das geht z.B. auch mit GameObjects. Du hast dann ein Pfad-Komponente und baust für jeden Pfad ein GameObject. Dann kannst du diese GameObjects referenzieren, um zu sagen: Hier ist der nächste Pfad.
  4. Die neue DOTS-Physikengine soll wohl deterministisch sein, aber wann die wohl brauchbar wird, steht in den Sternen. Mit dem Suchbegriff "Deterministic" kannst du auf die Suche gehen, aber ich befürchte ehrlich gesagt, dass 100% deterministische Sachen aktuell immer selber gebaut werden müssen.
  5. Ich weiß nicht so richtig, was du damit meinst, aber was auch immer es ist... es ist nicht das, was du tun willst Verstehe ich nicht. Wo ist das Problem beim aktuellen Code?
  6. @Peanut Nein, meine ich nicht Wenn du beim Build hier Häckchen setzt... ...dann wird im Build so etwas hier angezeigt: Wenn also eine Exception fliegt - und das ist, wie gesagt, meine aktuelle Vermutung - dann wird diese hier angezeigt.
  7. Das ist ja kein unwichtiger Hinweis Dann mach mal ein Häckchen bei Development Build und bei Script Debugging vor dem Export. Dann solltest du im Build eine Konsole haben, die Fehler anzeigt. Ich gehe stark von einer Exception in irgendeinem Code aus. Ganz allgemein hier schon einmal was zum Lesen: http://blog.13pixels.de/2019/things-that-can-make-a-difference-in-unitys-play-mode-compared-to-your-build/
  8. Hallo! Von alleine passiert so etwas nicht, da muss also irgendein Script seine Finger im Spiel haben. Stell erstmal im Game View verschiedene Auflösungen ein und schau, ob du das Problem im Editor reproduzieren kannst.
  9. Du kannst mehrere Punkte definieren; entweder durch mehrere GameObjects oder durch eine Liste an Vector3 auf einer Komponente. Dann kannst du deinem Charakter ein Script geben und ihn diese Punkte ablaufen lassen. Du merkst dir in einem Feld den aktuellen nächste Zielpunkt und schaust einfach in jedem Frame, ob der erreicht ist. Wenn ja, setzt du den Nachfolgepunkt als nächstes Ziel, wenn nein, läufst du auf den aktuellen Punkt weiter zu. Komplizierter wird es (und da bin ich mir bei deinem Pist nicht sicher, ob du das meinst), wenn du ein Netzwerk hast - also mehrere mögliche Start- und Zielpunkte hast. Da willst du eher nicht bei allen Kombinationen per Hand eintragen, wie der Weg aussehen soll. Da brauchst du dann einen Pathfinding-Algorithmus. Interessantes Feld, die Dinger, aber vielleicht nichts, wo jeder drauf Lust hat Gibt zum Glück ein paar (auch kostenlose) Pakete dafür. Und im Zweifelsfall kann man sich immer NavMeshes anschauen.
  10. Du hast es geschafft, die gestellte Frage geschickt zu umgehen Daher nochmal ganz explizit: Willst du, dass die Zahlen in der 3D-Szene an die Würfel gebunden sind? Als wären die Würfel Bildschirme, die etwas anzeigen? Dann könnte man die auch wegdrehen, etwa so: Oder willst du in Wirklichkeit einfach nur, dass eine Zahl über jedem Würfel zu sehen ist, die, genau wie Lebensanzeigen in vielen Top-Down-Spielen nichts mit dem Objekt zu tun haben außer ihrer Position? https://i.kinja-img.com/gawker-media/image/upload/t_original/bcjyblk1goennkdlu0rr.png Ich habe nämlich das Gefühl, dass du eigentlich letzteres willst, und in dem Fall ist die Herangehensweise mit den mehreren World Space-Canvas einfach schonmal komplett falsch. Stattdessen solltest du einen Screen Space-Canvas haben und den UI-Text-Komponenten ein Script geben, das ihre Position z.B. in LateUpdate in Abhängigkeit eines zuweisbaren Zielobjekts setzt. Dafür kannst du z.B. diese Klasse benutzen.
  11. Naja, das ist halt die Frage. Ich war mir beim Anfangspost halt nicht sicher, ob hier nicht doch von einem Screen Space Canvas die Rede ist. Oder aber sein sollte. Man kann ja auch Text in einem Screen Space Canvas so darstellen, dass er über Objekten der 3D-Welt liegt. Ist auch gar nicht mal so schwer. Von daher, @DerStefan, erzähl doch mal: Was genau versuchst du zu erreichen?
  12. Der Canvas ist auf World Space gestellt? Und das ist auch so gedacht, dass das UI in der 3D-Welt hockt und nicht als Overlay darüber?
  13. if (other.tag == "Player") if (other.GetComponent<Player>())
  14. Ah, du redest also vom UI. Schau dir mal den Canvas Scaler an. Spiele da einfach mal ein bisschen mit den Einstellungen. Du kannst in der Game View auch alle möglichen Auflösungen einstellen, um das direkt zu testen. Wenn der Canvas Scaler richtig eingestellt ist, musst du evtl. nochmal schauen, dass die Anker deiner UI-Elemente richtig sind.
  15. Ohne weiteres Zutun nimmt Unity meines Wissens nach auf mobilen Geräten immer die native Auflösung. Inwiefern passt die denn nicht mehr zum Spiel?
  16. Es ist nicht direkt ein Fehler, den du machst, aber so etwas muss leider obendrauf implementiert werden. Das Problem ist halt, dass für deine Hände die Regeln der virtuellen Physik nicht gelten und deshalb Sonderregeln gefunden und eingebaut werden müssen. Ist genau wie beim Kopf: Den kannst du munter in Wände stecken, also werden Sonderregeln wie das Schwarzfärben des Bildes implementiert, damit man nicht auf die andere Seite schauen kann. Bei Hand-Interaktion scheint der verwendete Code einfach Dinge an deine Hand zu positionieren und fertig. Bei kleineren und unbeschränkten Objekten geht das vermutlich ganz gut. Ich glaube, was ich versuchen würde (ohne jetzt zu viele Best Practices zu VR im Kopf zu haben), ist: Du hast ein unsichtbares Objekt, das der Spieler greifen kann. Es befindet sich an der Interaktionsstelle der Tür (also dem Türgriff). Der Spieler zieht es und die Tür versucht, sich so auszurichten, dass sie in Richtung des unsichtbaren Objekts zeigt. Dabei ist es okay, wenn man das Objekt etwas weiter weg zieht, als die Tür physikalisch zulassen würde. Zieht man allerdings über einen gewissen Schwellenwert hinweg, dann "bricht" die Verbindung und die Tür fängt an, das Objekt zu ignorieren. Lässt man das Objekt los, teleportiert es sich zu seiner Ausgangsposition am Türgriff zurück. Ist die Verbindung gebrochen, wird sie dann wieder hergestellt, falls man erneut greifen möchte.
  17. Forge! Das war das, das mir nicht eingefallen ist
  18. Unity hat UNet, was seit... ich glaube, inziwschen Jahren nicht mehr gepflegt wird. Mirror ist eine Weiterentwicklung davon aus der Community. Soll ganz okay sein. Fand's selber blöd, aber ich hab auch andere (nicht einmal: höhere ) Ansprüche an so ein Paket als viele Andere, wie mir scheint. Photon ist nach meinem Eindruck das beliebteste Ding, und für kleine Sachen scheint das recht gut zu sein. Für größere wird's auch benutzt, da weiß ich nicht, wie teuer das wird. Außerdem hab ich noch nicht raus, wie man das nutzen kann, ohne das in deren Cloud zu haben. Aber die Server in einer Cloud zu haben anstatt sie selber aufsetzen und pflegen zu müssen ist ja jetzt auch nun wirklich kein inhärenter Nachteil Letzten Endes hat alles so seine Vor- und Nachteile. Ich hab sogar selber mal son Ding geschrieben. Da ich aber nicht so viel in dem Bereich mache, entwickele ich da nicht gerade mit Hochdruck dran Kannst jedenfalls einfach mal nach UNet, Mirror oder Photon googeln. Gab noch ein paar mehr, die nicht uninteressant sind, aber die fallen mir gerade nicht ein.
  19. Multiplayer ist seit einiger Zeit bei Unity leider sehr mau, und man ist idR am besten beraten, da Photon oder irgendein anderes Third-Party-Tool zu benutzen. Leider ist die Landschaft da ziemlich wild - hoffe, da hat hier jemand ein bisschen Erfahrung zum teilen. Was lokalen Multiplayer angeht: Der ist gar nicht so schwierig. Du brauchst zum einen den richtigen Input. Das geht mit dem alten Input-Manager, ist aber alles andere als schön. Das neue Input-System ist da vermutlich besser. Zum anderen brauchst du eine hübsche Kamera, die alle Spieler gleichzeitig im Blick behält. Dann gibt's noch ein paar Kleinigkeiten beim Scripting, wie z.B. dass statische Variablen deutlich problematischer werden, obwohl sie in drölfzig Unity-Tutorials für Spieler-Scripte immer wieder vorkommen. Je nach dem, wie viel Scripting-Erfahrung du hast, aber alles kein Hexenwerk.
  20. Drücke mal oben in der Scene View auf "Gizmos", da sind die ganzen Einstellungen für solche Icons.
  21. Das ist ein finsterer Hack. Schau dir beim Rigidbody lieber "Constraints" und den Modus an. Anstatt so etwas durch extreme Zahlen, die in der Regel doofe Nebeneffekte haben, zu machen, stelle das Ding lieber direkt auf "kann sich nicht drehen". Die 2D-Komponenten können alles, was die 3D-Komponenten können. Naja, außer 3D sein. Du musst nur beachten, dass du dann anstatt OnCollisionEnter auch OnCollisionEnter2D benutzt. Nö. Tilemaps sind in keiner Weise erforderlich, um ein Spiel zu machen.
  22. Die Methode hat einen bool-Parameter. Ist er true, wird ignoriert, rufst du mit denselben Collidern noch einmal, aber mit false, auf, dann wird wieder kollidiert. Ich würd's aber, wenn nichts (wie beschrieben) explizit dagegenspricht, mit der Layer Collision Matrix-Variante probieren.
  23. Schau dir mal den Canvas Scaler an. Da kann man mit der Bildschirmgröße skalieren. Da wird dann die Pixeldichte des Displays benutzt. Stell dir z.B. kleine Buttons wie in einem MMO auf nem Handy vor, das will man nicht unbedingt. Du kannst aber auch rein nach Auflösung skalieren.
  24. Heyo, willkommen Bei den Import Settings deines Modells kannst du im Materials-Tab einstellen, dass er dir eine Liste mit allen vom Modell erwarteten Material-Slots anbietet, und da kannst du dann die Materialien per Hand reinziehen, um sie zu überschreiben.
  25. Der Input-Manager ist veraltet und das neue Input-System kann afaik alles, was das alte kann. Schau es dir also mal an - versprechen, dass das, was du suchst damit einfach geht, kann ich dir nicht, aber es soll wohl ganz gut sein. Einen Versuch wäre es also wert
×
×
  • Create New...