BlockDefinitions umlagern

[fnawratil]

Warscheinlich wäre es sinnvoller nicht für jeden Block eine eigene Definition-Klasse anzulegen, sondern einmal eine grundlegende Definition festzulegen und dann eine Liste in form einer Textdatei zu haben, in der alle Blöcke samt grundlegenden Eigenschaften definiert sind.

Zu grundlegende Eigenschaften würde ich u.A. Folgendes zählen:

• ID des Blocks
• Name des Blocks
• Texturen des Blocks
• Härte
• Von Schwerkraft beeinflusst?
• Gedroppte Items
• Solid

Für Blöcke mit speziellen Eigenschaften und/oder speziellem Verhalten könnten dann "Instance-Klassen" angelegt werden. Die Blöcke werden dabei aber weiterhin in den Textdateien definiert.

BTW: Für Items ein ähnliches System?
**EDIT: Doch kein CSV? **

INFO: Mir schwebt dabei KEIN JSON vor! Das wird bei vielen Blöcken schnell relativ unübersichtlich.
Ich wäre da eher für eine Art "CSV" mit einer Zeile pro Block

Vielleicht etwas in Richtung
octoawesome:basics:block:wool:white,Weiße Wolle,wool_white.png,10,false,octoawesome:basics:item:wool:white,true

Ist das sinnvoll?

[ManuelHu]

Ich bin immer noch der Meinung, dass das aktuelle System grade ganz gut läuft und das es wichtigere Dinge gibt, die anstehen. Im Code ist schon alles formal definiert.

Drei Punkte, die mir eingefallen sind und evtl. mit solchen Dateien nicht mehr (so einfach) gehen:

• Lokalisierung. Derzeit laden wir die lokalisierten Zeichenketten aus Resx-Dateien. Wenn wir die wirklichen Strings in die Datei speichern, wie oben vorgeschlagen, geht die Lokalisierung verloren. Wenn wir auf die Einträge in der Resx-Datei mit Keys verweisen ist leider auch die "Eigenständigkeit" einer solchen Textdatei dahin.
• Texturen laden. Derzeit werden über die AssetComponent die Texturen geladen, diese verwendet zur Adressierung den Namespace des aufrufenden Typs. Auf diesem Mechanismus basiert die Überschreibungsmöglichkeit durch Resource Packs.
• Hit In jeder BlockDefinition ist noch eine Hit-Methode vorhanden. Evtl. brauchen wir die noch pro Blocktyp wenn wir Tools implementieren (wer weiß?). Mit einer Datei für alle Blöcke würde das eher schlecht gehen.

Zu den Formaten:

• csv muss ich jetzt wohl nicht viel dazu sagen, oder?
• json Finde ich bei großen Dateien extrem unübersichtlich, bei langen Objekten muss man oft scrollen um herauszufinden, in welchem Objekt man grade ist. Außerdem kann JSON (offiziell) keine Kommentare, nur Json.Net bastelt da was hin
• xml Finde ich persönlich gar nicht so schlecht, vor allem wenn man eine eigenen Serializer verwendet (der aus dem Framework erzeugt zugegebenermaßen nicht den lesbarsten Code bzw. nur mit vielen Anpassungen)

Mir fehlt außerdem noch in den Angaben die Zuweisungen von Texturen auf Blockseiten, die Dichte (evtl. Später für Gewicht im Inventar verwendet) und andere physikalische Eigenschaften, die evtl. für Interaktionen mit Werkzeugen wichtig werden und zur Zeit in den PhysicalProperties vorhanden sind. Damit wäre das schon etwas viel und unübersichtlich.

Was mir aber so als Mittelweg eingefallen ist: BlockDefinitions sind keine eigenen Typen mehr, sondern nur noch Instanzen der (dann nicht mehr abstrakten) Basisklasse BlockDefinition. Damit sind die drei oberen Punkte weiterhin machbar.

[Gallimathias]

Beispiel Dateien, json und xml
Example.zip

[Gallimathias]

Hängt zusammen mit #197 #196 #195

[HierGibtEsDrachen]

