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

This is sweet thanks man.
Syntax is a bit hard to get used to but overall good job.



I found out the following issue:


This means that we cannot use the regular way we handle params. I've fixed and updated this issue, but that means that the add-ons that relies on this functionality needs to be updated to support the fix. You may download it again to get this update.

The only change for the structure is the following:
Code: [Select]
%list.value[%i, "params"];
%list.value[%i, "params", %n];
The first value now contains the amount of parameters, and then the second is the list index is %n.
« Last Edit: February 06, 2018, 01:37:20 AM by mctwist »

Mac keybindings have been fixed. The workaround is adding global bindings that is only activated when event window is open.

Changes can be seen here.

if Badspot is this lazy he might aswell hand over development to the community to add in the vanilla game.


I went and added "range and label generators". What that means is that certain events from add-ons, which contains a file named eventScriptLabels.txt, will generate ranges and labels for those events specified.

Example:
Code: [Select]
onActivate -> Self -> toggleEventEnabled("1 2 3 4")
onActivate -> Self -> setColor("1 1 1 1")
onActivate -> Self -> setColor("1 0 0 1")
onActivate -> Self -> setColor("0 1 0 1")
onActivate -> Self -> setColor("0 0 1 1")
Will be turned into:
Code: [Select]
onActivate -> Self -> toggleEventEnabled([onActivate1:onActivate4])
onActivate1: onActivate -> Self -> setColor("1 1 1 1")
onActivate -> Self -> setColor("1 0 0 1")
onActivate -> Self -> setColor("0 1 0 1")
onActivate4: onActivate -> Self -> setColor("0 0 1 1")
Or with labels disabled:
Code: [Select]
onActivate -> Self -> toggleEventEnabled([1:4])
onActivate -> Self -> setColor("1 1 1 1")
onActivate -> Self -> setColor("1 0 0 1")
onActivate -> Self -> setColor("0 1 0 1")
onActivate -> Self -> setColor("0 0 1 1")

All event indices used in that event field will be replaced with EventScript ranges and labels. This should make it a lot easier to share, migrate and merge events without other events interfering. Of course, the names that are created is not unique and that still needs to be handled manually, but that will take less time than manually changing the event numbering.

To make your add-on support this feature, just add eventScriptLabel.txt to your archive and format the file like this pseudo-file:
Code: (eventScriptLabels.txt) [Select]
<event name 1>\t<field>\t<version>
<event name 2>\t<field>\t<version>
<...>
Example:
Code: (eventScriptLabels.txt) [Select]
fireRelayNum 0 2
fireRelayRandomNum 0 2

Event name is the event that will be checked.
Field is the field index, starting from 0, where the numbers will be parsed.
Version is what type of version the field are. 1 means the defaults from like, setEventEnabled. 2 means enhanced, like fireRelayNum.

It might sound like "version" in this case means more like "type", and that is indeed correct as well.

There might be plan to add more versions for certain events, but for now I will let it be as this is the starting point.

Worth mentioning is that manual custom labels are supported, but currently not used.