Improved Event System

[Crispy_]

"Onplayertouch" "ifplayertouch" "whileplayertouch"
...what would "elseplayertouch" do? As a sentence, it doesn't even make grammatical sense...

Of course, it would not allow you to select some things. Like On Player Touch would be pretty much the same thing as If Player Touch, so player touch would not be listed when you select 'if', etc.

[Ad Bot]

[blueblur121]

Else would go directly to an output event. If would check for a variable to be true or false (variables should be added to this new system as well). While would be constantly activated every few ticks as long as the input is being activated. And then it would go back after the input isn't being activated.

EXAMPLES:

text box = []
dropdown list = <>

IF/ELSE:

Code: [Select]

<on> <playerTouch> <self> <IF/ELSE_EVENT>
<if> <BL_ID> <==> [1] <client> <centerPrint> [Hello, Badspot!]
<else if> <BL_ID> <==> [27046] <client> <centerPrint> [Hello, Blueblur!]
<else> <client> [Unrecognized BL ID.]
<end>This checks the BL ID of the person touching the brick and gives them a specific message based on who they are.

WHILE:

Code: [Select]

<while> <playerTouch> <self> <setColor> <blue>
This makes it so that if a player touches the brick it turns blue. When the player stops touching the brick it turns back to how it was.


If this new system was in place then a ton more things could be possible with events. Such as a capture point TDM sort of minigame.

Code: [Select]

<while> <playerTouch> <self> <IF/ELSE_EVENT>
<if> <team> <==> [red] <self> <setColor> <red>
<if> <team> <==> [red] <minigame> <chatMessageAll> [Red team has taken base 1!]
<if> <team> <==> [red] <player> <addScore> [1]
<if> <team> <==> [red] <client> <bottomPrint> [Holding base: +1 point]
<if> <team> <==> [blue] <self> <setColor> <blue>
<if> <team> <==> [blue] <minigame> <chatMessageAll> [Blue team has taken base 1!]
<if> <team> <==> [blue] <player> <addScore> [1]
<if> <team> <==> [blue] <client> <bottomPrint> [Holding base: +1 point]
While is activated every few ticks unless the player stops touching the brick.

[cocoaTHEhotdog]

This just seems like it's to confuse you.

[Peejster]

Of course, it would not allow you to select some things. Like On Player Touch would be pretty much the same thing as If Player Touch, so player touch would not be listed when you select 'if', etc.

If you want to really differentiate between "on" and "if", have "on" apply only the first time it happens, but have "if" activate continuously.
you're right that was stupid

[Threule]

This just seems like it's to confuse you.

Well this leads to easier non-scripting events

[blueblur121]

If you want to really differentiate between "on" and "if", have "on" apply only the first time it happens, but have "if" activate continuously.

No that's while. Look at my examples.

[Crispy_]

Another concept of how using variables would be like

(also i just realised i spelled some things wrong)

[blueblur121]

Why do all of your examples involve a horrifying death. Also "test variables" should be something else like "if/else statement."

EDIT: You should also add the "setVariable" output event and let it be set on bricks, players, clients, and minigames. There should also be variable types such as strings, integers/floats, and arrays.

[Crispy_]

Why do all of your examples involve a horrifying death. Also "test variables" should be something else like "if/else statement."

Client -> if/else statement -> [1          ]
Then event 1 would be tested, because it's event 1 and has 'if' as the first thing?
I guess it could clean things up if other add-ons are using 'if' as well.

[Electrk.]

Test varables

[blueblur121]

EDIT: You should also add the "setVariable" output event and let it be set on bricks, players, clients, and minigames. There should also be variable types such as strings, integers/floats, and arrays.

Don't forget this part.

[bambooXD]

oh plz someone make this!

[Crispy_]

And another concept. A door(?)

[blueblur121]

That second one should be "else". If it's already established that epicness isn't < 10 then why do you need to check if it's >= 10?

[Crispy_]

That second one should be "else". If it's already established that epicness isn't < 10 then why do you need to check if it's >= 10?

That's because you should be able to deal with multiple variables. Imagine if the variable on event 2 was Money. Woah. Now you're dealing with 2 variables. Now not only do you need to be epic, you also need to have money to get in that door. But at least the door won't kill you if you're epic.