|
Django Yifu
Beat Island Gaffer
Join date: 7 May 2007
Posts: 189
|
10-04-2007 14:02
Is it better to have 10 scripts running on timers scanning for changes in avatar states, for instance when the avatar starts flying, and then firing off their desired effect.
or;
To have 10 scripts listening within a link set with another script on a timer waiting for the avatar state change and then firing off a control message to the other scripts.
I know listens can be laggy but then so are lots of fast timers.
I guess I want to know if lots of scripts listening for link messages has the same effect as a lot of chat listeners and if that is worse or better than using some timers to control the scripts instead.
Sorry. Does that make sense to anyone?
_____________________
Tread softly upon the Earth for you walk on my face.
|
|
DanielFox Abernathy
Registered User
Join date: 20 Oct 2006
Posts: 212
|
10-04-2007 14:05
listens as long as they are not listening on channel 0 shouldn't create as much lag as timers I believe. Generally, event driven logic like a listen is more efficient then polled logic like a timer. But I may be wrong.  |
|
Void Singer
Int vSelf = Sing(void);
Join date: 24 Sep 2005
Posts: 6,973
|
10-04-2007 14:11
I'd definitely go with the later.... 1 actively timed event &10 passive scripts waiting for link_message sounds MUCH better than 10 actively timed events
why 10 scripts for one state change?
::grins:; you don't have to share, I'm just curious... I have a toy that requires 2~20 scripts to react to a state change
|
|
Django Yifu
Beat Island Gaffer
Join date: 7 May 2007
Posts: 189
|
10-04-2007 14:25
I'm creating an engine for a jet pack that has a number of prims change settings according to whether the avatar is flying or not, lights, anim textures, particles etc.
So i guess I am best setting up a control script to get all these changes to take place rather than have each prim make the check.
Thanks a lot guys. Saved me a whole lot of time in rescripting my project.
_____________________
Tread softly upon the Earth for you walk on my face.
|
|
Kidd Krasner
Registered User
Join date: 1 Jan 2007
Posts: 1,938
|
10-04-2007 16:09
From: DanielFox Abernathy listens as long as they are not listening on channel 0 shouldn't create as much lag as timers I believe. Generally, event driven logic like a listen is more efficient then polled logic like a timer. But I may be wrong. In this case, it's listening for link messages instead of channel messages, so it's even more efficient. |
|
Void Singer
Int vSelf = Sing(void);
Join date: 24 Sep 2005
Posts: 6,973
|
10-04-2007 16:27
are many of the features combinable?
what I mean is, even though llSetLinkPrimitiveParams ahs a built in delay of .2, some features can be called near simultaneously.... for instance, texture(set, rotation, repeats, offsets, alpha), can all be called at the same time at a serious delay time savings, along with things like lighting, color, rotation,..... w/o outsourcing the scripts.... and the delay kicks in AFTER those functions get called
and since particle system has no delay at all.....
I mention this because I'd actually considering forshortening my own product (wings that open close in sequence) to 2 scripts that controll either side... if I could reliably move all parts of each side at the same time for things like flapping or twitch/rustle
|
|
Django Yifu
Beat Island Gaffer
Join date: 7 May 2007
Posts: 189
|
10-08-2007 15:32
If I was using llSetLinkPrimitiveParams surely that would cause a delay as I made the settings for each prim that needs to change.
I have several prims changing settings at the same time (when the owner starts flying).
I presumed I would have to make a llSetLinkPrimitiveParams for each prim individually as they don't all want to change in the same way. In that case isn't the 0.2 sec delay introduced between each call making the changes stagger
_____________________
Tread softly upon the Earth for you walk on my face.
|
|
Void Singer
Int vSelf = Sing(void);
Join date: 24 Sep 2005
Posts: 6,973
|
10-08-2007 17:05
From: Django Yifu I presumed I would have to make a llSetLinkPrimitiveParams for each prim individually as they don't all want to change in the same way. In that case isn't the 0.2 sec delay introduced between each call making the changes stagger correct assumption, it all depends on howmany prims per side, and what exactly they are doing.... if it's color, alpha, particles, scale, (and a few others) those all have separate functions with 0 delay.... if it's multiple parts per side with rotation, position, texture, etc.... then yeah separate scripts for each prim to get simultaneous action but if for instance, only one prim on a side has the delay causing function (or function that has a 0 delay function requiring the script to be in that prim), then a single script per side is feasible |