# Commands

To create a command, define it with the word "command", and then it's name:

{% code overflow="wrap" lineNumbers="true" %}

```java
command myCommand:
```

{% endcode %}

{% hint style="info" %}
Command names may also be prefixed with a `/`, but this is optional.
{% endhint %}

Indented underneath this line is where all of a commands properties will go.

{% hint style="info" %}
**"What are command properties?"**

Unlike functions and events, which can only trigger code, commands have more features. Commands have built-in cooldowns, permissions, and a few other things this category will cover.
{% endhint %}

***

## Properties

Commands have numerous properties that allow for a ridiculous amount of customisation. Properties are defined just within the command structure.

Sometimes people will forget these properties are built-into commands by default, which leads to their commands being really messy and using useless if statements.

{% hint style="info" %}
To learn more about a specific command property, see the [Permissions page](/syntask/fundamentals/structures/commands/permissions.md), the [Usage page](/syntask/fundamentals/structures/commands/usage.md), the [Cooldowns page](/syntask/fundamentals/structures/commands/cooldowns.md), and the [Aliases page](/syntask/fundamentals/structures/commands/aliases.md).

There is one propery not listed here; `executable by:`. This lets you specify if the command can be executed by `players and console` (default), or just `players` or just the `console`.
{% endhint %}

***

## Trigger

The trigger is where all of your code will go under a command.

{% hint style="info" %}
You can use the `player` expression in commands, however it is more accurate to use `executor` as commands may also be executed through the console. Using the `executor` expression also prevents confusion between the executing player and any player arguments.
{% endhint %}

The trigger is just another command property, with one special rule: it must be the last property:

{% code overflow="wrap" lineNumbers="true" %}

```python
command ban:
  permission: admin
  permission message: You can't use this command!
  trigger:
    #: Notice how the trigger is at the very bottom, under the permission
```

{% endcode %}

Then all the code for a command goes within the trigger, remember to indent once for the command, and once for the trigger.

{% code overflow="wrap" lineNumbers="true" %}

```python
command spawn:
  trigger:
    teleport executor to {spawn}
```

{% endcode %}

{% hint style="warning" %}
Sometimes people don't add a trigger to their command because events and functions don't have a trigger, or people add triggers to events and functions because a command has one. A command is special in that regard, it's the only one that needs a trigger field.

This is because, as mentioned above, commands have numerous properties in addition to the code they run, whereas events and functions do not. This mean a command's code must be placed in a special section to distinguish it from other properties available in a command.
{% endhint %}

***

## Arguments

Arguments are things a player will input into the chat bar when using a command.

### Argument-%number%

This is the most standard way of using and referring to arguments. It's taught in pretty much every command tutorial and is hands-down the most common.

Simply specify the type of argument within angle brackets `<>`, and that's it.

Then, in the trigger section, you can refer to the arguments in the order they are listed in the command line with `arg[ument](-| )%number%`.

{% code overflow="wrap" lineNumbers="true" %}

```python
command giveMeItems <item type> <integer>:
#:                  <  arg-1  > < arg-2 >
trigger:
  give executor arg-2 of arg-1
```

{% endcode %}

{% hint style="info" %}
Since the item type is listed first, it is `arg-1` and `arg-2` is the integer, which is listed second in the command line.
{% endhint %}

### Named arguments

Using the above method can sometimes be confusing or unintuitive if you have multiple arguments. That's why the best route is to give your arguments names, so you don't forget which argument corresponds to each value.

Simply input a name and a colon, followed by the type. Then, you access the argument through a local variable of the same name:

{% code overflow="wrap" lineNumbers="true" %}

```python
command assassinate <target:player>:
  trigger:
    kill {_target}
    send "You assassinated %{_target}'s name%!" to executor
```

{% endcode %}

{% hint style="info" %}
Sometimes people will try to simplify their code with local variables; `set {_localVariable} to arg-1`, but this can be done right in the command line!
{% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://x8ight.gitbook.io/syntask/fundamentals/structures/commands.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.