Minecraft Wiki
Advertisement
Archiv

Bitte die Befehle dazuschreiben[]

Hallo, ich wollte das ganze mal ausprobieren und wollte nur mal darauf hinweisen, dass manche sich nicht so gut auskennen und es wäre nett unter die Beschreibung die kompletten Befehle dazu zu schreiben. z.B.: beim scheinbar nutzlosen Schwert: /give @p minecraft:diamond_sword 1 ... bitte die Befehle an sich dazu schreiben!!!! Damit man es selbst auch ausführen kann, auch wenn man sich nicht richtig auskennt. Danke! --Herbert8 (Diskussion) 11:07, 14. Feb. 2017 (UTC)

Der Befehl dazu steht darüber. Du musst nur über dem Text auf "ausklappen" drücken. -- Nethonos 11:12, 14. Feb. 2017 (UTC)
Die Befehle stehen überall dabei, allerdings befinden die längeren Befehle sich in einem Spoiler. Hinter "Befehl:" musst du nur auf [ausklappen] klicken und schon siehst du den Befehl. (Nethonos war schneller)   HorseHead MarkusRost (Diskussion) 11:15, 14. Feb. 2017 (UTC)
Danke, Leute. Und sorry das ich deswegen die Seite voll-gespamt habe. Aber könnte das irgendjemand irgendwie ganz oben dazu-schreiben, dass man auf ausklappen klicken muss?(so als unterüberschrift) --Herbert8 (Diskussion) 11:31, 14. Feb. 2017 (UTC)
Eine Frage noch: wo steht hier ausklappen und wo dieses Befehl? Finds nicht!!! --Herbert8 (Diskussion) 11:43, 14. Feb. 2017 (UTC)
Eventuell gibt es einen Ladefehler bei deinem Browser, dann einfach die Seite neu laden. -- Nethonos 11:44, 14. Feb. 2017 (UTC)

scheinbar nutzloses Schwert_name geht nicht[]

Ich hab den Befehl so ausgeführt wies da steht, mit markieren=> Rechtsklick => Chat öffnen => STRG+V (einfügen) und dann stand der Befehl so da wie er im Wikipedia steht.Dann enter und das schwert gekriegt. Es hat den wither ge-onehitet, der Angriffsschaden wurde nicht angezeigt, aber es hieß "Diamantschwert", nicht "Extraschaden". Bitte irgendwie verbessern! --Herbert8 (Diskussion) 07:12, 19. Feb. 2017 (UTC)

Wie du auf dem Bild siehst, heißt das Schwert nach wie vor "Diamantschwert". Der Name "Extraschaden" ist der Name des Attribut-Modifikators, der den Extraschaden verursacht. -- Sumpfhütte 08:56, 19. Feb. 2017 (UTC)
Das ist der Name des Attributs, dieser wird nirgends angezeigt und das soll auch so sein. Er ist nur ein interner Wert, dessen Nutzen von aussen nicht erkennbar ist. Dies steht aber auch im Beschreibungstext des Befehls.   HorseHead MarkusRost (Diskussion) 09:03, 19. Feb. 2017 (UTC)
Kann man so was mit {DisplayName:{"Extraschaden"}} ändern? Oder schreibt man das eben genannte Attribut anders? --Herbert8 (Diskussion) 10:40, 19. Feb. 2017 (UTC)

Creeperkiller: Keine Berechtigung[]

Problem: Das Beispielbuch „Creeperkiller“ liefert bei mir (gamemode 0) die Meldung, dass ich keine Berechtigung hätte, den Befehl auszuführen, obwohl der /execute Befehl das angeblich umgehen soll. Ist das neu oder ein neuer Bug oder woran kann das sonst noch liegen? --DscheJOuh (Diskussion) 15:10, 28. Jun. 2017 (UTC)

Ich vermute mal ganz stark, dass du dies auf einem Server mit einer Serversoftware wie z.B. Spigot getestet hast. Diese ändern die Rechteeinstellungen etwas, sodass auch mit dem Befehl /execute noch Operator-Rechte benötigt werden.   HorseHead MarkusRost (Diskussion) 15:17, 28. Jun. 2017 (UTC)

