User:Strife Onizuka/Talkpage Archive 01

Hi Strife....the term is "deprecated", not "depreciated". See "Deprecation" in Wikipedia -- Rob Linden 16:37, 27 January 2007 (PST)

I was wondering about that. I'll change the template (it's handled in the template).Strife Onizuka 16:42, 27 January 2007 (PST)

I'm still learning the ins and outs of MediaWiki, so these templates are moving along.Strife Onizuka 17:25, 27 January 2007 (PST)

Excellent work on the templates. The pages look really good! -- Rob Linden 18:38, 27 January 2007 (PST)

It's amazing what can be done with good documentation. MediaWiki is gold (just wish it was 1.9.x).

I was considering making some generic templates for function definition pages. Hasn't happened yet. And still have to make the templates for events.

And I made a bit of a mess of the Template namespace (you can delete the redirecting pages). Getting out of the habit of using CamelCase is tough ~_~ Strife Onizuka 18:59, 27 January 2007 (PST)

Great to see your contributions, Strife. Thanx for building up this resource. --Torley Linden 14:25, 30 January 2007 (PST)

Template magic needed

Hi Strife: great work on the wiki so far. When you get a chance, could you take a look at Template:LSL conformance test and Template:LSL conformance script, which were created for adding our conformance suite? See LSL llGetUnixTime test for an example. I'm mainly looking for help making sure that the interface is sensible (i.e. the template parameter list makes sense and the general structure makes sense). The formatting can wait. The idea is to get these stabilized, and that will provide us a mechanism for those of us at LL to consolidate our tests, and for the community to chip in if desired. -- Rob Linden 22:46, 7 February 2007 (PST)

(moved rest of conversation to Template talk:LSL conformance test -- Rob Linden 22:22, 8 February 2007 (PST))

function & generic template

Are you planning on putting something in your templates for constants used by that function or event? Anthony Reisman

There is, just set 'constants' equal to a table. Checkout llDetectedType. Strife Onizuka 13:24, 8 February 2007 (PST)

Ok, I wasn't sure if you were making a general table template or something. Sorry, I'm still new at wiki formatting. I didn't want to just edit if we working on a standard for the pages.--Anthony Reisman 11:24, 9 February 2007 (PST)

Templates for tables are very difficult to make and not very useful. By the time you have populated the template with information you have done more work then it would have been just to make the table by hand. Strife Onizuka 11:28, 9 February 2007 (PST)

In the example that you used, I noticed it was a template, which is why I wondered. I'll figure out how to make a table, and just stick it in the page I'm editing. Also, where do I find the list of all the templates used? I found the unused templates, but didn't find the a list of all. Again, sorry for the silly questions. I'm picking wiki up as I go.

An inline example you can find on llParcelMediaCommandList. Strife Onizuka 11:56, 9 February 2007 (PST)

Thanks! That was exactly where I was going to put it in. Back to my other question. How to I find all the templates and template names we'll use. I can use the examples from other pages, but it might be nice to look at all the templates we have available. Thanks again! Anthony Reisman 12:14, 9 February 2007 (PST)

Really isn't a big list of LSL templates yet. The ones I use and wrote are:

Name	Description
Template:LSL Header	The bit at the top of the page, you need it if your page isn't using 'LSL Function', 'LSL Event', or 'LSL Conditional'.
Template:LSLG	Used for links to any LSL_* page
Template:LSLGC	Used to link to categories that start LSL_*
Template:LSLC	Used to add a page to a category to which the category name starts LSL_*. This template also tries to figure out the sort value needed.
Template:LSL Hex	Used for hex values.
Template:LSL Hex/Parse	Template used to convert hex literals into integers. Doesn't work just yet.
Template:LSL Function	Template used for function pages
Template:LSL Event	Template used for event pages
Template:LSL Conditional	Template used for flow control pages
Template:LSL Generic	Parent Template of 'LSL Function', 'LSL Event', or 'LSL Conditional'. It is the template that does the heavy lifting, it also has a couple sub templates that handles some of the intersting stuff required for the child templates.
Template:LSL Generic/Text	Sub template for the making the text of the first box of text.
Template:LSL Generic/Title	Sub template for the making the title of the first box of text.

re: Talk:LSL Function Style

I apologise if anything I've said has offended you personally- accessibility is something of a sore point to me.
SignpostMarv Martin 12:27, 11 February 2007 (PST)

LSL markup

Have we got LSL syntax highlight yet? If not what's the holdup? Anyone know? Gigs Taggart 15:38, 11 February 2007 (PST)

