Diskussion:Befehl

Archiv
2012 – 2015

Mal wieder Befehlshilfe gesucht...

Weltdownload, in Snapshot öffnen: [1]
Dieser Aufbau soll das klassische Game of Life von Conway darstellen, jede Schicht höher ist eine Stufe später.
Die beiden Befehle, die den scoreboard "alive" verändern, der darstellen soll, ob die Zelle in der Phase zuvor lebte, sind:

• execute @e[type=ArmorStand,name=Feld,score_alive_min=1,score_blocks_min=2,score_blocks=2] ~ ~ ~ setblock ~ ~ ~ stone

und

• execute @e[type=ArmorStand,name=Feld,score_blocks_min=3,score_blocks=3] ~ ~ ~ setblock ~ ~ ~ stone

Eigentlich sollten doch in der voreingestellten Anordnung (Standard-Gleiter diagonal) immer genau 5 Armorstands einen Score von 1 haben und alle anderen 0, da in dieser Formation immer genau 5 lebende Zellen existieren. Stattdessen aber gibt es erst 5, dann 7 ArmorStands mit Wert 1, wovon einer der beiden fehlerhaften auch einen Stein setzt, was das ganze Muster zerstört. Diese beiden haben auch tatsächlich keinen Stein unter sich, also habe ich keine Ahnung, warum das passiert. Hat jemand eine Idee?
P.S.: Für meherere Wiederholungen der Tests müssen folgende Befehle eingegeben werden:

• kill @e[type=ArmorStand,name=Feld]
• execute @e[name=Start] ~ ~ ~ summon ArmorStand ~ ~ ~ {NoGravity:1,Invisible:1,CustomName:Feld}

Mechanismus einmal aktivieren mit setblock 6 55 8 redstone_block 0 destroy
Das beides ist leider noch nötig, da es sich noch im Debug-Modus befindet. ArmorStand-Sichtbarkeit umschalten mit F3+N. Fabian42 22:57, 14. Jan. 2016 (UTC)

Weiß irgendwer Rat? Fabian42 11:40, 20. Jan. 2016 (UTC)

Mittlerweile weiß ich übrigens, dass es an einem Bug lag, der die Zielauswahl durcheinandergebracht hat. Fabian42 15:58, 4. Sep. 2016 (UTC)

Tote Spieler erkennen

Geht das? Könnte ich gebrauchen, um Teams auszugleichen. Ich habe dazu noch kein Video auf Youtube gefunden, ich könnte ggfs. eins machen.

Meine Idee wäre, dass ich einen Spieler suche, welcher nicht @r[team=x] {DeathTime:0} erfüllt. Danke im Voraus, Gruß 2ndpopcornxD (Diskussion) 20:33, 18. Jan. 2016 (UTC)

Ich hab mal ein Video gefunden, das dazu ArmorStands nutzten, die in jedem Tick zum Spieler teleportiert wurden. Bräuchtest du aber wohl ein ID-System dafür. Wenn der Spieler nicht mehr gefunden wird (was allerdings auch passieren kann, wenn er den Server verlässt), wird er als tot angesehen. Ich finde das Video zwar gerade nicht mehr wieder, aber über die YouTube-Suche habe ich das hier gefunden. Fabian42 06:40, 19. Jan. 2016 (UTC)

Server-Befehle

Im Artikel stand nur, es gebe manche Server-Befehle nicht im Einzelspieler-Modus. Welche sind das denn? -- Yaouoay (Diskussion) 16:53, 1. Feb. 2016 (UTC)

Befehl /ban, Befehl /ban-ip, Befehl /banlist, Befehl /pardon, Befehl /pardon-ip, Befehl /save-all, Befehl /save-off, Befehl /save-on, Befehl /stop und Befehl /whitelist. | violine1101 ^(Diskussion) 19:54, 1. Feb. 2016 (UTC)

Danke -- Yaouoay (Diskussion) 13:48, 2. Feb. 2016 (UTC)

Zielauswahl mit NBT mit Etiketten erwähnen