Strikte Syntax[]

Ist es wirklich notwendig, alle Eigenschaften und Werte in Anführungszeichen zu setzen? Die werden nur benötigt, wenn im Namen der Eigenschaft bzw. dem Wert ein nicht alphanumerisches Zeichen (alles außer a-zA-Z0-9_/ A-Za-z0-9._-+ glaube ich, habe die Liste grad nicht parat) vorkommt, und das wird sich wohl auch so schnell nicht ändern. Und die Befehle werden nur unnötig lang dadurch. | violine1101 (Diskussion) 08:53, 11. Jul. 2017 (UTC)

Dier Syntax wurde mit den letzten Versionen immer strenger und wurde JSON ähnlicher. Bei den letzten Updates wurde immer eine bisherige Möglichkeit Pflicht und eine strikte Möglichkeit kam hinzu, war aber noch nicht nötig. Mit dem nächsten Update wurde diese dann Pflicht und eine neue optionale Möglichkeit kam hinzu.
Bisher hatten wir die mindeste Syntax, damit war der Befehl zwar abwärts kompatibel, musste allerdings auch mit jedem Update aktualisiert werden. Durch der striktere Syntax soll der Update Aufwand geringer werden, für alte Versionen kann man den Befehl ja noch in der Versionsgeschichte finden.   HorseHead MarkusRost (Diskussion) 09:36, 11. Jul. 2017 (UTC)
"Dier Syntax wurde mit den letzten Versionen immer strenger und wurde JSON ähnlicher" – nur mit der letzten Version. In 1.12 wurde nur der alte Parser durch einen neuen ersetzt. Und ich bezweifle stark, dass das nochmal passiert, geschweige denn solche Ausmaße hat. Oder hast du irgendeinen Beleg dafür? | violine1101 (Diskussion) 09:55, 11. Jul. 2017 (UTC)
Tatsächlich, es war nur bei 1.12. Da hat mich mein Gefühl getäuscht, wohl auch weil nach einem Update die JSON-Text immer wieder Probleme machen. Die Anführungszeichen kann man sich dann tatsächlich nochmal überlegen, allerdings würde ich das true und false für bool-Wert behalten. Dies ist zum Verstehen der Befehle besser als nur 1 und 0. Den Namensraum minecraft: würde ich auch immer angeben, dieser erscheint ja auch bei der Autovervollständigung in Befehlen.   HorseHead MarkusRost (Diskussion) 10:16, 11. Jul. 2017 (UTC)
Mojang hatte schon immer versucht, wenn sie ein strikteres System einführen möchten, zuerst immer die alte Variante noch zu erlauben, bis sie nach und nach entfernt werden, Beispiel: /give @p 17 1 => /give @p log 1 (1.7), /tellraw @p {text:"Hallo Welt"} => /tellraw @p {"text":"Hallo Welt"}(1.9), /summon Blaze => /summon blaze(1.11). Das sind nur paar Beispiele, aber wenn man noch weiter nachforschte, fände man noch weitere solcher Fälle (konjunktiv wiederbeleb). -- Nethonos 10:49, 11. Jul. 2017 (UTC)
@Nethonos: Dass die numerischen IDs irgendwann nicht mehr ausreichen, war von Anfang an klar, und es war nur noch eine Frage der Zeit, bis die verschwinden. Und dass der Befehl /tellraw jetzt mit JSON-Texten funktioniert, ist eigentlich nur logisch, es gibt ja keine NBT-Daten, die da verändert werden müssten. Achso, und Blaze (großgeschrieben) funktioniert, soweit ich weiß, immer noch.
@MarkusRost: Meiner Meinung nach sollten überall, wo keine Anführungszeichen benötigt werden, keine stehen. Die Befehle sollten so einfach wie möglich sein, und die Variante mit Anführungszeichen ist für Einsteiger vielleicht schwerer zu tippen und evtl auch ein wenig abschreckend. Ansonsten befürwortete ich auch "false"/"true" und die Angabe des minecraft-Namensraums. | violine1101 (Diskussion) 17:23, 11. Jul. 2017 (UTC)
@Violine1101: Ich weis nicht ob schon zu Alpha-Zeiten klar war das die Nummern durch Worte ersetzt werden sollen (give-Einführung), aber sie habens auf jedenfall nicht hart umgeändert (zu 1.7) sondern erstmal beide Varianten erlaubt um dann die Nummern zu entfernen. Die JSON-Texte wurden genauso gehandhabt, das zuerst beide Varianten benutzt werden konnten, bevor die alte entfernt wird. Bei den Objekten ist es sogar noch einfacher (für den Spieler) gemacht worden, sodass eben auch die alte Eingabe funktioniert, solange der Name des Objektes sich nicht völlig geändert hat. Das die Befehle so einfach wie möglich sein sollen finde ich genauso, aber auch ich glaube wie Markus, das Mojang die Anführungszeichen nicht ohne Grund eingebaut haben, denn vor 1.12 konnte man das nicht eintippen. Deshalb wäre das nur eine Präventivmaßnahme. Man kann es natürlich auch erstmal weglassen, bis es dann strikt wird. -- Nethonos 17:35, 11. Jul. 2017 (UTC)
Ich weiß aus verlässlicher (aber nicht zitierbarer) Quelle, dass die Überarbeitung des NBT-Parsers ne ziemlich riesige Aktion war. Und außerdem würde das wohl so wirklich jeden Befehl inkompatibel machen, und hätte obendrein auch keinen Grund. Wofür die Anführungszeichen? Funktioniert doch auch so.
Der Grund für die Syntaxänderung ist ganz einfach. Wie hättest du vorher minecraft:cobblestone:true interpretiert? Und wie item:minecraft:cobblestone? Der alte Parser war einfach uneindeutig diesbezüglich, und das ist das einzige, was die Anführungszeichen ändern. (Nur A-Za-z0-9._-+ müssen übrigens nicht quotiert werden) | violine1101 (Diskussion) 17:52, 11. Jul. 2017 (UTC)
Bei dieser "strikteren" Methode handelt es sich ja in erster Linie um eine Funktionserweiterung, des bestehenden Funktionsumfangs. Bei einer Umstellung nur mit Anführungszeichen ginge es nur darum eine Funktionsminderung durchzuführen, daher glaube ich, das es kein großer Aufwand ist, das entsprechend umzustellen. Aber wir werden es wohl erst mit den nächsten Versionen sehen, ob sie das auch wirklich durchführen. Ich für meinen Teil sehe in diesen ganzen Aktionen aber einen roten Faden: Mojang will alles strikt machen, sodass keine Zweideutigkeiten mehr erlaubt sind, daher meine Annahme das sie das genauso auch hier vor haben. -- Nethonos 18:21, 11. Jul. 2017 (UTC)

