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)