Rick Nightingale

Getting exactly the same as the OP here, in Wanderton, over the last hour. Came here to see if anyone had said anything. I got one message about inventory fault. I'm in the UK but even tried a VPN exit in the USA. No difference. That's when I *do* get in with the infamous: ...which happens about nine times out of ten so far! If I get chance I'll file that bug report but I'm just trying to get some work done right now... (finally got into Verenda which seems OK) Note that I have no network or other issues that I am aware of, everything works fine on Agni.

Has anyone seen an issue where llPlaySound with llSetSoundQueueing plays a sound more than once, or a subsequent call to llPlaySound with a different sound plays the previous sound again? I'm certain my script isn't calling it more than once... My script plays assorted sounds on the click of a HUD button. The sounds' names and durations are on a NC. Some of the sounds are multiple files split into 10 second lots, some are just a single file. In order to allow duplicate sounds to be played in succession (which llSetSoundQueueing does not allow) my script plays a "silence" file after every sound set. The HUD also has a Stop button which cancels any pending sound files in my queue and plays the "silence". If the script has a queue, each 'next' sound is preloaded with llPreloadSound as it is queued for playing, while the previous one is still playing. It all works perfectly and has for years... except in one region I tend to visit a lot: Fallen Gods. There, it will more often than not (but not always) play a sound twice, or even loop it (possibly indefintely, certainly 3+ times) until I press the Stop button. I'm only playing a single sound file, not one with multiple files chained together, so there is no actual queuing or preloading involved in this case. I have debugged the script with chat messages for every step, and it does nothing unexpected that should trigger the sound again. The llPlaySound function is only called as expected. The main script is in an attachment and listens to the HUD. This is the script in the attachment. Not all is shown (to keep it brief) but the missing code plays no part in the issue. The HUD script simply sends commands and doesn't play anything itself. key Owner; integer vChannel=[redacted my secret channel] list Length; // Play lengths list Sound; // Sound names integer Playing; // Index of playing sound. -1=nothing playing integer Queue; // Queue depth integer Volume=7; // Volume (1..10) Playit(string thesound, float thevolume) { llPlaySound(thesound,thevolume); llOwnerSay(thesound); } default{ state_entry(){ Owner=llGetOwner(); llSetSoundQueueing(1); state Running; } } state Running { state_entry(){ llListen(vChannel,"","",""); Length=Sound=[]; Playing=-1; } listen(integer channel, string name, key id, string m) { if (llGetOwnerKey(id)!=Owner) return; llOwnerSay("Heard: "+m); list task=llCSV2List(m); integer tasklen=llGetListLength(task)/2; if (tasklen) { // Should be a playlist llOwnerSay("Heard a playlist"); if (Queue) { // Already a queue, check for duplicate entry (cannot queue successive duplicates) llOwnerSay("There's a Queue"); if (llList2String(Sound,-1)==llList2String(task,0)) { // We have a successive duplicate Sound+="silence"; Length+="0.1"; } } Sound+=llList2List(task,0,tasklen-1); Length+=llList2List(task,tasklen,-1); if (Playing==-1) { // Not currently playing, start it up llOwnerSay("Wasn't playing, is now"); Playit(llList2String(Sound,Playing=0),0.1*Volume); llResetTime(); llSetTimerEvent(0.02); // Trigger the next sound queueing } else if (Playing==Queue) { // We have already started the previous last sound, need to rejig the timing llOwnerSay("Already playing, rejig"); --Playing; llSetTimerEvent(0.02); } Queue=llGetListLength(Sound); } else { if (m=="stop") { Playit("silence",0.0); llSetTimerEvent(0.0); Length=Sound=[]; Playing=-1; Queue=0; } else if ((integer)m) { Volume=(integer)m; } } } timer(){ if (++Playing<Queue){ // We have more to queue llPreloadSound(llList2String(Sound,Playing)); // Preload the next sound... Playit(llList2String(Sound,Playing),0.1*Volume); // ... and queue it float delay=llList2Float(Length,Playing-1)-1.04; if (delay<=0) delay=0.02; llSetTimerEvent(delay); llOwnerSay("TimerA: "+"P="+(string)Playing+" Q="+(string)Queue+" D="+(string)delay); } else if (Playing==Queue) { // Last sound should now be playing, give it time to finish float delay=llList2Float(Length,Playing-1)-1.04; if (delay<=0) delay=0.02; llSetTimerEvent(delay); llOwnerSay("TimerB: "+"P="+(string)Playing+" Q="+(string)Queue+" D="+(string)delay); } else { llSetTimerEvent(0.0); Playit("silence",0.1*Volume); Length=Sound=[]; Playing=-1; Queue=0; llRegionSayTo(Owner,vChannel,"stop"); llOwnerSay("TimerC: "+"P="+(string)Playing+" Q="+(string)Queue); } } } This is the debug chat: Heard: Darkness Laugh =7.75,7.75 Heard a playlist Wasn't playing, is now Playing: Darkness Laugh =7.75 TimerB: P=1 Q=1 D=6.710000 Playing: silence TimerC: P=-1 Q=0 As you can see, the debug shows only two calls to llPlaySound. Everything is as expected, and yet the sound "Darkness Laugh =7.75" played three times on that run! Finally, I've realised as I typed this that when I press stop, the sound stops immediately. As I understood it, the "silence" should be queued up but the currently playing sound should still finish because of the llSetSoundQueueing(1) in the default state_entry.

