Codeüberprüfung und Feedback gesucht!

[Kokujou]

1. von UnityEngine.Object erbende Klassen... hast du mal ein Beispiel? wenn erbe ich davon wahrscheinlich nur indirekt 😮 meinst du ScriptableObjects oder was?
2. Ja die sind wohl beim gitignore rausgeflogen, mach ich!
3. Ja darauf wurde ich schon hingewiesen >.< Das kommt davon wenn einem die Worte fehlen XD
4. Uff... Ja diese blöden Namenskonventionen.. da hängt sich am Ende jeder dran auf. Ich achte in Zukunft drauf aber jetzt rückwirkend alles umzuschreiben....
5. Also DistinctYaku sagt eigentlich alles was es muss allerdings nur wenn man mit den Spielregeln vertrauen lässt^^ es gibt Yaku die quasi zur gleichen Kategorie gehören, also werden quasigleiche Yaku aus der Liste entfernt Oftmals achte ich darauf dass Namen sprechend sind, eigentlich immer. Was hängen bleibt sind höchstens temporäre Variablen aber ich hab's schon auf dem Schirm, danke!
6. Das war auch mal viel schlimmer. Da hab ich sie oft direkt in der Szene gesucht. Ich arbeite auch da schon an ner Lösung indem ich die Card-Klasse vielleicht direkt zu ner Komponenten mache und dann die Referenzen direkt in die Klasse einbaue
7. Auch das ist ja glaub eher ein Einzelfall, wie würdest du das machen? Ich will ja nur wissen ob ich die Name-Eigenschaft abrufen kann, soll ich lieber über try/catch machen? Ich hatte sowas früher öfter in Projekten hatte aber irgendwann Performance-Einbrüche weswegen ich es jetzt so mache
8. Die ist größtenteils dabei überall rauszufliegen. Ich habe schon großflächig durch die neue ersetzt, aber ich glaub ich habs noch nicht explizit auf meiner ToDo guter Einfall!
9. was meinst du damit jetzt?
10. YakuHandler ist quasi die Komponente die den einzelnen Yaku (zu finden in den Prefabs) zugewiesen werden und quasi für deren Rendering zuständig sind, YakuManager koordiniert das Anzeigen der ganzen Liste. das fand ich eigentlich ziemlich gelungen
11. Ja ich hab vor Git alles über Kommentare und Strg+Z,C,Y gemacht XD darum findet man da so viel Müll drin, ich entferne ihn so schnell wie möglich :3

 

[Kokujou]

Ah und vielleicht kannst du mir mal was verraten, denn ich verstehs nicht.

Unity verändert ständig meine ScriptableObjects! kA was das soll das frustriert mich total >.> Der Großteil der Eigenschaften bleibt erhalten, manchmal schmeißt er einfach "Name" raus und das ist dann leer! Ich hab meinen ganzen Code durchgesehen, nirgends wird der Name gesetzt, readonly geht nicht dann fliegt er komplett raus. Ich muss ihn jedes Mal im Skript durch Name = name zuweisen. Da die private Namen-Eigenschaft ja leider Probleme verursacht wenn man auf sie außerhalb des Main-Threads zugreifen will.

[Sascha]

Oha

Okay...

1. Es geht um Component und ScriptableObject. Außerdem erben noch GameObject und alle Asset-Typen (Mesh, Texture2D, AudioClip, ...) davon, aber von denen wiederum erbst du ja nicht.

5. Geht mir weniger um Yakus, als darum, dass vällig unklar ist, was die Methode macht. Da ist kein Verb im Namen der Methode. Löscht sie Yakus? Filtert sie sie? Sortiert sie sie? Vermutlich sucht sie keine raus, denn der Rückgabewert wird nicht benutzt, aber wer kann sich da schon sicher sein...?

7. Wenn du den Namen von etwas brauchst, dann verwende für die Variable einen Typ, von dem du weißt, dass du dessen Namen erfahren kannst. Also statt ein "Auto" als Parameter zu erwarten und dann zu checken, ob es ein "Polizeiauto" ist, damit du die Sirene anwerfen kannst, verwende gleich "Polizeiauto" als Paramtertyp.