Ich denke, der Lösungsweg zur Auswahl eines NBT-Ziels mit Etiketten sollte (neben jenem mit objectives) auch erwähnt werden, da /scoreboard players tag @p add Spieler {playerGameType:2} genauso funktioniert und vermutlich eher dazu vorgesehen ist als /scoreboard players set @p Spieler 1 {playerGameType:2}. Gruß, 2ndpopcornxD (Diskussion) 02:11, 7. Mär. 2016 (UTC)

Stimmt. Artikel ist geändert. -- Sumpfhütte 11:35, 7. Mär. 2016 (UTC)

@2ndpopcornxD: Bei einem Gegenstand ist ein Etikett ratsam, bei mehreren gleichen gestapelten Gegenständen ist wieder der Punktestand besser, da man nur einem Gegenstand ein Etikett geben kann. Nethonos (Diskussion) 11:40, 7. Mär. 2016 (UTC)

Etiketten kann man meines Wissens nur an Objekte vergeben, also genaugenommen nicht an Gegenstände, sondern an Gegenstand-Drops. Und über die Zielauswahl kann man durchaus mehreren Drops gleichzeitig ein Etikett geben. -- Sumpfhütte 11:53, 7. Mär. 2016 (UTC)

Stimmt ich meinte die Drops welche die "Gegenstände" enthalten, hab das aber leider nicht deutlich gemacht. Ich meinte damit, dass man zwar einem Drop, der genau einen Gegenstand beinhaltet (zum Beispiel eine Fackel) ein Etikett bekommen kann, wenn abgefragt wird, ob es sich um einen Gegenstand in dem Drop handelt. Sobald man aber die Anzahl der Gegenstände in dem Drop abfragen will, in dem man nur bei einer bestimmten Anzahl dem Drop ein Etikett geben will, wird es einem nicht gelingen, das geht nur per Punktestand. Nethonos (Diskussion) 12:00, 7. Mär. 2016 (UTC)

Mach doch mal ein einfaches Beispiel, das würde ich gerne in den Artikel aufnehmen. -- Sumpfhütte 12:02, 7. Mär. 2016 (UTC)

Komisch, ich hab mich wohl geirrt, es klappt doch:

Punktestand: Befehl /scoreboard players set @e[type=Item] Fackel 1 {Item:{id:"minecraft:torch",Count:2b} }
Etikett: Befehl /scoreboard players tag @e[type=Item] add Fackel {Item:{id:"minecraft:torch",Count:2b} }

Also ist das Etikett in vielerlei Hinsicht besser als der Punktestand, da man dafür nicht extra eine Punktestand-Objekt benötigt, welches zuvor erstellt werden muss. Nethonos (Diskussion) 13:00, 7. Mär. 2016 (UTC)

Befehle auf PS4

Ich spiele momentan sehr aktiv Minecraft auf der PS4, Kenn mich auch gut aus. Es gibt jedoch eine einzige Sache die ich noch nicht herausfinden konnte, und zwar: Wo kann man auf der PS4 Befehle eingeben?--Fraankiboy (Diskussion) 10:04, 15. Apr. 2017 (UTC)

Auch wenn ich ein wenig spät dran bin damit, aber hier im Wiki wirst du verhältnismäßig wenige Spieler finden, die die Konsoleneditionen selbst spielen. Die meisten spielen nur die Java-Edition. Ich persönlich habe noch nie von Befehlen in der Konsolenedition gehört und in der Konsolen-Versionsgeschichte steht auch nichts davon. Ich gehe mal davon aus, dass es die in der PS4-Edition einfach nicht gibt. Oder noch nicht. | violine1101 ^(Diskussion) 20:11, 3. Mai 2017 (UTC)

NBT-Daten und Zielauswahl/Selektoren auslagern?

Die NBT-Daten und die Selektoren nehmen auf dieser Seite sehr viel Platz ein, da wären vielleicht eigene Seiten denkbar. Denn mit 1.13 wird es ja noch mehr und die NBT-Daten werden dann auch noch ein Teil der Selektoren ausmachen. Was meint ihr? -- Nethonos 08:47, 9. Nov. 2017 (UTC)

