Tofu loves us, too!

Linux Users Love Tofu Linden!

Yes, every Linux-using Resident of Second Life is now brimming over with love and affection for Tofu Linden, the Linux client developer for Linden Lab!

Today marks the first time the Linux client has had any sort of file upload/download capacity! Right now it's pretty rough around the edges, as there is still no file browser/picker, but it works! (Just rename the image to upload.tga and place it in your SecondLife/your_name/ folder, then use the upload menu item.) Tofu tells us that the file picker is in the works, which is also very nifty!

Since the last I posted about the Linux client, much progress has taken place, apparently due to the efforts of our hero, Tofu Linden! Audio playback was added August 29, including support for parcel audio streams, and Copy & Paste was added September 13—the Linux client is fast approaching the full feature set that the Windows and Mac users currently enjoy (plus, of course, the added "feature" of being able to log in to SL in Linux!).

I have found my own way to express my appreciation to Tofu: I created the adorable image above, featuring a penguin lovingly embracing a brick of tofu! (The image was created in Inkscape, by the way—a great piece of software if ever there was one!)

I then successfully uploaded the image, and a T-shirt featuring the image, to Second Life! Then I took a snapshot of me wearing the shirt (and standing in front of a waving flexi flag with the texture on it) and saved the snapshot to disk—you can see the proof here!

Since everybody should be able to show their love for Tofu Linden, I am giving out the shirt and textures* at my home/studio/gallery in Hallasan! (While you are there, say hi to Primmy!)

* A small word of caution, though: my gallery is in a Mature sim, and includes a few artistic nudes. You probably won't even see them if you go straight to those coordinates and don't poke around, but I thought I'd give you fair warning, in case you are logging in to SL while at work. In the Vatican. Where you share an office with his Holiness the Pope.

Section Radius

What I'm proposing here is fairly radical, in that it represents a very different method of building in Second Life. But, like everything I propose, it is not only possible, but feasible; I could devise the algorithm for it myself, with a bit of research as needed. This feature would require a more significant change to the data structure for prims than before, but the possibilities are astounding.

Throw away the Taper attribute for objects. It was great, but it will be made entirely obsolete by the feature I am proposing: section radii. Instead of describing the relative size of the beginning and end of the prim, as Taper does, Section Radius would describe the size of the prim at every point along its path.

NB: Every prim, with the exception of Sphere, can be represented as a two-dimensional shape such as a square or circle, which is extruded along a path to create a three-dimensional surface. For Box, Cylinder, and Prism, that path is a straight line into the third dimension; for Tube, Torus, and Ring, that path is a circle.

Take a look at my fancy diagram (to the right, click for a larger version). In (1), we are describing 5 different sections (solid lines), with another 4 values being interpolated between them (dotted lines). The gray line at the bottom represents the full span of the path from beginning to end.