9. Manager-Klassen (und Singletons!) sind problematisch, da sie ungefähr alle Codequalitäten auf einmal senken. Er wird weniger robust, schlechter bis gar nicht testbar und vor allem geht die Modularität flöten. Immer, wenn jemand eine Klasse namens "GameManager" in seinem Code hat, oder eben etwas vergleichbares, sehe ich gleich schlechten Code. Singletons sind zumindest im Unity-Kontext so lange erträglich, bis man bessere Lösungen verinnerlicht hat. Außerhalb von Unity wird man für Singletons zurecht schräg angeguckt. Manager-Klassen sindwesentlich seltener "nötig", als man anfangs glaubt, wenn man mal schaut, welche Klassen die Arbeit stattdessen übernehmen können. Aber wenn du dich für den geilen Kram bereit fühlst, der beides komplett überflüssig macht, empfehle ich mal das hier.

10. Das ist ja gut, dass du dafür eine Erklärung hast, aber es geht ja um die Namen. Ein Handler und ein Manager ist dasselbe, darum muss man entweder deinen Code oder eine Erklärung wie deine gerade lesen, um zu verstehen, wie das gemeint ist. Bei gutem Code muss man das nicht. Warum heißt der "YakuHandler" nicht einfach "Yaku"? Deine aktuelle Klasse "Yaku" könnte "YakuData" heißen. Alternatic kannst du den "YakuHandler" auhc "YakuDisplay" nennen, dann ist auch klar, was die Klasse macht. Aber "Handler" ist halt "macht Dinge damit", das hilft einem immer nicht weiter.

Zum anderen Post... Bin mir nicht sicher, was du da genau machst, aber...

• Verwende keine Namen von UnityEngine.Objects. Wir reden hier im Zweifelsfall vom Dateinamen des Assets, der muss sich ändern können, ohne dass dein Projekt in die Luft fliegt.
• Mach das Feld "Name" private und knall ein [SerializeField] drüber. Dann kannst du dir sicher sein, dass schon einmal keine deiner anderen Klassen daran herumfummelt.
• Ich habe gerade nicht einmal gefunden, wie du deine "Yaku"-ScriptableObjects erstellst. Wie erzeugst und speicherst du sie?

[Kokujou]

1. Also man hat mir geraten mein Skript möglichst auszugliedern also hab ich für jede Klasse erstmal ein eigenes Skript erstellt >.< sag mir nicht das war jetzt falsch. Von Component erbe ich ja auch nicht, es geht wohl nur um die 2 ScriptableObjects?

5. Ups... ich dachte distinct wäre ein Verb XD Ich seh doch immer in der Linq die Distinct Methode, wenns für die gut genug ist dann für mich auch oder Und ja es löscht.

7. Wir reden hier doch von der Equals-Methode die ich überschrieben habe und... irgendwie will mir VS nichtmal die Verweise finden XD Ich bin mir also nichtmal sicher ob das überhaupt aufgerufen wird. Aber ToEquals hat nur Parameter vom Typ object oder nicht. Wenn ich also ne Konvertierung vornehme und er den Typ nicht kennt schmeißt er ne Exception raus und das wollen wir ja nicht oder?

9. Ich versuch gerade krampfhaft meinen Codestil zu verbessern und Funktionen abzudocken, also dachte ich mir ich bau eine Klasse, die das Spawnen der Yaku und deren Animation koordiniert. Vorher hatte ich das alles in der Update-Routine gehandhabt, die dann auch entsprechend tausende Zeilen lang war XD wie würdest du es denn machen? Denn die Klasse braucht nunmal nicht nur wissen über den Einen sondern auch über den nächsten, muss wissen wanns zu Ende ist, ich dachte echt das wär so n guter Stil 😢