Eine Aufteilung in unterschiedliche Artikel finde ich hier nicht nötig. Es ist besser, alle Informationen über Befehle auf einer Seite zusammenzuhalten. Wir haben auch andere lange Artikel, das alleine sollte kein Grund sein. -- Sumpfhütte 10:27, 9. Nov. 2017 (UTC)

Ja das stimmt auch wiederum. -- Nethonos 10:34, 9. Nov. 2017 (UTC)

Befehls-UI

Mit den 1.13-Snapshots ließt man immer wieder „Befehls-UI”. Kann man das auf den Befehle-Parser zurückführen oder sollte diese Befehls-UI in einem Abschnitt in dieser Seite oder in einem eigenen Artikel näher erläutert werden? -- Nethonos 11:39, 2. Feb. 2018 (UTC)

Der Parser ist zwar im Kern nur eine Eingabeprüfung, aber die Eingabehilfe, die er anzeigt (engl. "command UI"), ist eng damit verbunden, sollte also im selben Artikel beschrieben werden. Dazu würde gehören:

• Die neue Option "Befehlsvorschläge".
• Die Beschreibung der Auswahllisten (anklickbar, Pfeiltasten nutzbar, Auswahl ist gelb, Auswahl treffen mit Tab).
• Die Beschreibung der Farben (hellblau, gelb, grün, lila usw. für verschiedene Parameter, rot für Fehler).
• Korrekturmöglichkeit und Befehlswiederholung (ggf. Esc-Taste drücken).
• weitere Besonderheiten?

-- Sumpfhütte 12:48, 2. Feb. 2018 (UTC)

Die Erklärung und Auflistung ist astrein, weitere Dinge sind mir auch nicht weiter in den Sinn gekommen. Dann weis ich was ich demnächst angehen kann. -- Nethonos 12:54, 2. Feb. 2018 (UTC)

Ich aktualisiere gerade den Befehl-Artikel. Es zeigt sich, dass die Eingabehilfe besser hier passt. Im Parser-Artikel wird dagegen gezeigt, wie der Parser bei Fehleingaben reagiert. Ich hoffe, das wird alles noch von Crowdin übersetzt, aber Mojang hat noch keine entsprechenden Beschriftungsvariablen im aktuellen Snapshot. -- Sumpfhütte 18:51, 11. Feb. 2018 (UTC)

Bei mir hätte es noch ne Weile gedauert, bis ich wieder die Möglichkeit hätte Ingame-Bilder zu schießen, aber nebenbei bemerkt, deine Abschnittsbearbeitungen sehen fantastisch aus, gerade die Bilder laden einen sofort ein diese Abschnitte sich näher zu führen :-) -- Nethonos 11:12, 12. Feb. 2018 (UTC)

Blockzustände und NBT-Daten anzeigen

Auf allen Befehlsunterseiten werden die Blockzustände und die NBT-Daten nicht in dem Syntax-Abschnitt angegeben da diese mit der 1.13 dann unter „<Gegenstand>“ und „<Block>“ möglich sind. Allerdings kann man als Neuling nicht sehen das nun unter diesen möglich ist, die beiden Daten angeben zu können, daher würde ich vorschlagen diese als optionale Syntax-Parameter anzugeben. Unter Befehl/clear hab ich es als Beispiel angewendet. Was haltet ihr davon? -- Nethonos 08:40, 4. Apr. 2018 (UTC)

Die NBT-Daten als Option anzugeben finde ich prima, aber die Verschachtelung bei den <>-Zeichen ist unüblich und wird sicher nicht verstanden. Wie wäre das: /clear [<Spieler>] [<Gegenstand>][<NBT-Daten>] [<MaxMenge>]? Im Text dazu wird dann ja erklärt, was das bedeutet. Insbesondere steht dort "Gegenstand funktioniert nur zusammen mit Spieler" als Ergänzung zu der vereinfachten Klammerung. -- Sumpfhütte 14:07, 4. Apr. 2018 (UTC)

