From c2c292430315b08899d6aff6cc36727c5287de68 Mon Sep 17 00:00:00 2001
From: David Walter Seikel
Date: Sat, 23 Jan 2016 14:21:26 +1000
Subject: Might actually be getting to a design here. B-)
---
TODO | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/TODO b/TODO
index 3d097d2..b74e440 100644
--- a/TODO
+++ b/TODO
@@ -167,6 +167,48 @@ Communication
Link messages include the number of the link (to or from, depending on which end you are at), a number, a string, and a key.
These are entirely internal to LuaSL though.
+purkle registers a listener, with no filter.
+llDialog's client side sends a say() to love.
+ Normally, that wont be bounced back to extantz.
+ SL and OS however, bounce all channels across the viewer, which is why some of them can peek at other channels.
+ Which is why purkle registers with no filter, gotta gettem all.
+ Later we should default to just channel 0.
+
+Soooo, every one sends their say() commands to love. Love decides who to send listen() events to, which may include sending back to the source.
+
+May need to start name spacing Lua stuff.
+ scripts.compile(), scripts.run(), scripts.reset() scripts.listen() which would include avatar's clients registering via purkle pretending to be a Lua script,
+ world.say()
+
+The only place where there is any ambiguity is LuaSL.
+Purkle accepts event.say() from love, LSLGuiMess sends world.say() to love.
+Love routes world.say()'s around, even back to the source if needed, sending them as event.say().
+LuaSL sends world.say() to love. LuaSL accepts event.say() from love for scripts.
+ When a say() comes in, it's executed, which triggers the say() that sends to love. OOPS!!!!
+ world.say() -> events.say()
+
+More generic event system?
+ There are other events flying around.
+ BASIC event Just send it to LuaSL, it loops through all scripts, sending the event to them all if they have an event function in their current state.
+ REGISTER event Script has to register for these events with love. Can have filter. love loops through all regisitered "scripts", applies filters, sends events.
+ REQUEST event Script has to request an event from love. Can have a filter. Love sends event straight back to the script. Once.
+ This covers the "wait for return value" case as well. events.return()?
+ touch_start goes from extantz to LuaSL, via love. Most of the rest go from love to LuaSL I think. link_message, state_entry, state_exit are internal to LuaSL, timer should be.
+ All manner of arguments sent to events.
+ Some of them include the llDetected*() functions for getting more info.
+ So we need some way of sending arbitrary data, as well as a bunch of fixed data, over the network when we send events.
+ Listen events are common?
+ collision, land_collision, not_at_*_target , and touch might be ongoing?
+ llCollisionFilter(string name, id, integer accept)
+ llTarget(vector position, float range)
+ llTargetRemove(integer number)
+ llVolumeDetect(integer detect)
+ Sensor and no_sensor might be common, but you request those, your silly fault, they have filters though.
+ llSensor(string name, string id, integer type, float range, float arc)
+ llSensorRepeat(string name, string id, integer type, float range, float arc, float rate)
+ Event types can have filters? Events can be types? In otherwords, generic filter system, attach say filters to say events, etc.
+ Figure this all out as we go along.
+
LuaSL crashes
-----------------
--
cgit v1.1