10. Da sieht man meine Wortfindungsschwäche... Dann benenn ich's halt in YakuRenderer um^^ Ich bin nicht sonderlich gut mit Worten darum vertausche ich auch dauernd deutschen und Englischen Code.

Ich hab sie nur einmal erzeugt, das ist ja der Punkt. Es sind fixe Karten, das war ja der Vorteil. Ichh ab sie einmal im code gebaut, dann in den Deck/Yaku Ordner ausgelagert, den du im GitHub inzwischen unter External findest und lade sie durch ihre Referenzen die ich in der Szene zugewiesen habe in die Global.AllCards bzw AllYaku.

Die gesamten eigenschaften sollen nur gelesen werden können, mehr nicht.

Und noch ein kleiner Nachtrag: Ich hab kA warum zur Hölle da überall veraltet dran stand. Das muss VS einmal gesehen und dann immer wieder beim Abdocken hizugefügt haben XD

[Kokujou]

Achja und was meintest du mit "Global den Spielverlauf beeinflussen", sicher nicht den textuellen Spielverlauf? XD

[Sascha]

vor einer Stunde schrieb Kokujou:

also hab ich für jede Klasse erstmal ein eigenes Skript erstellt >.< sag mir nicht das war jetzt falsch.

Das ist doch genau das, was ich dir selber vor zwei Posts geraten habe. Ist aber eben nicht überall der Fall.

vor einer Stunde schrieb Kokujou:

Ich seh doch immer in der Linq die Distinct Methode, wenns für die gut genug ist dann für mich auch oder

Linq-Statements sind direkt als solche zu erkennen. Bei deiner Methode ist durch den Namen völlig unklar, was sie macht.

vor 1 Stunde schrieb Kokujou:

Wir reden hier doch von der Equals-Methode die ich überschrieben habe

Oh Mann, du hast Recht. Equals ist die Ausnahme von der Regel, hab ich übersehen. Mein Fehler!

Zu 9.:

vor 1 Stunde schrieb Kokujou:

wie würdest du es denn machen?

Ich gehe folgende Liste durch:

1. Wenn Objekte Dinge für sich selbst klären können, sollten sie das tun.
2. Ansonsten: Wenn Objekte Dinge untereinander klären können, sollten sie das tun.
3. Ansonsten: Wenn Mengen gleichartiger Objekte gemeinsam etwas tun müssen, dann reichen statische Variablen und Methoden in dieser Klasse.
4. Ansonten: Wenn irgendein Objekt und irgendein andersartiges Objekt miteinander kommunizieren sollen, dann gibt es zwei Fälle:
   1. Die Identität des Dienstleisters ist relevant für den Klienten (Beispiel: Welche Tür der Knopf öffnet ist für den Knopf wichtig). In diesem Fall sollte der Dienstleister über den Editor gesetzt werden, nicht über Code. Dabei helfen entweder serialisierte Felder oder serialisierte UnityEvents.
   2. Die Identität des Dienstleisters ist nicht relevant für den Klienten (Beispiel: Der Spielfigur ist es egal, was für ein UI-Objekt seine HP anzeigt - oder ob es überhaupt eine solche Anzeige gibt). In diesem Fall sollte eine globale Variable oder ein Event-System her. Beides kann man eben durch Manager-Objekte implementieren, aber da geht wie gesagt Code-Qualität bei flöten.

Ich sehe oft Manager-Klassen, und leider nicht selten bei allen diesen Fällen. Bei 1. bis 4.1. allerdings kann man mit ordentlicher Architektur wunderbar ohne auskommen. 4.2 ist der Fall, wo es etwas schwieriger wird, Manager zu umgehen, aber auch das geht - siehe Link zwei Posts weiter oben. Dafür wird aber erstmal ein gewisses Verständnis von Architektur wichtig, und zum anderen muss man den Kram erstmal brauchbar implementieren. Meine eigene Implementation landet vielleicht demnächst im Asset Store. Mal schauen.

Bis man so eine Implementation hat, ist es halt okay, für Fall 4.2. Manager-Klassen zu verwenden, aber man sollte im Hinterkopf behalten, dass das nicht gerade elegant ist.