Klingt gut, das würde ich dann bei Blockzuständen genauso handhaben: /setblock <x y z> <Block>[<Blockzustand>][<NBT-Daten>] [<Platzierung>]. -- Nethonos 14:16, 4. Apr. 2018 (UTC)

Ja, klingt ebenfalls gut :-) -- Sumpfhütte 14:23, 4. Apr. 2018 (UTC)

Es gibt noch ein Problem: Blockzustände müssen in eckigen Klammern angegeben werden, was die bisherige Metasyntax (eckige Klammern = optional) unverständlich macht. Schau dir mal das an:

• /setblock <x y z> <Block>[<Blockzustand>][<NBT-Daten>] [<Platzierung>]

Hier ist kaum zu verstehen, dass der Blockzustand bei der Eingabe in eckigen Klammern stehen muss, die NBT-Daten aber nicht.

Daher hat Mojang die eckigen Klammern der Metasyntax komplett weggelassen und listet dafür alle Optionen einzeln auf. Wir sollten die eckigen Klammen ebenfalls weglassen und stattdessen den Text formatieren. Beispiele bisher (mit vielen verwirrenden Klammern):

• /setblock <x y z> <Block>[<Blockzustand>][<NBT-Daten>] [<Platzierung>]
• /clear [<Spieler>] [<Gegenstand>][<NBT-Daten>] [<MaxMenge>]

Notwendiges fett, Optionales nicht:

• /setblock <Position> <Block>[<Blockzustand>]{<NBT-Daten>} <Platzierung>
• /clear <Spieler> <Gegenstand>{<NBT-Daten>} <MaxMenge>

Vielleicht sogar die spitzen Klammern auch weglassen und dafür Variablen kursiv, Konstanten nicht:

• /setblock Position Block[Blockzustand]{NBT-Daten} Platzierung
• /clear Spieler Gegenstand{NBT-Daten} MaxMenge

Oder andersherum: fett=Konstante, kursiv=optional (das gefällt mir am besten):

• /setblock Position Block[Blockzustand]{NBT-Daten} Platzierung
• /clear Spieler Gegenstand{NBT-Daten} MaxMenge
• /time set Zeit
• /time add Zeit
• /time query Messung

-- Sumpfhütte 08:39, 6. Apr. 2018 (UTC)

Ok, prima du hast direkt für das Problem mehrere Lösungen parat. Die von dir favorisierte Lösung gefällt mir auch am besten. -- Nethonos 10:13, 6. Apr. 2018 (UTC)

Ich hab jetzt testweise bei den vier Inventar-Befehlen die neue Syntax eingebaut und sie ist wirklich besser und verständlicher. Mir ist noch eingefallen, das man die Selektoren vielleicht noch allgemein halten könnte, denn dort steht zur Zeit entweder nur <Spieler>, <Spieler oder Objekt> oder <Zielauswahl>. So ähnlich sieht es mit den Gegenständen aus, die man aus dem Inventar entfernen oder dazulegen kann, dort wird nur <Gegenstand> angegeben, dort fehlt aber „Block“. Wenn man die neue Syntax für alle Befehle einheitlich gestalten will, wäre es vielleicht besser hier neue Wege anzusetzen.

Statt so:

• /give Spieler Gegenstand{NBT-Daten} Anzahl
• /clear Spieler oder Objekt Gegenstand{NBT-Daten} MaxMenge
• /kill Spieler oder Objekt

besser so?

• /give Selektor Gegenstand{NBT-Daten} Anzahl
• /clear Selektor Gegenstand{NBT-Daten} MaxMenge
• /kill Selektor

oder so (analog zu /time)?

• /give Name|@e|@a|@p|@r|@s Gegenstand|Block{NBT-Daten} Anzahl
• /clear Name|@e|@a|@p|@r|@s Gegenstand|Block{NBT-Daten} MaxMenge
• /kill Name|@e|@a|@p|@r|@s
• /time set|add|query Zeit

Was meint ihr? -- Nethonos 10:52, 6. Apr. 2018 (UTC)

