Talk:LlSetSoundQueueing
Queueing survives take and rez even if it has no script in it when taken and then a script without queueing is placed in it. It also survives when a brand new script never used before replaces the original. The queueing state continues to exist unless it is expressly ordered to FALSE. Cool I liked the challenge. bring em on. lolz -- Eddy 01:20, 16 May 2009 (UTC)
Calling Strife Onizuka... hehehe. I would assume you would be the first to find this.
As you are aware I am trying to find a way to make good use of this function since lists and sleeps are rubbish in comparison but the two sound limit is beyond frustrating. What I have found is that even with switching queueing on and off at responsible times and by shifting states and even by trying to run different sounds from different scripts I cannot find a way to get the second of two sounds to become the first of two if a third is introduced. *Can you think of any little trick that might work?* I can't imagine that there is not a way. But I am assuming that the problem with allocating the second sound as a new first in a new pairing is linked with the way sounds are played out (the fact that the second sound function fires before the first sound has finished playing). Any inspiration would be appreciated since even though I have the will I simply don't have the skill. -- Eddy 01:49, 29 May 2009 (UTC)
- ~_~ I wasn't going to comment until inspiration struck... which it has... about other topics. Sorry. No brilliant insights. You could use a Sync Master instead with a silent looping sound, then play your sounds as slaves; mimicing the queuing by doing the timing yourself, it doesn't have to be perfect as long as you trigger your sounds once per loop. It should work... assuming they didn't break it. -- Strife (talk|contribs) 12:04, 30 May 2009 (UTC)
Mmm. Considered that but unless I understand you wrong I would (anyone would) still need to know the timing of the sound being played to avoid a slight skip. I put in a feature request for llPlaySoundLoop and although Soft Linden made some helpful suggestions along the same lines there is no better way than queueing I can find for any lengths of sound to match up perfectly. Until (if ever) LL grant what I asked for in SVC-4260 I would love to find a cheat to get around this 2 sound nonsense. Things we know -- 1) If say 10 llPlaySounds are scripted in a block with a llSay to advise when the playsounds are done, the say will fire before the first sound is finished (if over a second or so)(and I know that of course only the last sound will actually play. The point is that the llPlaySound function is over faster than the sound is). 2) llLoopSoundMaster etc knows when the sounds are on and off. From this I deduce that somewhere in the deep code the full details of the sound playing is known including the length. So all I need to do is trick the "viewer"? into filing the sounds in accordance with that knowledge. Since queueing seems to be the only way for the scripter to access that info without ever seeing it or knowing it in advance (if one uploaded it for example) I (have just realised I am going on a bit) wanna do that. -- Eddy 12:43, 30 May 2009 (UTC)