Interface for the Editor Tool

This one is going to be a little bit long, I am afraid.  Once again, I am posting working notes.

The real challenge of the Building/Editor Tool is not the code.  llGetPrimitiveParams() and llSetPrimitiveParams are going to handle better than 90% of it. That’s not “hard”, just “tedious, lengthy, and requires careful organization.”  I’m good at tedious and lengthy, and I can get careful organization after a few tries.

The part that requires Creative Coding rather than assembling existing parts is the User Interface.

As is so often the case with these things, I am working my way through a compromise.  After all, this is something that will work entirely through chat channel commands, but it is a workaround for the lack of accessibility of the Edit tool in the Standard Viewer.  It’s worth noting that many Sighted, Abled-Bodied people look at that tool and run away and hide.  It’s rather intimidating!  Even so, that defines the “language” that everyone else uses.  If I require the users of this tool to speak a different language, it is going to be inherently discriminatory, placing needless barriers to communication and instruction.

Therefore, the internal help documents and the commands are going to be based off the tabs in the standard editor.  If you type “/7 General”, you will get a list of commands relating to the Name, Description, Owner, Creator, Permissions, Left-Click behavior, etc.  If you type /7 Object, you will get Locked, Physical, Temporary, Phantom, Position, Rotation, Size, Material, etc. If you type Features, you get Flexible Path and Light.  If you type Texture, you get access to the “faces” commands. If you type Content, you get something cool and amazing that I am sure to figure out before the first Beta-Tester gets ahold of it.

This way, if a person without any experience with my tool says to look for “Force X” under “Flexible Path” in “Features”, the process to get to that point in my Editor will be parallel.  There will be some extra commands, such as a command to set which face you are currently working on (0 through whatever, or All), a help command, and eventually other things relating to linking stuff together, but as far as possible, someone with the standard editor and someone with the Adaptive Editor will be speaking the same language.

This is not going to be “menu based”, though. While you can work through the “menus” until you find what you want, any command will always be available.  So if you know from the start that you want to change the plus X side of the Box to  Full Bright, you can type /7 face plusx and then /7 fullbright on.

I should note that /7 is an arbitrary channel.  I intend to allow for different channels so you can be working on more than one prim at a time.  I am also going to allow for collaboration: this is a feature that some people without disabilities may find to be of interest as well!  You’ll be able to either keep it owner-only or else open it up for others to edit.  I haven’t worked out all the details on that yet, of course.

In the end, this is going to be a bigger project than the Guide.

Here’s my working notes which are mutating slowly into a list of commands for this.

GENERAL
Name (string)
Description (string)
Creator (key)
Owner (key)
Group (key)
Permissions
“You can modify this object.”
Share with Group (boolean)  [Deed to Group Button]
Allow anyone to move (boolean)
Allow anyone to copy (boolean)
Show in search  (boolean) [Research this!  Can objects show up in search, or is this a legacy thing?]
For Sale (boolean) Price: L$ (integer)
Original/Copy/Contents
Next Owner Can
Modify (boolean)
Copy (boolean)
Transfer (boolean)
Left-click behavior
Touch/Grab, Sit, Buy, Pay, Open, Play Parcel Media, Open Parcel Media

OBJECT
Locked (boolean)
Physical(boolean)
Temp_on_rez (boolean)
Phantom (boolean)
Position (vector)
Size (vector) meters
Rotation (rotation) need to change to degrees.
Material
Type
Path Cut (vector, xy)
Hollow (float)
Hollow Shape (integer constant)
Twist Begin/End (vector, XY)
Taper (vector, XY)
Top Shear (vector, XY)
Slice (vector, XY)
Dimple (vector, XY)
Hole Size
Profile Cut
Radius
Revolutions
Sculpt Texture
Mirror
Inside-out
Stitching Type

FEATURES
Flexible

1. Softness
2. Gravity
3. Drag
4. Wind
5. Tension
6. ForceX
7. ForceY
8. ForceZ

Light

1. Color
2. Intensity
3. Radius
4. Falloff