Ich wäre ebenfalls für den letzten Vorschlag von Sumpfhütte und was Selektor/Zielauswahl angeht bin ich für die Lösung mit Selektor, die anderen sind zu unübersichtlich.
@Nethonos: Du hast die Syntax von Sumpfhütte glaube ich etwas falsch verstanden. Fett sind nur feste Konstanten, kursiv ist alles Optionales und Bezeichnungen, die noch genauer erklärt werden müssen sind normal (außer sie sind optional)
Beispiel: /setblock x y z Block[Blockzustand]{NBT-Daten} keep
  MarkusRost (Diskussion) 11:05, 6. Apr. 2018 (UTC)

Im Vorschlag von Sumpfhütte steht das Konstanten fett und optionale Parameter kursiv sind. Weil im letzten Beispiel der zweite Befehl nur optionale Parameter nach dem Befehl besitzt, ging ich davon aus, dass der erste Befehl einen Fehler enthielt. Denn im Text wie auch in allen anderen Beispielen steht nichts von formatlosen Angaben. -- Nethonos 11:10, 6. Apr. 2018 (UTC)

Ja, es steht nicht direkt im Text. Aber an den /time Befehlen kann man es gut erkennen. Ohne die Klammern fällt es sonst ja schwer zu erkennen, welchen Begriff man direkt übernehmen muss und welchen man erst noch anpassen muss. Fett = muss übernommen werden; Nicht fett = Platzhalter, muss entsprechend ersetzt werden; Kursiv = optional; Kursiv und fett = optional, muss aber so übernommen werden, falls man es angeben will.   MarkusRost (Diskussion) 11:19, 6. Apr. 2018 (UTC)

Auch im Text darüber steht man sollte die Texte formatieren. Aber @MarkusRost: deine Korrekturen sind auch gut. So kann man das übernehmen. -- Nethonos 11:39, 6. Apr. 2018 (UTC)

Ja, so wie MarkusRost es beschrieben hat, war es gemeint: fett=Konstante, nicht fett=Variable, kursiv=optional, nicht kursiv=zwingend. Alle vier Kombinationen von fett und kursiv sind möglich. - Zu beachten wäre allerdings noch, dass Mojang noch vorhat, die help-Texte auf Crowdin übersetzen zu lassen. Beispiel für Befehl /help clear: "<targets> <item> <maxCount>". Das passt schon prima zu unserem "Selektor Gegenstand{NBT-Daten} MaxMenge". Aber statt "x y z" schreibt Mojang "<pos>", was sicherlich zu "Position" oder "Koordinaten" übersetzt wird. Da es für die Leser nachvollziehbarer ist, wenn Wiki und Spiel (größtenteils) übereinstimmen, würde ich dies mit beachten, wo sowieso alles angefasst wird (außerdem sind fette Einzelbuchstaben im Code-Format schwer zu erkennen, daher ist "Position" besser als "x y z"). - Dann noch zu den senkrechten Strichen: Die würde ich weglassen und die Befehle getrennt auflisten. Das machen wir jetzt auch schon in Tabellenform, es würde dann nur die übergeordnete Syntax wegfallen (z.B. bei /time). -- Sumpfhütte 13:01, 6. Apr. 2018 (UTC)

Ok, gut. „Position“ statt „x y z“ find ich auch besser und wenn Mojang das auch noch so vorhat, dann ist es somit auch die schönste Lösung. Die senkrechten Striche hab ich bisher auch weitestgehend immer durch eine Tabelle ersetzt, wie bei /execute oder anderen Befehlen. Solche Befehle wie den /time-Befehl werde ich anpassen, so dass sie alle später einheitlich sind. -- Nethonos 13:26, 6. Apr. 2018 (UTC)