Das einzige Problem das ich sehe ist die Hit Funktion.
Für die Lokalisierung könnten einfach vollständige Pfade verwendet werden.
Hab da eigentlich an so was gedacht: (ist ein Beispiel aus einem anderen Projekt^^)
Example.zip

[ManuelHu]

Nicht nur die Hit-Funktion, auch jede sonstige Logik wäre schwer.
Was meinst du mit vollständigen Pfaden? Den Key aus der Resx-Datei, der auch zur Zeit zur Identifikation verwendet wird?

Na ja, und wir müssten einen zweiten, Namespace-unabhängigen Weg zum Laden von Texturen einführen (oder an den Standard-Namespace der Erweiterungs-Assembly binden)

[HierGibtEsDrachen]

Hätte vllt. eine passable Idee. ist zwar weder fertig noch ausgereift aber es könnte gehe, was meint ihr?
Dann müssen die Extension-Klassen aber mehr Logik implementieren.
[fileblockdefinition.zip] https://github.com/OctoAwesome/octoawesome/files/1745531/fileblockdefinition.zip)

[jvbsl]

die IDs für resourcen werden erst zur Runtime festgelegt, natürlich nur einmal, aber abhängig von Mods u.ä. somit würde das wenig Sinn ergeben das hier reinzuschreiben.
XML find ich etwas sehr redundant und unübersichtlich, welche Resourcen ein Block zurückgibt sollte meiner Meinung nach vom WorldGen festgelegt werden, nicht vom Block selbst, außerdem finde ich man sollte einfach nur stein oder whatever haben und man weiß nicht wie viele resourcen drinne sind, man kann es dann aber zermahlen und dann wird je nach Maschine der entsprechende Output erzeugt, so würde mir das zumindest besser gefallen, weil es doch auch etwas realistischer ist. ;)

[HierGibtEsDrachen]

Die ID war eher so gedacht das die Extension dann weiß welcher Block bzw. Resource das ist und welche Methode dafür aufgerufen werden soll... Jo das mit dem WorldGen ist auf jeden Fall einleuchtender. Dann sollten wir aber die Resourcen zuerst in den WordGen laden damit er sie anschließend wenn der Block tatsächlich verarbeitet wird (über die Blockposition) verteilen kann?
Aber wenn die physikalischen Eigenschaften wie Dichte usw. in jedem Block vorhanden sind kann auch die Hit - Methode ausgelagert werden. Die muss die Blockdefinition auch nicht kennen (meiner bescheidenen Logik nach). Und das laden der Extension muss nicht unbedingt kaputt Optimiert sein. XML ist halt gut lesbar und übersichtlicher als Binary :P

die IDs für resourcen werden erst zur Runtime festgelegt

Es kann alles geändert werden, sofern es sinnvoll ist ^^

[jvbsl]

Ja eine Blockdefinition kann von mir aus theoretisch bestimmte Dinge eingrenzen, wie z.B. Schnee kann kein Eisen enthalten, aber Aluminium(ergibt kein Sinn aber ist nur ein Beispiel), was dann ja auch Teil der BlockDefinition wäre, der WorldGen bekommt ebenfalls die BlockDefinitions. Ich meine die Blockdefinitions könnten von mir aus auch noch ein PostProcessing über die vom WorldGen gelieferten Daten machen.
Dichte und ähnliches würde ich wiederum nicht für jeden einzelnen Block machen(höchstens abhängig von den intern vorhandenen Rohstoffen, was dann wieder ein PostProcessing step und somit als Teil der BlockDefinition nicht unsinnvoll wäre)

nene ich meinte damit nicht, dass man ein Binäres format hat(außer dass ich gerne ein Binäres Format hätte zum Cachen, aber da ist ja das Anfangsformat egal).
Sondern eben ein Format, was das ganze nicht so künstlich aufbläst, z.B. json eben, oder eine abgewandelte Version davon

[HierGibtEsDrachen]

