Jump to content
Unity Insider Forum

Sascha

Administrators
  • Gesamte Inhalte

    13.617
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    780

Alle erstellten Inhalte von Sascha

  1. Nö, es gibt echte Gründe: Die Engine ist viel größer und da hängt viel mehr drin. Extrem viele, sehr diverse Projekte laufen auf der Engine und immer, wenn daran geschraubt wird, muss darauf geachtet werden, dass man nicht die Kompatibilität zu 10% davon zerschießt. Das macht alle Prozesse langsamer. Prioritäten. Nette Sprachfeatures sind ja eine Sache, aber die betreiben natürlich durchgehend und unaufhörlich Analysen, um zu entscheiden, was Nutzer und sie selbst am ehesten brauchen. Und die Komfortfeatures einer neueren C#-Version sind da einfach nie am wichtigsten, solange es noch so viele andere Baustellen gibt. Schau dir halt die Changelogs von Unity 6 an und entscheide selbst, ob du einen nennenswerten Anteil davon eher unter dem .NET-Update priorisiert hättest. Vor allem aus Sicht eines Unternehmers und nicht eines Hobbyisten, der das eher zum Spaß macht Godot hat halt keine dieser Einschränkungen. Die haben von Version 3 auf 4 so krasse Änderungen rausgehauen, da hätte sich bei Unity die Aktie halbiert, wenn sie das gemacht hätten. Können die sich halt leisten. Und wo wir beim Vergleich sind: Ich hatte mir im September die 4er-.NET-Version geladen und konnte da nach bauen eines Hello-World-C#-Scripts das Spiel nicht starten. Godot hat mit .NET also auch seine Höhen und Tiefen
  2. Dann lad's bei einem Image-Hoster hoch und verlinke es hier
  3. Schick doch mal einen Screenshot von deinem Editor.
  4. Wenn es Müll gibt, um den du dich kümmern musst, dann ist es dein eigener. Hinter Unity musst du nicht aufräumen. Wie sieht die Deformation aus? Das klingt schon sehr nach etwas, das schief gehen kann.
  5. Moin! Ja, es gibt durchaus Möglichkeiten, wie man Memory Leaks baut, die den Speicher nach und nach zumüllen. Ich hab da aber gerade keine simple Auflistung zur Hand, die du mal durchgehen könntest. Benutzt du viele Plugins? Editor-Code? Prozedurale Generierung?
  6. Klingt, als wärst du in der Game View, willst aber in der Scene View sein. Erstere ist zum Spiel Testen, da passiert nichts drin außer deines Spiels - die Scene View ist zum Editieren deiner Szene.
  7. Nicht unbedingt. Der Ressourcen-Ordner ist, wenn du mich fragst, auch für 98% der Probleme eine schlechte Lösung. Einfach schon, weil man Strings zum Identifizieren der Assets benutzt. Meistens besser: Ein serialisiertes Feld anlegen (wenn nicht bekannt: einfach "public GameObject prefab;") und da dein Prefab im Inspektor rein ziehen. So ein GameObject hat, wenn du nicht Shakespeare in eine Komponente rein pastest, nicht mal ein KB groß. Mach dir mal nicht wegen drei GameObjects um deinen Speicher Sorgen. Tatsächlich gibt es eine Technik Namens "Pooling", die Objekte recycelt, also deaktiviert und dann wieder re-aktiviert, anstatt ein neues Objekt zu instanziieren, weil Zerstören und Instanziieren weitaus schlechter für die Performance ist als zeitweises Deaktivieren. Nicht, dass das für dich einen Unterschied machen sollte, daher einfach weiter im Kurs - aber ich konnte das nicht stehen lassen, ohne den Samen des Zweifels an dieser Ansicht zu sähen
  8. Mach dir bloß nicht zu viel Hoffnung, dass Unity in nächster Zeit an irgendeiner Front in irgendeiner Weise aufholen wird. Der Firma geht's im Moment gar nicht gut. Die kriegen seit vielen Jahren dieselbe Handvoll Baustellen nicht vernünftig gebacken, und die nächsten Jahre werden noch härter werden, weil bei denen gerade alles drunter und drüber läuft.
  9. Wenn ein Script nicht kompiliert, hast du immer (mindestens) eine Fehlermeldung in deiner Konsole. Die kannst du oben über "Windows -> General -> Console" öffnen. Einmal darin auf Clear drücken, dann verschwinden alle Meldungen, die nicht Compilerfehler sind (also die Fehler, die in deinem Code sind und Unity daran hindern, ihn zu kompilieren und zu benutzen). Wenn du uns den/die Fehler hier hinkopierst, machst du uns damit das Leben viel einfacher Davon mal abgesehen hast du mehrere Male Zeilen in der Form "a - b" im Code. Zwei Dinge voneinander abziehen ist aber keine vollständige Anweisung. Du musst das Ergebnis auch in irgendeiner Weise benutzen, z.B. indem du es in eine Variable schreibst. Ich nehme aber an, dass du in Wirklichkeit einfach nur "=" schreiben wolltest und nicht "-".
  10. Sascha

    Collider

    Moin! "greifen nicht" heißt, dass die Objekte durcheinander fallen ohne zu kollidieren? Sind beide Collider 3D-Collider oder ist einer von beiden 2D? Hast du einen Screenshot von deiner Szene für uns?
  11. Hallo, Willkommen und viel Erfolg!
  12. Moin! Ich hatte schon versucht, das Problem zu erfassen, aber ohne Screenshots klappt's nicht. -200 klingt wie das Gegenteil von "okay", aber mehr weiß ich auch nicht Kannst du sonst nochmal auf irgendeinem anderen Bildhoster hochladen und verlinken?
  13. Moin! Gizmos (also Linien und Icons und so) müssen in der Scene View angeschaltet werden. Der Knopf dafür ist der ganz oben rechts:
  14. Da gibt's viele Ansätze. Ich denke an Dungeon Keeper und dergleichen: Erstmal sind das vom Rendern her gar keine Cubes. Du siehst ja nur die Oberseite, ein Wandmodell oder den Boden. Du kannst also statt Würfeln Quads nehmen. Darüber hinaus kannst du größere Flächen auch partitionieren: Wenn dein Spiel irgendwo 5x5 unangetastete Felder findet, kann es eine 5x5-Fläche rendern statt 25 1x1-er. Wenn du noch weiter gehst, kannst du auch in Echtzeit Chunk-Meshes generieren. Also alle 8x8 (oder was auch immer für Werte gut für dich funktionieren) Felder als ein Mesh rendern, das in Echtzeit generiert wird, wenn sich darin etwas ändert.
  15. There is no way we can help you without any kind of information. We'd need to at least look at your relevant code.
  16. Da kannst du ja direkt ansetzen. public float acceleration = 5f; public float minSpeed = 0f; public float maxSpeed = 10f; void Update() { speed += Input.GetAxis("Vertical") * acceleration * Time.deltaTime; speed = Mathf.Clamp(speed, minSpeed, maxSpeed); distanceTravelled += speed * Time.deltaTime; ... Input.GetAxis ist eine Möglichkeit. Je nach Input-System gibt's dann andere. In jedem Fall kannst du einfach speed anpassen und dadurch ändert sich... naja, deine Geschwindigkeit
  17. Moin! Wie hast du denn deinen Pfad implementiert? Irgendwo in deinem Code müsste dann ja eine Geschwindigkeit drin stehen, mit der du dich den Pfad entlang bewegst. Diese Geschwindigkeit kannst du variabel machen und über Input abändern lassen.
  18. Moin! Der Code hat ein paar Merlwürdigkeiten, ist aber prinzipiell so richtig. (später - früher).Days ist die abgerundete Anzahl an Tagen zwischen später und früher. Hast du dir denn mal deine beiden DateTimes vor dem Verrechnen ausgeben lassen?
  19. Das hier stimmt auf jeden Fall noch nicht. Deine Beschreibung klingt aber so, als wäre das nicht das einzige übrige Problem. Solltest du trotzdem erstmal lösen.
  20. Du hast immer noch genau dasselbe Problem drin. Wenn kein Paket rein kommt, berechnest du trotzdem distanceX neu, wobei immer 0 heraus kommen wird.
  21. Moin! Ich würde vermuten, dass du nicht in jedem Update eine neue Position rein bekommst. Wenn das der Fall ist, hast du mehrere Updates in Folge dieselbe Position, und der Abstand ist entsprechend immer 0. Pack diesen Code am besten direkt hinter den Code, der die neue Position entgegen nimmt und auf den virtuelles Objekt anwendet. Dann musst du natürlich auch statt Time.deltaTime einen eigenen deltaTime-Wert nehmen, der genauso berechnet wird wie distanceX.
  22. Vielleicht mag Unity es nicht, dass das Objekt noch keine Meta-Datei hat, sei es direkt oder eben vom Parent-SO. Wenn du keine Kombination/Reihenfolge findest, solltest du sonst auch jederzeit ein neues SerializedObject erstellen können. Ist wie gesagt nur ein Wrapper zum Bearbeiten. var serializedObject = new SerializedObject(entity);
  23. Moin, ich bin mir nicht ganz sicher, woher das kommt, aber rein von der Logik her würde ich vermuten, dass jede einzelne dieser vier Zeilen AssetDatabase.AddObjectToAsset(newAttribute, this.entity); AssetDatabase.ImportAsset(AssetDatabase.GetAssetPath(newAttribute)); AssetDatabase.SaveAssets(); AssetDatabase.Refresh(); das Potential hat, das SerializedObject zu disposen. Ein SerializedObject ist ein Wrapper um ein UnityEngine.Object, der für das Editieren dieses Objekts da ist. Deswegen kennt es auch die SerializedPropertys des Objekts. Solange das SerializedObject existiert, soll da auch am besten nicht noch jemand anderes an dem Objekt herum fummeln. Die erste dieser Zeilen editiert halt das Asset, die zweite Importiert es (nach AddObjectToAsset haben ja beide Assets denselben Pfad), und SaveAssets und Refresh sind auch beide von der Idee her nicht damit kompatibel, dass da noch Bearbeitung offen ist. Lange Rede, kurzer Sinn: Versuch mal, mehrere (wenn nicht alle) dieser vier Zeilen unter das letzte ApplyModifiedProperties() zu packen.
  24. Naja, du hast ja zwei Arten von Objekten hier. Das eine ist nach deiner Beschreibung "statisch" (wie gesagt: voll okay, solche Begriffe zu nutzen, auch wenn sie anderswo schon eine feste Bedeutung haben, solange man es erklärt). Das andere Objekt wird instanziiert (oder auch nicht, je nach dem) und reagiert darauf, angeklickt zu werden. Ich sehe da auf jeden Fall zwei Scripts. In dem Fall: ItemPosition public class ItemPosition : MonoBehaviour { public Item item; public ItemRepresentation spawnedItemPrefab; private ItemRepresentation spawnedItem; private void SpawnItem() { // Wenn ich schon ein Item in der Szene habe, dann lass mal if (spawnedItem) return; spawnedItem = Instantiate(spawnedItemPrefab, ...); spawnedItem.item = item; } } ItemRepresentation public class ItemRepresentation : MonoBehaviour { public Item item; private void OnMouseDown() { Inventory.AddItem(item); Destroy(gameObject); } } Ist jetzt nur ein minimales Beispiel, wo sich ein Item immer ins Inventar packt und dann selbst aus der Szene löscht. Was aber auch geht: Du packst den Collider und damit die "Anklickbarkeit" auf das "statische" Objekt. Kann ich mir auch gut vorstellen. Dann brauchst du nur ein Script, weil die Prefab-Kopie nix macht außer hübsch auszusehen. ItemPosition würde sich dann um Inventory.AddItem und Destroy kümmern.
  25. Ja, keine Sorge - ist nix neues. Aber entsprechend muss ich das ansprechen, wenn die Kommunikation uns daran hindert, eine Lösung zu finden. Und vielleicht hast du ja auch auf Dauer was davon, mehr korrekte Begriffe zu kennen Entsprechend auch etwas Terminologie für das, was du geschrieben hast: Ein Prefab ist ein GameObject, das nicht in einer Szene existiert. Instantiate kopiert ein GameObject in die aktuell aktive Szene. (Du kannst damit in der Tat auch GameObjects kopieren, die schon in der Szene sind - es muss kein Prefab sein). Da es in der Tat möglich ist, ein Prefab zu ändern, ist es wichtig, zwischen Prefabs und ihren in der Szene existierenden Kopien zu unterscheiden. Wenn du nämlich "ein Prefab änderst", dann hat das je nach Kontext einige sehr... "interessante" Nebeneffekte. Man redet bei dem, was in der Szene landet, wenn man ein Prefab hinein zieht, daher von einer Prefab-Instanz. Bei dem, was Instantiate zur Laufzeit produziert, übrigens eher nicht. Der entscheidende Punkt, dass geänderte Eigenschaften im Prefab auch in dessen Instanzen übernommen werden, fehlt da nämlich. Dann etwas worüber ich jetzt schon mehrfach gestolpert bin: Es ist völlig okay, dass du auch Begriffe benutzt, die woanders eine feste Bedeutung haben. Aber du solltest hier nicht von "statischen Objekten" reden, ohne einmal kurz zu erklären, was das bedeutet. Meinst du damit einfach nur, dass das Objekt nicht zur Laufzeit erstellt oder zerstört wird, sondern immer vorhanden ist? Also verstehe ich das richtig, dass du ein Script hast, das ein Prefab instanziiert, und das resultierende Objekt hat wiederum ein Script, welches darauf reagiert, dass es angeklickt wurde? Du solltest dringend die Namen deiner Klassen überarbeiten. Es ist zwar schön einfach, die Dinger "IrgendwasManager" zu nennen; aber genau solche Zusammenhänge gehen durch solche Namen verloren. Wenn ich dir als Namen z.B. "ItemPosition" und "ItemRepresentation" vorschlage, dann weißt du sofort, welche Klasse welche wäre. Und so als Tipp: Deine eigene Denkweise kannst du damit auch beeinflussen. Wenn du deine Namen sorgfältig wählst, fällt es dir einfacher, über die Zusammenhänge nachzudenken, in denen sie vorkommen. Wenn deine Annahme jetzt jedenfalls korrekt ist und du den Grund für das Problem gefunden hast, habe ich hier die Lösung für dich: Instantiate gibt dir eine Referenz auf das Objekt zurück, das es erstellt hat. Du kannst also dein neues Objekt direkt bearbeiten. var itemInstance = Instantiate(itemPrefab); itemInstance.representedItem = myItem; Was ich hier übrigens mache, ist bei "itemPrefab" als Typ nicht GameObject, sondern den Typ der relevantesten Komponente zu nehmen: public ItemRepresentation itemPrefab; // oder wie auch immer das bei dir heißt. Da kann man dann alle GameObjects rein ziehen, die diese Komponente haben. Und Instantiate gibt direkt eine Referenz auf diese Komponente auf der erstellten Kopie zurück, sodass man sich ein GetComponent sparen kann.
×
×
  • Neu erstellen...