Sunday, August 20, 2006

Ambiguous Object Chat

This post appeared originally on the old blog. The original comments attached to the post are listed at the bottom. -J 09/03/06

Consider the following LSL script:

llSay(0,"Hello, Avatar!");
llOwnerSay("Hello, Avatar!");
// edit: fixed erroneous argument in previous line. Thanks MP!
llInstantMessage(llGetOwner(),"Hello, Avatar!");
Drop that script into a prim and run it. Three lines of chat will appear for the owner:
Object: Hello, Avatar!
Object: Hello, Avatar!
Object: Hello, Avatar!
Three forms of chat available to scripted objects show up exactly the same! (The other two, shout and whisper, can be distinguished from all others.) But of these three forms of chat, only one can be heard by other people.

This issue comes up with scripted objects which use chat to report something to the owner. Sometimes these scripts use llSay when they should instead use llOwnerSay. (If your script does this, it is a naughty script that should be publicly flogged. I'm looking at you, "MultiGadget by Timeless Prototype"! For shame!) Being the considerate person that I am, I do not want to use an object which will spam everyone around me, but I cannot determine at a glance which method of communication the object is using.

So, If I Ruled the Grid, every form of visible object communication would be easily distinguishable from every other form, at a glance. The results of the script would show up as something like this:
Object: Hello, Avatar!
[Own] Object: Hello, Avatar!
[IM] Object: Hello, Avatar!
Not only would each form have different text boilerplate, but they would use different colors (which could be changed in your preferences, of course). The Grid would be a much less ambiguous place to live in, and that's a good thing.

Since I do not yet rule the Grid, I will point out for the benefit of my readers that you can tell if an object is spamming the general chat channel by using another object which has been scripted to repeat to you everything which is said on channel 0. Here is a script that should do the job (pending actual testing in SL):


listen( integer channel, string name, key id, string message )
llOwnerSay( name + " said: " + message );

To my knowledge, it remains impossible by any means (short of packet sniffing, which may or may not violate the Terms of Service) to tell the difference between llOwnerSay and sending an instant message to the owner.

Comments from the original post:
Timeless Prototype said...

The Multi Gadget advert can be disabled by its owner by saying 'cmd|advert|off'. That is to say it is the choice of the owner. Everything else is an IM or OwnerSay, except for the "key getter" feature which is deliberately a whisper because you might be getting keys for a friend to use.

I like your idea of prefixing what is said with [Own] or [IM]. Here's how that can be achieved by your LSL script:

myOwnerSay(string message)
string preserveName = llGetObjectName();
llSetObjectName("[Owner] " + preserveName);

8/21/2006 5:28 PM

Erbo Evans said...

I know I'll definitely turn that off on my copy of the MG...I just wonder if the setting "sticks" when the MG is detached and reattached (which is basically every time I change outfits). Perhaps I'll need to make a gesture that issues that command to the MG that I can use whenever needed.

8/24/2006 11:18 AM

Mera Pixel said...

You already know this, but llOwnerSay doesn't take a channel as the first example shows.

*waves to timeless*

8/25/2006 6:12 PM

Saturday, August 19, 2006

Missing Linux Client Features

There is an alpha (testing) version of the Second Life Client on Linux. And I appreciate it. I wouldn't be a part of Second Life if it had not been available. It has let me participate in a thriving community, build beautiful objects, and write useful scripts.

But it's missing some important features which put a damper on my creative ability:

  • Image, sound, and animation uploads from file.
  • Texture downloads.
  • Snapshot to disk or postcard. (Upload snapshot works fine.)
  • Text copy & paste.
  • Audio.
  • Streaming media playback.
The man behind the port is none other than Ryan C. Gordon a.k.a. Icculus a.k.a Icculus Linden, cross-platform porter extraordinaire. Last I heard of his ongoing SL work, he was working on switching out the FMod sound engine for OpenAL, which will eventually lead to audio playback for Residents running the Linux client alpha, as well as saving Linden Lab a bit of cash on library licensing fees.

That's great, but as a builder, designer, graphic artist and scripter, I would flag image uploads/downloads and text copy/paste as highest-priority items. But until we get them, there's always WINE to tide us over.

Comments from the original post:
Erbo Evans said...

I can't even use the Linux client because my video drivers for X aren't up to snuff...the Radeon accelerated driver seems to lock X hard, requiring a reset to regain control of the system. The VESA drivers work, but they're so slow I can see screen repaints even on a 2D desktop...

Oh well, that's what dual-boot is for. :-)

8/24/2006 11:20 AM

Friday, August 18, 2006

Object Clones

This post appeared originally on the old blog. The original comments attached to the post are listed at the bottom. -J 09/03/06

Suppose for a moment that you are a builder of detailed houses within Second Life. In a typical house, you might have ten window fixtures, eight decorative columns, four doors, and two statues in the garden. Each of these items is identical to the others of its type, and is constructed of, perhaps, ten prims each, with the exception of the statues which are 100 prims each.

You've just spent 420 prims of your parcel budget to make twenty-four objects, and we haven't even added furniture! That's 420 prims which must be saved to the sim, and 420 prims which must be sent to every Second Life client which wants to view your magnificent houses.

What a waste, when each item is exactly the same as the others of its type, with only a different position, rotation, and possibly scale!

With object clones, which I am herein proposing, you could build the exact same house, but the above-mentioned 420-prim figure would be reduced to a mere 130 prims.

At this point, some of you will think I have gone insane, but the clever among you will have deduced how this could be possible and are now bubbling over with glee at the prospect. For the benefit of those who don't yet see it, I will explain.

An "object clone" would be a special object which has no prims of its own; instead, it inherits prims from the original object. This means that instead of storing the details of ten window fixtures, you store the details of one window fixture, and then create nine clones, saying, "These nine objects are constructed exactly like the first one."

From a technical perspective, object clones are a simple form of lossless data compression. Rather than storing n identical sets of data, we store one set and n-1 additional references to that set. The compression rate becomes more dramatic as the number of duplicates increases. (I think object clones would constitute a type of dictionary coding, but I may be wrong on that.)

Because a clone only has to store a reference (the UUID of the original) and a transformation matrix (position, rotation, and scale), it takes considerably less data storage space than even a single prim (which must also store such things as texture information and prim parameters).

But, even if Linden Lab counted each reference as equivalent to one prim for the purposes of parcel limits, we could still reduce our example of 420 prims to 130 prims + 20 clones = 150 'prims'.

Clearly, this feature would be of incredible importance to builders of all types! Frankly, it is such a simple concept with such extraordinarily far-reaching benefit that I find it hard to believe that Linden Lab hasn't already thought to implement it.

I have in mind several extensions to this concept which would further revolutionize the way we build in Second Life, but this post is already lengthy, so I will save them for another day.

Comments from the original post:
Alexander Lapointe said...


Wow, what a wonderful idea! I'm not a regular builder at the moment, but even with the making of Trav Doll/Trav Hat this would have been useful and would have cut down the prims to 8 from 11, which isn't that big of a difference, but still....

Plus, it would be nice for owners of small parcels with low prim limits, *cough* *cough*, by allowing for the little extras that make home-owning wonderful. Or the possiblity of having a house and a skybox that one could use.

8/24/2006 8:48 PM

Thursday, August 17, 2006

Flexible prim scale adjustment

This post appeared originally on the old blog. The original comments attached to the post are listed at the bottom. -J 09/03/06

When it comes to flexible prims, size does matter. A small prim just won't bend as much as a larger prim with the same flex settings. So if you want your lop-eared pet rabbit's ears to lop just the right way, you may have to scale him up to 5 meters on a side!

If I ruled the Grid, flex would be independent of size. Depending on how Linden Lab has implemented flexible paths, this would likely involve subdividing the path into the same number of parts when it is big as when it is small—that is, a number of subdivisions per path, not per meter of the path's length.

Since flexible prims have already been implemented, and that change would "break" a huge number of existing objects (not to mention cause plenty of embarrassment for flexi-skirt users who go without the luxury of "glitch pants"), Linden Lab could instead add a new attribute to control the scale used for subdividing the path. The default setting would be equivalent to the current scale, so that existing flexible prims would not behave differently.

Comments from the original post:
Reina Quine said...

Go ahead and break 'em! Serves those hussies right for not wearing glitch pants!

8/17/2006 7:34 AM

Tuesday, August 15, 2006

Instructors Group Chatter

This post appeared originally on the old blog. The original comments attached to the post are listed at the bottom. -J 09/03/06

Yesterday evening before logging off, I was invited to the Instructors group. Today, I encountered my first example of chatter in the Instructor group IM channel. Someone couldn't figure out a scripting-related issue for his own project, and so decided to ask in the Instructors channel.

Do not do this. This is wrong.

The Instructors channel is for Instructors to discuss issues related to teaching in Second Life. It is not a scripting helpline, nor a basic building workshop, nor a gossip hub. There are other groups for all those things. Use them.

When I applied for the Instructors program, I was fully aware that there would be stupid chatter. I had heard my Instructor friends complaining about it, and seen forum threads like the one linked above. I knew exactly what I was getting into.

And I am going to fight it.

Our script-nescient friend got a few replies from other instructors. If it had ended there, or perhaps moved to a private IM session with someone who was willing to help him, I would have let it go. After a minute or so of back-and-forth petty chatter between two instructors, I (politely) suggested that they continue the conversation in private IM or another, more on-topic channel. They responded that I could just close the IM window if I didn't want to hear it. One even drew me a helpful ASCII diagram with an arrow pointing towards the Close button.

Charming, but they missed the point.

If you were to come to a Real-Life meeting of baked goods enthusiasts and start blathering about how much you love kittens, you would be asked to leave. Even if some of the people at the meeting also liked kittens, it is not the proper channel for discussion of the merits of our furry friends. The people there came to talk about baked goods. If they wanted to talk about kittens, they would have gone to a meeting of kittens enthusiasts. You would be wasting everybody's time, and hindering their ability to do what they came there to do.

There are a lot of helpful and knowledgeable people in the Instructors group. Indeed, Instructors, by their nature, tend to be helpful and knowledgeable people. If you have a question, chances are one of the many Instructors will be able and willing to answer it. But if you ask the Instructors group a question that is unrelated to the topic of teaching in Second Life, you are spitting on the proper purpose of the channel, and wasting the time of everyone who upholds that proper purpose.

But this site isn't called I Like to Whine Without Offering Solutions, it's called If I Ruled The Grid! Time for some proposed action.

  1. Linden Labs should decouple the Instructors group from the Instructor benefits. Some people want to teach without being constantly exposed to useless chatter.

  2. Linden Labs should clearly state the purpose of the Instructors group in the group charter, and deal with abuses of the group channel. Chatter is a serious drain of resources, and should result in a warning on the first offense, and removal from the group on the second offense.

  3. Instructors should refuse to answer off-topic questions asked in the group.

  4. If you do feel compelled to answer it, answer it in private IM with the invidual, then tell him not to ask in the group again. For the purposes of signalling to other Instructors that you are handling the question, it is acceptable to make a brief reply to the group first.
I can't say I expect either #1 or #2 to happen. Linden Labs has demonstrated that it is not concerned whether it alienates the dedicated individuals who shape the Grid and make our Second Lives enjoyable.

[Edit: Just as there is no "I" in team, there is no "S" in Linden Lab. Many thanks to Mera for pointing this out. -J 08/17/06]

Comments from the original post:
Mera Pixel said...

Wow. Come out of the corner swinging, why don't you. :) Instructors used to be, are at times are, the most quiet of the volunteer groups. It's been getting gradually worse lately.

And to be nit-picky, it's Linden Lab. :)

Congrats on the site...and thanks for the linkage, however incestual it may be.

8/16/2006 5:49 PM