Ja dann ist die Frage ob der User das File per Hand Editieren können darf bzw. kann oder soll oder was auch immer oder das quasi gemanaged im Spiel abläuft mit einer wunderschönen graphischen Oberfläche. Bei Dichte und Masse geb ich dir vollkommen recht, PostProcess NEEEEED.
Jason hab ich iwie keinen Bock selber zu schreiben ^^
Die Eingrenzung ist aber nur Bedingt möglich außer die Resource weiß wo sie nicht hingehört (bzw. weiß wo sie hingehört Tiefe, Art des Blocks d.h. Flüssig, Fest), denn sonst muss die Blockdefinition Hellsehen können. Wenn wir schon dabei sind hat jemand über Gase nachgedacht? (:

[susch19]

@HierGibtEsDrachen Also ich muss ganz ehrlich sagen, dass ich JSON immer selber schreiben kann, auch ohne Tool oder Fancy Editor. Notepad von Windows reicht vollkommen aus. Bei XML ohne einen guten Editor bin ich aufgeschmissen, da schleichen sich so schnell Fehler ein und man muss so viel mehr tippen. Vermutlich ist das eine persönliche Meinung, aber das ist scheinbar auch dein Argument.
Außerdem ist bei Tooling das Ausgabeformat vollkommen egal, dann können wir das auch mit einem BinaryWriter und BinaryReader wegserializieren, dann brauchen wir weder XML noch JSON.

[HierGibtEsDrachen]

Was ich noch sagen wollte zu diesem leidigen Thema... xml, json, binary oder Digitalisierung von jvbsl Gedanken? Warum nicht alles auf einmal, dann kann sich der User immer noch entscheiden was er machen will! Es wird meiner Meinung nach nicht schlimmer wenn man mehr Features hat.
Und liebe Leute man kann XML so und so schreiben, dass eine wird größer das andere besser :)
Ein Tool kann xml immer noch in jason umschreiben.

Wir bräuchten um die Ressourcen vernünftig berechnen zu können eine Datenbank mit Element bzw. Stoffen und ich meine nicht die BlockDefinitions, dass reicht nicht den eine Definition definiert einen Block und die Definition existiert ohne Kontext. Könnte über ein eingebautes Periodensystem gehen,
Wasser, Schnee Eis ist 2 H und O -> H2O ... somit kann Alu darin nicht vorkommen? Ein Stein ist hingegen vieles, und wird als Mischobjekt betrachtet, zusammen mit der Dichte und näherer Beschreibung des Steins könnten dann andere Ressourcen berechnet werden. Wie die Beschreibung aussehen könnte weiß ich noch nicht aber das wird auch umfangreicher.
https://www.welt.de/print/die_welt/wissen/article108767158/Wie-viele-Stoffe-gibt-es.html
Wir müssen den Maßstab nicht so hoch setzen.^^

Was ich noch sagen muss. Eine Kennung für ausgelagerte Definitions muss auf jeden Fall her. Momentan ist es so, dass die Definition zur Runtime eine ID bekommt, und damit kann gearbeitet werden sobald das ganze ins Rollen gekommen ist. Allerdings ist es momentan so das sich der Complexplenetgenerator die ID über den Type der Definition wieder raus holt. Das geht noch solange es nur eine Extension gibt bzw. alle Extensions nur ihr eigenes Zeug verwenden. Ich könnte damit leben wenn die Definitions eine Art festes Token bekommen, am besten einen string da ist die viel fallt schier unendlich, über die Ingame auf eine unbekannte Definition verwiesen werden kann. Dadurch könnten Definitions in eine Datenbank ausgelagert werden die Extension unabhängig ist. Notfalls zieht man sie sich vom Server und speichert lokal ab. Was die Logik in den Definitionen angeht bin ich der Meinung das diese ausgelagert werden kann und und diesem Zusammenhang aus sollte.

[XYZLassi]

Hallo,m
alle zusammen, ich möchte die Diskussion mal wieder aufgreifen.

Ich bin jetzt nämlich für yaml als Format, weil ab der Version 1.2 von Yaml ist Json eine echte Untermenge und damit könnte ein Parser beides ohne Probleme parsen.

[Gallimathias]

Der Vorschlag gefällt mir @CsharpLassi. Vor allem ist das ein schöner Kompromiss. YAML ist sehr einfach in seiner Grundstruktur, das bekommt quasi jeder hin, und wenn man mehr was objektorientiertes braucht bzw. was komplexeres kann man einfach json mit in die Datei nehmen. Das ist klasse.