Getting Started Old

Getting Started

Triggers and Executors

First of all, there are big two parts in this plugin: triggers and executors.

Just like the name itself suggest, triggers are the medium that will run the exectors, and executors are the medium that will actually work on the Bukkit world. Does it make sense?

For example, if a player enter /test command, the server will receive it and will create an event. What is an event? just think it as it is. When something happens in Bukkit world, we call them all event. In our example, the event will be 'Player typed a command' event. There is a specific name for this kind of events, but it's not necessary if you are not into plugin development.

Trigger

Anyway, if an 'event' happens, TriggerReactor will look for an appropriate Trigger. If you have created a Command Trigger named 'test', when an user type /test command, your Command Trigger, 'test', will react to the event. And if trigger contains executor in the code, it will execute codes including zero or more Executors.

Try it yourself!

/trg cmd myFirstCommand #MESSAGE "Well done "+$playername+"!"

/myFirstCommand

Executor

Now for Executor, it is one form of code that makes your life easier. Instead of lines of codes, some tasks can be simply done with Executors. You can find the list of Executors in the Executors section.

For any Executors, it has form of #<executor name> <argument1> <argument2> <...> and so on. It may have no argument depends on what Executor you are using. For very basic, lets look at the #MESSAGE executor. #MESSAGE executor is the one that send message to the player who has activated the Trigger. So in most cases, #MESSAGE is valid. Command Trigger for example, it will be activated when a command is used right? And if we have this #MESSAGE Executor with argument "HI" is passed, the player will see the message HI when they used the command.

#MESSAGE "HI"

Placeholders

And to aid you even more, Placeholder is added since version 1.4.0. Placeholders can be found in the Placeholders Section.

Placeholders are just like the Executors; it simplifies the long and complex code into simple one. If you are familiar with the VariableTrigger, for example, $playername is equivalent to the <playername> of VariableTrigger.

#MESSAGE "Hi "+$playername

Very Useful Tip

It's tedious and lots of work to code everything, and the hardest place is where you encounter the errors. Because you are not used to the debugging the code, I highly recommend you to play around with /trg run command first. /trg run is a temporary Command Trigger that just act like /trg cmd except it is temporary; therefore, code will not be saved. This is a great place to try the codes.

• /trg run #MESSAGE "Your name is "+$playername

• /trg run #BROADCAST "Hello everyone in server!"

• /trg run #MESSAGE "Moving you to lobby server."; #SERVER "lobby"

  • Look closely at the 'semi-colon' next to server.".
  • This will be explained below.

How TR Interprets Your Scripts

Left to Right and Top to Bottom

In TriggerReactor, the codes are read from left to right, and then top to bottom.

#MESSAGE "hi"; #MESSAGE "hi2"
#MESSAGE "hi3"

How is this code going to be interpreted by TriggerReactor? Just like I said, it reads from left to right, and then top to buttom.

In the code above, we have two lines of code; the first line has two #MESSAGE executors, separated by semicolon, and one another #MESSAGE executor right below them. We call these each chunk of codes 'statements.' A statement is just a code that contains one task at a time to be executed. So if you have two statements, it means those codes will be executed one by one via TR. (Obviously, this can be a little different story if concurrency is involved. But if you are not familiar with what 'concurrency' is, just ignore it.)

Separating Statement

So how TriggerReactor knows which statement is separate from which statement? To notify that, you have to use either enter or ;(semicolon) at the end of your statement.

In the above code example, the first line terminate one statement with semicolon; therefore, TriggerReactor can cut out statement, #MESSAGE "hi", so that the following code, #MESSAGE "hi2", can be separated by the prior statement.

If you were missing the semicolon

#MESSAGE "hi" #MESSAGE "hi2"

Trigger reactor would process them as one statement, and it will cause error. Unlike we can simply distinguishing those two statements, TriggerReactor will simply process that the statement as whole, and as a result, instead of two separated statements, it becomes one #MESSAGE executor with three arguments passed.

//executor arg1 executor arg1 -- This is when semicolon or enter is used correctly
#MESSAGE "hi"; #MESSAGE "hi2"

//executor arg1 arg2 arg3 -- Notice that missing semicolon caused TriggerReactor to process executor as an argument.
#MESSAGE "hi" #MESSAGE "hi2"

Comments

Even though I already used them in example, the comments are useful tool when you want to document your code.

//#MESSAGE "this is a commnet"
#MESSAGE "this is not a comment"
/*#MESSAGE "this is also"
  #MESSAGE "a comment"*/

The first comment is the 'double slash' comment. The double slash comment can be used when you want TriggerReactor to ignore the entire line next to it before the next line. In example, the first code will be ignore as the double slash is commenting the code next to it. Next line will be not affected.

Another comment is using '/* */'. Unlike the double slash comment, this comment can be used when you want to specify the region of codes you want to ignore. In the example, the third line starts with /* comment, and at the forth line, */ is closing the comment section. Therefore, the code between /* and */ will be all treated as comment, and it will be ignored by interpreter.