Sayrah Parx

We need someone to reopen https://jira.secondlife.com/browse/SVC-7170 . Please read my comments there before deciding against it.

Thanks, the physics changes and the new prim scale limit still work great now that it's on the main channel. I'm probably going to wait until a 1.x interface viewer like Singularity has mesh support before I do anything with mesh, unless the Snowglobe project is resumed. Something I've been wondering about after the new prim scale limit is if the maximum distance for llRezObject and LlRezAtRoot could be standardized somehow. It would be nice if the limit was always the same no matter what, so those functions could always be used predictably. Hopefully something relatively sane that should still cover most uses, like 48 or 64 meters.

Maestro Linden wrote: Sayrah Parx wrote: Thanks, the permissions fix works well and there are some great new script features. llSetMemoryLimit() appears to work as far as llGetFreeMemory() and llGetUsedMemory() are concerned, which should help a lot with objects that have many small scripts. I've heard that OBJECT_SCRIPT_MEMORY with llGetObjectDetails() is still supposed to return 65536 at this time, as well as the memory count in Viewer 2, for any mono script. Do you know if setting a lower memory limit actually lowers the amount reserved on the server, even though the reporting tools don't see any difference? Using llSetMemoryLimit() to lower your script's memory footprint also lowers the amount of memory reported by OBJECT_SCRIPT_MEMORY and the 'script info' interface. The lower limits are also enforced - if you have a small script and set its memory limit to be slightly more the current memory usage, then e.g. allocate a large string, the script will hit a stack/heap collision, even if total memory usage is less than 64kB. Thanks, I tested OBJECT_SCRIPT_MEMORY again with the same test objects I made before and this time it reflected the lower limit I had set. I must have used the wrong UUID before. It will be great to set lower limits once it's on the main channel, thanks for adding it.

Is it more efficient to have something like this: state_entry() { llListen(12345, "Object 1", "", ""); llListen(12345, "Object 2", "", ""); llListen(12345, "Object 3", "", ""); } listen(integer channel, string name, key id, string message) { do_something(); } Instead of something like this: state_entry() { llListen(12345, "", "", ""); } listen(integer channel, string name, key id, string message) { if ((name == "Object 1") || (name == "Object 2") || (name == "Object 3")) { do_something(); } } Or is it always better to have fewer listens, even when the listens are narrowly defined?

Thanks, the permissions fix works well and there are some great new script features. llSetMemoryLimit() appears to work as far as llGetFreeMemory() and llGetUsedMemory() are concerned, which should help a lot with objects that have many small scripts. I've heard that OBJECT_SCRIPT_MEMORY with llGetObjectDetails() is still supposed to return 65536 at this time, as well as the memory count in Viewer 2, for any mono script. Do you know if setting a lower memory limit actually lowers the amount reserved on the server, even though the reporting tools don't see any difference?

Thanks, but still need the pending fix for https://jira.secondlife.com/browse/SVC-7104

Is there a way to report inappropriate conduct or actions by a Linden for their superiors to review, or does Linden Lab have no way to ensure that employees are accountable for their actions? Is it possible to contact any kind of personnel supervisor? Edit 2011-08-26: I'm wondering if there are any standard business channels, rather than if it's possible to file an abuse report on an employee, although it's nice to know that they won't ban you for AR'ing an employee. I'm wondering if there is any kind of organizational or management structure.

Still no fix for https://jira.secondlife.com/browse/SVC-7104

Uh Lindens, you have said before that you weren't able to make changes to the JIRA software when we needed it to be more tailored to SL. You said that you were going to always use the standard JIRA software and that if we wanted new features for it we needed to request them on the JIRA software company's JIRA. But I guess you can always make exceptions when it comes to finding new ways to ignore residents.

AzaliaTsutsuji Bosatsu says: I have the snowglobe viewer version 1.42 and it still will not let me add groups past 25 limit, so i am just guessing that there is no 42 group raise for the snowglobe viewer since there is no information on it what so ever, only info on phoenix and the newest version of secondlife. Is a shame would be lovely for snowglobe to have such a raise in group space since snowglobe is the most stable viewer. It says "25 maximum" but it will let you add more, unless it's working differently on your computer for some reason.

how would i get this for snowglobe viewer? It lets you have up to 42 in Snowglobe 1.42, even though it says the limit is 25.

42 groups works in Snowglobe 1.42!

Working on things is not a problem in Viewer 2 if you do it in a vacuum. Try working on a real project when you have to respond to people in local chat and IMs at the same time. I've been able to do that well enough with the 1.x interface and I'm not able to manage things nearly as well with the Viewer 2 interface. Please try to not assume that people are stupid or lazy just because they have different needs than you. I've tried Viewer 2 and I really want to be able to use the new layer and other things in a viewer that I can actually use to work on things. For something that's supposed to be based on facebook, it doesn't seem to take social needs into consideration at all. So I have to wait for a Viewer 2 that allows me to keep up with and participate in local and IM converations while I'm working on something.

We still need the 1.x interface to be an option, and to be able to easily create alternative color schemes. Also, do the beta releases still delete your chat logs when you uninstall?

Thank you so much, that worked perfectly! It will save me many headaches in the future I'm sure. I'm also going to try the style sheets from your signature to see if they make the pages here actually fit within my screen at 1024 x 768.

Is there any way to disable the alt + enter shortcut which switches between full screen and windowed mode? I use Snowglobe 1.32 in windowed mode and accidentally switch to full screen when I'm camming around while I'm chatting, which is much more of a hassle than it sounds like.  It takes 15-20 seconds to switch to full screen, which I would have to go into preferences to make usable, and then about another 15-20 seconds to switch back.  So not only is it annoying, it's almost a minute of me standing there idle while people think I'm AFK at best or ignoring them at worst.