Author Topic: Sub Events  (Read 12596 times)

Sub Events
Allows you to do all kinds of crazy stuff if you know how!

Description
Contains a grand total of:
- ONE Input Event
- ONE Output Event
onSub input, and doSub output.

The doSub output has two parameters: first and last events to process. It then processes all events of onSub input starting at the lower and ending at the upper bound you supply:

  • 0 [ x ] 0 onActivate -> Self -> doSub [ 1, 2 ]
  • 1 [ x ] 0 onSub -> Self -> SetColor [ Red ]
  • 2 [ x ] 0 onSub -> Client -> Centerprint [ Hello World!, 2 ]
  • 3 [ x ] 0 onSub -> Self -> killBrick

Activating that brick would cause it to turn red and centerprint. Changing the 2 in the doSub event to a 3 would also cause it to kill.

v2: Introduced loop delay enforcement (like onRelay -> FireRelay delays)
RTB Server Control has a preference for this, it is by default 100ms minimum delay and can be set as high as 1000ms (one second).

Edit (7:35am 24-6-2009 GMT+10): Fixed a bug where if you provide the start and end of range in reverse, the safeguards would instead set them both to be the lower value instead of swapping them. Fixed this - thanks, Space Guy!

Download
Event_doSub.zip (Last Updated: Wed Jun 24, 2009 7:35 am)

Installation
Put Event_doSub.zip into the Add-Ons folder in your Blockland folder.

Click Here to view this file on the RTB Download Manager
« Last Edit: June 23, 2009, 05:36:29 PM by M »


If this does what I think it does, can someone say multiple ifX events without multiple bricks? Sounds amazing. Seems like there would be so many uses for this. Downloaded. Seems like Events is on its way to becoming its own "script" system (well, more than it technically already is...)

This looks like a complicated Relay.. Very nice Clock.

Epic...  Just epic...

Hm. I dont really understand what this does...

Wait... I just figured out that the onSub event would take up the space where the variableTrue/False would go, so unfortunately, no multiple variables here... unless the doSub event works on inputs other than onSub.

1 [ x ] 0 onActivate -> Self -> SetColor [ Red ]
2 [ x ] 0 onActivate -> Client -> Centerprint [ Hello World!, 2 ]
3 [    ] 0 onActivate -> Self -> killBrick

Then enabling event 3 would make it also kill.

I really see no purpose for this. Show me something that you couldn't do without this.

Tom

I really see no purpose for this. Show me something that you couldn't do without this.
Exactly.

1 [ x ] 0 onActivate -> Self -> SetColor [ Red ]
2 [ x ] 0 onActivate -> Client -> Centerprint [ Hello World!, 2 ]
3 [    ] 0 onActivate -> Self -> killBrick

Then enabling event 3 would make it also kill.

I really see no purpose for this. Show me something that you couldn't do without this.
You appear to have forgotten what an example is. Let me refresh your memory - see def. 2.
Simply because you CAN do something without this, doesn't mean it's as easy or convenient. I have built keypads from only default events with some 32-digits of combinations, just to see if I could, and I could do the same with this in half the events or less because I don't need a long string of toggleEventEnabled events.
One digit before was some four events. With this, it's one: onSub -> Self -> toggleEventEnabled [this event, next key's event]

As for multiple variable checks; this is something I wrote originally for variables v5, I just adapted it to be independent. It requires some integration into variable events to allow it to do that, so you'll have to wait.


Also, v2 is uploaded (lol I forgot something) - introduces instant-loop protection so you can't have 0ms delayed onSub->doSub events. Default minimum delay is 100ms.

Ace

These are extremely useful, you have my download.

Fantastic work, Clock.

block of text
Whoa, whoa, whoa. I wasn't criticizing it, I was just wondering if there was anything new that could be created from this, or an example of a situation where this would be extremely useful, which you gave to me.

Whoa, whoa, whoa. I wasn't criticizing it, I was just wondering if there was anything new that could be created from this, or an example of a situation where this would be extremely useful, which you gave to me.
Haha, I just love overreacting. <3

  • 0 [ x ] 0 onActivate -> Self -> doSub [ 1, 2 ]
  • 1 [ x ] 0 onSub -> Self -> SetColor [ Red ]
  • 2 [ x ] 0 onSub -> Client -> Centerprint [ Hello World!, 2 ]
  • 3 [ x ] 0 onSub -> Self -> killBrick

Activating that brick would cause it to turn red and centerprint. Changing the 2 in the doSub event to a 3 would also cause it to kill.

Even with the explanation, my head still hurt.

ummm sub as in submarine?