Get Data Table Row dynamisch Werte zuweisen

    @DarkFaces
    Da spricht absolut nix gegen die RowNames durchzunummerieren.
    Ich meinte eher so einige recht bekannte Inventar-Tutorials und Lösungen im Netz, die zeigen wie es gehen soll, sind aber im Grunde recht schlecht entwickelt.
    Die ID ist dann meist einfach ein Int-Wert.
    Dann werden alle Einträge durchgeloopt erst einmal komplett eingelesen und mit jedem Eintrag wird der Int-Wert verglichen.
    Anstatt gleich den RowName als ID zu "missbrauchen" und direkt zum richtigen Eintrag zu springen, was bedeutend schneller geht.
    Aber du machst das ja absolut korrekt - ich habe das Ganze nur so allgemein dazugeschrieben, weil es zum Thema passte und auch nicht jeder weiß bzw. den "Trick" kennt.


    Also die meisten Survival-Spiele und Ego-Shooter haben mit unter heutzutage tausende verschiedenen Items und hunderten Eigenschaften dazu.
    Dafür braucht man mindestens eine DT - aber besser wäre SQl, weil man seine SuchFilter als direkten Indexzugriff definieren kann.
    Denn auch für die Filter braucht man nicht eine Unmenge an Branches usw.
    Wer einmal auf einer Webseite mit SQL programmiert hat kennt die unglaublich guten Möglichkeiten.
    Im Groben ist einer SQL-Datenbank nämlich egal wie groß sie ist - sie wird nicht langsamer, weil indexiert wird.
    Eine Daten-Tabelle hingegen kommt einfach einer CSV-Datei gleich, die von oben nach unten seriell ausgelesen wird.
    Die langsamste Methode Daten zu lesen.
    Mit den RowName=ID "Trick" kann man wenigstens etwas schneller aus den Speicher lesen - ersetzt aber keine Indexierung.
    Da im Grunde intern trotzdem auch mit den RowName-Direkt-Sprung die ganze Tabelle von Anfang an bis zum exsprechenden Eintrag durch geloopt wird.
    In der Indexierung einer SQl-Datenbank wird die Festplatte direkt zum Eintrag angefahren.
    Ein Unterschied wie Tag und Nacht.
    Wenn man natürlich nur 50 Items in seinem Projekt hat, fällt es nicht ins Gewicht.


    @Socke
    Das ist die API-Anbindung, die es ermöglicht ein Datenbank-Plugin zu integrieren.
    Die API gibt es seit Anbeginn und ist keine Vorbereitung für eine evtl. geplante standardmäßige SQL-Integration.
    Das ist reine Drittanbieterunterstützung.

    @Franz99


    Ok, für tausende Items mag das System mit den DataTables nicht geeignet sein. Aber wir als kleine Hobby Entwickler brauchen ja schon Jahre um uns tausende sinnvolle Namen einfallen zu lassen.


    Wäre natürlich schön wenn die Engine für jeden von uns die Tools hätte die man sich wünscht, aber ich glaube bei Epic hat das keine hohe Priorität. Große Studios haben jemand der dafür zuständig ist und wir müssen halt gut planen und tricksen.

    Mir würde es schon gefallen, wenn der DatenTabellen-Editor mal etwas mehr Suchfilter und Eintrags-Ordnungsfunktionen hätte.
    Wenn man mal ein Item irgendwo dazwischenschieben möchte, kann das bei entsprechend vielen Einträgen schon mal das Wochenende andauern.
    Stell dir vor du nummerierst deine Items durch.


    25 Apfel
    26 Pflaume
    27...
    usw.
    Nun füge mal ein Item Birne hinzu.
    1. ist der Eintrag nur ganz unten oder ganz oben und muss Zeile für Zeile an die richtige Position geklickt werden und 2. ist die ID nun auch nicht mehr so einfach dazwischenzuschieben.
    Eine Sisyphus-Umbennen-Arbeit erster Kajüte. :D
    Wenn einem allerdings die Reihenfolge oder die ID völlig egal ist - kann man neue Dinge natürlicjh immer nur ans Ende setzen.
    Dann braucht man aber auch keine Tabelle, die eigentlich Ordnung und Übersicht bringen soll. ;)


    Die Datentabelle, die in der Engine eigentlich Ordnung in viele Daten bringen soll, versagt nämlich genau an der Stelle, wenn es um Ordnung geht, weil einfach wichtige Funktionen fehlen.
    Für mich unverständlich, aber man gewöhnt sich ja so allgemein an vieles . ;)


    Aber als Tipp - besser ist solche Tabellen in zb. Excel zu erstellen und zu pflegen und dann erst als CSV in die DT zu importieren.
    So mache ich das. :)

    Ja den DT-Editor kann man wirklich nur gebrauchen um zu schauen ob der Import geklappt hat oder um schnell ein paar Test Einträge für die Entwicklung zu machen. Lieber in Excel und Co ändern und neu importieren.


    Zitat von Killerzwerg

    Meinst du es wäre besser, lieber mehrere kleine DataTables zu benutzen, statt einem großen?

    Ich glaube das kann von Projekt zu Projekt unterschiedlich sein.
    Wenn man das Aufteilt hat man halt kein riesiges DataTable mit nutzlosen Einträgen für verschiedene Item Typen. Einem Heiltrank ist die Reichweite eines Schwertes ziemlich egal.


    Ich hab das jetzt so organisiert das es ein Master-DataTable für alle Items gibt. Da sind die Sachen drin die auch jedes Item braucht, also die ID, welches Mesh, welches Bild im Inventar angezeigt wird, welche Kategorie usw, und das DataTable mit den Werten für die einzelnen Kategorien.


    Man braucht ja auch nie alle Werte gleichzeitig. Ein Item das in der Welt rumliegt und auf seinen neuen Besitzer wartet braucht seine Werte ja nicht zu wissen, nehme ich es auf wird es eh zerstört und die Id meinem Inventar hinzugefügt. Schaue ich dann ins Inventar wird mir erstmal nur ein Bild und die Anzahl angezeigt. Erst wenn ich es mir genauer anschaue werden auch die genauen Werte benötigt. Die kann sich dann das Widget aus dem DataTable holen.

    Ich hab z.z. 2 Main-DTs, eine mit allen Items und eine mit allen Rezepten fürs Crafting, wobei in der für alle Items grad auch noch Rüstung und Waffen-Werte drin stehn, was aber irgendwann ausgelagert wird, spätestens wenn die Hotbar und das Angriffssystem halbwegs fertig ist und ich mehr DTs für die ganzen Unterkategorien erstellt hab.
    Das einzige was jetzt schon drin ist, ist ein Enum "Kategorie", welches aber noch keine Funktion hat...

    Ganz nebenbei:
    Vielleicht kann das jemand bestätigen.
    Wenn man geschachtelte Structuren für eine DT benutzt - also Structur-Variable in einer Structur-Variable, habe ich ab und an Compiler Errors, wenn ich die Structur, die in der Structur liegt, verändere - das heißt Variablen hinzufügen, löschen oder umbenennen.
    Damit meinte ich nicht, dass dadurch evtl. Node-Verbindungen reissen - das ist schon klar - sondern, dass die Structuren selbst auf einmal Compiler-Errors produzieren.
    Die einzige Möglichkeit das zu fixen ist dann alle Structuren komplett neu anzulegen.
    Es passiert nicht immer - eher sogar seltener, aber es passiert.
    Hat da jemand Infos zu?

    Hab schon öfter gelesen das es mit Structs Probleme gibt, hatte selber aber noch keine.


    Es gibt ein als Beta markiertes Plugin Namens StructBox (Adds new struct type, that can contain any other struct). Keine Ahnung ob es bei dem Problem was hilft.

    Am Anfang hab ich auch mit einer DT mit nummerischen ID gearbeitet. Das ist aber ein Fehler in meinen Augen. Aktuell haben wir Tables mit Kategorien. Die kann man auch zwischen den DT verlinken, wenn man es im CS einstellt.


    Es spiel letztlich keine Rolle, wie der Aufbau der Items ist, da die Position im DT keine Rolle spielt, das dient der eigenen Übersichtlichkeit, aber sonst nix und die Erhält man, wenn man DT für Kategorien anlegt, da alles weitergegeben werden kann. Die Dinger sind schließlich readonly, sodass man nur die Row auslesen muss und da funktioniert eine Verkettung. Der Rowname sollte keine Zahl sein, sondern ein eindeutiger Name mit einer Syntax.

    Zitat von Annubis

    Der Rowname sollte keine Zahl sein, sondern ein eindeutiger Name mit einer Syntax.

    Einen wirklichen Grund hast du mir aber nicht genannt. Im Grunde ist der Name auch völlig egal da man ihn nie wirklich sieht.
    Nur derjenige welcher die Items in der Welt platzieren muss hat die Arschkarte und darf jedes mal den Namen eingeben. Hier wäre ein Dropdown Menü besser, aber das ist eine andere Geschichte.


    Mit Ziffern als RowName kann man auch einfach Random Items erzeugen.


    Zitat von Annubis

    Der Rowname sollte keine Zahl sein, sondern ein eindeutiger Name mit einer Syntax.

    Also ich benenne zwar die RowNames eher auch nach dem, was der Gegenstand darstellen soll, aber was spricht denn gegen eine Zahl?
    Der Name ist doch in erster Linie intern einfach nur eine ASCI Reihenfolge und der Engine müsste es ergo völlig egal sein, ob das 123 oder ABC ist.
    Genau aus dem Grund kann auch jede Datei auf dem Computer einfach nur aus Zahlen im Namen bestehen.
    Ich empfinde das mit den Zahlen sogar als kreativen Vorteil, denn was immer man auch so verrücktes machen kann, man könnte thoeretisch sogar mit den RowNames richtig rechnen. 8)
    Der Grund warum ich auch keine IDs als Name benutze ist aber nur, dass ich mir die ganzen IDs nicht merken muss wenn ich im Editor mal ein bestimmten Gegenstand ändern oder hinzufügen möchte.
    Vielleicht ist das ja auch deine Argumentation, die gegen eine Numerierung spricht.

    Da ich das hier gerade lese. Mal im Blueprint "File" -> "Refresh All nodes" probiert?