Hier ist ein kleines Architekturbeispiel von mir dafür, wie man gänzlich ohne Manager auskommt: https://gitlab.com/FlaShG/Unity-Architecture

vor 1 Stunde schrieb Kokujou:

Da sieht man meine Wortfindungsschwäche...

Ausreden helfen nix, guter Code bleibt guter Code und schlechter Code bleibt schlechter Code. Mach dir halt bewusst, was Dinge tun, und dann schreib dir das auf. Eine Methode löscht Dinge, aus einer Liste, die nicht Eigenschaft X haben? Nenne sie "DeleteObjectsWithoutX" und fertig. Du sollst ja kein Kind benennen (auch wenn es Programmierphilosophien gibt, die besagen, dass du das genauso sorgsam tun sollst), sondern eine Beschreibung finden für das, was etwas tut.

Ne allgemeine Lebensweisheit ist aber, dass es dir nix hilft, irgendwelche Schwächen vorzuschieben und zu sagen "joa ich bin Legastniker, ich kann da nix für". Arbeite daran oder du wirst hinter anderen zurückbleiben.

vor 1 Stunde schrieb Kokujou:

Ich hab sie nur einmal erzeugt, [...]

Mein Verdacht waren die fehlenden Meta-Files im Repo, aber das ist eigentlich Quatsch, weil du die ja lokal auf jeden Fall hattest. Passiert das mit den gelöschten Namen bei allen ScriptableObjects oder nur bestimmten? Ich würde die Felder jedenfalls in "Title" umbenennen, damit keine Verwirrung entsteht.

vor 47 Minuten schrieb Kokujou:

was meintest du mit "Global den Spielverlauf beeinflussen"

Das bezieht sich auf meine Liste weiter oben. Dinge sollten sich selbst beeinflussen, so weit es geht. Ein Flugzeug in einer Formation sollte lieber sich selbst im Bezug auf die anderen steuern, als dass ein abstrakter Manager alle Flugzeuge gleichzeitig unter Kontrolle hat. Zumindest in der Spieleentwicklung. Die Metapher ist mit Vorsicht zu genießen, da man sie gerade im Bezug auf ECS auch ganz falsch auslegen kann. Grundsätzlich gilt bei Programmierung, auch außerhalb von Unity: Je weniger verschiedene Einheiten (Klassen, Objekte) über die anderen wissen, desto besser. Je weniger ein Script funktioniert, sobald ein Fehler in einem anderen Script ist, desto schlechter.

[Kokujou]

Achso dann gehts dir um den Schnippsel mit CardRef? XD ich hab mich verlesen und gedacht jetzt ist es plötzlich schlimm DASS ich sie ausgegliedert habe. Naja wegen dem einen Schnippsel wollte ich keine extra Datei erstellen, das käme mir irgendwie sinnlos vor. Er gefällt mir eh nicht aber ich schätze mal man kann nicht gleichzeitig von ScriptableObject und MonoBehaviour-Erben... oder sollte zumindest nicht stimmts?

Ich rede ja auch nur von dem Namen. Woher weißt du denn was Linq Distinct Methode macht? die könnte ja auch alles mögliche sein oder? Aber zur Kenntnis genommen.

Okay ich versteh nicht wirklich warum das ein schlechter Stil ist. Vorher hatte ich alles in einer Funktion. Da hat man sich beschwert, also hab ich's in Klassen ausgegliedert und das ist jetzt auch falsch? Ich wüsste nicht wirklich wie ich das noch besser hinkriege. Da ist auch überhaupt nichts statisches dabei, was den ganzen code runterziehen könnte. Ich kann dir ja mal erklären was da abgeht:
Man bekommt eine Liste mit Yaku. Jeder Yaku hat eine eigene Darstellung die man in drei Typen unterteilen kann, als GUI-Element. Also zeichnet sich erstmal jeder Yaku. Und dann müssen sie alle für etwa 3 Sekunden eingeblendet werden, bevor man dann durch eine Slide-Animation weiter zum nächsten geht. Und am Ende muss erkannt werden dass es das war, die Liste ist abgearbeitet, also muss nun ein weitere UI-Element gespawnt werden. Klar könnte ich das auch über ne einzelne Funktion regeln  und hatte es auch erst so aber die, die ich gefragt habe hängen sich irgendwie daran auf dass Unity nunmal OOP ist und da mit Klassen gearbeitet wird. Und wenn ich dann noch Code in Dateien abdocken soll kommt es mir einfach blöd vor ne Datei zu haben wo nur Funktionen drinne stehen.

