Levio Serenity

I don't understand where you're coming from? Are you making a gamification engine? Are you hoping someone else makes one you can use? Presumably Sansar will not include any more game mechanics than SL did, and indeed people will have to build up their own code bases somehow.

Random 499s are a part of life in SL scripting. All you can do is watch for them and if you get one, wait awhile and resend the request. Of course your server has to be able to gracefully handle getting a duplicate request since it may be sent multiple times. Sometimes customers will report a lot of 499s from a single sim, in that case, ask them to have the sim restarted.

RE: Point B. I agree with you Perrie. I specifically asked at weekly office hours to confirm this with the Lindens there. It is supposed to make a brand new shiny backup immediately before shutting down and NOT just use whatever the last hourly backup happened to be.

Some people here aren't getting the point. If a sim has a controlled restart (rolling or otherwise), it should never lose any data, period. It doesn't matter how long any AVs present were given notice. It doesn't matter what they were doing up until the very last second they were on. Absolutely, no matter what, there should be zero loss of data or duplication of no copy objects. The sim is free to take as long as it needs after AVs have been kicked off to save its state and restart. Players have been desensitized to errors of this nature and have these ingrained behaviors of "never build on Tuesday mornings." which is sort of sad.

I would have them file a JIRA on this. No objects should be lost during a planned restart, only from unexpected crashes. However, this happens with an alarming frequency. I don't think LL realizes this is happening all the time.

Yes. And also recently I wanted to be able to play a sound from a non-HUD attachment just for the owner. However, llPlaySound() is heard by everyone nearby, and I can kludge something up with llTriggerSoundLimited() however, this function ignores the sound queueing features that llPlaySound() has. You just can't win in SL scripting.

Despite the release notes for this version saying the interest list bug(s) were addressed, I still don't see any improvements in animated objects being rendered correctly. I'm referring specifically to BUG-1779 (although not filed be me) As far as I'm aware, this is affecting 100% of every animated object in SL. I'm sure others along with me have spent an awful lot of time and energy scripting/animating things, and it's a real shame that SL looks so bad now. I am embarrassed to show our Meeroos to outside parties when the prims break apart over the place. This bug has been out there for months now, and should never have made it to the live grid, please address ASAP. -Tiger

Please make sure this code uses the position of my camera and not my avatar. It's frustrating when using a 3D mouse and you detach your camera and try to cam around, but none of it will rezz in because it's too far from your AV but is immediately in your camera view. TY!

Great. Now there is no breedable category that applies for Meeroos.

For what it's worth, Meeroos has had no contact with LL over this, we didn't ask for this and they did this on their own. I'm guessing it was just a byproduct of the fact that our products have dominated the top of the sales charts for a year now. -Tiger

I found another instance of a non backwards compatible change to llDeleteSubString() https://jira.secondlife.com/browse/SCR-306 -Tiger

FPS is not the same as lag, although people often use them interchangably which leads to tons of confusion. in the past, there were various bugs that caused your client to choke if you set the bandwidth too high. i believe this also just recently occurred again when the HTTP texture fetching was first added. what torley is saying is that these issues have all been resolved and there is no reason to cap your bandwidth setting any longer - unless you're sharing your wire with another user or you don't have an unlimited data plan. lance's "advice" is outdated and telling people to still do this is counter-productive. if you set it to max and experience a problem, a new JIRA needs to be opened for it.