I ran your script and it parsed perfectly. However, it will display a warning for the colors if they don't exist in the colorset. Also, I noticed that on line 21 it didn't have any delay, which will destroy the whole purpose. I've put 2000 delay on it and will update all my examples to this instead and credit you.
Woops! I was trying to demonstrate how you don't need brackets, but I forgot what my own events were supposed to do lol.
Looks like you are using an Add-On that might modify the default layout so when I read it I get bogus data. If so, please tell me and I'll find a fix around it.
I am using
Make Events Great Again. I'll make sure to disable it if I do any more testing in the future.
I think that labels at all is dirty. It's frowned upon in all languages but where it came from. It is sometimes a necessity, though. In our case, we're not using it like others are using it, so adding labels in such a fashion might confuse people, or make it obvious to them.
Yes. Labels are typically considered bad practice in C. They are really only present for historical purposes. But, as you said, our use case is different. Eventing is not C. It's more like an instruction set. So for a more apt brown townog to event, look at any assembly language. In assembly, labeling and jumping is quite common (e.g.
labels in x86 Assembly). In fact, it's pretty much necessary.
Keep in mind, that when labeling is used with indexing [from:to], it's not obvious that it's to-1. By having it at the event, it might make it more apparent that we are aiming at the event, instead of the event after it.
This is actually a bit of an oversight on my part. It hit me earlier what I had done wrong. It might be better to not auto-decrement the second value in an interval like I did implicitly. Rather, [from:to] should be written like [from:to-1] to avoid confusion. This would be more intuitive to programmers (who will probably be familiar with MATLAB and Python slices) and non-programmers.
I get what you're saying about aiming labels at an event. It makes more sense in the context of the auto-decrement critique. But of course, people could always choose to write labels as
# Turn light on
onStart: [x][0]onActivate->Self->setLight("Player's Light")
[x][0]onActivate->Self->setEventEnabled([offStart:offEnd], 1)
onEnd: [x][0]onActivate->Self->setEventEnabled([onStard:onEnd], 0)
# Turn light off
offStart: [][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled([onStard:onEnd], 1)
offEnd: [][0]onActivate->Self->setEventEnabled([offStart:offEnd], 0)
Another benefit of explicit, non-bracketed labels is that it might actually make code a bit more intuitive, and hence make parsing easier to a certain extent. If we go with bracket notation, we have to consider four different cases:
- no brackets - default behavior
- 1 bracket - label (?)
- 2 brackets - no label, enabled and delay
- 3 brackets - label, enabled, and delay
This would require you to pre-parse each set of brackets, and then decide how to treat each of them.
But with labels declared separately with colons, we only have to consider two cases for brackets:
- no brackets - default behavior
- 2 brackets - enabled and delay
I imagine this would require less (or no) pre-parsing, as the presence of a forward brackets indicates that the second case is the one to consider.
Another option could be blocking instead of labeling, e.g.
# Turn light on
lightOn {
[x][0]onActivate->Self->setLight("Player's Light")
[x][0]onActivate->Self->setEventEnabled({lightOn}, 1)
[x][0]onActivate->Self->setEventEnabled({lightOff}, 0)
}
# Turn light off
offStart {
[][0]onActivate->Self->setLight("Player's Light")
[][0]onActivate->Self->setEventEnabled({lightOff}, 1)
[][0]onActivate->Self->setEventEnabled({lightOn}, 0)
}
Albeit less flexibly, this feels more intuitive, and it looks a bit nicer to me. If we want to increase the flexibility of this method, we could allow for the inclusion of multiple blocks in a block reference, i.e.
{label1, label2, label3}. And as the cherry on top, this method would probably be the easiest to code up, as it doesn't allow/encourage the use of arithmetic inside intervals/block references.
I would say, too, that the ability to nest blocks need-not and should-not be implemented with this. Eventing is more 1-dimensional than most programming languages, and hence doesn't need such complexities. Plus, nesting would add a whole other layer of complexity to the code.
