EventScript - Eventing 2.0

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

I just added indexing. It means that you can specify either specific indexes, or ranges. This addition is just a leverage for the next update with labels. Please do tell if any errors occurs.

Example:
Code: [Select]
onActivate->Self->toggleEvents([1:3])
[ 500]onRelay->Self->setColor(1 0 0 1)
[1000]onRelay->Self->setColor(0 1 0 1)
[1500]onRelay->Self->setColor(0 0 1 1)
« Last Edit: November 17, 2017, 11:47:33 AM by mctwist »

personally i prefer the first method of labeling platypi suggested: most clear and easiest for non-coders to figure out. the rest excepting the curly brace one is too wordy and tedious, defeating the point

labels are frowned upon in real programming languages not for the uses they have here. they’re frowned upon as goto is frowned upon - in this case its more a lookup table kind of thing

You are absolutely correct. The main purpose of labels is in fact to name a position in the memory, which means that using them this way should work accordingly. However, I would like to point out that even though we have in this case addresses(line-number-ids), I like the second version that Platypi suggested, by putting the labels on the same location where they belong, which means that the indexing wont work like [start:end-1], but instead work like [start:end]. This shouldn't confuse the programmer as we are defining an inclusion range, from start to and including end.

I may of course be wrong in this, and that's why I leave it in the open for discussion. I might be able to add labels later this evening, but it'll be made so it's easy to change it according to how you guys really want it.

<label:start>
lines
<label:end>

and refer to using <label>

clearest, doesnt forget with existing special syntax chars like [] while not introducing a new set of chars. only validation needed is label name cannot have :, and spaces if that gets bothersome

<label:start>
lines
<label:end>

I am sorry, but that syntax is really ugly. I don't want to introduce XML into this. I'm going all in on Platypi on this now.

I added labels in the latest version. They work as the second version of what Platypi suggested. More information is in the OP. I might make a better guide later on as this progress. The op is not a mess, but it lacks information, and it's not consistent with how it's written. Whenever that will happen...

As I got some free time, I'm fixing up the indexing/range feature to make them more interleaved:
Code: [Select]
[3:7,9,15,20:23]

It's the exact same semantic as fireRelayNum, so it should be quite easy to make it.

Edit: Well, that went faster than I expected. Released an update with that addition.
« Last Edit: November 19, 2017, 03:17:44 PM by mctwist »

We got problem with the Mac. Apparently they cannot use the keybind I set up. I'm currently working with Jam Jar to solve this issue, but if anyone else got information about it, please be free to let me know as that would be of big help.



Other than that, some client Add-Ons that heavily modifies the event window will break my script(Which is based on default behavior). So either I need to make a workaround for those, or I'll give a small scripting lesson of how easy it really is to make their own client implementation to work this issue out:

First off, override EventScriptClient_save and EventScriptClient_load. The first returns the script and the second takes in a script parameter.
Secondly, there is two functions that is used to parse the script: EventScript_toScript and EventScript_fromScript. The first one takes in a script and an error handler parameter and returns an object. The second takes in an object and returns a script.

The object mentioned is just a list. It is best described like this:
Code: [Select]
%list.count;
%list.value[%i, "line"];
%list.value[%i, "enabled"];
%list.value[%i, "delay"];
%list.value[%i, "inputEventName"];
%list.value[%i, "targetName"];
%list.value[%i, "NTName"];
%list.value[%i, "outputEventName"];
%list.value[%i, "params"];
%list is the object, count is the amount of events and %i is the index. The rest talks for itself.

As long as this is followed, it's really easy to implement this into their own Add-On. If anyone have anything else to say about this, then please be free to do so.

The finished code is here:
https://pastebin.com/nAka1zvq

It'll be added to the next release.

That looks alright, but I would make one change if I were you:

A better package name. In your case, I would suggest MEGA_EventScriptPackage.

Anyway, I'll see to add support for a more advanced system when it comes to input from other add-ons and consistency between scripts and events that have been copy-pasted. I left an issue to solve this eventually, but I cannot guarantee that I'll be able to add it the next few weeks. For now I got the urge to fix the case sensitivity and no-parameter-newline-hack. The problem that occurs with case sensitivity, though, is that it might slow things down as there is no real brick table available. I'll see to add such a thing soon so it'll become way faster to get the names and also make it case-insensitive.

That looks alright, but I would make one change if I were you:
A better package name. In your case, I would suggest MEGA_EventScriptPackage.
Haha yeah I'll have to change that.
The updated version of my mod with support has been uploaded.
But yeah, support for features in the mod would be cool, add them when you get the chance.

I'm working on it. I'll just need to find a fix around that and then I'll get to work.

Just stumbled across boodal 2's old project by the name of Event Script. It's different, but I thought it was interesting.

I've already talked to him about it and we both agreed that they were different from each other and he had nothing against me from using the name anyway. They are a bit different due to him having a space and I am not. Also, his was a bit error prone due to the use of eval.

you should make it so you can paste things like fonts and colors and <a:>  :cookieMonster:

That is an additional functionality that I rather not add. Fonts and colors are literally impossible, and links are an extra feature that will be more of a nuisance than an addition.