An Unpredicted Event has occurred! Namely, that I have shuffled off the Chains of Idleness and Attempted to provide Answers Of Some Use to the questions which I Previously Invited regarding Scriptery. I believe that blithely promising a Weekly Session was somewhat ambitious of me, but I really should not have taken such a ridiculous length of time.
In any case, Self-Flagellation aside, here the Curious and Unjustly Delayed might find responses of some sort. Please, sir or madam, do feel free to request further detail, correct my undoubtedly innumerable errors, berate me for Flippancy, and also, ask more questions, which I shall try not to take Quite So Long To Answer in the future.
Rez Gray
Dear Ordinal,
As a fellow scriptor, we both know according to lore that LSL was supposedly written by two of the linden programmers in a few days. I have theorized based on some experience with syntactic decision analysis that LSL might have been composed and written by a room full of chimpanzees banging away at TR-80 Mini Computers in the same time frame. This is supported by the fact that the old Linden Office wasn’t very far from a black market animal testing lab for Avon.
I’m also willing to posite that at least a few of them still do the bulk of the world code for the company, only the crack dosages have been lowered due to market fluctuations in the SanFran area.
The Monkey Keyboard Theory has at times been promoted as an explanation for some of the more Unique Features of both the Language that we delight in regularly and the Grid upon which we do so, but I am more of the opinion that Intelligent Design must have been involved. Just as the Problem Of Evil is counter-argument to the existence of a Benevolent Deity but positively supports the existence of a Malevolent one, so some of the Baroque Stylings can only be the product of an Agent possessed of more cunning and a greater sense of irony than the average collection of imprisoned chimpanzees.
I am in fact in possession of Mr David Hume's unpublished and problematic final manuscript, in which he argues against his previous attacks on the Argument From Design. The first sentence of the first dialogue begins "Consider the quaternion...".
Cinco Pizzicato on February 12, 2009 at 1:27 am
I have a topic you might address, Ordinal.
Given that there’s no ‘llGetMyParentWhatRezzedMe()’ function, what is the best, happiest, and most secure way for an object to know who sired it? llDNATesting() seems to be a long way off.
Now, I see that Aleena Yoshiro has answered this very question below - a terrific example of Resident Collaboration, excellent stuff which means I am required to do less work. That really is practically identical to the way that I would have written things.
Opensource Obscure http://friendfeed.com/oobscure on February 12, 2009 at 2:00 am
I’d love if you wrote something about upcoming HTTP-in features and about what they can be used for.
At this point I could say "so, sir, would I", only that might be considered a little evasive. To be perfectly honest, at the moment I think that the best immediate use will be just to streamline and make more efficient (hopefully) communication between objects and offworld servers, and also to allow inworld objects to communicate with each other via HTTP rather than rubbish old email. The former will mean that, say, inworld object delivery servers will no longer be forced to regularly ping an offworld delivery list server and say "Excuse me, but are there any outstanding deliveries to fulfil? No? Oh well then." every few seconds, which has to be an improvement.
More significantly, if objects can simply send messages directly to each other with HTTP, triggering an event, that would make scripting systems requiring inter-sim communication an awful lot easier, rather than them having to sit their endlessly checking their email as if they are Terminally Bored Office Workers.
However, at this moment, possibly due to not having thought about it all that much, I do not see any qualitative changes to what is and is not possible arising from it, merely more convenience and efficiency. I may well be wrong.
Edward Pearse http://victorianaesthetic.blogspot.com/ on February 12, 2009 at 3:17 am
Dear Lady Ordinal,
A timely invite for topics. I’m currently attempting to understand texture animation scripts. I admit my LSL knowledge is about on par with explaining computers to my mother, though I can hack numbers in existing scripts with the best of them. Is it better to scrunch up a texture to be animated so as the prim surface just has the texture of 1 length, or (in the case of steps on an escalator) can a single step repeated 10 times work just as well?
Sorry for the ignorance. I’ve been looking at the LSL wiki but it makes my head hurt.
When setting a texture to move around on a prim's face, in my experience it is impossible to have said texture repeat itself for any length of time (it is possible to fiddle with the prim manually, but eventually the it will reset itself) - the ratio is determined by the function call and cannot be greater than 1x1. Thus I am afraid that scrunching will be required.
Peter Stindberg http://stindberg.blogspot.com on February 12, 2009 at 12:19 pm
/me gives up on eloquent Victorian way of words
Ordinal, what puzzles me (and other scripting beginners) time and again is the asynchronous nature of the dataserver. Basically when I ran into my first serious dataserver mangling, I more or less gave up scripting. I would love to see a “best practice” approach of dataserver querying that goes beyond “reading lines from a notecard”. Especially how to handle consecutive dataserver calls (e.g. read avatar name from notecard and check age of avatar).
Thanks!
Mr Stindberg, a broad issue, but usually when doing more than simply reading consecutive lines, I will usually keep a record of the current operation engaged in - either in a variable, usually, or by changing state, so that the dataserver event can respond to this and know what that data represent.
For instance, for (a)
string gAction = "";
integer gLine = 0;
key gCurrentAvKey = NULL_KEY;
get_next_avatar()
{
gAction = "get key";
gQuery = llGetNotecardLine(NOTECARD_NAME, gLine++);
}
get_avatar_age(key id)
{
gAction = "get age";
gCurrentAvKey = id;
gQuery = llWhateverTheFunctionIsCalledToGetADateOfBirthFromAKey;
}
default
{
...
dataserver(key query, string data)
{
if (gQuery != query) return;
if (data == EOF) llOwnerSay("Finished!");
else if (gAction == "get key") {
get_avatar_age((string)data);
}
else if (gAction == "get age") {
llOwnerSay("The avatar with key " + (string)gCurrentAvKey + " was born on " + data);
get_next_avatar_key();
}
}
}
Jaymin Carthage http://www.ocean-of-storms.com/jaymin on February 12, 2009 at 5:59 pm
My Esteemed Ordinal, My heart leap at the possibility of understanding from you a simple and eloquent description of the nature of Quaternions. I fear though that this would break the “no tears before bedtime” rule.
You are correct (as above).
Instead, this comes to mind. While shopping for a new hat they other day (and later determining that one of my own invention would be more satisfying) I was surprised to see my own visage in a shop window. My fame is extraordinarily small, and I thought it quite a coincidence for someone to have erected a monument in my honor. After a moment’s pondering it struck me that this was the same picture that was in my profile. The obvious deduction is that there is some capacity within LSL to find out the texture that a passing avatar has used to illustrate themselves in their profile. I must confess, although I normally consider myself a LSL expert, I was previously unaware of this capacity. Should you know the answer to this riddle, I would be most enlightened to learn. In service, JC
Excellent, another question answered by Correspondents - Messrs Dale Innis and ichabod Antfarm have answered this point most accurately below. I hope you will not be offended if I quickly move on to the next query; no personal offence is at all implied.
Kage Seraph http://blog.shadowmecha.org on February 13, 2009 at 4:06 am
How about a discussion of the relative importance of primary factors determining smooth vs. jerky region border crossings in vehicles?
Dale Innis http://daleinnis.wordpress.com/ on February 14, 2009 at 3:45 pm
Anything at all related to Vehicles, as for instance the mysteries of Banking, of Movement in the Vertical Direction, of those vehicles which are steered through the use of Mouselook, would be of great interest to me; this is an aspect of the Linden Scripting Language with which I have struggled, but never gotten beyond the level of those who Fiddle to See What Happens.
As penance for having had two questions answered for me, I see that now we have Vehicles. Hm. I have a confession to make here: I have never managed to get the Banking Parameters working either, and, as usual when faced with implacable linguistic odds, I have simply stepped around and to the side. I determine the sort of movement that I expect to happen for certain events (for instance, banking to the right when moving forwards and turning to the right) and apply a rotational velocity to turn the vehicle to the right when controls indicate that this is taking place. This I find much more predictable and productive than playing endlessly with parameters that may change their meaning entirely when other parameters also change.
Mr Seraph, I am sure that you know better than I the problems of crossing region boundaries, and it is an art rather than a science preventing issues, but I will here list an observation that I recently made regarding the practice. I recently scripted an automatic vehicle that carries me reliably across six or seven sims to the destination at quite high speed, twenty metres per second or so, which surprised me somewhat, and my guess is that this unexpected reliability results from
(a) Region crossings actually not being as unpleasant as they once were, back when I was a callow scripting youth; and (b) The linear size of the vehicle, or more accurately, linear separation of prims on the X-Y plane. In this instance it was a balloon being held above me; linear separation of prims does not get an awful lot smaller than that. The explanation for region crossing issues that I have always heard in the past has been that there is confusion when "handing off" an object to another region in parts, when one prim crosses the border before another. When this is minimised, issues are much reduced, and in combination with better performance of regions in general, why, it is almost as if one can just fly wherever one wants and not have to worry about being hurled to <0,0,0>.
Attica on February 21, 2009 at 4:57 am
multiple queries
Is region say quite impolite and a bit of noise pollution unless an item absolutely needs it?
Actually it is rather efficient, I am told, as distance need not be calculated when judging whether a script can hear a particular message. I am not however sure whether the distance constraint is evaluated before the channel constraint; if true, and there are many scripts listening on the same channel in the same region, a regionsay would indeed be less efficient if one is sure that the listener will be in the appropriate range. I think that it is almost always likely to be better than a shout though.
I am frightened of for/while loops. I think they are dangerous cos they might get stuck. I used to wake up with a start at night wondering if someone had driven a vehicle into my teleporters landing point. What frightens you ? Are you fearless?
I fear no while loop yet constructed, but, apart from polar bears and the inevitability of death, the chance of an object simply disappearing for no good reason (odd physics behaviour, a sudden influx of objects on a parcel) occupies my mind far more than it should. In this day and age such things are unlikely, but I have replaced an awful lot of trams by hand overe the years, and I continue to build all sorts of "ping" and "re-rezzer" scripts into systems which really do not need them.
I cannot reset scripts in no mod objects, so I have to throw away no mod no copy sofas cos the sit script crashed etc. Is there a clever way of tricking sl into resetting a script inside a no copy no mod object? Please do not tell me not to purchase unmoddable, where would I be without my stuffed leather victorian tramploine?
I am not aware, off-hand, of one. Resetting the script is possible by taking it out and then putting it into another prims, but that will not help you in this instance. Perhaps the rezzing of some form of excessively large poseball might do?
Is there a simple way to figure out whats better or worse for lagging? I know that chess has a points sytem for how much various elements are worth, does lsl and I missed it? For example- I guess based on how many “steps” it has listening on an obscure channel is better than sensoring used for satelite object control (Cos sensortime two things and listen is one thing). Is this true?
Unfortunately there is no easy way to determine this, and also there are many different sorts of lag that occur in many different situations, and disagreement as to what actually causes them, as you will discover should you make an innocent post on the subject to the Scripters' Mailing List and be treated to several Encyclopedias' worth of technical discourse.
I made a while for nonphys teleporter movement and it got stuck when i put a chair in its road. Is using a timer and die, a listen and die, an unsit die and also making the thing temporary a wanton use of resources, or simply good and prudent housekeeping?
Odd - a nonphysical teleporter should really not have gotten stuck at all due to objects in the way - but nevertheless, I find that making things temporary is the most effective way of making sure that they do not overstay their welcome. Deliberate suicide on the part of the object once it has done its job is also a good thing to implement, but temporary objects that are being sat on will stay there until abandoned and then go, and one never has to worry about the script stopping working for some odd reason.
ichabod Antfarm on February 22, 2009 at 8:29 pm
The code for displaying profile pictures on prims is here -http://www.lslwiki.net/lslwiki/wakka.php?wakka=LibraryDisplayProfilePic
Ordinal,
Having spent the morning fruitlessly wrestling with llDetectedGrab() trying to create a slider widget for a HUD, how about a little talk on that poorly documented function. Whatever hair remains on my head would be eternally grateful.
Thank you.
Now, I would answer this, but unfortunately I cannot recall ever having used said function for anything at all. (NOTE TO SELF: look up function and write an authoritative-sounding reply wherein you pretend to have immense experience with it.)
Icterus Dagger on April 6, 2009 at 12:39 pm http://ordinalmalaprop.com/engine/2009/02/11/ordinal-seeks-questions-of-a-querying-nature-regarding-the-implementation-of-the-linden-scripting-language-for-sundry-tasks/comment-page-1/#comment-104170
I have a couple of questions:
1.
Is there a way to disable or override the default “swirly” particle effect that occurs whenever a scripted item does something?
The "swirl" only occurs when the item says something that one can hear, either by ownersay, whisper, say or shout. However, there is no method of turning it off by the actual script in those circumstances. One can disable the effect in one's client by, say, turning off particles off entirely, but that can be inconvenient.
2.
How might one smoothly fade from one texture to another on a prim (when touched)?
-iD
The general method is to have the two textures on different faces, either faces on different objects or perhaps faces on the same abusively tortured prim, so that the outermost texture A obscures the inner texture, B. To "fade" from A to B, use llSetAlpha or llSetLinkAlpha in a loop, to change the alpha value of the face that displays A from 1.0 to 0.0 gradually. To fade from B to A, merely do the opposite, from 0.0 to 1.0. While a texture is obscured or at 0.0 alpha, it can be replaced, so for instance a sequential display system could have A fade to nothing (displaying B), then replace A with C (still invisible), then have C fade in (obscuring B), then change B to D (still obscured), and so on and so on.