Ja aber ellenlange Funktionsnamen sind jetzt auch nicht unbedingt gerne gesehen.. ich zumindest mag sie nicht wirklich. DeleteObjectsWithoutX, besonders wenn X dann noch länger ist in nem code zu sehen und dann noch ne Liste von Parametern... Uff. Aber ich geb mir Mühe das besser hinzukriegen. Ich schiebs ja nicht vor und sage "find dich damit ab" ich sag nur warums so ist und dass ich dran arbeite ^^

Es passiert komischerweise in allen. Und es ist auch nur der Name... Irgendwie scheint's immer zu passieren wenn ich Unity neustarte, aber ich speichere die Szene immer bevor ich's schließe und Assets kann der doch schlecht einfach zurücksetzen wie's ihm passt...

Und ich meinte eher ob du für "Global den Spielverlauf beeinflussen" irgendein Beispiel in meienm Code hast oder ob das jetzt eher so ein allgemeiner Tipp war.

[Sascha]

vor 25 Minuten schrieb Kokujou:

Er gefällt mir eh nicht aber ich schätze mal man kann nicht gleichzeitig von ScriptableObject und MonoBehaviour-Erben... oder sollte zumindest nicht stimmts?

Du hast halt zwei Klassen in einer Datei, das ist nicht das Problem. Die können erben von was sie wollen. Das Problem ist, dass Unity Klassen über ihre GUID identifiziert. Die liegt in der Metadatei des Scripts (deshalb dürfen die auch nicht im Repo fehlen) und es gibt immer nur eine pro Datei. Hier siehst du, wie dein eines Karten-ScriptableObject von innen aussieht. Das Feld "m_Script" hat die GUID, die in der verlinken Metadatei angegeben ist. Da steht eben nicht der Name der Klasse.

Wenn du jetzt irgendwo eine Mehrdeutigkeit hast, dann weiß Unity nicht, welche der beiden Klassen mit der GUID gemeint ist. Es kann sein, dass du bei einem MonoBehaviour und einem ScriptableObject Glück hast, da bei der Benutzung (vielleicht?) immer angegeben ist, welches von beidem gemeint ist. Das kann ich gerade aber nicht mit Sicherheit sagen... und selbst wenn, dann müsste man sich immer merken welche Kombination okay ist, und wenn man daran etwas ändert muss man Klassen nachträglich auslagern. Daher: Warum nicht gleich immer nur eine Klasse pro Datei?

vor 32 Minuten schrieb Kokujou:

Woher weißt du denn was Linq Distinct Methode macht?

Du bist in einer Linq-Abfrage im Kontext einer Logikprogrammierungs-Abfrage. Da gibt es halt bestimmte Begriffe, die man irgendwann lernt, genauso wie man irgendwann lernt, was ein Stack oder eine Queue ist. In einem generischen Kontext ist das eben nicht so eindeutig.

Mal davon abgesehen ändert Distinct, was dir von deiner Methodenkette zurückgegeben wird. Deine Methode allerdings ändert den Zustand eines Objekts.

vor 37 Minuten schrieb Kokujou:

Da ist auch überhaupt nichts statisches dabei, was den ganzen code runterziehen könnte.

Static hat nichts mit schlechtem Code zu tun.

vor einer Stunde schrieb Kokujou:

Vorher hatte ich alles in einer Funktion.