In (2), we see a top-view of a cylinder with the sections that were defined in (1). Note that by smoothly interpolating between the defined sections, we can achieve a very smooth result without defining a large number of sections. In (3), we see a top-view of a torus with the same sections (or, at least, a passable representation of one; it's hand-drawn, not mathematically computed, so it may not be very accurate).

In the example, all the sections were equally spaced, but that need not be the case. Nor need there be a set number of sections. An arbitrary number of sections could be defined, with data storage increasing linearly with the number of sections defined (i.e. if we define twice as many sections, it takes twice as much space to store the data).

The advantage taper has is that it can be represented as two numbers between -1.0 and +1.0, one number for each axis X and Y. So, it doesn't take much bandwidth to transmit the Taper attribute of a prim. The disadvantage to taper is that its possibilities are decidedly limited: the shape's size can only be changed by a constant value as it is extruded along its path. It cannot, for example, start out small, become large in the middle, then small again at the end (making a surface resembling a lemon or American football).

With section radius, on the other hand, it would be possible to make such a shape, and a great many other shapes, with a single prim: vases, bullets, wavy french fries, bushy tails, barbells, and a great many non-PG items (which I will refrain from linking to). I haven't even started to mention all the possibilities with torus and kin!

There is, of course, a trade-off: section radius takes more information to store and transmit than taper. How much more?

One axis of taper requires, at most, a single floating point number (i.e. not an integer). If Linden Lab is clever, they don't even need that, because the granularity of each attribute is in the hundredths (I may be wrong, it may be thousandths), meaning there are only 200 (or 2000) possible values for one taper axis. That would take only 8 (or 11) bits to represent, versus a 32 bit float value.

Section radius, on the other hand, would require at least twice that, for every section defined. The more sections you define (i.e. the greater the detail in the section radius), the more data you have to store. I say "at least twice", because additional storage would be needed for storing the interpolation type (linear, smooth, step, and perhaps others). That might be stored once for the entire curve, or stored for each section. The latter would require more storage, but would be more flexible.

Section radius can, of course, be used to emulate the current Taper attribute (as well as the poorly-named Hole Size attributes for torus and kin, at no extra cost): one section each defined at the beginning and end, with linear interpolation between them. That's between four and six times as much data, for the same result.

When it's phrased like that, it seems like a bad idea. The same result, but a higher cost? No thanks!

But consider this: section radius would enable shapes which were impossible before. And if you were to try to approximate such a shape using existing building methods, it would require (n-1) separate prims, where n is the number of sections. Each prim, of course, has to store a great many redundant attributes (position, rotation, size, texture data, etc.) which would not be necessary for a single complex prim. And besides taking more storage space (not to mention parcel prim limit space), a many-prim solution would require a great deal of time to construct, and the results would be blocky and undesirable.

To put this in another light: section radius would enable complex and beautiful shapes to be made from a single prim, but would make creating a large number of simple shapes slightly less efficient.

It represents a shift from low-level, difficult-to-use tools to higher-level, easy-to-use tools. This is a shift that Second Life needs to make, in many areas, if it hopes to attract and retain the Doers and Makers that create the content of Second Life.

Prim's Amazing Journey

Today, a joyful reunion marks the end of an amazing true story of struggle, perseverance, and hope.

Prim, a purebreed plywood cube and the adored pet of Jacek Antonelli, was returned to his owner today after being missing for nearly two weeks. "I had almost given up hope of ever seeing my dear Primmy again," says Antonelli. "I'm so glad he's back. My life just wasn't the same without him."

Jacek Antonelli looks on as Prim stretches out for a much-needed nap outside their home in Hallasan.

Prim went missing on September 4 after he bounced away from the cottage where he resided in Hallasan (located along the south-east coast of the Most-Southern Continent). "Prim needed some excercise, so I set him on physical and gave him a script to set his llTargetOmega," tells Antonelli. "But I forgot to put on his leash before I closed the edit window, and he bounced up into the air, right over the house! I was so surprised."

Jacek Antonelli searched for hours to find Prim, but he was nowhere to be found. When Prim hadn't been returned after several days, Antonelli feared the worst: "I thought he must have bounced into the ocean and drowned, or gotten trapped in a sex club and asphyxiated."

The route Prim may have taken from Hallasan (south) to Chamisak (north).

(Artist's recreation)

But today, Antonelli logged on to find some good news: Resident Artlan Doctorow found Prim on his parcel in the Chamisak region, over 5.5 kilometers from Antonelli's cottage. Said Antonelli, "I was so surprised! I have no idea how he got all the way to Chamisak by himself."

Asked for comment, Doctorow beamed, "I'm just glad to have helped reunite the two. No one shoud have to go through the fear of losing a pet, especially one that cute."

Now Prim, exhausted but seemingly no worse for wear, purrs contentedly as Antonelli strokes him. "I'm absolutely amazed at how he managed to keep going so long, especially with the grid restarting to frequently. I never imagined he would make it, but I'm so happy that he's back."

Antonelli has a plan to keep Prim safe and sound from now on: "I'm going to be extra-careful when dealing with physical objects. I'm giving Prim a script so I can track him wherever he goes, too. You know, just in case he gets loose again."

When asked to comment on his journey, Prim replied: "Hello, Avatar!"

Defining ourselves

Mera offered a thought stream which got me thinking about deriving identity in activity—the idea that you are what you do. If you center yourself around doing N, who would you be if you stopped doing N?

(I am reminded here of the crises of people who, after working their entire lives at the same job, reach retirement and are at a loss as to how they should spend their time. The job had become their identity.)

This struck a chord with me because I do tend to derive a lot of my identity from what I do. In both Lives, I keep myself perpetually buried in projects, so that I will always have some activity to define myself in relation to.

I create, so I am a creator.
I teach, so I am a teacher.
I do, so I am.

Assuming, of course, that it is undesirable to be left in a state of doubt about one's identity, one should endeavor to prevent and cure such a state. Defining oneself in relation to only one or two things is risky; interests come and go, and the anchor that holds today may not tomorrow. A less risky option (and the one I am prone to do) is to grab hold of as many activities as possible, so that each matters less. If one fails, the others are there as backup. But there is a danger to this too, that of spreading oneself too thin, so that there is no meaningful benefit in anything.

No matter how we define ourselves in relation to other things and activities, there is always the very real possibility that we will lose or shift away from them.

But what if we define ourselves not in relation to something else, but as being ourselves, no matter how we change?

I am myself.
I look a certain way, act a certain way, and enjoy certain things.
In the future, I will look another way, act another way, and enjoy other things.
I will be myself then, too.

(We'll see.)

Build Window: Particles

The Build window should have a tab for controlling a prim's particle system.

That's simple enough, yeah? But I like to hear myself type, so I'll go into more detail.

Right now, the only way to activate on deactivate particle systems on a prim is through the use of a script which calls the llParticleSystem() function. That function takes a list of many pairs of parameters, each pair describing what is being defined (e.g. PSYS_PART_START_COLOR, i.e. particle starting color) and what that thing is being defined as (e.g. <1,0,0>, i.e. pure red). Constructing such a list is a tedious and frustrating task, but fortunately there are plenty of helpful scripts which can make it a bit more convenient. But even these helper scripts must call llParticleSystem() eventually, or there will be no particles.

You might think, based on the fact that a script is the only way to activate particles, that a prim must necessarily be scripted to have particles. This is not the case: the particle system is stored with the prim itself, not the script. Consider the fact that you can stop or even delete the script which activated the particles, and the particles will continue unabated.

To summarize, particle systems can exist without scripts, but there is currently no method aside from scripts to turn them on or off. As scripts are a tedious and ultimately unnecessary way of creating, changing, and deleting a particle system, it thus stands to reason that a more convenient method should be provided as a supplement to the scripted method. The Build window's Features tab (which currently houses the settings for flexible paths and light-emission) seems to be the natural place for this. But particles have a lot of settings, and the Features tab is already a bit crowded, so, at risk of over-complicating the user interface, I recommend branching the Features tab into sub-tabs, one of which would be dedicated to particle systems.

(In fact, particle systems have such a large number of settings that two or more tabs may have to be dedicated to particle systems. An obvious but imperfect division is between PSYS_PART_* and PSYS_SRC_* flags. A more natural but less clear-cut division is between settings which define the appearance of each particle, and those which define how they are emitted and behave as a system.)

So what would we see when we look at the Particle tab(s) of the Build window? It turns out that particle system settings are represented by a handful of distinct types of data, and the proper UI widgets to control each type are already used in other places in Second Life's interface, especially in the Build window itself:

type	widget	example
bitfield	checkboxes	General tab: permissions
option	radio buttons / drop-down menu	General tab: for sale options / General tab: When Left Clicked
float	numeric control	Object tab: Revolutions
integer	numeric control	Object tab: Hollow
vector	multiple numeric controls	Object tab: Position
color	color picker	Texture tab: Color
texture	texture picker	Texture tab: Texture
object/avatar	object picker	Report Abuse window

Some notes: in the script, colors are actually the vector data type, but it is non-intuitive to select a color the same way you set e.g. size in a graphical widget. Also, a script has the advantage in selecting a client asset texture by key, whereas the graphical widget can only select from inventory. And, the object picker in the Report Abuse window can only select the root prim of an object, which would be insufficient when targetting a child prim of an object.

In addition to all the particle system attributes, one more UI element would be needed: a checkbox for whether the particle system is currently active or not. But unchecking that box should not make in impossible to change the other settings, as happens with the flexi and light features (in fact, it should not do so in those cases either!). This might require a small change to the way particle systems work, as I am not certain if non-active particle systems are saved with prims. But even if the values for the attributes of a non-active particle system were stored only client side (so that if the client crashed, they would be lost), it would still be a useful feature.

I feel compelled here to anticipate several possible arguments against this feature:

1. "Newbies and griefers will be making ugly and annoying particle systems left and right! At least now, you have to be able to script to abuse particle systems!"

   To this I have two responses. Firstly, newbies and griefers already make ugly and annoying particle systems left and right, because scripted smoke bombs etc. are already easily available. Secondly, I don't think that imagined fear of abuse is a legitimate reason to prevent progress in ease of legitimate use.

2. "This change would put the makers of particle helper scripts out of business!"

   Adapt or perish. Should we have stuck with the telehub system, because point-to-point teleporting forced vehicle makers to change their business models? Perhaps we should get rid of the Object tab, and force all changes to a prim's shape be made through scripts, to increase demand in the prim-twisting script market?

   The fact is, scripts which control particle systems will still be useful; but they will have to go beyond the basics and have more complex behavior. Some examples include particle systems which gradually rotate through all the colors with time, or particle systems which detect nearby avatars, look up their favorite color in a database, and shoot particles of that color at them.

As I see it, there are plenty of reasons to add this feature and few reasons to reject this feature, little effort required to add it and much benefit from its addition. So get it done.

Procedural Textures

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

Textures take a long time to download, even on the asset servers' good days. The fact is, they use a lot more storage space and bandwidth than the actual prims they cover. While moderately-sized textures will weight in at several kilobytes, a prim takes perhaps a hundred bytes (the exact figure does not matter at this point, only its relative magnitude). How can a three-dimensional object take less space to store than a two-dimensional image?

The trick is in how prims are created. Every single prim is parametric' or procedurally generated. Second Life has functions (i.e., procedures) which take certain parameters (e.g., size, twist, taper) and generate the three-dimensional mesh of, say, a torus based on those parameters. So you don't have to transfer the 3D mesh, just the parameters; the mesh can be constructed by any client locally.

Textures, on the other hand, store pixel data for the image. Of course, image compression is used, and varying levels of detail are generated (so you only have to transfer the lowest level of detail needed), but it still requires much more data than a prim.

But, just like it is possible to procedurally generate 3D primitives, it is possible to generate 2D images, i.e. procedural textures. Procedural textures are common in 3D computer animation as an easy and storage-inexpensive way of creating high-detail textures. Most animation packages come with a number of texture procedures, and although the complexity of the procedures varies, they all have something in common: one procedure can generate a (seemingly) unlimited number of similar (but not identical) textures, based on the procedure's parameters. In addition to the "standard" texture procedures which come with the program, many packages allow knowledgeable users to create their own procedures.

(To avoid confusion, I will use the terms "texture procedures" or "procedures" to indicate blocks of code which are executed to generate a texture, and "textures" to indicate collection of image data, either from an uploaded image or the saved result of a texture procedure.)

Consider a "wood-grain" texture procedure . Some of the parameters it might have are: wood color, grain color, ring density, ring uniformity (how similar in thickness each ring is), ring noise (how distorted the ring shape is), and so on. Based on these parameters, the procedure would generate a texture. If you used slightly different parameter settings, the procedure would generate a slightly different texture.

If I Ruled the Grid, there would be several standard texture procedures written in a simple 'shading' language (affecting surface color only; control over how light affects the surface would be excessive for Second Life). Eventually, custom procedures could be written by users and distributed through Second Life as objects.

Some examples of standard texture procedures would be:

• multiple-octave Perlin noise (or similar)
• wood grain
• stone/marble
• text
  

Standard texture procedures, which would be distributed with the client software, present a much simpler problem because everyone will already have the procedures on their computer. Custom procedures complicate the system, because they must be distributed across the net to other clients, but the IP rights of the creator must be respected. (Distributing the procedure code, even in compiled form, increases the risk of it being decompiled or reverse engineered.)

To allow the creators of texture procedures control over the use of their creations (making possible a market for procedures), special permission settings would be required, as detailed below. Unless otherwise noted, each setting can be enabled or disabled separately for creator, owner, group, everyone, etc.:

• Modify: user can access and modify the procedure's source code.
• Run: user can set parameters and execute the procedure.
  
• Save: user can save the results of the procedure as a texture in his/her inventory.
  
• Save Permissions: saved results will be created with these mod/copy/transfer permissions.
  
• Download: user can download the compiled procedure to the client. If this is disabled, only cached server results can be seen.
  
• Copy, Transfer: as with other types of object.
  

Obviously, some uses of custom texture procedures do not take advantage of the reduced bandwidth use of procedural textures; instead, they are used as a convenient way for the creator to generate many customized textures, which can then be used separately. The ability of texture procedures to create many textures with minimal human effort is no less useful than its bandwidth conservation.

---

Comments from the original post:

Akela Talamasca said...

Thank you for explaining the whole 'pocedural' thing... since the advent of Spore, there's been a lot of talk about 'procedurally generated animation' and the like, and I've never understood what it meant, and why it was able to provide suce small file sizes. Now I know. And knowing's half the battle. *GI Joooooeeeeeeee!*

8/31/2006 9:47 AM

---

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:

default
{
state_entry()
{
  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):

default
{
state_entry()
{
  llListen(0,"",NULL_KEY,"");
}

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);
llOwnerSay(message);
llSetObjectName(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

---

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

---

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...

Mindgasmic!

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

---

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

---

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

---