Diskussion: Modelldaten

Weitere TAGs bei Blockmodellen mit unbekannter Funktion[]

Ich hab mir eben nochmal ein paar Dateien von Block-Modellen angeguckt und weitere TAGs gefunden, bei deren Nutzen ich mir nicht ganz sicher bin.

Einmal gibt es da randomOffsetX (gleiches für Y und Z), welches bei Gräsern und Blumen zur Anwendung kommt und meiner Meinung nach für die leichte zufällige Verschiebung eben dieser Objekte verantwortlich ist. Es hat allerdings keine Auswirkungen den Wert von true'# auf false zu setzen oder den TAG komplett zu löschen, die zufällige Verschiebung bleibt.
Dann gibt es den tintindex, der Standartmäßig bei 0 liegt und wohl für die biomspezifische Färbung von Gräsern und Blätter zuständig ist, es hat allerdings keine Auswirkungen, wenn man den angegebenen Wert verändert. Nur wenn man den TAG komplett löscht fällt auch die Färbung der Blöcke weg und diese werden nur noch mit einer grauen Textur dargestellt.
Den TAG inventoryRender3D hab ich zwar schon in die Liste aufgenommen, was er tatsächlich bewirkt, hab ich aber auch nach zwei Tagen rumprobieren noch nicht rausgefunden. Da es den schon recht lange gibt, kann es gut sein, dass seine Funktion weggefallen ist, der TAG selber aber noch nicht aus den Dateien entfernt wurde (habe auch manchmal noch cull gefunden, was eigentlich durch cullface ersetzt wurde), würde mich also nicht wundern wenn da was verschlafen wurde.

Vielleicht weiß ja einer von euch zu irgendeinem der Punkte ein bisschen mehr, sonst wird sich das wohl im Laufe der Zeit noch klären. Jason135792 (Diskussion) 13:01, 21. Jun. 2014 (UTC)

Leider steht immer noch "Fair warning, this format is highly likely to change even more in the future!" in den Dateien. Der Name "inventoryRender3D" lässt vermuten, dass es um die 3D-Darstellung im Inventar geht, aber das scheint keine Wirkung zu haben. Dann trifft im Zweifelsfall wohl zu, was Dinnerbone im Blog zum Snapshot geschrieben hat: "It is very likely that this snapshot may be more unstable than usual, slower than usual, slightly more sentient than usual or just generally unusual." Daher ist deine Prognose wohl die richtige: das wird sich hoffentlich mit den nächsten Snapshots klären. -- Sumpfhütte 13:49, 21. Jun. 2014 (UTC)

Fehler builtin/buildin[]

Ich habe gerade einen kleinen Fehler gefunden. Und zwar wird im Absatz über die Gegenstands-Modelle manchmal von builtin und manchmal von buildin gesprochen. Was ist wann richtig oder gibt es eines gar nicht? Allerdings liegt auf jeden Fall ein Fehler beim Beispiel mit der Fackel vor. Dabei wird oben im Code von builtin, in der Beschreibung aber von buildin gesprochen.
LG
Flitzor (Diskussion) 16:16, 22. Nov. 2014 (UTC)

Danke, ist korrigiert. Es heißt immer "builtin". -- Sumpfhütte 16:23, 22. Nov. 2014 (UTC)

Blockmodelle "angle" ist ein Int?[]

Hallo,
Mir ist gerade aufgefallen, dass "angle" als Integer eingetragen ist. Das kann aber nicht sein, da es ja 22.5 enthalten kann. Was ist denn da der richtige Datentyp? --Schortan (Diskussion) 13:59, 20. Feb. 2015 (UTC)

Oha! Leider kann man nicht einfach mal in den Blockmodellen nachgucken, denn das rotation-Tag mit origin, axis, angle und/oder rescale wird von keinem einzigen Blockmodell genutzt. Das bedeutet, dass das Tag entweder entfernt wurde oder dass es nur für Ressourcenpakete gedacht ist. Das müsste man mit einem Test-Blockmodell ausprobieren oder noch besser: den Quellcode dazu analysieren. -- Sumpfhütte 14:16, 20. Feb. 2015 (UTC)

Es ist ein Float. | violine1101 ^(Diskussion) 17:12, 20. Feb. 2015 (UTC)

Der Tag existiert definitiv. Siehe cross.json in den Standardressourcen. --Schortan (Diskussion) 20:19, 20. Feb. 2015 (UTC)