Ich habe mir nochmal ein paar Gedanken bezüglich der neuen Syntax gemacht. Ich finde sie zwar sehr angenehm, allerdings ist sie nur schwer für einen Leser zu verstehen. Sie weicht stark von den Ingame-Vorschlägen ab (keine Klammern) und ist nur zu verstehen, wenn man vorher den entsprechenden Abschnitt auf Befehl gelesen hat (was man eher selten tut, wenn man einen bestimmten Befehl sucht). Was bedeutet kursiv? Eckige Klammern sind für Optional hingegen weit verbreitet. Außerdem ist es schwer zu erkennen, wo eine Variable endet und die nächste beginnt. Dies war mit den Klammern eindeutiger und man konnte Variablen auch aussagekräftigere Namen geben (bsp: <Zeit in Sekunden> wird zu Zeit (welche Einheit?)). Unser größter Punkt zum Entfernen der Klammern war, dass die Blockzustände eckige Klammern verwenden und wir Block[Blockzustand]{NBT-Daten} schreiben wollten, da es für einen Anfänger mit einfach nur <Block> schwer verständlich ist, dass hier auch Blockzustand und NBT-Daten dabei sind.
Mein Vorschlag wäre nun die Klammern wieder einzuführen und in der Syntax auch nur <Block> zu schreiben. Darunter werden ja alle Variablen nochmal genauer erklärt und dort würde ich dann, wie aktuell mit der Zielauswahl, auf einen Abschnitt auf Befehl verlinken, der die Block/Gegenstands-Argumente genauer erklärt. (Wie z.B. hier von Dinnerbone gemacht)   MarkusRost (Diskussion) 06:52, 12. Apr. 2018 (UTC)

Ich finde den Vorschlag nicht schlecht, aber bevor man nochmals alles umändert, würde ich vorschlagen erstmal alle Angaben die mehrere optionale Möglichkeiten besitzen sammeln, damit nicht später noch sowas auftaucht und wir wieder alles anpassen müssen. Sollten wir vielleicht sogar bis zum Release der 1.13 damit warten, damit wir sicher gehen können das sich nichts mehr groß ändert? -- Nethonos 07:03, 12. Apr. 2018 (UTC)

• Selektor => Zielauswahl und Variablenname
• Block => Block[Blockzustand]{NBT-Daten}
• Gegenstand => Gegenstand{NBT-Daten}
• Partikel => Partikel Blockpartikel

Ich würde nicht zurück zur alten Syntax zurückkehren, da sie mit den spitzen Klammern in Kombination mit den eckigen Klammern sehr einzigartig und sonderbar ist (engl. Wiki nutzt nicht diese Syntax). Aus der Informatik kenne ich eine simplere und bessere Syntax, und zwar nennt sie sich diese allgemeine Syntax EBNF, sie ist mit ihren eckigen und geschwungen Klammern einfach und verständlich gehalten und würde man sie nutzen, hätten man es auf jeden Fall leichter. -- Nethonos 08:44, 12. Apr. 2018 (UTC)

Ich würde die spitzen Klammern für Variablen durchaus vorziehen, damit man sie einfach und deutlich von Konstanten unterscheiden kann. Die spitzen Klammern entsprechen auch der Ingame-Vorschau der Befehle   MarkusRost (Diskussion) 09:08, 12. Apr. 2018 (UTC)

Für den Einsatz von spitzen Klammern spricht, dass Mojang sie auch verwendet. Allerdings ist es egal, ob Fettschrift oder spitze Klammern, beides muss man erklären. Die Backus-Naur-Form hilft da nicht weiter, eine vereinfachte Form hatte wir vorher. Und sobald wir die eckigen Klammern der BNF als Metasyntax verwenden würden, gäbe es Verständnisprobleme an den Stellen, an denen sie real eingesetzt werden. Schauen wir mal, was Mojang gemacht hat: Vorher im Spiel:

/help give
  /give <Spieler> <Gegenstand> [<Anzahl>] [<Metadaten>] [<NBT-Daten>]
/help setblock
  /setblock <x> <y> <z> <Block> [<Metadaten>|<Zustand>] [replace|keep|destroy] [<NBT-Daten>]

Jetzt im Spiel:

/help give
  <targets> <item>
  <targets> <item> <count>
/help setblock
  <pos> <block>
  <pos> <block> destroy
  <pos> <block> keep
  <pos> <block> replace