Hmm... I see at least one on there that might fit the bill. I'll go and take a closer look. Thank you!

Thanks, but that's the one I mentioned above Yeah, the lack of rigging kills it, as does the no-mod perms as well although I might live with that for the perfect (rigged) hair.

Bram Stoker's Dracula hair would be perfect for a character I'm doing... can anyone suggest a similar one on the MP? Rigged mesh please. REBIRTH does one that would be perfect if it was rigged, but having it clip through my shoulders when I turn my head is a non-starter. Not the old, grey look, but this one:

Brilliant, thank you. That will make (second) life easier.

I often log in several alts on one PC for testing, but I've always avoided logging in the same alt simultaneously on Agni and Aditi. Just in case. although I did once do so accidentally and nothing exploded that I noticed. Sometimes it would be quite useful to do. So, is it safe to do that? Or will my inventory get stolen by aliens or my alt get pulled into a singularity?

Exactly what I thought too. I wouldn't be surprised to see some very big lawsuits from the big IT players against Intel for this, to offset the additional costs of that additional speed they will need to allocate. I feel fortunate that I'm no longer in the IT game right now. Too many virtual server farms with my name on them, lol.

I wonder how much impact this will have on SL's servers? https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ Briefly, a serious exploit has been found in all Intel x86-64 series CPUs since the Pentium. It's unfixable in microcode and needs an OS fix to work around the vulnerability. Potentially average 30% performance hit, worse on applications which make lots of system calls. Like virtualisation! I wonder if Intel will even survive this.

That looks exactly the issue, thank you! (I did search first, but obviously not well enough, lol. I blame the tequila.) ETA: Hmm, except that my hands are playing Bento animations repeatedly, but only for the hands. My main AO is non-Bento. Still likely the same issue though.

Has anyone else seen this issue? I'm not sure if this is server or viewer side, but... From another SL account, logged in on a different PC, I've repeatedly noticed that my left Bento hand sometimes appears fixed in a pose. It is in an uncomfortable-looking fingers splayed straight out position. I've seen it when both accounts are logged in on the same PC too. At first my hands appear to function properly and the animations can be seen, but at some point it goes to the fixed pose and sticks there. Then, the only way to fix it is for me to relog. But bear in mind the below: From my perspective, my hand functions as normal, playing it's various animations. That splayed-out position is not even in my hand's animations. I made the very simple AO myself and used standard animations supplied with the Aesthetic Bento hands. There is nothing wrong on my side - it works perfectly fine. If I wasn't watching from another account in the same room, I would have no idea what was happening in the other viewer. For clarity: The frozen hand is only seen in someone else's viewer. In my viewer, it works normally. I'm using the latest Firestorm. I would like to think it's a problem with my hand or something here because I could fix it. Given what happens though, I can't see how it is.

Thank you Whirly.

Thank you for the reply. I think we tried going to Aditi on 26th, so that fits. I was there with my building alt before that but there were no changes to that account, so I would not have noticed if anything updated or not. I'll prod support in a couple of days (after the usual Tue/Wed server stuff) if nothing changes.

Has anything changed recently with updating the Aditi inventory from Agni? I'm not getting updates. I've been away from SL for a year, but was a regular Aditi visitor for testing mesh etc. I remember that inventory updating was working well, after some teething problems in the system. For the last two weeks I've been in and out of Aditi and my inventory has never updated. The same for my wife's account which is actually the one we need updated (to work on things for her new Bento body).