Ja, das klingt sehr schlecht. Das heißt nicht, dass deine jetzige Lösung nicht auch verbessert werden kann.

vor einer Stunde schrieb Kokujou:

die, die ich gefragt habe hängen sich irgendwie daran auf dass Unity nunmal OOP ist und da mit Klassen gearbeitet wird

Genauer gesagt mit Komponenten, da muss man ein bisschen aufpassen. Einige OOP-Konzepte sind in Unity gar nicht mal so dolle. Stichwort "Komposition ist besser als Vererbung".

Irgendwie mit Paradigmen wie "Klassen benutzen" zu arbeiten führt nirgendwo hin. Das ist also ob du Handwerker bist und sagst "Leute haben mir gesagt, die Bohrmaschine sei ein geiles Werkzeug". Nützt dir aber nichts, wenn du ein Ikea-Regal aufbaust. Anstatt fest nach irgendeinem Kredo zu arbeiten, musst du ein Gefühl dafür entwickeln, an welcher Stelle du was benutzen willst. Schau dir wie gesagt gerne mal das hier an.

vor einer Stunde schrieb Kokujou:

Und wenn ich dann noch Code in Dateien abdocken soll kommt es mir einfach blöd vor ne Datei zu haben wo nur Funktionen drinne stehen.

Kommt drauf an, was genau das heißt. Ich hab auch Script-Dateien, in denen eine leere Klasse drin ist. Sogar sowas kann sehr sinnvoll sein.

vor einer Stunde schrieb Kokujou:

Ja aber ellenlange Funktionsnamen sind jetzt auch nicht unbedingt gerne gesehen.. ich zumindest mag sie nicht wirklich.

Das ist dein Geschmack. Gibt auch Leute, die das genauso sehen, da haben die Funktionen dann Namen mit maximaler Länge von fünf Zeichen, weil die das cooler finden. Keine gute Idee.

vor einer Stunde schrieb Kokujou:

Es passiert komischerweise in allen. Und es ist auch nur der Name... Irgendwie scheint's immer zu passieren wenn ich Unity neustarte, aber ich speichere die Szene immer bevor ich's schließe und Assets kann der doch schlecht einfach zurücksetzen wie's ihm passt...

Das ist tatsächlich merkwürdig. Versuch mal, ein Minimalbeispiel zu bauen (neues Projekt mit sonst nichts drin) und schau, ob du das Problem reproduziert kriegst.

vor einer Stunde schrieb Kokujou:

Und ich meinte eher ob du für "Global den Spielverlauf beeinflussen" irgendein Beispiel in meienm Code hast oder ob das jetzt eher so ein allgemeiner Tipp war.

Naja, so Klassen wie "Global" oder "Spielfeld" haben sehr viel Ahnung von dem, was überall passiert. Je mehr eine Klasse über andere Klassen weiß, desto weniger kann jede andere Klasse alleine leisten. Wenn du jetzt einen Fehler in "Spielfeld" hast, geht vermutlich das gesamte Spiel in die Brüche, weil die ganzen Systeme deines Spiels alle davon abhängen. Und das ist nicht gut.

Gerade beim drübergucken habe ich übrigens noch etwas neues entdeckt: Lange Funktionen. Versuch mal, deine Sachen in kurze Funktionen aufzuteilen. Beispiel... Statt

public void StartCar(Key key)
{
  if (key.isValid && keyslot.Accepts(key))
  {
    engine.enabled = true;
    engine.temperature = 30;
    engine.audio.Play();
  }
  else
  {
    alarm.enabled = true;
  }
}

eher

public void StartCar(Key key)
{
  if (KeyIsAccepted(key))
  {
    EnableEngine();
  }
  else
  {
    alarm.enabled = true;
  }
}

private bool KeyIsAccepted(Key key)
{
  return key.isValid && keyslot.Accepts(key);
}

private void EnableEngine()
{
  engine.enabled = true;
  engine.temperature = 30;
  engine.audio.Play();
}