Wie man sieht, wird jetzt völlig auf eckige Klammern und senkrechte Striche verzichtet. Abkehr von Metasyntax und BNF, weil unverständlich. Blockzustände und NBT-Daten stehen gar nicht in der Syntax, dafür gibt es jetzt die Eingabehilfe. Aber das passt eigentlich gut zum Vorschlag von MarkusRost, die Blockzustände und NBT-Daten auch im Wiki nicht in der Syntax, sondern in der Erklärung aufzuführen. Um im Text aber Wiederholungen zu vermeiden, führt kein Weg daran vorbei, die Details an zentraler Stelle zu erklären. Fazit: Egal wie wir es machen, wir werden bei der Metasyntax und bei den Eingabedetails (Syntax der Blockzustände, NBT-Daten, Selektoren und Koordinaten) auf zentrale Stellen verlinken.

Am verständlichsten für den Leser wäre wohl eine möglichst genaue Anlehnung an das Spiel. Im Wiki könnte das so aussehen (falls die Parameter noch übersetzt werden, dann natürlich in Deutsch):
Alternativen:

/give <targets> <item>
/give <targets> <item> <count>

Parameter:

• <targets>: Spielername oder Selektor, ggf. ohne Leerzeichen gefolgt von Zielfiltern.
• <item>: ID-Name des Gegenstandes, ggf. ohne Leerzeichen gefolgt von NBT-Daten.
• <count>: Maximale Anzahl.

Alternativen:

/setblock <pos> <block>
/setblock <pos> <block> destroy
/setblock <pos> <block> keep
/setblock <pos> <block> replace

Parameter:

• <pos>: Koordinaten
• <block>: ID-Name des Blockes, ggf. ohne Leerzeichen gefolgt von Blockzustand und NBT-Daten.
• destroy: ...
• keep: ...
• replace: ...

-- Sumpfhütte 09:51, 12. Apr. 2018 (UTC)

Der Vorschlag von Sumpfhütte gefällt mir, allerdings werden wir wohl nicht ganz ohne die ein oder andere eigene Variable auskommen. Denn bei einigen Befehlen wie z.B. /playsound wären das deutlich zu viele Alternativen. Angenommen die Parameter werden übersetzt, könnte man einfach <Geräuschart> als eigene Variable hinzufügen mit Erklärung und schon hätten wir aus den 50 Alternativen nur noch 5 Alternativen gemacht. Damit wären dann immer noch keine Parameter in eckigen Klammern (optional), da dies durch die Alternativen gelöst ist.   MarkusRost (Diskussion) 10:54, 12. Apr. 2018 (UTC)

Fände ich gut (und wurde teilweise auch schon so von uns gemacht). /gamerule wäre auch so ein Fall, wir würden <Spielregel> als eigene Variable hinzufügen. -- Sumpfhütte 11:27, 12. Apr. 2018 (UTC)

Verstehe ich das jetzt richtig? Ihr wollt jede noch so erdenkliche Kombination aus Parametern aufführen? Hoffentlich nicht. Mit der Tabellenauflistung erspart man sich so einige Dopplungen. -- Nethonos 13:24, 12. Apr. 2018 (UTC)

Über Discord habe ich mit Markus nochmals über dieses Vorhaben ausgetauscht und zusammen sind wir nun zu dem Entschluss gekommen, das eine etwas abgespeckte Syntax-Liste und ein paar kleineren Tabellen die beste Lösung ist, da damit textuelle Redundanzen vollständig vermieden werden können, so werden beispielsweise niemals zweimal eine Option in der Beschreibung auftauschen und dennoch bleibt die Syntax-Liste klein. -- Nethonos 15:21, 12. Apr. 2018 (UTC)

Zu '/datapack' könnte die Syntax so aussehen:

/datapack disable <Datenpaket>
/datapack enable <Datenpaket>
/datapack enable <Datenpaket> <Sortierung>
/datapack list
/datapack list <Option>

=> Tabelle zu Sortierung und Option

---