Weia! Offenbar gab es einen Fehler bei meiner Textsuche. Du hast recht, es gibt sogar viele Blöcke mit "angle", darunter brewing_stand_bottles, double_sunflower_top, fire, flower_pot, lever, stem, tall_grass, torch_wall und tripwire_hook. -- Sumpfhütte 13:49, 21. Feb. 2015 (UTC)

Ist ja nicht weiter schlimm^^

Aber wenn wir gerade schon dabei sind: Bei den Blockmodellen, überall wo ein list mit [x, y, z] ist, können auch für x, y, z Kommazahlen verwendet werden. Da dies hier aber einfach nur als list angegeben ist, wäre es schön, entweder einen Datentyp für den Inhalt der List anzugeben oder wenigstens einen Hinweis hinzuzufügen, dass Kommazahlen verwendet werden können. Beim Erstellen meines Ressourcenpaketes ging ich nämlich lange Zeit davon aus, dass ich bei der Einheit an 16er Schritte gebunden bin. Gerade wenn man bei z.B. einem 32x32-Paket pixelgenau arbeiten will, ist es schon gut zu wissen, dass das mit x.5 geht. --Schortan (Diskussion) 11:43, 22. Feb. 2015 (UTC)

Erledigt. -- Sumpfhütte 17:19, 22. Feb. 2015 (UTC)

Blockstates auf Blockseiten?[]

Mir ist aufgefallen, dass in der englischen Wiki auf allen Blockseiten aufgeführt wird, welche Blockstates für den Block zur Verfügung stehen. Die Frage ist jetzt, wäre dies auch hier erwünscht? Ich würde mich da an der Umsetztung auch beteiligen, nur wäre es halt blöd, wenn ich jetzt einfach mache und es aber nicht gewollt ist.
Die Frage wäre auch, ob man es genauso umsetzt wie in der englischen Wiki. Es gibt Blockzustände, die nicht in der Block.json verändert werden können, wie z.B. has_record beim Plattenspieler. Desweiteren gibt es Blockstates, die zwar beeinflusst werden können, aber nicht über die Datei. Das ist dann der Fall, wenn es sich um unterschiedliche Blöcke handelt. Der Block mit der ID minecraft:stone hat z.B. den Blockstate "variant" mit möglichen Werten "stone", "granite", "smooth_granite", "diorite", "smooth_diorite", "andesite" und "smooth_andesite". Es gibt für jeden Blockzustand in diesem Falle aber eine eigene Datei (stone.json, granite.json,...).
Mein Vorschlag wäre etwas in dieser Richtung:

Blockstate	Werte	Beschreibung	Änderbarkeit
z.B. has_record	z.B. true false	z.B. True, wenn in dem Plattenspieler eine Schallplatte eingelegt ist.	Kann in blockname.json verändert werden je nach Dateiname kann nicht in vanilla Minecraft verwendet werden.

In der englischen Wiki wird dafür eine Vorlage verwendet, was ich auch als sinnvoll erachte, um zu verhindern, dass eigene Designs verwendet werden.
In der englischen Wiki wird die Tabelle immer auf die Seite Block/BS geschrieben, da dort alle Blockstates auf einer Seite zusammen gefasst werden und man so dieselbe Tabelle auf unterschiedlichen Seiten verwenden kann. Wollen wir auch so eine Seite? --Schortan (Diskussion) 09:41, 8. Sep. 2015 (UTC)

Darüber habe ich auch schon nachgedacht. Ich glaube jedoch, die Blockzustände sind für den normalen Spieler völlig unbedeutend. Das Wichtigste, was man über einen Block wissen möchte ist: "Wie sieht der aus, wie bekommt man den und was kann man damit machen?" Das wird in den jeweiligen Artikeln erklärt. Mit Befehlen können schon nicht mehr alle Spieler, sondern nur noch die im Singleplayer experimentieren. Blockzustände sind aber auch für diese nicht interessant, sondern höchstens für jemand, der die Modelldaten ändern möchte. Unerwähnt sollten sie aber auch nicht bleiben. Wie wäre es, wenn wir es genauso machen, wie mit den Metadaten: Die stehen in jedem Blocksteckbrief mit Verlinkung auf den richtigen Abschnitt im Metadaten-Artikel. Mit einem einzigen Klick ist man dann da. Das könnte für die Blockzustände genauso gemacht werden. -- Sumpfhütte 11:10, 8. Sep. 2015 (UTC)

Die Idee gefällt mir. einfach eine beschreibende Verlinkung. Das würde auch erlauben, Zustände, die von mehreren Blöcken verwendet werden zusammen zu fassen.

