Domitan Redenblack

Ah, thank you Rolig. New issue created in scripting https://jira.secondlife.com/browse/SCR-157

Feature Request for search -- Search Places {Region Name} which would list all parcels/places in that region. I have searched the JIRA and found 100s of results to: seach region name None of them are relevant. Looking further, I can find "Bug Report JIRA" but I have a feature request, not a bug report, and I don't see where to do that. Where else should I make my request, please.

I have searched the JIRA and found 100s of non-related items to: seach region name None of them are relevant. Looking further, I can find "Bug Report JIRA" but I have a feature request, not a bug report, and I don't see where to do that. God forbid someone give me a URL, thank you very much.

That link points to a page which has links to the place in the Old Closed forums, which then dump you into top level new forums. Which forum is best to suggest this?

Cerise, thanks. Did not add because did not want to step on toes of admin there. But... I have added "Menu (Dialog)" and "Dialog" now :matte-motes-sunglasses-1: -- Great for newbies and forgetful minds... If these are not "stylistically approved", or could be improved, I would appreciate feedback or correction, thanks.

Rufus Darkfold wrote: You would need to execute llGetParcelInfo 4096 times to get all the parcel names and rough boundaries for a single sim. Getting the owner name is a dataserver request unless it is in the sim's cache. Instead, my navigator HUD scans ahead in the direction I am looking (how far ahead depends on how fast I am moving), and it will also check anywhere in the same sim that I click. It displays parcel name, prim count/max, banlines, rez zones, damage enabled, nofly, and the owner name if the sim has it in cache or if it is "Governor Linden". Clicks also generate slurls in chat history which can be clicked for more information or to teleport. It can also check in other sims if those sims have a navigator beacon. Dots appear on the map in either case, green for OK, red for banlined or full parcel, yellow for no information. Contact me in-world if you would like one. It is free, full-perm, and open-source. Very cool HUD, Rufus! I think inclusion of the region name automatically in search would be pretty simple. Remind me please where I can request this, thanks.

Pardon me, but searching in-world for places is a LOT more complex that this, so why can't you search on region name? This sounds LL-intentional to me, sorry.

from Braise Bashly, 07-29-2011 08:06 PM http://secondlife.lithium.com/t5/Second-Life-Viewer/Apple-OS-X-Lion-Compatibility/m-p/994507 I tested the new MacBook Air (10.5", 1.8 GHz i7, 4 Gb RAM, Intel Graphics 3000, Lion) with the latest (July 28, 2011) versions of the Second Life, Phoenix, and Firestorm Beta viewers. FPS was recorded at each of two altitudes (25M and 2700M) using each of the four Render Quality Settings (Low, Mid, High, Ultra) for each of the three viewers. Default settings were used with one exception: the draw distance was altered to 200M for each Render Quality Setting. The Second Life viewer and FireStorm Beta had similar results (25M altitude Low:28 fps Ultra:10 fps) (2700M altitude Low:58 fps Ultra:37 fps). The 25M altitude was a texture and script rich rendering challenge and the 2700M altitude was a sky build with many fewer textures and scripts. Subjectively all viewers performed well, rendering nice reflections in Ultra. I spent a few hours inLife using FireStorm Beta with varied activities, many teleports and sims and Firestorm performed perfectly. Bottom line. The new 2011 MacBook Air with OS X Lion performed perfectly with the three tested viewers.

from Braise Bashly, 07-29-2011 08:06 PM http://secondlife.lithium.com/t5/Second-Life-Viewer/Apple-OS-X-Lion-Compatibility/m-p/994507 I tested the new MacBook Air (10.5", 1.8 GHz i7, 4 Gb RAM, Intel Graphics 3000, Lion) with the latest (July 28, 2011) versions of the Second Life, Phoenix, and Firestorm Beta viewers. FPS was recorded at each of two altitudes (25M and 2700M) using each of the four Render Quality Settings (Low, Mid, High, Ultra) for each of the three viewers. Default settings were used with one exception: the draw distance was altered to 200M for each Render Quality Setting. The Second Life viewer and FireStorm Beta had similar results (25M altitude Low:28 fps Ultra:10 fps) (2700M altitude Low:58 fps Ultra:37 fps). The 25M altitude was a texture and script rich rendering challenge and the 2700M altitude was a sky build with many fewer textures and scripts. Subjectively all viewers performed well, rendering nice reflections in Ultra. I spent a few hours inLife using FireStorm Beta with varied activities, many teleports and sims and Firestorm performed perfectly. Bottom line. The new 2011 MacBook Air with OS X Lion performed perfectly with the three tested viewers.