Im aktuellen Snapshot sieht die Befehlsliste anders aus. Sie listet vor allem nicht mehr alle Optionen Gleichzeitig und es gint Literalgruppern (z.B. (a1|a2)) und Optionales (z.B. [<opt>])
`execute` sieht bei `/help` ohne parameterangabe zunächsteinmal nur so aus: /execute (align|anchored|as|at|facing|if|in|positioned|rotated|run|store|unless). Weitere Informationen werden nicht geben.
Gibt man allerdings /help execute ein, kommt folgendes dabei heraus:

/execute align <axes> -> execute
/execute anchored <anchor> -> execute
/execute as <targets> -> execute
/execute at <targets> -> execute
/execute as <facing> (entity|<pos>)
/execute if <facing> (block|blocks|entity|score)
/execute in (overworld|the_end|the_nether)
/execute positioned (as|<pos>)
/execute rotated (as|<rot>)
/execute run ...
/execute store (result|success)
/execute unless <facing> (block|blocks|entity|score)

Das kann man dann natürlich noch weiter vertiefen. /help execute if gibt folgendes zurück:

/execute if block <pos> <block> -> execute
/execute if blocks <start> <end> <destination> (all|masked)
/execute if entity <entities> -> execute
/execute if score <target> <targetObjective> (<|<=|=|>|>=|matches)

Man könnte das eventuell so oder so ähnlich in Tabellenform angeben.
Ich fände es prinzipiell auch nicht schlecht, den Parameter-Typen ähnlich zu Bedrock zu haben. Man könnte sich da evtl. ne nette Vorlage basteln und dann sogar zu dem Parser-Typen verlinken. Dann hätte man z.B. die Erklärung zum Block-Parameter woanders. Man kann in der Tabelle ja trotzdem noch eine kurze Erklärung hinzufügen (evtl. hier sogar eine Unterseite einbinden, damit jeder Befehl mit Block-Typen dieselbe Erklärung verwendet?) --NeunEinser (Diskussion) 15:14, 9. Mai 2018 (UTC)

Im Wiki würde ich die Befehle dann aber überall bis etwa die letzte Ebene auflisten, ansonsten wäre das zu unübersichtlich. Diese wäre dann ziemlich genau der letzte Vorschlag von Nethonos (so listet es auch der Wiki-Bot im Discord). Damit hätte man eine gute Übersicht über alle möglichen Varianten des Befehles und kann ihn sich gut rauskopieren (mit den Variablen). Die Variablen werden darunter in einer Tabelle erklärt. Somit hat man die Erklärungen direkt gut zusammen und einheitlich und auch der Befehl ist nicht mit verschiedenen Teilen auf verschiedene Stellen im Artikel verstreut (aktuell ist das z. B. bei execute sehr schlimm).   MarkusRost (Diskussion) 15:51, 9. Mai 2018 (UTC)

Ich fände eine Zusammenfassung in gewissem Maße trotzdem sinnvoll. z.B. execute (if|unless) block <Position> <Block> -> execute oder /setblock <Position> <Block> [replace|destroy|keep] --NeunEinser (Diskussion) 16:45, 9. Mai 2018 (UTC)

Problem mit Selektor @s

In einer Diskussion zu den Befehlen mit Selektoren wie @p wurde dazu geraten diesen Selektor durch den Selektor @s wenn möglich zu ersetzen (ich weis nicht mehr wo). Der Unterschied ist klar, während @p den nächsten Spieler auswählt, wird @s den eigenen Ausführer auswählen und da haben wir schon das Problem, denn ein Befehlsblock oder eine Funktion kennt kein Selbstobjekt das ausgewählt werden könnte. Damit jedoch die Befehle im Wiki allgemein immer funktionieren müsste man @p statt @s wählen. Das wollte ich mal angesprochen haben. -- Nethonos 13:58, 11. Apr. 2018 (UTC)

Stimmt, das ist ein guter Hinweis. Da bei Befehlsblöcken nur @p funktioniert und bei Ausführung durch den Spieler denselben Effekt wie @s hat, ist @p die bessere Wahl fürs Wiki. -- Sumpfhütte 14:58, 11. Apr. 2018 (UTC)