Da ein Block aber mehrere Parameter bei den Blockzuständen haben kann, würde ich dann für jeden Zustand eine eigene Verlinkung verwenden. Ausnahme könnte hier so etwas wie north: true/false, east:true/false (...) sein, da man dies zusammenfassen könnte. --Schortan (Diskussion) 20:55, 8. Sep. 2015 (UTC)

Ich hatte das so gedacht, wie bei den Metadaten. Da gibt es im Block-Steckbrief eine Verlinkung zu dem passenden Abschnitt im Artikel Metadaten. Das gibt es jetzt auch für Blockzustände. Guck mal in den Steckbrief vom Amboss, da habe ich es eingebaut. Du könntest nun diesen neuen Steckbrief-Parameter nach und nach in alle relevante Blockartikel einbauen (ca. 100) und dabei prüfen, ob die jeweilige Tabelle im Artikel Blockzustand noch richtig ist. -- Sumpfhütte 11:26, 9. Sep. 2015 (UTC)

Oh, ich habe diese Seite noch nie gesehen. Ich habe mal eine Weiterleitung von Blockstates erstellt, damit auch Leute wie ich dahin finden :D

Mir gefällt dort die redundante Datenhaltung nur nicht so. facing liefert z.B. 29 Treffer bei 29 unterschiedlichen Blöcken mit diesem Zustand. und in der Beschreibung steht dann auch derselbe Text.

Ich würde da eher eine globale Erklärung zu facing verwenden, wo dann auch die Blöcke, die es verwenden aufgeführt sind.

Bei den Metadaten ist es ja auch soweit wie möglich zusammen gefasst. --Schortan (Diskussion) 12:02, 9. Sep. 2015 (UTC)

Naja, ich verstehe diese Anordnung aber schon auch. Man sucht ja eher danach "was gibts beim Amboss?". Und so müsste man sich alles immer zusammen suchen. Trotzdem würde ich dann lieber eine Blockzustand/facing anlegen und diese dann dort einbinden, wo Facing verwendet wird. ich wage aber zu bezweifeln, dass die aktuelle Vorlage das zulässt.

Die Frage wäre auch, wie und ob man die von mir angesprochene Änderbarkeitsspalte hinzufügt. --Schortan (Diskussion) 12:31, 9. Sep. 2015 (UTC)

Ich habe noch nicht verstanden, was du mit dieser Spalte aussagen möchtest. Die Zustände sind doch ein Ergebnis dessen, wie man den Block setzt. Um den Zustand eines Blockes zu ändern, muss man ihn nur anders setzen. -- Sumpfhütte 12:57, 9. Sep. 2015 (UTC)

Ich meine nicht das Ändern das Blockzustandes. Ich meine das Ändern das Blockmodells basierend auf den Dateien im Ressourcenpaket unter "blockstates". Auf "has_record" hat man dort z.B. keinen Zugriff, man kann also kein anderes Modell für einen Plattenspieler mit has_record zur Verfügung stellen. Woanders braucht man die Zustände doch auch gar nicht. --Schortan (Diskussion) 13:18, 9. Sep. 2015 (UTC)

Verstehe. Dann würde ich die Spalte "Blockmodell" nennen. Ein "nein" bedeutet, dass es kein Blockmodell für diesen Zustand gibt, d.h. der Zustand ist am äußeren Erscheinungsbild des Blockes nicht erkennbar. Zusätzlich könnte man noch die Spalte "Speicherung" hinzufügen. Wenn der Zustand in den Metadaten gespeichert wird, wird auf den entsprechenden Abschnitt verlinkt, wenn nicht, wird beschrieben, wie das Programm den Zustand erkennt (z.B. durch die Koordinaten oder die Nachbarblöcke). -- Sumpfhütte 13:32, 9. Sep. 2015 (UTC)

Ich würde bei Blockmodell aber auch die Variante berücksichtigen, dass oft für variant mehrere Dateien existieren (wie oben beschrieben). Man könnte z.B. die Spalte nennen "Zuweisung eines Blockmodells" und die Variantem "in blockname.json" oder "nicht möglich" verwenden.

Speicherung könnte man machen, ja. Es sollte aber berücksichtigt werden, dass es sein kann, dass Mojang in 1.9 oder anderen zukünftigen Versionen Metadaten komplett entfernt und durch Blockzustände ersetzt. --Schortan (Diskussion) 12:59, 10. Sep. 2015 (UTC)