Annahme, ja. Aber ich sehe das nicht kommen. Ich sage ja nicht, dass das nie so sein wird, ich bin nur der festen Überzeugung, dass es nie so weit kommt (es gibt faktisch gesehen einfach keinen Grund dafür, alles in Anführungszeichen zu setzen, außer die Community zu trollen). Was ich damit meinte, dass das ne riesige Aktion war, ist, dass es auch nicht geplant ist, die Anführungszeichen einzubauen – denn dann hätte man direkt den JSON-Parser nehmen können.
Wie auch immer, das Wiki sollte den Status quo beschreiben. Auch wenn es momentan möglich ist, die Anführungszeichen einzubauen, ist es nicht notwendig, und das suggerieren all diese Beispiele dem unerfahrenen Benutzer, der sie kopiert, ein wenig verändert und sich ärgert, dass sie nicht in die Chatzeile passen. | violine1101 (Diskussion) 18:32, 11. Jul. 2017 (UTC)

Mich überzeugen die Argumente von violine1101: Es wird erstmal nicht zu Anführungszeichen kommen (sonst hätte man es gleich zusammen mit der /tellraw-Änderung strikt gemacht), sie sind momentan nicht nötig, die Befehle im Wiki sollten einfach sein, das Kopieren und Ändern der Befehle soll einfach sein. - Ansonsten: ich bin für true/false im ganzen Wiki. Das minecraft-Präfix würde ich dagegen weglassen, weil ohne Präfix alle Befehle kürzer und übersichtlicher sind und es nicht nötig ist (wie die Anführungszeichen). -- Sumpfhütte 16:02, 14. Jul. 2017 (UTC)
"Einfach" ist sicherlich jedermanns Interesse, daher kann man das ja so handhaben, wie über mir geschrieben. Da will ich nur bloß hoffen das sich Mojang da nicht wieder was anderes zu überlegt. Ich hab mir mal die Schreibweise von JSON im Wikipedia-Artikel dazu angeschaut und dort wird das offenbar immer mit Anführungszeichen gemacht JavaScript Object Notation. Wenn ich Entwickler wäre, würde ich versuchen mir das Leben so einfach wie möglich zu machen und keine Abweichungen extra einprogrammieren, die ich auch noch warten muss. Daher würde ich mal sagen, warten wir ab, bis der Zug die (Anführungszeichen-)Klippe tatsächlich Richtung (Escaping-)Abgrund fährt und reagieren passiv darauf. -- Nethonos 14:48, 15. Jul. 2017 (UTC)
Re minecraft:-Präfix stimme ich jetzt doch Sumpfhütte zu, das Präfix ist eigentlich redundant (da es von Minecraft standardmäßig ergänzt wird) und verlängert nur den Befehl unnötig. (Außerdem sieht's in Zielauswahlen recht unschön aus, aber das ist ne andere Sache)
@Nethonos: Deswegen meine ich ja, wenn man überall Anführungszeichen wollte, hätte man direkt den JSON-Parser genommen, statt extra einen neuen zu bauen. Die NBT-Daten werden eben nicht in JSON angegeben, sondern in einer Javascript-ähnlichen Formatierung (nicht ganz, gibt noch einige Eigenheiten, die im Wiki leider nicht explizit erwähnt werden, wie bspw. Array-Typdefinitionen [I;123,456,789]), die hier im Wiki "NBT-JSON" genannt wird. Das kommt im Artikel über JSON leider immer noch nicht so richtig eindeutig rüber. (Siehe auch Diskussion:JSON#JSON ist nicht NBT, das gilt immer noch)
Diesbezüglich ein kleiner Off-Topic-Vorschlag am Rande: Was haltet ihr von "NBT-Notierung" statt "NBT-JSON"? | violine1101 (Diskussion) 15:22, 15. Jul. 2017 (UTC)
Ich habe jetzt mal den Artikel bis inklusive Illuminati-Rüstung überarbeitet (d.h. alle minecraft:-Präfixe entfernt, unnötige Anführungszeichen entfernt und die Texte ein bisschen besser formatiert mithilfe von <code>-Blöcken. Könnte vielleicht jemand nochmal über die Attribute bei der Illuminati-Rüstung schauen? Ich bin mir nicht sicher, ob das optimal gelöst ist und kenne mich mit Attributen nicht sonderlich gut aus. | violine1101 (Diskussion) 18:12, 22. Jul. 2017 (UTC)
minecraft: und unnötiges escaping sind jetzt überall weg.   HorseHead MarkusRost (Diskussion) 20:29, 22. Jul. 2017 (UTC)
Attribute der Illuminati-Rüstung getestet: Wenn die UUIDs unterschiedlich sind (was sie auch sein sollten, daher der Name), addieren sich die Attributwerte, wenn man mehrere Teile anlegt. Text ist angepasst. -- Sumpfhütte 13:08, 24. Aug. 2017 (UTC)

Der Namensraum minecraft: würde ich gern wieder überall verwenden können, da mit 1.13 der Namensraum immer vorgeschlagen wird und ein manuelles entfernen mehr Aufwand ist als es so zu lassen, was auch genauso funktioniert. Zu der Zeit wo entschieden wurde, den Namensraum zu entfernen, war der Namensraum auch noch nicht standardmäßig überall vorhanden, das hat sich ja gerade erst durch die weitere Entwicklung der 1.13 ergeben. Ich würde gern eure Meinung zum Thema erfahren. -- Nethonos 17:57, 7. Apr. 2018 (UTC)

Schon vorher hat das Spiel bei der Tab-Ergänzung den Namensraum mit angezeigt. Das ist jetzt genauso, nur dass man eine ganze Auswahlliste sieht. Man kann den Namensraum aber nach wie vor weglassen. Sämtliche Befehle funktionieren auch ohne minecraft-Namensraum. Der minecraft-Namensraum ist ganz offiziell nicht notwendig. Im Wiki würde ich "minecraft:" immer weglassen, weil das alle Beispiele deutlich kürzer und verständlicher macht: Man sieht schneller, worum es geht. -- Sumpfhütte 08:28, 8. Apr. 2018 (UTC)
Vorher, war das bei expliziten beschwören oder erzeugen, jetzt gibt es bei sämtlichen Auswahlkriterien (Beispiel: @e[type=Tab ↹) die Namensräume und Autovervollständigung, das war vorher nicht im Ansatz so ausgeprägt wie jetzt. Wenn man einen neuen Befehl schreibt dann hat man automatisch auch immer den Namensraum dabei (davon ausgehend das man nicht immer jeden einzelnen ID-Namen weis). Wenn jemand also neue Befehle hier ins Wiki einträgt wird das zukünftig mit sehr hoher Wahrscheinlichkeit mit Namensraum sein. Wenn man beispielsweise mit dem Selektor mehrere Typen abfragt, erhält man für jede einzelne Abfrage eine Autovervollständigung. Wenn man nun alle Namensräume entfernt, hat man mehr Arbeit (ist also nicht mehr „einfach“). Natürlich funktionieren die Befehle zum Glück, nach wie vor, auch ohne Namensraum, aber das muss man dann explizit nachtragen. Ich finde mMn das es eine Zumutung ist, die vielen Namensräume jedesmal zu entfernen und auch sonst wo zu überprüfen. Vielleicht muss man nicht klar gegen den Namensraum sein aber auch nicht dafür, vielleicht ließe sich ein Mittelweg ebnen. Es gibt sogar einen Fall bei dem der Namensraum richtig hilfreich ist und zwar wenn man nach minecraft: per Strg + F sucht, erhält man sämtliche IDs der jeweiligen Objekte, Kreaturen, Blöcke und Gegenstände und kann recht einfach diese ausmachen. Falls ein Update wieder sämtliche ID-Namen ändert, könnte sogar ein Bot diese Aufgabe nur aufgrund des Namensraums ändern (wurde im Technik Wiki schon erprobt). -- Nethonos 11:18, 9. Apr. 2018 (UTC)
Ich finde weiterhin, die Angabe des Namensraums macht die Befehlsbeispiele im Wiki für den Leser unübersichtlich. Das Eintragen neuer Befehle ins Wiki kann ein Argument sein, aber mit einem einfachen Suchen/Ersetzen ist der Namensraum rausgelöscht, egal wie umfangreich der Befehl ist. Um eine Entscheidung zum zukünftigen Aussehen der Befehle im Wiki zu treffen, würde ich gerne möglichst viele Meinungen der anderen hören. -- Sumpfhütte 15:49, 9. Apr. 2018 (UTC)
Der Namensraum macht den Befehl länger (eventuell zu lang für den Chat?) und unübersichtlicher, allerdings gibt es auch stellen, an denen der Namensraum unbedingt mit angegeben werden muss (bei Inventarabfragen, wenn ich mich recht entsinne). Da wäre es einheitlicher die Namensraum überall mit anzugeben. Einfach nur minecraft: aus dem Befehl (besonders bei komplexeren Befehlen, wie den komprimierten) funktioniert daher nicht immer. Auch müsste man, wenn man den Namensraum bei allen Befehlen angibt, überlegen, ob man auch den ID-Namen in den Steckbriefen mit Namensraum ausstattet. Der Namensraum wäre da dann aber ziemlich redundant, da wir hauptsächlich vanilla behandeln und kaum Artikel zu Modifikationen haben. Andererseits hat der Namensraum natürlich das großes Plus, dass er automatisch vervollständigt wird. Da könnten Anfänger eventuell verwirrt sein, warum da plötzlich ein Namensraum und im Wiki nicht. Fazit: Ich würde mich gerne vorerst enthalten. Auf jeden Fall bin ich aber dafür, die Entscheidung, der Einheitlichkeit wegen, auf alle Befehle im Wiki anzuwenden.   HorseHead MarkusRost (Diskussion)
Markus hat da noch was interessantes angesprochen: die Steckbriefe. Ich würde das so lassen, aber man könnte dort eventuell den Seitenlink auf Namensraum per Vorlage mit einbinden, aber sonst sollte das so bleiben, denn das würde wie schon angesprochen diese nur verlängern und man verwendet dort ja auch keinen Befehl dafür.-- Nethonos
Da stimme ich zu: Steckbriefe und sämtliche anderen Nennungen des ID-Namens (ID-Namen-Listen, Geschichtsabschnitte) werden den Namensraum auf gar keinen Fall bekommen, hier geht es nur um Befehlsbeispiele. Ich weiß nicht, wie irgendein Leser verwirrt sein könnte, wenn es /give @s stone heißt. Man kann den Befehl aus dem Wiki kopieren und er funktioniert, wie von den Entwicklern vorgesehen. Das Weglassen des Namensraumes ist ja volle Absicht der Entwickler, um Befehle kurz und übersichtlich halten zu können. Wenn du den Namensraum hinzufügst, musst du in NBT-Daten auch Anführungszeichen hinzufügen, sonst hast du verwirrenderweise zwei Doppelpunkte (id:minecraft:stone).
/summon minecraft:villager ~ ~1 ~
 { Profession:5,
   CustomName:"{\"text\":\"Mystiker\"}",
   Offers:
   { Recipes:
     [ { buy:  {id:"minecraft:enchanted_book", Count:1b},
         sell: {id:"minecraft:emerald", Count:1b}
       },
       { buy:  {id:"minecraft:soul_sand", Count:4b},
         buyB: {id:"minecraft:emerald", Count:11b},
         sell: {id:"minecraft:wither_skeleton_skull", Count:1b},
         maxUses:3,
         uses:0
       },
       { buy:  {id:"minecraft:iron_ingot", Count:10b},
         buyB: {id:"minecraft:emerald", Count:1b},
         sell: {id:"minecraft:gold_ingot", Count:9b},
         maxUses:7,
         uses:0
       },
       { buy:  {id:"minecraft:ender_eye", Count:1b},
         buyB: {id:"minecraft:emerald", Count:7b},
         sell: {id:"minecraft:end_crystal", Count:1b},
         maxUses:4,
         uses:0
       }
     ]
   }
 }
-- Sumpfhütte 05:40, 10. Apr. 2018 (UTC)
Bei der Namens-Eigenschaft habe ich noch die strikte Syntax angepasst, weil sonst der Befehl nicht funktioniert. -- Nethonos 16:02, 10. Apr. 2018 (UTC)

Zeilenumbruch auch in Funktionen[]

Wenn man die hier gelisteten Befehle in Funktionen nutzt, werden sie ohne weiteres nicht funktionieren, da Funktionen Zeilenumbrüche von Befehlen nicht tolerieren. Man kommt nicht drum herum, alle Zeilenumbrüche bei den Befehlsteilen zu entfernen. -- Nethonos 07:38, 4. Jul. 2018 (UTC)

Display attribute geändert?[]

Es scheint als würden {display:{Name:"Name"}} und {display:{Lore:["Linie 1","Linie 2","Linie 3"]}} nicht mehr funktionieren.
Hab das in 1.15.1 getestet und bekam (in meinem fall) nur den Spielerkopf mit der eigenen textur zurück. Der name war weiterhin "Spielerkopf" ohne irgendwelche Beschreibung darin.
Hat sich der Syntax eventuell geändert? --178.192.148.87 00:05, 4. Jan. 2020 (UTC)

Advertisement