|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
07-06-2006 13:06
Just occurred to me, a HUGE number of scripts in SL (animation over-riders, keyboards etc) use the llGetAgentInfo() function to fetch data. However, this has to be done frequently to get a quick response time, but often is completely redundant, meaning we have a lot of scripts, constantly using resources because they have a timer event triggering every second (or fraction of a second) just to check the current agent info!
So, since LSL is a state-based, event driven scripting language, why don't we have an agent_info() event?
llGetAgentInfo() would still be there for basic requests, however, there would be a new call, say; integer llMonitorAgentInfo(key id)
id is the key to check, and integer is a unique identifier for the monitor. llMonitorRemove(integer num)
num is the monitor to remove.
Then an event: agent_info(integer num, key id, integer info)
num is the monitor's id number (for removing it), key is the agent id, and info is the same as a call to llGetAgentInfo() would give. The exception is that this event is only triggered when an agent's info changes, and a script happens to be monitoring their info, allowing for instant response ONLY when needed.
There are likely other functions this kind of event pattern could be used for, polling is probably the source of 99% of script work when in many cases it may not be needed at all.
_____________________
Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)
|
|
Seronis Zagato
Verified Resident
Join date: 30 Aug 2005
Posts: 454
|
07-06-2006 21:30
From: Haravikk Mistral The exception is that this event is only triggered when an agent's info changes Brilliant !
_____________________
From: Johnny Mann Just cause SL redefines what a videogame can be doesnt mean it isnt a game. From: Ash Venkman I beat SL. (The end guy is really hard.)
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
07-07-2006 10:21
Just seems odd to me this wasn't how it was done before really, since avatars don't really change states THAT much (comparatively). My original idea was to do the same with sensors, but I ditched that because the processing of the filters for the movement of every object would implode the servers. Except maybe if the act of adding a filter caused your object to have a large volume detect around it (ie a sphere of range radius) which would then result in collision_start() and collision_end() style events (with nothing happening for avatars already in the filtered area). Hmmm.
I still can't remember what the other ones were, I thought of two or three as well as agent info that made sense at the time, but then I WAS at work, thus I've forgotten.
_____________________
Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)
|