EventScript - Eventing 2.0

Author Topic: EventScript - Eventing 2.0  (Read 11387 times)

EventScript

There has been several ways to handle events, even additions that add more functionality for it. Some even used it in ways that it was not supposed to. However, there was no specification or standard of how to write events outside of Blockland. Everyone went as they pleased and even if most people understood it, it was still tedious to implement the events if they were long enough.

Introducing the new scripting language EventScript. It standardizes the specification of how to write events through text.


Copies the left code into the event system and then copies the event system into readable script.

EventScript Support List
  • Standardized format for events, everything included
  • Optional semantics
  • Easy as copy-paste
  • Comments
  • Labels
  • Indexing and ranges

Example
Code: [Select]
# Normal event
[x][33]onActivate->Self->fireRelayNum("1-5 5 7", "Brick")

# Disabled and delay with no params
[ ][500]onBlownUp->Player->Kill
[x][  0]onRelay->Self->fakeKillBrick("5 10 3.4", 2)

# Separate lines
[x][56]onRelay
->Self
->setColor(
"0.000000 0.000000 1.000000 1.000000"
)

# Default behavior
onRelay -> "test_brick" -> setColliding (1)
setApartment -> And -> setOwner (9845)
onProjectileHit -> Projectile -> Bounce (1.3)

# Indexes and ranges
onRelay -> Self -> toggleEvents([0:3])
onRelay -> Self -> toggleEvents([1,3,5])

# Labels
myLabel:
onRelay -> Self -> toggleEvents([myLabel:myLabel])

Semantics
The language is built on being forgiving. All sort of whitespace is ignored and newlines are the only used as an exception for certain cases due to parsing issues. Below is a detailed walk-through of the first event in the example above.

Enabled / Delay
Code: [Select]
[x][33]
Each of these needs to be put between a pair of square brackets.
The first x is defining that the event is enabled. If there is no x, then it is disabled. Leaving this parameter out will default to enabled.
The second 33 is the delay. Leaving this out will default to 0 or server default.
These can be written in any order.

Input
Code: [Select]
onActivate->
This defines the input event name. The arrow indicates the end of the name and the beginning of the target.

Target / Name
Code: [Select]
Self->
This indicates the current target. For named targets, one just put the name between double quotes. As for input event name, the arrow indicates the end of the name and the beginning of the output name.
Code: [Select]
"test_brick"->

Output
Code: [Select]
fireRelayNum
The output name of the event.

Parameters
Code: [Select]
("1-5 5 7", "Brick")
The parameters for the output event needs to be put between paranthesis. This is optional for output events with no parameters. Each parameters is separated with a comma. They could also be put between double quotes if it contain comma or double quotes. Recommendation is to put everything that isn't number between double quotes to avoid issues.

Indexes and ranges
Code: [Select]
[1,3,5]
[0:3]
Indexes or ranges is a feature to handle a bigger amount of event numbers. It supports both specific indexes and ranges from one number to inclusive an another number.
Code: [Select]
[2:5,7,10,15:20,25]

Labels
Code: [Select]
myLabel:
The above code creates a label that can be used to reference to the event after it.
Code: [Select]
[myLabel:myLabel]
These are then used for indexes and ranges so direct numbers are not needed.

Links
« Last Edit: November 03, 2018, 05:42:00 AM by mctwist »



would add to the long petition of addons to make default

Instead of writing ->, why not a ;? Quicker to write.

X 0 onActivate; Self; setColor(0)

Instead of writing ->, why not a ;? Quicker to write.

Easier to understand. The events move in that direction, hence an arrow to strengthen that fact.

X 0 onActivate; Self; setColor(0)

The enabled and delay to the left is both that it looks better, but also so we can make them optional.

Instead of writing ->, why not a ;? Quicker to write.

X 0 onActivate; Self; setColor(0)
That looks gross and no other syntax does this.

This looks super useful.

I find myself saving a set of bricks w/the duplicator and modifying a save file directly w/a text file editor, rather than try to deal with some sort of eventing ui mod.
This EventScript would probably cut through some of that.

I can see it's possible to paste eventscript into the game.
Will it be possible to copy events from the ingame window and paste them into a text editor?

This is gonna be great

Will it be possible to copy events from the ingame window and paste them into a text editor?

yes
« Last Edit: November 14, 2017, 09:49:01 AM by Electrk² »

god damn this looks loving super

Will it be possible to copy events from the ingame window and paste them into a text editor?

I'll explain the gif: From there I'm copying the text from the editor and pastes it into the event window with a shortcut you specify. Then I copy that event window with an another shortcut and pastes it into the text editor.



A quick update: I'm currently trying to add the functionality for the server as well, but I think I might have to scrap that due to difficulties for getting a correct id->datablock list on the server.

Edit: I might have found a way around it.
Edit2: And we're golden. Saving and loading scripts through server also now works.
« Last Edit: November 25, 2017, 02:02:42 AM by mctwist »

Instead of writing ->, why not a ;? Quicker to write.

X 0 onActivate; Self; setColor(0)

Are spaces allowed in event names? If not, maybe it could just be "onActivate Self SetColor" without any unnecessary syntax.

Are spaces allowed in event names? If not, maybe it could just be "onActivate Self SetColor" without any unnecessary syntax.

You could even write it like this if you wanted to:
Code: [Select]
X 0 onActivate Self setColor 0
But I feel that looks really odd and removes the possibility to build upon it. My design was made in such a way that one could easily set have their own coding style while still enforcing a standard that everyone understands.

I've released the Add-On. Do tell if you find anything that needs fixed.

https://forum.blockland.us/index.php?topic=314714.0

Design, scripting, debugging, testing, discussing and uploading all took in the time of yesterday to today, in total of about 20 hours.

This looks hot. Nice job!