Domitan Redenblack

Again, I am trying to get a list of all objects in a parcel, and their prim counts and owners. I still do not see a clear path to that list of Objects from the functions you have both mentioned. llGetObjectPrimCount requires the UUID of a prim in the object, but I only want to do each object once, not once for each prim in it. And a list of prims on a parcel will include many prims which are in the same object.... I am trying to make a clever little object that will list all the objects in a parcel, sorted by prim-count, so the owner of the parcel can see what they might delete or return first to free up prims in the parcel.

Rolig Loon wrote: ...then use llGetObjectDetails ... Does that have a way to get the prim count of an object? I don't see how... Background: - My parcel is prim-full, I want to get rid of prim-heaviest objects. Where the feck are they?

Is there a way to get a list of objects, with prim counts and owners in a parcel? Area search, parcel objects, etc, do not give a broken down list with prim counts.

I think I see what is going on: If I am far away from the light, it is no longer bright -- it fades as I walk away. Must be due to the way local lights work etc So when I click-edit it, it brightens up as if I were nearby Sound right?

I have some lamps in my home parcel, and when I click-edit them, they get Much brighter, untll I stop edit. Why?

Thanks, Dora and Notgoing...

What's the best way to ignore "old" touches on an object? For example, if I use llSleep( 30 ) after the first touch, then subsequent touches get queued...

Thanks, Void, and ... I'm not sure, thus the series of questions and comments here. 1. There will be three parties writing scripts, potentially for the "Hat" (not really a hat, sorry): - Me, the "Feather" maker, and the owner of the "Hat+Feather". The Feather-maker will provide his scripts and feather to me before sale. The Owner may write (or have written) scripts which are dropped into the root (as easily as possible to design, LSL write and drop-into Hat) NB: I wanted to allow the owner to switch feathers and keep the same hat, but clothing-inventory-copy-not-transfer means there could be too many different versions; so the Hat+Feather will be monolithic, joined before delivery by me. 2. The Main script in the Hat will provide a set of features, which both the Feather (maker) and the Owner (scripter) may wish to control (via Chat or Linked Messages), and the owner and public via Blue Dialog Menu sets (which are ONLY chat communicating) 3. In addition, the Main script will wish to report various states of the Hat to the other scripts. For example the Hat colour may change over time, and the Hat would announce the colour each time it changes into the comms chat channel, or via Linked Message. I am trying to come up with an elegant solution, which allows dialog Menus to control the features, while also allowing the Owner-scripter to write as simple LSL as possible, along with easy installation. Given that all functions will be available via Blue Dialog Menus, then chat is already being used, so it's not clear Linked Messages are needed. Perhaps for the hat-colour-change announcement; but that means a second way of communicating with the Feather-scripts and Owner-drop-in-scripts. I have never done this before in LSL, and LSL and SL have strange limitations that prevent a "standard approach", so I do appreciate all the help I receive here - all very useful to me for (a) learning and (b) solving. Thanks!

Okay, I have reconsidered. Here is the big problem: Menus. They only speak into chat channel, period. And I need to use them, which was probably not made clear here, sorry. If I have a total of 8 or 9 sets of menus, plus a Master top-level menu, with a total of perhaps 30-40 "chatted commands", then WHY use Linked Messages? Seems like a crazy idea to just convert the chatted menu results back into Linked Messages, when they can be heard by all. Am I missing something? Are there ways to have Menus other than having them speak into chat channels?

Darrius Gothly wrote: Always keep in mind that other scripts will "hear" what you "Say" as well, so it will result in a lot of extra (and in most cases wasteful) script execution time. Very true, thanks. Hmmm.... Maybe a front end that listens for chat-based commands from those nearby... and in a unique channel for the object. Let me go back to the drawing board for a while. Whatever I do, I want this to be easy for LSL-beginners to drop a script into the root (via the owner) to extend functionality.

Kaluura Boa wrote: ... What you will notice is that an object cannot hear itself... as said in the wiki... Actually, it says "prim" not object: ---> A prim cannot hear itself, to prevent problems with recursion. :matte-motes-big-grin-wink:

Hello all, thanks for your previous support on comminicating with other scripts in the root prim. Since I want to use channel-listen (due to avatar local chat control of scripts & features as well), I think this might be a good solution: 1. Each command_with_args will be whispered into the <key-based> chat channel and can be heard by all prims, except root prim. This means that any linked objects will also hear the commands as well. The <key-based> channel number is based on "0x7" + first 5-7 chars (etc) of UUID of object. Basic problem solved. 2. I can also create a HUD eventually so that "authorized" avatars can speak to the scripts without typing the long chat channel ID. When this is ready, then a list of authorized avatars might be kept somewhere etc. 3a. I will have a second prim pre-linked to the root which has an "echo function" to repeat each command_with_args back to the root prim via the <key-based> chat channel. 3b. This could be done with llMessageLinked(ROOT_PRIM, etc) or with llRegionSayTo(root_key, etc), yes? 3c. Echo-prim would not repeat commands coming from other avatars, only from the root prim to prevent ugly loops. Comments?

