Drawing Lessons from Inventories

I am not given to excessive complaint...

...well, that is not entirely true. I frequently am moved to complain about almost anything, but I find that rarely does it make any difference in practice, thus usually confine myself to bitter sarcasm in conversations between myself and associates. Really, any reader thinking that I complain at times here about the physics engine should hear me in Second Life itself.

I do like to think, though, that I am able to take a balanced view regarding changes and their import; I may have preferred some small detail as it was but really, it's hardly the end of the world. It is also not a worthwhile pursuit badgering people with abuse regarding something, even if it is actually quite serious: "I am still extremely concerned about the changes in permissions that mean everything I own now belongs to someone else, and would like an update on when it is going to be fixed" rather than "how could you DO THIS? don't you IDIOTS ever CHECK THINGS before releasing UPDATES? WELL???". The former carries information, the latter is a noise, and one does not have the right in polite society to make noises at other people simply to make oneself feel better.

Having said all that, an hour or so of trying to put on and remove clothes and having to close all inventory folders and then search anew each time has driven me rather close to the line. I am aware that this issue has drawn Linden attention and thus I won't rant about the situation (too much) but there seems to me to be a fairly simple principle at work here: if I open a folder, or select something, I do not expect the folder to close or the selected object to change until I change things myself, deliberately. If I deploy a filter and then remove the filter, I expect my view to go back to how it was before deploying the filter. That's all, really.

I would say that this was a generally applicable principle - if I change something it shouldn't change back unexpectedly. I am sure that there is some academic term in the field of Human-Computer Interfacing to describe it, though I am by no means an expert in that area.

Looking at this principle in the broader spectrum of scripting within SL, designers are aided by the fact that scripts tend to keep their state even if one detaches or takes an object and then re-rezzes it. It does mean, though, that one should be careful with anything that might reset a script. It is sometimes useful to have

on_rez {
    llResetScript();
}

in a script, but really, in many cases it is idleness, not wishing to update variables or indeed having lost track of all of the variables concerned. It is quite common, for instance, for scripts to keep the key of the owner in a variable which needs to be reset should the owner change, but all that means is that one needs to have

on_rez {
    owner = llGetOwner();
}

rather than having to reset everything. For simple scripts this does not matter, but I was reminded of my own breach of my principles yesterday when considering the HUD attachment that I use to plot courses for my automatic vehicles, which clears the current course and also the email address to send it to each time it is rezzed. This is not good design. (I did, in my mitigation, write that script an awfully long time ago.)