Das erhöht die Lesbarkeit der Methode enorm. Des weiteren kann man so etwas an solchen Stellen verwenden.

Du machst hier dieselbe Sache mit zwei unterschiedlichen, aber gleichartigen Objekten. Erstelle dir stattdessen eine Methode, die einen Player übergeben kriegt (oder diesen vielleicht sogar erstellt) und rufe sie zweimal auf.

Eins zum Schluss noch: Ich habe in diesem Thread sehr viel Absolutes geschrieben. Ich bin natürlich kein Coding-Gott, der immer Recht hat. Ich sage nur Dinge, deren Hintergrund ich verstanden habe und den ich dann auch erklären kann. Trotzdem kann es natürlich sein, dass ich irgendwo mal was falsch verstanden oder wiedergegeben habe, oder zumindest eine Meinungssache wie ein Fakt rübergekommen ist. Das gilt für mich natürlich so wie für andere Leute, von denen du Informationen hast. Es ist daher auf jeden Fall richtig, Dinge zu hinterfragen und nichts einfach hinzunehmen. Vor allem nicht, wenn es nicht ausreichend erklärt wurde, dass alles Sinn ergibt. Ich glaube, das kriegst du ganz gut hin, aber ich dachte, ich schreib's mal, spätestens für andere Leute, die dieses Thema jetzt oder irgendwann einmal lesen

[Kokujou]

Ja bei den Funktionskürzungen bin ich fleißig dabei, was ja auch die Ursache des YakuManagers ist den du so anprangerst. Ich schieb schon überall Funktionen raus, ich hab auch kürzlich die ExtensionMethods entdeckt a la Linq und wie man die macht. Ein echter Segen. Btw. danke für den Absaz den hab ich übersehen^^

Obwohl ich eigentlich ein Fan der OOP bin hab ich wohl ne geheime Vorliebe für globales entwickelt... das werd cih noch wegkriegen müssen... Vorher waren 3mal mehr statische Variablen in der Global.cs

Und bei den Funktionsnamen: Man muss halt die goldene Mitte finden. Gegen 10 Zeichen hab ich nichts aber bei 30 hört's halt langsam auf XD

Ich hoffe dass sich der Fehler mit den SOs erledigt hab ich habs mal mit AssetDatabase.SaveAsset oder so versucht. Aber ob das was bringt weiß man ja erst später^^ Notfalls muss ich die zeilen halt immer in die Global schreiben.

Genau weil Unity dieses Komponentensystem hat versuche ich ja darauf umzusteigen. Darum ja auch der Yaku-Manager. So hat jedes Yaku-Prefab ne Komponente die sie rendert und der Yakumanager ist ne Komponente die sozusagen ihre Children im Griff hat und das gesamte Steuert.

[Sascha]

vor 18 Minuten schrieb Kokujou:

Ich hoffe dass sich der Fehler mit den SOs erledigt hab ich habs mal mit AssetDatabase.SaveAsset oder so versucht.

Ja Moment, geht es um Bearbeitung im Editor oder zur Laufzeit?

vor 19 Minuten schrieb Kokujou:

Darum ja auch der Yaku-Manager.

Joa, bei dem Ding würde ich aber eher den Namen Bemängeln. Ein YakuManager würde man i.d.R. interpretieren als ein Ding, das Yakus managed, nicht als die Koponente, die ein Yaku hat. Aber du hast da ja bereits eine Namensänderung vorgenommen, wenn ich mich recht erinnere

[Kokujou]

Ufff... es hat nicht geklappt >.> ich hasse es wenn mein ganzes Teil deswegen abstürzt... ich hab nur die Szene verwechselt und die Namen sind wieder weg... ich weiß echt nicht mehr weiter 😢 ich wüsste aber auch nicht wie ich ein Beispiel konstruieren soll ich weiß ja nichtmal woran's liegt! Ich hab jetz mal den Namen in Title geändert... aber wenn das auch nicht geht dann verklopp ich die *schmoll*

