[E2] dataSignals - A combination of signals and gvars

[Divran]

Information
I've created a new E2 extension: dataSignal
It's a combination of signals and gvars. Basically the two put together.
Instead of sending a signal to run an E2, and then using gvars to get the data, you send both at the same time.
Variables are not saved on any shared variable. They are only transmitted.

They basically act like dynamic wire inputs between E2s.

Download

http://divranspack.googlecode.com/svn/trunk/ divranspack/Divrans various E2 Plugins/dataSignal.lua

Functions
Here is a list of all functions so far.

The available scopes:
0 = Your own E2s
1 = Your E2s and Prop Prot friends' E2s
2 = Anyone

Send a signal directly to another E2:
dsSendDirect( signalname, ent, variable )

Send a signal to all E2s in a group and scope:
dsSend( signalname,  variable ) -  (Sends to the E2s own group and scope)
dsSend( signalname, scope,  variable ) - (Sends to the E2s own group)
dsSend( signalname, group,  variable ) - (Sends to the E2s own scope)
dsSend( signalname, group, scope,  variable )

Probing (returns an array of the E2s the signal WOULD HAVE been sent to if it was sent using this group and scope)
dsProbe() - (Sends to the E2s own group and scope)
dsProbe( groupname ) - (Sends to the E2s own scope)
dsProbe( scope ) - (Sends to the E2s own group)
dsProbe( groupname, scope )

Set/Get Group/Scope:
dsSetGroup( group )
dsGetGroup()
dsSetScope( scope )
dsGetScope()

Getting the data:
dsClk() - (Returns 1 if ANY signal triggered the E2)
dsClk( signalname ) - (Returns 1 if this signal triggered the E2)
dsClkName() - (Returns the name of the current signal)
dsGetType() - (Returns the variable type of the receiving data)
dsGet*() - (Gets the data. If the current type is not equal to *, it returns *'s nil value)
dsGetSender() - (Gets the entity of the E2 who sent the signal)

As you probably noticed, I have a dsSetScope() function. What's this used for?
If you set this, it will only allow signals with matching scopes to trigger your E2. See the available scopes above for what "matches" and what does not.

[Bull]

Ohh, that sounds very interesting.
Gvars and signals go together hand in hand already, a combined version would simplify a lot of things.

[Divran]

Ohh, that sounds very interesting.
Gvars and signals go together hand in hand already, a combined version would simplify a lot of things.

When I made this, I was thinking of Lyings dozens of drones, Filipe's OS (although a gvar system might be simpler there) and your Wired Worms

[Divran]

BUMP because of update.
I have now added support for EVERY SINGLE type by looping through the wire_expression_types table and using registerFunction.
"Download" link added. (Copy it into a file in expression2/core/custom)

[Syranide]

I haven't really analyzed the API in too much detail yet so can't say anything about this implementation, but I've always been a supporter of merging them both. I never quite understood why they became separate (other than because they were developed by separate people).

So I definately think something like this should be made available, but like I said, I haven't dug deep enough to know if this is "it".

[Syranide]

Having looked more at this extension and talking to Divran I'm feeling pretty confident that this is a definate commit once a few important bugs has been fixed.

[Divran]

SVN UPDATE!
Renamed functions
dsToE2 -> dsSendDirect
dsToGroup -> dsSend

[Matte]

I haven't really analyzed the API in too much detail yet so can't say anything about this implementation, but I've always been a supporter of merging them both. I never quite understood why they became separate (other than because they were developed by separate people).

So I definately think something like this should be made available, but like I said, I haven't dug deep enough to know if this is "it".

Exactly my thoughts. In my opinion, the extension which came last (gvars or signals, can't remember) should have been merged with the exisiting one as an update rather than separate extension.

[Syranide]

Exactly my thoughts. In my opinion, the extension which came last (gvars or signals, can't remember) should have been merged with the exisiting one as an update rather than separate extension.

Agreed.

It should be noted that this extension doesn't strictly deprecate both gvars and signals, only signals (and some uses of gvars). As there is no global storage, only the ability to send data with the signals. Another interesting fact is that this is pretty much an implementation of the often used "message passing" technique, which is commonly used when dealing with threads and parallell programming (much like distributed E2s). Although I've left the decision whether to rename it to "message passing" or keep "data signals" up to Divran.

I've looked through the code so far and it's very well-written and the API is well thought out. It should also be noted that Divran is implementing support for recursive sending tomorrow, so that E2s can execute one another recursively without causing all kinds of funny stuff... or having to delay executions until the next frame as signals does unless I'm mistaken.


Note to divran:
You should consider merging dsSetGroup and dsSetScope, I can't really come up with a situation where one would want to control both separately, rather than mostly set it up once and keep it that way (and in the other cases, it's easy enough to just supply the group/scope again). I'm fine with either, but merging them might simplify it a bit... but I leave the decision up to you.

Also, with the introduction of queues, being able to send messages to one self might be useful in some circumstances (however, messages sent to a group should obviously not be sent to the E2 itself, only dsSendDirect() should do so). So in hind-sight I'd recommend moving the check into E2toGroup().

Awesome work, really.

[Colonel Thirty Two]

Curses divran, you beat me to it. x(
Anyway, cool. This is really needed, as simply triggering an E2 is pretty much pointless.