"We tried to use start using this on Thursday, but ran into some problems. Thraxis, it'll help if you can contact me privately to discuss some of the issues. -- Rob Linden 00:37, 11 February 2007 (PST)" Taken from Talk:LSL Portal

Energy: 10?

Why do all the functions take 10 energy? Even ones that have nothing to do with physics? Gigs Taggart 15:46, 11 February 2007 (PST)

I can't say for sure. Probably to counter balance bytecode throttling and to keep complex objects from using all the CPU time. As a non sequitur llSleep and llDie do not require any energy to call. Don't remove the value though, it is technically important, all objects have energy and if it runs out the scripts stops regardless of physics. Strife Onizuka 16:38, 11 February 2007 (PST)

Oh. Oops. I took it out on one or two. Gigs Taggart 20:07, 11 February 2007 (PST)

Already fixed it, don't worry about it. It is only a minor annoyance (a pet peeve) but an easily fixed one at that. I got the information from one of the source files used by LSL, so it is accurate. Strife Onizuka 20:12, 11 February 2007 (PST)

This would be where the lookup templates I alluded to in the layout examples I proposed- allowing the information only to be included where it's relevant. The information for all functions can then be displayed in a separate article- Energy (Havok) perhaps ? The Havok-disambig'd article will become more relevant if/when the server code is released, although the structure of the article should not take this into account until such time as the code is released.

SignpostMarv Martin 03:12, 12 February 2007 (PST)