Und nein du hast was misverstanden der Manager ist die Komponente die der Parent ALLER yaku kriegt. der ehemaliger YakuHandler, dessen namensänderung geplant ist, ist die Komponente der einzelnen Yaku

[Sascha]

Äh... ne, hatte ich schon richtig verstanden. Hab nur die Namen verwechselt, denn die sind sich zu ähnlich!

Ich meinte natürlich den Handler.

Was aber die Namen angeht... ohne den Code da jetzt nochmal zu durchwühlen. Du erstallst die doch im Editor. Dann speicherst du sie. Warum erstellst du die überhaupt programmatisch (tust du doch, oder? nicht sicher), anstatt die einfach ganz normal im Editor anzulegen - also, mit der Hand?

[Kokujou]

Ich hab sie ja nur EINMAl angelget. dann waren sie da. ich hatte vorher alles über den konstruktor gemacht also habich mir ne ähnliche funktion gebaut und die Teile übers Skript erstellt^^ dann waren sie da und die Funktion ist rausgeflogen.

Das hat überall funktioniert nur bei den blöden Namen nicht.

[Sascha]

Und jetzt gehen die Namen sogar immer flöten, wenn du sie im Editor einstellst?

[Kokujou]

Immer nur in unregelmäßigen abständen ... vielleicht wenn ich Unity schließe oder ne neue Szene lade, keine Ahnung

Die Namen erstelle ich nicht im Editor, denn die Assets heißen ja genauso wie der Name sein soll also machich im Skript einfach .Name = .name

Und danach habich extra sogar AssetDatabase.SaveAsset oder so aufgerufen

[Sascha]

Warum rufst du nicht einfach .name direkt ab, anstatt denselben Wert woanders hinzuschieben?

[Kokujou]

Weil die Eigenschaft nur im MainThread abgerufen werden kann... ich hatte da in der ToEquals mal ne Fehlermeldung, keine Ahnung... Nur so ging es leider zu lösen 😢

[Sascha]

Gerade eben schrieb Kokujou:

Nur so ging es leider zu lösen 😢

Na das wage ich zu bezweifeln

Aber deswegen sage ich ja... Nenn das Ding "Title", benutz das stattdessen, und mach es unabhängig vom Dateinamen. Einfach im Editor eintragen und das benutzen

[Kokujou]

Na entweder das oder so ein krankes Konstrukt wie ich unterscheide welchen Thread ich für ne Funktion nehme XD aber das war mir zu blöd.

Keine Ahnung ob das jetzt FUnktioniert. Name und name dürfte als Unterscheidung eigentlich reichen solange er die Eigenschaft nicht schon benutzt hat. und das tut er eigentlich ja nicht.

[Sascha]

Wenn's dir nur um Unterschiedung geht, warum vergleichst du dann nicht einfach Referenzen oO

[Kokujou]

Ich meinte für Unity!

Die beiden Variablen kannst du doch hintereinander instanziieren, ich würd echt gern wissen warum Unity die plötzlich löscht.

[Sascha]

Weiß nicht, an welcher Stelle du .Name = .name machst, aber wenn du solche Dinge anfängst, dann arbeitest du nicht mehr mit dem Serialisierungssystem, sondern kämpfst dagegen an, und das ist nie eine gute Idee.

[Kokujou]

Serialisierungssystem? >.<

ich wollte nur eine öffentliche Eigenschaft haben die den gleichen Wert hat wie die krankhaft Threadgeschützte .name Eigenschaft die man aus dem Objekterbe hat

[Sascha]

Aber wozu? Wozu willst du den Dateinamen eines ScriptableObjects auslesen, das später gar keine Datei mehr ist? Mach dir doch einfach ein Titel-Feld und arbeite damit.

[Kokujou]

Hab ich ja! Das ist alles initiale Arbeit!
Bei der Erzeugung hatte das Asset denselben Namen wie die Karte später haben sollte und cih hab nur im Skript das nochmal gleichgesetzt weil ich keine Lust hatte alles händisch zu schreiben XD