Zur Speicherung: Ich kann mir nicht vorstellen, dass die Metadaten entfernt werden, denn noch in der 1.8 - als das API-Konzept mit den Modelldaten kräftig weiterentwickelt wurde - wurden verschiedene Steinarten als "Stein mit Metadaten" hinzugefügt. Ich kann mir auch nicht vorstellen, dass Blockzustände gespeichert werden, denn sie ergeben sich aus den Metadaten oder aus den Nachbarblöcken (Zaunausrichtung) oder Koordinaten (Feuer mit 3072 Varianten).

Zu den Varianten: Mach doch mal eine Beispieltabelle (ohne die Vorlage) für die "Tür". Sie hat 5 Zustände mit insgesamt 32 Varianten. Das ganze für sechs Holzarten = 192 Varianten. Wie könnte das deiner Meinung nach aussehen? -- Sumpfhütte 15:14, 10. Sep. 2015 (UTC)

Ich glaube auch nicht, dass alle Blockstates gespeichert werden. Ich weiß auch nicht, wie es kommen wird oder ob. Aber wenn es kommt, muss es halt dann noch mal geändert werden. Ist jetzt ja auch nicht so wichtig.
Wo du übrigens gerade vom Feuer sprichst: Interessanterweise sieht die fire.json unter blockstates in den Snapshots anders aus, als vorher. Nur noch 50 Zeilen. Wie man mit diesem Sonderfall umgeht, weiß ich auch noch nicht, zumal ich es auch nicht zu 100% verstehe, was dort los ist.

Die Art der Tür wird durch die unterschiedlichen Dateien im Ressourcenpaketordner unter blockstates festgelegt (Da es sich um unterschiedliche Block-IDs handelt, gibt es keinen Variant-Zustand).

ID	Name der Datei	Beschreibung
64 wooden_door	wooden_door.json	Eichenholz
71 iron_door	iron_door.json	Eisen
193 spruce_door	spruce_door.json	Fichtenholz
194 birch_door	birch_door.json	Birkenholz
195 jungle_door	jungle_door.json	Tropenholz
196 acacia_door	acacia_door.json	Akazienholz
197 dark_oak_door	dark_oak_door.json	Schwarzeichenholz

Zustand	Werte	Beschreibung	Blockmodell- zuweisung	Speicherung
facing	`north south east west`	Die Himmelsrichtung, in die die Tür-"Innenseite" ausgerichtet ist. Dies ist die Richtung, in die der Spieler beim Platzieren der Tür schaut. Eine geschlossene in Richtung Osten ausgerichtete Tür z.B. befindet sich auf der westlichen Hälfte des Blocks.	möglich	In den Metadaten.
half	`upper lower`	Die Tür besteht aus 2 Blöcken. Der Wert bestimmt ob es der untere (lower) oder der obere (upper) ist.	möglich	In den Metadaten.
hinge	`left right`	Die Seite, auf der die Türklinke ist.	möglich	In den Metadaten.
open	`true false`	true, wenn die Tür im Moment geöffnet ist.	möglich	In den Metadaten.
powered	`true false`	true, wenn die Tür im Moment ein Redstonesignal erhält.	nicht möglich	nirgends

Da es irgendwie blöde wäre alle 7 Türdateinamen aneinanderzureihen, habe ich jetzt doch nur "Möglich" reingeschrieben und dafür oben die Dateinamen aufgeführt. --Schortan (Diskussion) 18:15, 10. Sep. 2015 (UTC)

Ja, das sieht schon mal ganz gut aus. Man bräuchte jetzt noch weitere Beispiele, und zwar solche, wo es ganz anders ist. Könntest du das noch hinzufügen? Nur so können wir herausfinden, welche Spalten wir brauchen und wie sie am besten beschriftet und gefüllt werden. Dann ändere ich die Vorlage und die Verbesserung des Artikels kann beginnen. -- Sumpfhütte 11:08, 17. Sep. 2015 (UTC)

Erledigt: Ich habe den Artikel Blockzustand jetzt überarbeitet. Nun sind dort alle Blockzustandsdateien aufgelistet und alle Metadaten verlinkt. Die Zusammenfassung von ähnlichen Blöcken erfolgte analog zu den Metadaten. -- Sumpfhütte 14:53, 19. Okt. 2015 (UTC)

Sieht schon mal ganz gut aus so. Tut mir leid, dass ich nicht mehr geantwortet habe, ich habe irgendwie nicht gesehen, dass hier noch etwas von dir gekommen war. --Schortan (Diskussion) 17:35, 4. Nov. 2015 (UTC)