Energy is implemented in the VM. While energy predominantly is important for physical objects you can also run out of it on non-physical objects, such as ones with negative mass (which don't have any at all). And it's not like it takes up a lot of space on the right side of the page. There isn't much known about energy at this time so it would not be a good thing to remove it until there is more known. But if you want I'll comment out the code that displays the value. Better to have the value and not display it then not have it at all (I am not keen on going through the source again to re-add those values to 328 pages; so please don't remove it).

I was planning on making tables for all of that information on their pages but it hasn't happened yet (with the exception of delay). So much to do and it not been a high priority. Strife Onizuka 06:06, 13 February 2007 (PST)

I repeat; allowing the information only to be included where it's relevant. The information for all functions can then be displayed in a separate article.

Including content that doesn't affect the operation of a script will confuse new comers, and the "seperate article" would be written in a relatively technical language and only be of interest to those working with the VM directly.

SignpostMarv Martin 07:08, 13 February 2007 (PST)

P.S. If you don't use a lookup template, you'll find that it'll be a pain in the ass to update everything if the default energy value for non-energetic LSL functions (you want to try updating 328 pages with the current issue of "session data" getting lost ?), whereas using a lookup template will be one edit.

SignpostMarv Martin 07:10, 13 February 2007 (PST)

LL is loath to change the VM, even to fix bugs. I can only think of two instances in my three years in SL that the Sleep value has changed for a function. Energy usage could be considered a caveat. It normally isn't something a user needs to worry about unless it is causing them problems. The information is relevant because it is a number specific to each function (and there are functions with different requirements). If I were a user wanting to know the energy requirements for a function would I look for a central table on energy usage first or the functions article? Well we don't know, it could go either way. Best to have it in both places. I did consider making a huge template to include such information as a lookup table, but that just smacked me as inefficient, a waste of CPU time.
The information is relevant because it is a function specific attribute. Information should be easy to find, not just easy to edit. Strife Onizuka 07:34, 13 February 2007 (PST)
P.S. It's not even like it takes up a large amount of screen space.

I repeat:

1. Including content that doesn't affect the operation of a script will confuse new comers
2. "seperate article" would be written in a relatively technical language

Also:

1. Lookup templates aren't a waste of CPU time.
2. You still seem to be forgetting this whole "community resource vs technical manual" thing.

SignpostMarv Martin 11:53, 13 February 2007 (PST)

You seemed to have missed the most important fact of energy. It does effect the operation of scripts. It causes them to stop working if none is left. I would imagine a new scripter would be quite peeved if such information were not obvious and their scripts stopped working. For an example a rapid firing turret: rezzing many prims quickly. If it rezzes too many prims too fast the scripts will stop working in the entire object. Why? because llRezObject has a high energy cost. Where should the energy cost for llRezObject be? On an obscure article about energy? Yes, but it should also be on the page for llRezObject. Now you're going to say: "But a new user wouldn't make a rapid firing turret" you would not believe the percentage of new scripters who make guns.
Imagine for a moment going into a store and there were no price tags. How would you know if you had enough money before going to the checkout? Energy is the price of scripting. Strife Onizuka 12:40, 13 February 2007 (PST)

For the third time:

• Including content that doesn't affect the operation of a script will confuse new comers

SignpostMarv Martin 13:21, 13 February 2007 (PST)

Exactly why it should be included I'm glad we agree. ^_^ Strife Onizuka 13:32, 13 February 2007 (PST)

Read the LSL Wiki article on Energy. http://lslwiki.org/index.php/Energy

SignpostMarv Martin 13:26, 13 February 2007 (PST)

I wrote a good portion of that article. The information it contains could not be verified at the time of it's writing. I know it is inaccurate because I've read portions of the applicable LSL VM source code. If you like I will cite the line numbers. Strife Onizuka 13:32, 13 February 2007 (PST)

*reads article* hmmm looks like some idiot came back and rewrote it. That is not what I would have written about energy at all. What it has to say about energy is incomplete. Looks like something Eep wrote. Strife Onizuka 13:35, 13 February 2007 (PST)

Branching out discussion due to pain-in-the-ass nesting

How many functions actually use the energy listed

The key point is that functions like llAbs() don't appear to actually consume energy.....
SignpostMarv Martin 15:01, 13 February 2007 (PST)

Yeah the branching is a pain. The return of llGetEnergy is normalized. Part of what I don't know yet is how much energy an object has. Sure llAbs may use 10 energy, but if thats out of 1,000,000 total, it would regenerate before you can call llGetEnergy. Or there is the other possibility that LSO VM no longer uses the Energy Supply Register (ESR). It is a small detail in the bigger picture to me, being that it can be easily removed from the template I wasn't going to research it until later. Further research would most undoubtedly require a conversation with Phoenix or Babbage. On a side note, executing any arbitrary bytecode costs 0.1 energy per operator (according to the source). Strife Onizuka 15:28, 13 February 2007 (PST)

It's fairly trivial to test. Have between 20 and 100 scripts running a function on a fast timer, with a separate script:

float energy = 1.0;

default
{
    state_entry()
    {
        llSetTimerEvent(0.01);
    }
    timer()
    {
        if(llGetEnergy() < energy)
        {
            llSetText((string)llGetEnergy(),ZERO_VECTOR,1.0);
        }
    }
}

SignpostMarv Martin 18:32, 13 February 2007 (PST)

Haven't logged in a while. If you tried that on such a short timer most of the updates would be dropped because of the rapid updates. AND events only trigger every 0.1 seconds (unless you are talking about control events which are every 0.05 seconds). If you want that code to actually work try:

//Slaves
default
{
    link_message(integer a, integer b, string c, key d)
    {
        a = 1000;
        do llAbs(b); while( a=~-a);
    }
}

//Master
default
{
    touch_start(integer a)
    {
        llMessageLinked(LINK_SET, 0, "", "");
        list b;
        float c;
        a = 100;
        do if(1.0 != (c = llGetEnergy())) b+=c; while( a=~-a);
        a = -llGetListLength(b);
        do llOwnerSay(llList2String(b,a)); while( a=-~a );
    }
}

Strife Onizuka 19:11, 13 February 2007 (PST)

*notices the category name change*
Well, what happens is, on any bytecode, 0.1 is subtracted from the ESR and then when a function is called whatever thats specific energy amount is subtracted from the ESR as well. The code is functional, but you see, only the essential parts of the LSL VM are included in the source package and not the sim code that interfaces with it. The bits that read and set the initial value of the ESR (and the SLR) are in the sim code. Strife Onizuka 19:37, 13 February 2007 (PST)

Bleh ?

SignpostMarv Martin 21:04, 13 February 2007 (PST)

*nods* "Bleh" pretty much sums it up. Strife Onizuka 21:30, 13 February 2007 (PST)

Do functions like llAbs() consume energy or not ?

SignpostMarv Martin 04:08, 14 February 2007 (PST)

Is the energy value for each function, the one transcribed onto every function page, used to update the Energy Supply Register? Yes. Is the Energy Supply Register used to update the objects memory? Unknown. Need to talk to a Linden who has detailed knowledge of the insides of the VM & Havok. From the parts of the source visible the answer could be said to be: Yes or No. Strife Onizuka 07:51, 14 February 2007 (PST)

you know if you'd run the test you'd get an answer. If it is not obvious from running a test, then for the sake of simplicity one would assume "no". Besides, having every single function consume energy would be moronic.

SignpostMarv Martin 10:00, 14 February 2007 (PST)

How many languages would allow a bug like (1.0-2) == 1 to exist (think they may have finally fixed this one)?

Or how about a compiler that has such a limited stack size you have to get creative to work around it's limits?

Or a compiler that doesn't even remove dead?

LSL is moronic.

I take it then you ran the test and it spammed chat with lines of nothing?

Strife Onizuka 10:08, 14 February 2007 (PST)

Nope, not had the chance- although when I ran mine I had an endless stream of 1.00000

SignpostMarv Martin 11:21, 14 February 2007 (PST)

If yours returned an endless stream of 1.00000 then the value was not in fact 1.0 (remember you are doing a test to filter out 1.0) but something less or more. Though it's unlikely it would round up even if it were only a bit away from 1.0 hmmm.

Try:

//Slaves
default
{
    link_message(integer a, integer b, string c, key d)
    {
        a = 1000;
        do llAbs(b); while( a=~-a);
    }
}

//Master
string hexc="0123456789ABCDEF";//faster

string Float2Hex(float input)
{// Copyright Strife Onizuka, 2006, LGPL, http://www.gnu.org/copyleft/lesser.html
    if((integer)input != input)//LL screwed up hex integers support in rotation & vector string typecasting
    {//this also keeps zero from hanging the zero stripper.
        float unsigned = llFabs(input);//logs don't work on negatives.
        integer exponent = llFloor(llLog(unsigned) / 0.69314718055994530941723212145818);//floor(log2(b))
        if(exponent > 127) exponent = 127;//catch fatal rounding error in exponent.
        integer mantissa = (integer)((unsigned / (float)("0x1p"+(string)exponent)) * 0x1000000);//shift up into integer range
        while(!(mantissa & 0x1))
        {//strip extra zeros off before converting or they break "p"
            mantissa = mantissa >> 1;
            exponent = -~exponent;//++c;
        }
        string str = "p" + (string)(exponent - 24);
        do
            str = llGetSubString(hexc,15&mantissa,15&mantissa) + str;
        while(mantissa = mantissa >> 4);
        if(input < 0)
            return "-0x" + str;
        return "0x" + str;
    }//integers pack well so anything that qualifies as an integer we dump as such, supports netative zero
    return llDeleteSubString((string)input,-7,-1);//trim off the float portion, return an integer
}

default
{
    touch_start(integer a)
    {
        llMessageLinked(LINK_SET, 0, "", "");
        list b;
        float c;
        a = 100;
        do if(1.0 != (c = llGetEnergy())) b+=c; while( a=~-a);
        if(a = -llGetListLength(b))
            do llOwnerSay(Float2Hex(llList2Float(b,a))); while( a=-~a );
        llOwnerSay("done");
    }
}

Float2Hex is lossless (tested the edges and fed it random numbers along the entire float range, without unexpected error). Should answer the question. If Float2Hex says the value is 1 then the value is 1. It doesn't work properly in Mono though because they uses doubles and not singles and it wasn't written with they extended range or precision in mind (it was made to run fast and efficiently in LSO without writing it LSO assembly). Something unconsidered is that llGetEnergy might only looks at a portion of the range or that it is a rounded or cropped result.

Strife Onizuka 11:38, 14 February 2007 (PST)

re User:Strife Onizuka#Downloads and Downloads

You wouldn't happen to have a handy shortcut for the OS X & Linux Main/Preview Viewers and First Look Viewers for all 3 OSs would you ?
SignpostMarv Martin 05:35, 15 February 2007 (PST)

Let me see if I can dig them up, I remember seeing it somewhere recently. Strife Onizuka 10:11, 15 February 2007 (PST)

Think it was the downloads page you just mentioned that I saw. I did some quick tests looks like the update URL doesn't take an 'os' parameter. If I come across anything I'll post it. *wanders off to make a late breakfast* Strife Onizuka 10:22, 15 February 2007 (PST)

Should one of us file a JIRA "New Feature" later to have the update urls improved to include OS params and first look ?

SignpostMarv Martin 06:03, 17 February 2007 (PST)

I'm not in a wag the dog mood today, but please go ahead. Strife Onizuka 08:37, 17 February 2007 (PST)

re: Wiki Troll (but a good one, causing drama isn't why i'm here).

I believe the correct term for a good Wiki Troll is a Wiki Gnome :-D

Thanks for the tip. Strife Onizuka