from Braise Bashly, 07-29-2011 08:06 PM http://secondlife.lithium.com/t5/Second-Life-Viewer/Apple-OS-X-Lion-Compatibility/m-p/994507 I tested the new MacBook Air (10.5", 1.8 GHz i7, 4 Gb RAM, Intel Graphics 3000, Lion) with the latest (July 28, 2011) versions of the Second Life, Phoenix, and Firestorm Beta viewers. FPS was recorded at each of two altitudes (25M and 2700M) using each of the four Render Quality Settings (Low, Mid, High, Ultra) for each of the three viewers. Default settings were used with one exception: the draw distance was altered to 200M for each Render Quality Setting. The Second Life viewer and FireStorm Beta had similar results (25M altitude Low:28 fps Ultra:10 fps) (2700M altitude Low:58 fps Ultra:37 fps). The 25M altitude was a texture and script rich rendering challenge and the 2700M altitude was a sky build with many fewer textures and scripts. Subjectively all viewers performed well, rendering nice reflections in Ultra. I spent a few hours inLife using FireStorm Beta with varied activities, many teleports and sims and Firestorm performed perfectly. Bottom line. The new 2011 MacBook Air with OS X Lion performed perfectly with the three tested viewers.

Thanks. Interesting. Is there a reason that in world "place" search for a Region name does not return a list of parcels in that region? Is there a reason not to show these on the map? Does LL intentionally block this? Why?

What parcel names are in a region? Is there a way to determine this without jumping around each region? Would it be possible to write a bot which collects all parcel names for all of SL? *(except perhaps parcels which are banned) (Why? I am tired of looking at the Map Window and seeing blobs with no names or boundaries :matte-motes-nerdy:)

Yes, I am seeing the differences now. This is a very useful discussion for me. Lots of side-effects and gotchas that were unclear when I asked the question *(which is why I asked it this way). Thanks very much, both of you. Let me look closer at llMessageLinked( ) and see if I have more questions about it. °͜°

If you are thinking "menu dialogs" you will not get far. Thus I am here now. Courtesy and convenience, and consideration especially for newbies, dictates that an item "Menus" should be created. I think I will, unless that will get me burned at the stake.

Rolig Loon wrote: ...I'd suggest creating a two-prim object. Your script must contain this line in state_entry: gChannel = (integer)("0xF" + llGetSubString(llGetKey(),0,6)); and chat messages must be in the form llWhisper(gChannel, message). Then just be sure that your own script contains the same definition of gChannel and has an open listener tuned to it. .... ETA: Anything the user drops in the object will end up in the root prim (d'uh, forgot that), but you can move it as soon as it's dropped in. Just write: llGiveInventory(llGetLinkKey(prim),gThisScript); if (~llGetInventoryType(gThisScript)) { llRemoveInventory(gThisScript); }  where prim is the number of the child prim (2) and gThisScript is the name of the script someone just dropped in. Rolig, thanks. 1. This is a very cool solution, and yes, only the owner will be dropping stuff into the object. That fixes that problem, correct ? 2. I will need one channel for Root-chatting-to-#2-prim and a different channel for #2-chatting-to-Root-prim, yes? (e.g. gChannel - 1), or does the "can't chat to your own prim" automatically fix this? (I think it does...) 3. I will need a Changed( ) handler to recognize the owner drops the new script in, and then do the script move, correct ? Or is there another way? :matte-motes-sunglasses-1:

Certainly not obvious that Menu Dialogs are part of chat or communications, i.e. "if you know where to find it, you know where to find it" !

Darkie, sorry, but I feel very stupid and confused, and now paranoid here. Your replies seem very vague to my inexperienced mind; I am asking for advice on What experienced scripters would recommend, and how to go about setting up comms with a script which is dropped in by the owner of the object. 1. Can I use llMessageLinked if the drop-in script is in the same contents as the main object script? How? Do I need to detect "an addition" to the contents and then search the contents and then set up llMessageLinked( )? Is that a stupid way to do it? 2. Is it easier to chat to the drop-in script on channel -12345 (etc) and have the drop-in chat back on channel -54321 (etc) ? If two diff channels are used for send/receive, I do not see how that could cause recursion... 3. Some other method that newibes (me) would not notice? Thanks

Yes, thanks. I found it, but my comment was: It Should Appear on the Contents Page of the Wiki.

So if someone drops in a script into the main object contents, how should I talk to it and vice-versa? I want a third party script to be able to issue commands (on a channel?) to control functions in the main script of the object...

https://wiki.secondlife.com/wiki/LSL_Portal

Darkie Minotaur wrote: ...chat isn't an option since it is not heard. Even if the dropped-in script has a Local chat listener, or a channel listener?

I have an object which allows a script to be dropped into it's contents. Should I use llMessageLinked( ) to talk with it? Or a chat channel?

Void Singer wrote: on the overkill comment, I meant that if you know the pattern of data you will receive, then there's no reason to add type prefixes, since you can reconstruct the proper types without them. Yes, thanks, my interest was academic mostly.

yes if I were to do this, I would prefix each string coerced element with a letter (i, k, f, v, etc) to show the type, then strip that off before coercion this assumes non-complex strings, e.g. with embedded quotes etc

Ah yes, thanks Darkie. I assumed you would need something like that, but escaping the strings as well is a big plus.