TEXTURE
Texture [Let's differentiate this somehow, in an intuitive way, from the tab-title "Texture".]
Color
Transparency
Glow
Full Bright (Boolean)
Mapping (Texgen)
Shininess

1. None
2. Low
3. Medium
4. High

Bumpiness

• NONE      0      none: no bump map
• BRIGHT     1     brightness: generate from highlights
• DARK     2     darkness: generate from lowlights
• WOOD     3     woodgrain
• BARK     4     bark
• BRICKS     5     bricks
• CHECKER     6     checker
• CONCRETE     7     concrete
• TILE     8     crustytile
• STONE     9     cutstone: blocks
• DISKS     10     discs: packed circles
• GRAVEL     11     gravel
• BLOBS     12     petridish: blobby amoeba like shapes
• SIDING     13     siding
• LARGETILE     14     stonetile
• STUCCO     15     stucco
• SUCTION     16     suction: rings
• WEAVE     17     weave

Repeats per face

• Horizontal    [Flip]
• Vertical         [Flip]

Rotation (degrees)
Repeats Per Meter
Offset

• Horizontal
• Vertical

Align Media Texture Button

CONTENTS

Saving Face!

Yes, that title is a horrible pun. 

I am going to ask that you bear with me.  As I write this, I am working through the structure of the script that I have to write.

I have been playing with the llGetPrimitiveParams() function, and I have created a script that will tell you pretty much everything *except* the Face flags.  Face, you see, is not a simple concept for LSL.  Check out the Face List and you will see just how interesting this can be!  I can’t start making scripts that will permit Blind/VI users (and possibly those with other disabilities that inhibit use of the client’s editing tools) to create and manipulate objects until I am able to describe those objects with some degree of accuracy.  Clarity is another matter: the learning curve on this stuff is going to be steep, and we are going to have to find good teachers for it!

So, before we can describe the object, we have to know how many faces there are, and which ones they are. This is going to involve a fairly high degree of Artificial Intelligence for an LSL script: it’s going to have to analyze the prim that it is inside of and infer some things about how it looks.  Remember that a prim can have just 1 face (an unmodified sphere or sculpted prim), and as many as 9 faces (a heavily modified box or tube).

1. What type of Prim am I?  We’ve got 8 possibilities here.
2. How many sides (faces) do I have?  llGetNumberOfSides()
3. The following are in varying order and may or may not appear depending on the answer to #1
4. Am I hollow?
5. Is there a profile cut?
6. If there is a profile cut, have one or more faces disappeared as a result? Which ones?
7. If there a path cut?
8. If there is a path cut, have one or more faces disappeared as a result? Which ones?
9. Do I have dimples? (And do they make me look cute?)
10. Is the circular path broken for some reason besides a path cut? (Several conditions can create this.)
11. Now we should have all the faces in their proper order in a list, by name.

Then we go through by face number, pull the name we assigned to that face, and add whatever information the builder is looking for: texture, shininess, bumpiness, alpha, color, texgen, glow, or fullbright.

When looking at the object as a whole, it would probably be best to just put the information in a parallel list. That way if we wind up with a list where the values are all the same, we can just say “This applies to all sides.” when speaking of a parameter.  If everything is the same color value, there is no point in spamming the user with the same value for each face.

Figuring out how to present the information efficiently is a later challenge, though.  First I have to figure out how to get the information accurately and without *too* much script load.  Fun!

The good thing is, once I know how to get it all effectively, making a script to modify the parameters should be relatively easy.

Sic Transit Guide

It’s been a couple months since I posted here.  Real Life came along and gave us some hard hits, and we have had other things going on in SL as well.

As for the topic of this post: the Guide isn’t dead–yet.  Nor will it completely die for some time to come!  However, the people over at the Radegast Client Project have been doing an amazing job of making their product accessible.

In fact, it is possible (Dianna tells me) to read Scripts.  She says she can’t yet edit or create them, but she can read a script from her inventory.  This is coming very close to one of my Big Goals! There is a slogan among People With Disabilities that I firmly believe in: “Nothing About Us Without Us.”  I have always hoped to see my role as a Scripter for Blind and Visually Impaired people become at least somewhat deprecated.  I don’t feel that every Blind or VI user in SL should or even could become a competent Scripter, but the Community as a whole should have a chance to produce some coders who can bring their direct experiences to the task.

It’s an adage in SL as in many other such situations that, if you don’t like what’s already out there, learn LSL and go do your own thing!  The problem is that, for now, that’s not really an option for Dianna or others like her.  Oh, she could write a script, email it to me, and have me paste it into SL and compile it for her.  Think about the cycle of debugging, compiling, tweaking, and compiling again!  Doing it through someone else is just not very practical, and bound to create tensions.  Besides, I would either have to log in as her (which is OK between a husband and wife, but not necessarily for others!), or she would have to surrender ownership of her code to someone else.  LL looks at the name in the “Creator” field, after all.  Being able to open the editor, write or paste in her own stuff, and hit “compile” is just the way to go.  Once that happens, the Blind Community doesn’t have to try to cajole and convince the Sighted Scripters that what they need is what they want: they CAN do it themselves!

Freedom of the Press belongs to the guy who owns one.  Freedom of the Code belongs to the guy with a compiler.

 

But I digress.   With the advances we are seeing, Dianna and others are using the Guide less and less, though they keep it for some things.  A few have chosen not to switch to Radegast, which is their right!  It’s also one of the reasons why I made ScriptAble products Open-Source: others can pick it up and move it in whatever direction works best for them.

With Radegast moving along well, I intend to work more on things that are not so easily solved by making an accessible client.  I am working on an accessible sailboat, though I have to be careful of the license on that one, as I am using someone else’s code and the license is not exactly like what I use.  I am also working on my crazy building project idea.  More on that in the next post.

If you use the Guide and you would like to see a new feature, or if you find a bug?  I’M STILL HERE.   I haven’t gotten a single feature request or bug report in months, which tells me that people are either well-satisfied, or else they are moving to Radegast and don’t need it. But if somebody needs it, I’m not leaving you adrift!  Talk to me.

When Do I Get The Payout?: Coding To User Experience.

You walk into a casino and put some money in the Slot Machine.  You pull the handle.  Odds are, you aren’t going to get anything the first time.  Probably not the second, or the third.  But Casinos know that there is a window of opportunity for them: if you don’t see something line up in front of you, if you don’t hear the ring of coins or chips dropping into the till within a certain span of time, you are going to walk away.  They set the odds, therefore, such that within that window of opportunity you probably will get a payout of some amount.

Probably not the Jackpot.

More than likely, not even as much as you have put in.

Still, you have to get some measure of satisfaction and gratification from it, or eventually even the Gambling Addicts are going to walk away–or at least try a different game.  The level of payout required is determined, not via any intellectual mathematics, but through a sort of emotional calculus that varies person-to-person.

The same theory applies to developing technology for the End-User: if the User starts using your tech and doesn’t get some sense of satisfaction from it fairly quickly, they will decide it is not worth their valuable time.  They will view it as “broken”, and they will describe it as such to others.  Given that word-of-mouth is still the most potent form of advertising, this can make or break you.

Microsoft learned this the hard way with Windows Vista.  They thought that people not only would not, but could not go back to XP.  They did, in droves.  Apple recognized this when they released Snow Leopard: while Snow Leopard contains some important stuff for the future of Macs, it’s all under the hood.  The average user isn’t going to see much of a “payout”, so they priced it really low: $29.  To bring things in line with the topic of this blog, Linden Lab recognizes this basic fact about how people choose and adopt technology: they put a lot of effort (even if some of us don’t see it happening! Lack of payout, there) into resolving questions like these about Resident’s early experiences within Second Life.

Now add the challenges of Assistive Technology.  Most Software Development (sadly) assumes the hypothetical “Normal Person” as the audience.  This person doesn’t really exist, of course.  We are too diverse.  Perhaps we need to reconsider that whole concept, but that is a post for another time, and probably another blog.

My audience is almost never going to fit the “Normal Person” characteristics.  The End-User may not use their eyes.  They may not use–or even have!–hands.  They may have a high level of intelligence yet have difficulty communicating with me effectively due to dysfunction in one part of their brain.  They may have a disability “just like” someone else’s, and yet live their lives and deal with the world in a totally different way.  It is my job to create technology that will give them a “payout” in their first hour using it.  Sometimes, I even succeed.

I am NOT complaining!  I have been exposed to life in a call center for an ISP.  I have dealt with “Normal Person”, and I don’t ever want to go back.  I love these challenges!

How do I do it?  Sometimes, I have to just sit down with the person and talk about what their needs and expectations are.  This part of the process can sometimes take longer than the actual “programming”–nor is that a bad thing!  As I see it, spending an hour talking to a client and then 10 minutes writing what they need is a better use of my time than 10 minutes talking to them and an hour fixing things I didn’t get right on the first go.

Some things, I build in based on experience.  For instance, I have had scripters question why I have the Guide working on three channels: /2, /3, and /4.  It’s a matter of User Experience.  First, the people who use it are typically taught Orientation, Mobility, and Other Skills.  So, I divided it up like that.  /2 is Orientation.  who, what, where. There are refinements of each, but the basic stuff is found in those three commands.  Once you have mastered those? PAYOUT!  You have mastered a set of essential skills needed to navigate SL.  Then you can move on to /3, which involves Mobility (commands to move your avatar from point to point.)  After that, you can worry about stuff like clothes and profiles and other miscellany.

I give them two Payouts that can be reached with some effort, but significant reward.  Then I worry about the little stuff.

My first Transcriber Tool was a failure.  The scripts compiled, and they do wonderful things!  Nobody used them! The people doing transcription from VoiceChat to Text weren’t interested, and the consumers of their product didn’t seem to want it.  I made it too complicated.  I required too many actions from the Transcriptionist and from the Receiver of Transcription.  So, I tossed it out and went back to the KISS rule.

First, the person who wants/needs the service need do nothing but show up, just like Hearing folks and those who have no technical issues with Voice Chat do.   Second, the Transcriptionist (who has other things to do!) has to go through, at most, four steps to get their product to the clients:

1. Attach the Tool to their HUD
2. Set the name of the Tool to either “Voice” or the name of the speaker with a built-in command
3. Drop a notecard with the prepared remarks in the Tool.
4. Click the Tool in step with the speaker to send each line to local chat

OR

1. Attach the Tool to their HUD
2. Set the name of the Tool to either “Voice” or the name of the speaker with a built-in command
3. (If they are using an RLV-enhanced Viewer) set their viewer to divert anything they type in local chat to /1
4. Type the meaning-to-meaning (not word-for-word) text of the speech, adding /1 at the beginning if not using RLV.

This version got good reviews, and it is being used regularly.  The first time, I failed User Experience.  The second time, I managed to get it right.

The moral of this story?  IT Students should be sure to get a good Liberal Arts education.  OK, seriously: the code you write may look elegant, efficient, and useful–to another Scripter.  How does it look to the End-User? If they don’t start getting some coins in their till pretty quickly, they are going to stop pulling the handle, and you wasted a lot of time on a work of modern art.

Get to know your audience.

Rambling: Radegast, Building Tools, and the 1-Prim Database!

Well, before long the Guide may be somewhat deprecated.  Somewhat, I say!  I think there will be a need for spinoffs from it for some time to come.

Over in her blog, Dianna talks about her experiences with Radegast, a new SL Viewer in development that is working on being fully accessible for her.  There’s a few things yet to do, but already it replaces most of what my Guide can do, and it includes some things I cannot do, like give access to IMs, using the in-world economy, etc.  It’s also an all-in-one solution for client-side accessibility: viewer and speech in one package.  She’s pretty psyched about it!

And I am pretty darned happy with it, too.  I have always stated that most of this stuff should be considered no more than an ugly workaround, and I have advocated for a client-side solution from Day 1.

That doesn’t mean ScriptAble will be irrelevant!  Some people may prefer to use the other options.   For example, someone with Low Vision may well prefer a graphical Viewer with Speech as a complement.  Some things are going to be harder to implement with the viewer than with LSL.  And, the most important point of all: when we make these scripts and hand them out to people, we learn things.

I found the landowner tool to be more frustrating than fun, so I put it on the shelf for a little bit. I am going to get it into the shop, I just need to avoid the temptation to jump up and down on it with cast-iron boots.  Instead, I am tackling the beginnings of a challenge that has fascinated me since I picked up the LSL Hammer: Building In SL for the Blind. I really don’t know where this is going to lead us, but I know we aren’t going to learn anything, or make anything useful, unless we try.  I am starting with llGetPrimitiveParams and putting together a (relatively) simple script to let my Alpha-Tester (that’s Dianna) tell me how to better present the information.  I know the learning curve on this is going to be steep! We’re starting with one prim for now, and we’re going to just give information for the moment, not permit changes.  Once we have the feedback system working like we want, we can add in functions to shape and change this prim into…well, I don’t know what is going to come out of it!

Working with llGetPrimitiveParams inspired me to a bit of Mad Science. This really has nothing to do with Assistive Technology, it just shows what a complete Nerd Genius I am.

One of the complaints of the LSL Scripter is that it is nearly impossible to store information using an LSL script, unless you pipe if off-world to a URL that can receive it and return it at need.  (That gets ugly in its own way, from what I have seen.)

Then it hit me: if you are willing to get a little creative with how you encode your information, you have a Data Storage Device in your basic 1-prim box! It’s all numbers, after all…

Take PRIM_TYPE and PRIM_MATERIAL, and you have a 2-digit Octal numeral.  There are a maximum of nine different Faces on the basic Box, with the ability to store 2 booleans on each (PRIM_FULLBRIGHT and PRIM_TEXGEN). Discounting Temp_on_Rez, there are places to store 22 different boolean integers on one box.  Vectors and Rotation, Floats, Integers of varying ranges: a really enterprising Nerd LSL Scripter could encode a lot of information on one prim without having to worry about the ephemeral nature of script variables.

I don’t think I am going to implement this myself, but it would make for an interesting challenge: how much useful/usable information can you store in one Prim?

How to make Talvin scream

Want to ruin my day?

Say Dataserver

AHH!  I said “Dataserver“!

AHHHHH! I said “Dataserver” AGAIN!

Talvin glares balefully at the Lindens and stomps off to his Scripter’s Cave again.

2.0! Wiki. And the future

Been a while since I posted here!  But I have been busy!

Guide 2.0 went out. I haven’t gotten a single bug report back.  I hope that means people are using it and are happy.

The Wiki LIVES! http://ScriptAble.wikispaces.com/ Rather than posting code here, you can find it there. The formatting should be a little easier to read.

Interested in becoming an editor or contributor to the Wiki?  Got some Assistive Technology you are willing to license under the Creative Commons?  Talk to me, I’m all ears.  Yes, even if you think you have made something like what I made, but better. I’m open to the idea.  Room enough in there for both.  There are some Contributor Guidelines, but they are written in plain, blunt English. 

I managed what I consider a BIG win this last week: I got Blue Linden to put the link to the Wiki on the TeenSL Forums.  To the best of my knowledge, this is the first attempt to bring Accessibility to the Teen Grid.  I think we can build on this.

So, where do I go from here?

1. If one more person asks me, “So how are you advertising your stuff?” I am going to…concede that they are correct.  I need to get out there and wave the flag more.  I’m working on how exactly to do that.  I have to reach more of the market that is already in-world, and I need to reach more people who are thinking about trying SL.  I also need to reach more organizations that are looking for resources like mine.  Hey, it’s free: can’t beat that.
2. I need to find more Scripters.  I have branched out a little bit, but I am still focused on Blindness/Low Vision with most of my stuff.  Other people with other interests can make ScriptAble something truly diverse and alive.
3. On the practical side, I am going to devote some time this week to getting the landowner’s tool in the shop. It’s not difficult, I just need to apply myself a bit.
4. Once that is done, I think it is time to start working on “Toys”.  Until now, I have mostly focused on things that help you use Second Life on the most fundamental level: sensing, moving, dealing with inventory, managing a parcel of land.    Now I want to move into stuff that is just fun: games, RP tools, etc.  I would like to see if I can make at least some of it compatible with existing systems, but I will have to see what is out there and what the owners of those copyrights think.
5. This is my blue-sky project: Building Tools.  Code-wise, it can be done.  In practical terms, I just do not know!  I can make the tools and see how they are used, that’s all.  At the least it will be a fun toy!

BTW: some people have suggested I should charge for this stuff.  I went out and canvassed my friends who write Code for a living (not LSL), explained what I do, and asked what I should expect to get paid a year for doing it. Opinions varied: $37,000/year USD was the low end, we won’t talk about the high end.

So, to make it actually worth my while, I would need 1,000 users of my products paying me $37/year.  I don’t see 1,000 users right now!  OK, let’s shoot for a more realistic number: let’s get 100 Blind People into SL and charge them $370 a year to do what anybody else can do for free. Yeah, that’s the ticket!

Eh. Fuggedaboutit.  It’s staying free.  Awfully sorry if this disappoints anyone.

16 Objects

llSensor returns 16 objects.  No more, and less only if fewer than 16 are in range.

There are blessed few places in SL that you can go where you will find fewer than 16 objects!

So, here’s an idea:

Make a Skybox object.  That’s 1!  Put it up out of range of other people’s builds.

Now, make the most interesting and accessible place you can–for both Sighted and Blind users!–with just 15 other objects. Prim count is not so much an issue here, but what can you make with 15 things? Remember: an object is just prims linked together. The Guide doesn’t see prims, it sees one object, and reports back on it.

Right now, it couldn’t be a store, because Vendor Objects don’t work with the available tech.  Some other builds might be similarly without use at this time.

What can you make?

2.0 Beta

So, I have this object that is going to be the 2.0 Beta for the Guide. I am going to sleep on it tonight, do a couple things to it in the morning (like putting copyright and license notices in the files, etc.), and then I am going to hand it to my Beta Testers.

After they have had a chance to comment, and any tweaks/fixes have been made, I’ll get it out there to everyone.

So, what’s new?

• follow is fixed.  Um, kids, when declaring a global variable, be careful not to redeclare it in a function.  Just redefine the variable. Don’t put string in front of it if you did that already, just say variable = blah;   Yeah. Trust me on this one.  *headdesk*
• profile This is a fairly simple one that will give you the URL for somebody’s profile on the web.  Like going into the search tool in-world and looking them up in “All”.
• New name.  ScriptAble. Dianna and I are working on the Wiki.  Going to open it up to other scripters who want to use it to share their work.
• Support for–to some extent, reliance on–the Restrained Life Viewer.  The old commands and scripts still work!  I have carefully separated out the commands into scripts that end with -alt, so they can be excluded in a “Standard Version”.  Though, maintaining two versions may be more trouble than I need.  We’ll see.
• Thanks to the RLV, we have: face, sit, stand, tp, and for clothing and attachments, we have: add, remove, replace, inv, clothing.

The much-promised look and ping are going to wait.  Why?  They require things that are outside the Guide itself.  I have to get some tools made up for those who want to make their builds accessible, and I have to convince a few builders at least to use them.  That’s not going to happen in the next couple of weeks!

The new Wiki will also be a good place to show off the new Transcriber Tool (revised from earlier concept under the KISS Principle) as well as another project I stopped to do for some folks.

Oh, I don’t know if I said this: somebody out there is modding my stuff to work in OpenSim.  (I know diddly and squat about how LSL behaves in OpenSim!)  To this I say yea, and yay!  That’s the sort of thing I had in mind when I started this: take it and run with it.

I’ll see if we can get that added to the Wiki as well.  It’s up to them.

New Name

I was going to do this later, but later is getting awfully close to “now”.

We have a new name.  ScriptAble. That should be spoken like “Script Able”, not “Scriptable”, though I am not too stressed over it however you decide to say it.
Why?

1. BOSS is a horrid acronym.
2. It contains the name “SL”, and that gets into legal gray areas with their trademarks.  I’m being proactive in changing it.
3. It’s not just about Blindness anymore.  Every time I turn around, we’re adding another subset of the Disability Community to those being served.
4. Nobody else can post here, so some of the functions of this blog are going to be moved to a Wiki, so others can post what they are doing–or what they need!

The basic concept remains the same.  There is a Wiki that I am getting set up to hold the documentation and the code.  This will just be my “Here’s what’s going on in Talvin’s projects” blog.

More on this later!