Thinkerer Melville wrote: You can make a poster that displays a web page. You can update the web page anytime you want. You can make the poster wearable, so the person can read it without rez rights. I have such posters out on Cookie (a sim) You can get free copies there in the welcome kit. Here is post about this: Posterize your blogs in Second Life http://virtualoutworlding.blogspot.com/2011/04/posterize-your-blogs-in-second-life.html TKR Very cool, Thinkerer

Can a web server deliver a Notecard to a resident? How is this done? Can Marketplace deliver a notecard which is updated via the internet every day? ty

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 He says in that thread: 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.

Does anyone know the minimum and "recommended" CPU & GPU requirements for proper display of up coming Meshes (Viewer 2, Firestorm) ? I have been using Passmark CPU and GPU benchmarks here: CPU - http://www.cpubenchmark.net/cpu_list.php GPU - http://www.videocardbenchmark.net/gpu_list.php Admittedly, these are intimately linked with the rest of your system, but can be good "baseline" indicators of resources available to the viewer. Does LL or anyone have any idea how many residents will refuse to buy new PCs (or Macs) to handle this, and will simply abandon SL ? Admittedly, my own ancedotal evidence shows a significant number (perhaps 20-25%) do not have "enough system" to run well now, much less in Firestorm or Viewer 2.

I checked this and not_at_rot is not triggered at all until you tilt the object.

No, it is generally static, only tilted or moved during initial placement.

Innula Zenovka wrote: I've always been a worried about when to use no_at_target events because, presumably, they're firing constantly until I reach my target, so it's a bit like using a very fast timer -- not really a good idea over extended periods except when absolutely necessary. Or am I being over-cautious because I've misunderstood? Since we start out At The Target, presumably not_at_rot_target will not fire until the disc is tilted. Then it will only fire until the target stops moving, which I assume will be pretty quick. Yes?

Excellent! Works a treat! Question though: When I edit-tilt my disc, it stops spinning until edit done... If I edit the other disc I have, it continues to spin even while I edit-tilt etc. Why is that? integer giRotationStart;default { on_rez ( integer start_param ){ giRotationStart = llRotTarget( llGetRot(), 0.05); } not_at_rot_target( ) { llRotTargetRemove( giRotationStart ); llTargetOmega( <0.0, 0.0,1.0> * llGetRot( ), 1.0, 1.0 ); giRotationStart = llRotTarget( llGetRot( ), 0.05); } }

Void Singer wrote: you can cheat and set a rotation target of the current rotation, and the not_at_target event will catch rotation changes... at which point you would cancel the old target, set a new one, and run your target omega code again Clever! I assume you mean not_at_rot_target and does this work if you start at the rot_target then leave it? Is the test not turned off upon current_rot == target_rot ? Is it possible to set a rot_target for only two axes?

Dora Gustafson wrote: Rolig Loon wrote: Yeah, you must have done something odd. I use that trick all the time to center hover text on message boards. It works because hover text is always set to hover on the +Z axis above the prim's center. So if +Z points out toward you, "above" does too. You forgot to mention that the Z-axis must be minimized (z=0.01m) The the text position, the height, is a function of the z-dimension AHA! LOL, thanks Dora. That is why I was banging my head today Got it now

Dora Gustafson wrote: There are two events: moving_start() and moving_end(), but none for rotation (I wonder why I keep on looking up functions for other people) :smileyindifferent: Here are all the available events listed. I have found moving_start and moving_end to be very unreliable. Have you? If I don't use those, should I use a timer to fix the llTargetOmega repeatedly? That seems kind of laggy-inducing.

Dora Gustafson wrote: State entry is only called once, when the script is first entered. To update the rotation axis you have to call your function at regular intervals Ohhhh! I did not see anything about that in the Wiki, thanks! Is there a reliable event to tell if the disc has been moved?

Yes, Darkie, I read the Wiki, but must be missing something... I have two spinning discs which rotate using llTargetOmega( ) One of them can be moved around and tilted, and it still rotates like a spinning disc. My disc spins nicely, until you edit-rotate it, then it wobble-spins all over the place. default { state_entry() { llTargetOmega( <0.0,0.0,1.0> * llGetLocalRot( ), 2.0, 1.0); } } I tried both llGetRot and llGetLocalRot - makes no diff. Am I missing something?