Change font size
It is currently Mon Nov 19, 2018 11:11 am


Post a new topicPost a reply Page 1 of 1   [ 4 posts ]
Author Message
 Post subject: Fu Barr's 2018 Scripting class
PostPosted: Thu Aug 16, 2018 9:33 am 
Furious Typer
User avatar

Joined: Tue Nov 24, 2009 9:48 am
Posts: 165
This is a condensed and edited log file of Fu's scripting class held on August 11/2018


[11:35] Fu Barr: okay well i guess we can get started, :)
[11:37] Fu Barr: i'm going to rez a few primses in a minute
[11:37] Fu Barr: they are very super most highly simple
[11:37] Fu Barr: nother spactacular
[11:37] Fu Barr: *nothing
[11:37] Fu Barr: then, if you please please take a copy of the prims and rez them for yourself
[11:38] Fu Barr: click the button and see what it does.
[11:38] Fu Barr: the 'lesson' will be about understanding what the script does to make the thing work.
[11:38] Fu Barr: 2 boxes and a cylinder - linked
[11:38] Fu Barr: DO NOT UNLINK
[11:39] Fu Barr: just rez and press the green cylinder a few times
[11:39] Fu Barr: TAKE a copy and click on your OWN copy :)
[11:39] Fu Barr: you do all know how to steal stuff?
[11:39] Fu Barr: *grin*
[11:39] Fu Barr: right click and 'take'
[11:41] Fu Barr: okay everybody get a copy and try it out. it's a very simple light switch
[11:42] Fu Barr: if you press the green cylinder - it switches on/off
[11:42] Toggle boxes: state: unlit
[11:42] Toggle boxes: state: lit
[11:43] Fu Barr: now it's stupid it's a pointless thing - but it will serve to explain some very important programing in LSL asics
[11:43] Fu Barr: *basics even
[11:43] Fu Barr: first thing we'll learn is - where do scripts live.
[11:44] Fu Barr: so - everybody please select the boxes in build mode, and go to the 'contents' tab...
[11:44] Fu Barr: you'll find the script that it's running iin there.
[11:44] Fu Barr: please open the script by 2x clicking on it.

[11:45] Fu Barr: i'll wait a minute for everybody to find the script
[11:45] Fu Barr: who DOESNT have the script open yet?
[11:45] Boomslang Mamba: /*
Fu's basic light switch
v0.1
- basic on/off toggle

[11:45] Boomslang Mamba: was that it?
[11:45] Fu Barr: yeah - that one
[11:46] Fu Barr: okay now we're going to read the script together
[11:46] mika mesmeriser: can i take box out of edit??
[11:46] Fu Barr: or rather I'm going to tell you what to read and how it's structured
[11:46] Fu Barr: sure
[11:46] Fu Barr: we will only need the script for now
[11:46] Fu Barr: first of all. anything in orange is a comment
[11:47] Fu Barr: ni the script window
[11:47] Fu Barr: orange == comment and it is NON FUNCTIONAL
[11:47] Fu Barr: it doesn;t do anything
[11:47] Fu Barr: it's just there to help you the scripter to member what you did 6 months ago
[11:48] Fu Barr: so the first few orange lines just tell me that this is the first version and that it does next to nothing
[11:48] Fu Barr: you can do this however you like
[11:48] Fu Barr: i like to add this stuff to the top of my scripts - it keeps me sane. but you dont have to d this.
[11:48] Fu Barr: after all this is non FUNCTIONAL stuff
[11:49] Fu Barr: now, under the comments you see two lines starting with 'integer'
[11:49] Fu Barr: those lines 'declare to the rest of the script that there are 2 values to be used in the whole script'
[11:49] Fu Barr: i declate the word DEBUG to beTRUE
[11:50] Fu Barr: and the word LINK_LAMP to be the number 3
[11:50] Fu Barr: *declare
[11:50] Koni Lanzius: the declaration is required?
[11:50] Fu Barr: if I use DEBUG or LINK_LAMP anywhere after these lines anyplace in the script... the cript will replace the WORD with the value
[11:50] Fu Barr: yes
[11:51] albertlr Landar: so an integer can be either True or False or a number?
[11:51] Fu Barr: yes
[11:51] Fu Barr: because the script engine internally sets TRUE to 0
[11:51] Fu Barr: and FLASE to -1
[11:51] Fu Barr: *FALSE
[11:51] Koni Lanzius: is that minus one or just one
[11:52] Fu Barr: so we rea it as a word, but the script sees an integer
[11:52] Fu Barr: no MINUS one
[11:52] Arielle Popstar: is the word DEBUG arbitrary?
[11:52] Fu Barr: -1
[11:52] Fu Barr: yes
[11:52] Arielle Popstar: can use anyword?
[11:52] Fu Barr: i chose
[11:52] Fu Barr: it
[11:52] Koni Lanzius: dash one
[11:52] paela argus: it works like a switch is electricity going on either not
[11:52] Fu Barr: but I chose it for a reason
[11:52] Fu Barr: we'll see why i chose it later in the script
[11:52] Fu Barr: okay one last thing....
[11:53] Fu Barr: word you use as symbols for values, like here DEBUG or LINK_LAMP
[11:53] Fu Barr: are called 'variables'
[11:53] Fu Barr: and you can change the value at any time
[11:53] Fu Barr: so if i declare LINK_LAMP = 3 at the top
[11:54] Fu Barr: i can later decide to say: LINK_LAMP = 5
[11:54] Fu Barr: so now LINK_LAMP points to the number 5 not 3
[11:54] Fu Barr: variables are like little ziplock bags for data

[11:55] Fu Barr: any questions so far?
[11:55] Fu Barr: you should be asking me one
[11:55] albertlr Landar: each command line must end with ";"?
[11:55] Koni Lanzius: where is the 3 in the script?
[11:55] Fu Barr: yes
[11:55] Koni Lanzius: ahh
[11:55] Fu Barr: very good Koni - we'll gt to that :)
[11:56] Fu Barr: but no you should be asking, 'Fu, do variables have to be in CAPITALS'?
[11:56] Koni Lanzius: do they?
[11:56] Fu Barr: and the answer is no, they dont
[11:56] Koni Lanzius: why do you use them?
[11:56] Fu Barr: but i;m using an old tradition from C programming
[11:56] Koni Lanzius: ahh
[11:57] Fu Barr: some variables never change during the life of the script
[11:57] Fu Barr: these sort of variables are called 'Constants'
[11:57] Fu Barr: sort of obvious :)
[11:57] Fu Barr: and in C there was a tradition that Constants were written in CAPITAL to make them 'jump out' as being constants
[11:58] Fu Barr: LSL itself uses this tradition too.
[11:58] Fu Barr: we already saw how LSL itself defines TRUE and FALSE as constant variables
[11:58] Fu Barr: TRUE = 0, FALSE = -1
[11:58] Fu Barr: the idea should be clear. i hope
[11:58] Koni Lanzius: but why the dash before the one?
[11:59] Fu Barr: it's not a dash - it's a minus
[11:59] Fu Barr: -1 negative == false
[11:59] albertlr Landar: negative number
[11:59] Fu Barr: 0 is positive == true
[11:59] Fu Barr: okay let's move to the meat of the script
[11:59] Fu Barr: please look at the next line
[12:00] Fu Barr: it says 'default {'
[12:00] Fu Barr: the bracket is important
[12:00] Fu Barr: this left hand bracket is the 'beginning of a code block'
[12:00] Koni Lanzius: indicates the resting state of the object?
[12:00] Fu Barr: the code block is called default
[12:01] Fu Barr: now a few lines later you see a single } on it's own
[12:01] Fu Barr: line 21
[12:01] Koni Lanzius: hehe
[12:01] Fu Barr: so that's the close bracket on the block of code
[12:01] Fu Barr: open and close brackets ALWAYS need to be in balance
[12:02] Fu Barr: one open, one close
[12:02] Fu Barr: and the blocks can live inside of one another
[12:02] Fu Barr: look at line 17
[12:02] Fu Barr: state_entry() {
[12:02] Fu Barr: see, theres an open bracket
[12:02] Fu Barr: and the close bracket that belongs to it....
[12:02] Fu Barr: that's on line 20
[12:03] Fu Barr: see how they are always balanced?
[12:03] Koni Lanzius: mine are not numbered
[12:03] Koni Lanzius: yes
[12:03] Fu Barr: one of the most annoying code things to go wrong is forgetting or deleting per accident a bracket
[12:03] Fu Barr: because you'll spend hour looking for the bracket
[12:04] Fu Barr: so keep your brackets balanced... and that's why you use tabs and indentation to help you 'show the structure of your code blocks'
[12:04] paela argus: { //1 } //1
[12:04] Fu Barr: any questions about the brackets?
[12:05] Fu Barr: cool.
[12:05] Fu Barr: now find the line that says: state unlit {
[12:05] Fu Barr: then scroll down and find the close bracket for that first bracket...
[12:05] Fu Barr: sure
[12:06] Fu Barr: have you found it
[12:06] Koni Lanzius: would that be the next close bracket in the script?
[12:06] mika mesmeriser: line 21?
[12:06] paela argus: 42
[12:06] Fu Barr: nope
[12:07] Fu Barr: the open bracket is on line 24
[12:07] Fu Barr: nope not 42
[12:07] Koni Lanzius: mine has no numbered lines
[12:07] Fu Barr: no the close bracket is further down on line 51
[12:07] Koni Lanzius: wait it appears if I click on it...nevermind
[12:08] Fu Barr: exactly as i said before brackets HAVE to be balanced
[12:08] Fu Barr: can everybody see that the open bracket is on 24 and the close is on 51 ?
[12:09] Fu Barr: well - i'll leave it as home work to find the missing bracket :)
[12:09] Fu Barr: like we said, we use brackets to define code BLOCKS
[12:09] Fu Barr: everythin between the bracketss is ONE block
[12:09] Fu Barr: it looks like lots of lines etc. but it's one block
[12:10] Fu Barr: so we've seen that this script so far has 2 blocks - at least
[12:10] Fu Barr: the default block
[12:10] Fu Barr: and the 'unlit' block
[12:10] Fu Barr: there's another 3rd and final block - who can find it for me?
[12:11] Fu Barr: 81 is the closing bracket - where's the opening bracket?
[12:11] Koni Lanzius: 54?
[12:12] Fu Barr: ecellent! 54!
[12:12] paela argus: state lit { yup
[12:12] Koni Lanzius: ahh
[12:12] Fu Barr: it says 'state lit {
[12:12] Koni Lanzius: wouldnt that last bracket represent all the blocks tho?
[12:12] Fu Barr: nope
[12:13] Fu Barr: check how the brackets are balanced you'll see there are 3 main BLOCKS of code
[12:13] Fu Barr: the are brackets INSIDE of those blocks...
[12:13] Fu Barr: but that's just blocks inside of block, a bit like the russian doll thing
[12:13] Fu Barr: one doll inside another doll
[12:13] Fu Barr: one block inside another block
[12:13] Koni Lanzius: so there is not a encompassing block surrounding the three
[12:14] Jeff Hall: for those who dont know LSLEditor can highlight beginning and ending brackets, can help
[12:14] Fu Barr: there re many ways to do it - up to you to find one that works for you
[12:14] Fu Barr: so what have i been trying to show you guys so far...
[12:14] Fu Barr: i;m trying to show how code is mde of blocks and that these blocks have STRUCTURE
[12:14] Fu Barr: do this block. first
[12:15] Fu Barr: then if you need to, do this other block
[12:15] albertlr Landar: each block is like a room
[12:15] Fu Barr: it may well be that there is code in a script that you will NEVER actually RUN
[12:15] albertlr Landar: and you can have room inside those too.
[12:15] Fu Barr: because the situation that needs that code never happens
[12:15] Fu Barr: so a block might be used, it might ot, it depends on the structure of the code.
[12:16] Fu Barr: so when you first read a script.... you have to lok for it structure
[12:16] Blue Bird: Like having a cat tree, but not having any cats yet...
[12:16] Fu Barr: yes, a bit :)
[12:16] Fu Barr: so this script has 3 parts.
[12:16] Fu Barr: the first part is called 'default'
[12:17] Fu Barr: the second part is called 'unlit'
[12:17] Fu Barr: and the third part is called 'lit'
[12:17] Fu Barr: now who wants to have a go at what these parts actually do?
[12:18] Koni Lanzius: resting state, unlit state, lit state
[12:18] mika mesmeriser: turns light on and off
[12:18] Fu Barr: exactly
[12:19] Fu Barr: so what's this algorithm the is being mentioned.
[12:19] Fu Barr: well it's a fancy word for 'recipe'
[12:19] Fu Barr: how to get stuff done
[12:19] Fu Barr: i want a thing to light up when I click a button
[12:20] Fu Barr: the algorith would be:
[12:20] Fu Barr: 1. wait for click
[12:20] Fu Barr: 2. detecct click
[12:20] Fu Barr: 3. switch to the relevant state of lit or unlit
[12:20] Fu Barr: and this is exactly what happens
[12:20] Fu Barr: look in the defaults code block - it says:
[12:21] Arielle Popstar: how does it remember the state of lit or unlit?
[12:21] Fu Barr: when you enter the state, chenge the state from default to unlit.
[12:21] Fu Barr: one sec Arielle - that's the next bit :)
[12:21] Arielle Popstar: ok :)\
[12:22] Fu Barr: does every body see that in the default state it aits for state_entry and then sends the script to state unlit?
[12:22] Fu Barr: *waits
[12:22] Kawaii Unicorn: yes
[12:22] Arielle Popstar: hazily
[12:22] Arielle Popstar: sort of browned out atm
[12:22] Fu Barr: for get about the exact meaning of the code, there'details i;m leaving out, but whats iportant is the FLOW of the script
[12:22] Fu Barr: ok.
[12:23] Kawaii Unicorn: ok
[12:23] Fu Barr: let's do this slowly and i'll back up
[12:23] Kawaii Unicorn: ok
[12:23] Fu Barr: dont want peple to get lost
[12:23] Kawaii Unicorn: ty
[12:23] Boomslang Mamba: yeah man
[12:23] Fu Barr: so arielle asked - ow does the script know where it is
[12:24] Fu Barr: well, the script has a 'life cycle'
[12:24] Fu Barr: a scripts starts, loops for a while as long as it is needed, then it ends. and goes away
[12:24] Fu Barr: start, do stuff, go away
[12:25] Koni Lanzius: but the lit state is the final state, is that correct?
[12:25] Fu Barr: now this cycle moves through what OpenSim calls 'states'
[12:25] Jeff Hall: well the script is always listening for event too no Fu?
[12:25] Fu Barr: yeah - events is my next comment - but yes you're right :)
[12:25] Fu Barr: so as the scripts moves through the states....
[12:25] Fu Barr: it experiences stuff.
[12:26] Fu Barr: like people or avatars
[12:26] Fu Barr: i logn and go to lbsa, chat a bit, tp to someplace, then logoff.
[12:26] Fu Barr: it's a sequence.
[12:27] Fu Barr: now scripts tend to loop, forever till they are witched off... so koni
[12:27] Fu Barr: you said 'lit' was the end state
[12:27] Koni Lanzius: yea?
[12:27] Fu Barr: in a way it's true
[12:27] Fu Barr: but it's really just another intermediate step
[12:27] Fu Barr: if i click the button in the lit state it goes to the unlit state,
[12:28] Fu Barr: and vice versa
[12:28] Fu Barr: on and on
[12:28] Fu Barr: so there's actually no end to the CYCLE.
[12:28] Koni Lanzius: ahhh
[12:28] Fu Barr: the states come to an end, but the lifecycle of the whole script (in this case) is an endless loop
[12:28] Lance Fang is offline.
[12:28] Koni Lanzius: i see
[12:29] Fu Barr: when I start the script it goes automatically to 'default'.
[12:29] Fu Barr: that's jsut how it is. a rule in scripting.
[12:29] Jeff Hall: it will wait for click event non stop
[12:29] Koni Lanzius: i see
[12:29] Arielle Popstar: so the switch itself does not remember whether it is lit or unlit state but just acts as a toggle?
[12:29] Fu Barr: then I the scripted decided that I wanted to switch the script to the unlit state
[12:29] Fu Barr: *I the scripter
[12:29] Arielle Popstar: the default state does not = lit or unlit?
[12:29] Fu Barr: no arielle - it's the EXACT opposite
[12:30] Fu Barr: the only this a script knows is in which state it is
[12:30] Fu Barr: *thing
[12:30] Fu Barr: when a script starts it automatically goes to defaut
[12:30] Fu Barr: it just does
[12:30] Fu Barr: then I the scripter force it to go to state 'unlit'
[12:31] Arielle Popstar: so the state entry is unlit
[12:31] Fu Barr: in the unlit state... i wait for something to happen.... if that something is a touch on the button.... I force the script to move to state 'lit'
[12:31] Fu Barr: the script drags it arse into the lit state.
[12:31] Koni Lanzius: hehe
[12:31] Fu Barr: then it sit and waits for he next thing to happen
[12:32] Fu Barr: if it's a click on the button...
[12:32] Jeff Hall: event programming
[12:32] Fu Barr: it moves back into the state 'unlit'
[12:32] Fu Barr: yep jeff has the formal term right there.
[12:32] Fu Barr: you make the script react to 'events'
[12:33] Blue Bird: What if you turn it on and your sim resets while it's "on"?
[12:33] Fu Barr: the event being script started, or button got pressed, or something was heard
[12:33] Fu Barr: it goes back to the starting point - ie. the default state
[12:33] Blue Bird: ohh
[12:33] Fu Barr: scripts always start in default
[12:33] Fu Barr: some scripters who dont really understand the power of states, they stick all their code in the defaults state...
[12:34] Blue Bird: yea, that would be me
[12:34] Fu Barr: it's a nightmare to work with or change/improve tier code
[12:34] Fu Barr: *their
[12:34] Blue Bird: <--- wizart
[12:34] Koni Lanzius: thats like a header in writing?
[12:34] Fu Barr: best to throw it all out and start fresh
[12:35] Fu Barr: well, it's how you decide to write. its more about coding stle.
[12:35] Fu Barr: *style
[12:35] Koni Lanzius: kk
[12:35] Fu Barr: i use the default state to set the stage for my scripts.
[12:35] Koni Lanzius: kk
[12:35] Fu Barr: hen I move though the stages I need to deal with various events that might occur
[12:35] Fu Barr: moving the script into stag X or Y as I see fit
[12:36] Fu Barr: manipulating the life cycle of the script
[12:36] Koni Lanzius: spacing is important too, isnt it?
[12:36] Fu Barr: if you read this script again quietly you'll see it clearly i;m sure
[12:36] Fu Barr: just for humans
[12:36] Koni Lanzius: extra spaces can kill a script
[12:36] Fu Barr: the script engine only cares about brackets and semi-colons
[12:37] albertlr Landar: I have a question about the viewer editor.
[12:37] Fu Barr: now i just want to spend th last few minutes about some of the othe code inside the state
[12:37] Fu Barr: shoot albertlr
[12:38] albertlr Landar: It says Edit at the bottom, and apparently that is for external editor how does one set that up.
[12:39] albertlr Landar: The reason I mention it is the lsleditor program now supports the ossl functions too.
[12:39] Fu Barr: oh that edit - i never use that button - like I say i edit all my scripts in the viewer editor
[12:39] albertlr Landar: its set up somewhere in the advanced but not sure where.
[12:39] Koni Lanzius: when i click the edit button it says "Complie successful! save complere"
[12:39] albertlr Landar: https://sourceforge.net/projects/lsleditor/
[12:41] Fu Barr: you can change the editor font size.
[12:41] Fu Barr: okay so final thing.
[12:41] Fu Barr: lets look at the unlit state
[12:41] Fu Barr: first let's find the blocks
[12:42] Fu Barr: then lets see what those blocks are
[12:42] Fu Barr: blocks as we now know live in between brackets
[12:42] Fu Barr: so we have two main blocks in this state
[12:42] Toggle boxes: state: unlit
[12:42] Fu Barr: the first block is labelled state_entry()
[12:42] Fu Barr: the second block is labelled touch_end
[12:43] Fu Barr: can you guys see that?
[12:43] Koni Lanzius: yes
[12:43] mika mesmeriser: yep
[12:43] Fu Barr: inside those blocks there are more blocks...
[12:43] Fu Barr: liek we said.. russian dolls
[12:43] Fu Barr: in the state_entry block there are 3 seperate bits
[12:44] Fu Barr: if(DEBUG)
[12:44] Fu Barr: and 2x llSetPrimitiveBlaBLabLa
[12:44] Koni Lanzius: right
[12:44] Fu Barr: only the if(DEBUG) has BRACKETS
[12:44] Fu Barr: so only the if(DEBUG) is a block
[12:45] Fu Barr: the other two are just 'commands'
[12:45] Fu Barr: but most commands need relevant information to work properly and all the () and [] and all that is to help structure the info the command needs
[12:46] Fu Barr: i've used a lot of white space here to make it all look a little neater
[12:46] Fu Barr: but just to finish...
[12:46] Fu Barr: if i want to make the prim 'light up'... I can set all the sides to FULL_BRIGHT
[12:46] Fu Barr: is i want to turn the light off....
[12:47] Fu Barr: well i need to set FULL_BRIGHT to FALSE...
[12:47] Fu Barr: now look at the code
[12:47] Fu Barr: it's EXACTLY what is happening
[12:47] Fu Barr: i;m telling the script...
[12:48] Fu Barr: find the linked prim which is the bulb prim (LAMP_PRIM =3) and set the prim value to something relevant
[12:48] Fu Barr: if you look at the link set of these prims
[12:48] Fu Barr: you'll see that the prim that acta as a bulb is 3rd in the linkset
[12:49] Fu Barr: green cylinder = 1
[12:49] Fu Barr: the brown thing= 2
[12:49] Fu Barr: and the white one is 3
[12:49] Fu Barr: so what this script does...
[12:49] Fu Barr: cycle through lit/unlit states
[12:50] Fu Barr: and in each state set the relevant FULL_BRIGHT value on the 3rd prim
[12:50] Fu Barr: that's it
[12:50] Fu Barr: nothing else
[12:50] Fu Barr: it just looks al little complicated but conceptually it's very simple
[12:51] Fu Barr: if i move into lit, set fullbright, if i move into unlit, turn fullbright off
[12:51] Fu Barr: and all i do is 'wait' for a touch event
[12:51] Fu Barr: read the script again carefully and it'll be quite clear now that you understand the concept of script life cycle and states and 'brackets'
[12:52] Koni Lanzius: on line 40, what is that number/letter series
[12:52] Fu Barr: that is the UUID of the 'blank texture'
[12:52] Fu Barr: everything in opensim/OSgrid has a unique number
[12:52] Fu Barr: here I use that number to force the texture on the bulb prim to be pure white
[12:53] Fu Barr: I'm setting TWO parametrs on the pri. 1. full bright, 2. the blank texture
[12:53] Koni Lanzius: i see
[12:54] Fu Barr: btw. the SecondLife LSL wiki is ESSENTIAL
[12:54] Fu Barr: you cannot script without the LSL Wiki and the OSSL wiki
[12:54] Arielle Popstar: i am still not getting how the script know whether to use the lit or unlit block codes of script to toggle the light on or off depending on its present state. Seems to me it would just run the last bit of code to turn an allready on light to continue in the on state
[12:54] Jeff Hall: why do u have a state_entry embedded in state unlit since its allready called in default / state_entry?
[12:54] Fu Barr: that's where all the info is of how to use the various functions
[12:54] Kawaii Unicorn is online.
[12:55] paela argus: http://wiki.osgrid.org/index.php/LSL_Functions
[12:55] Fu Barr: jeff - because i need to run off the light :)
[12:55] Fu Barr: *turn#
[12:55] Fu Barr: one state turns it on
[12:55] Fu Barr: the other off
[12:55] Fu Barr: i do that in the state_entry event of the relevant state
[12:55] Fu Barr: arielle -
[12:55] Fu Barr: the script doesnt keep running
[12:56] Jeff Hall: u could remove the state_entry in state unlit and just make it turn off
[12:56] Fu Barr: from state to state
[12:56] Fu Barr: it stays in one sate untill you the scripter force it into anpther state
[12:56] Fu Barr: no you cant remove the state_entry - because the script engine always expect to see a state_entry block :)
[12:57] paela argus: there are several ways to do it, let's stay on the one of fu or everybody will lose it
[12:57] Fu Barr: each state needs at least state_entry. otherwise it flags a syntax error
[12:57] Fu Barr: yeah - many ways to skin a cat.
[12:57] Fu Barr: i chose this one because I felt it was the most 'clear' way to do it
[12:58] Fu Barr: jeff - you cannot not have a state_entry in a state.
[12:58] Fu Barr: the script engine will flag an error
[12:59] Fu Barr: anyhow - thats it for this evening. i hope it wasn't too overwhelming and dont be embarrassed to reach out to me in IM or here in chat with questions. Happy to help and go over things a million times
[12:59] Jeff Hall: ty Fu
[12:59] Koni Lanzius: was brilliant, thank you Fu!!
[12:59] Koni Lanzius: ~** APPLAUSE **~
[12:59] albertlr Landar: Well thanks for the lessons Fu Barr.
[12:59] Koni Lanzius: ~**YAY!!!!**~
[13:00] Blue Bird: Thank you FU, you have helped a lot!
[13:00] Fu Barr: i do suggest you just carefully read the script
[13:00] paela argus: meow meow
[13:00] albertlr Landar: Also I solved my external editor question.
[13:00] Fu Barr: so i guess we'll do another one next week?
[13:00] Koni Lanzius: awesomes!
[13:00] mika mesmeriser: thank's Fu made it more understandable
[13:00] paela argus: please clear stuff before leave peoples :)
[13:00] Koni Lanzius: yea really helped
[13:00] Fu Barr: bring a friend etc. spread the word
[13:00] Fu Barr: all of that jazz
[13:00] Koni Lanzius: kk
[13:00] albertlr Landar: It Singularity its under Advanced and debut settings. Then you enter ExternalEditor and it allows you put in the link.
[13:00] Koni Lanzius: bye for now
[13:00] Fu Barr: dnt forget to clean uuip your prim
[13:01] Jeff Hall: ty Fu and see u soon
[13:01] Fu Barr: thanks for coming and joining in all!


This is the script being studied
{L_CODE}:
/*

    Fu's basic light switch

    v0.1
    - basic on/off toggle

*/


integer DEBUG = TRUE;

integer LINK_LAMP = 3;      // named like this to match LSL's LINK_ROOT constant used below


default {

    state_entry() {

        state unlit;
    }
}


state unlit {

    state_entry() {

        if(DEBUG){ llOwnerSay("state: unlit"); }

        llSetLinkPrimitiveParamsFast(LINK_ROOT,

            [ PRIM_FULLBRIGHT, ALL_SIDES, FALSE ]
        );

        llSetLinkPrimitiveParamsFast(LINK_LAMP,

            // the UUID here is the OSgrid specific one for 'Blank Texture'

            [ PRIM_FULLBRIGHT,  ALL_SIDES, FALSE,
              PRIM_TEXTURE,     ALL_SIDES, "5748decc-f629-461c-9a36-a35a221fe21f", <1,1,0>, <0,0,0>, 0 ]
        );
    }

    touch_end(integer num_touches) {

        if(llDetectedLinkNumber(0) == LINK_ROOT) {

            state lit;
        }
    }
}


state lit {

    state_entry() {

        if(DEBUG){ llOwnerSay("state: lit"); }

        llSetLinkPrimitiveParamsFast(LINK_ROOT,
       
            [ PRIM_FULLBRIGHT, ALL_SIDES, TRUE ]
        );

        llSetLinkPrimitiveParamsFast(LINK_LAMP,

            // like in the 'unlit' state, the UUID here is the OSgrid specific one for 'Blank Texture'

            [ PRIM_FULLBRIGHT,  ALL_SIDES, TRUE,
              PRIM_TEXTURE,     ALL_SIDES, "5748decc-f629-461c-9a36-a35a221fe21f", <1,1,0>, <0,0,0>, 0 ]
        );
    }

    touch_end(integer num_touches) {
       
        if(llDetectedLinkNumber(0) == LINK_ROOT) {

            state unlit;
        }
    }
}



The next class will be Saturday August 18 at 11:30 Grid time (PDT)


Top
 Profile  
 
 Post subject: Re: Fu Barr's 2018 Scripting class
PostPosted: Mon Aug 20, 2018 9:41 pm 
Site Admin
User avatar

Joined: Sun Jun 27, 2010 10:34 am
Posts: 123
Location: France
thanks you Arielle

_________________
Paela Argus,
Webmanagement Osgrid

https://www.osgrid.org


Top
 Profile  
 
 Post subject: Re: Fu Barr's 2018 Scripting class
PostPosted: Tue Aug 21, 2018 8:40 pm 
Furious Typer
User avatar

Joined: Tue Nov 24, 2009 9:48 am
Posts: 165
Part 2 of the scripting tutorial:

[11:31] Fu Barr: we have a new prop!
[11:31] Fu Barr: meet ALien Plant :)
[11:31] Arielle Popstar: looks great :)
[11:31] Arielle Popstar: mesh?
[11:31] Fu Barr: hehe
[11:31] Fu Barr: nah
[11:31] Fu Barr: never mesh
[11:31] Fu Barr: pure prim
[11:31] Arielle Popstar: wow
[11:32] Fu Barr: lol - i always smile when people do that :)
[11:32] Arielle Popstar: wouldnt have thought it could be made to look that good in prim
[11:32] Fu Barr: hey albertlr
[11:32] Arielle Popstar: Hi Albertr
[11:32] albertlr Landar: Hum. Audrey 2?
[11:32] Fu Barr: nope Alien Plant :)
[11:38] Fu Barr: so first a short recap of last week and then we'll segway into this week's subject: Events
[11:38] Fu Barr: last week we spoke about a few things the most important were:
[11:39] Fu Barr: 1. every object/linkset has a life cycle
[11:39] Fu Barr: rez, exist, de-rez
[11:39] Fu Barr: during this lifecycle a script that in placed inside an object/linkset can react to the world around it. things that happen in the world during the life cycles of the object/linkset are called events
[11:40] Fu Barr: 3. inside of an object/linkset this lifecycle can be extended by stepping through 'states'
[11:41] Fu Barr: 4. there's always one default state... called 'default'
[11:41] Fu Barr: 5. a scripter can decide to use more than one state to structure his/her code.
[11:41] Fu Barr: 6. brackets {} indicate blocks of code.
[11:41] Fu Barr: 7. blocks of code always have open and close brakcets - they ALWAYS need to be balanced.
[11:42] Fu Barr: i think that's just about the core of what we spoke about last week.
[11:42] Fu Barr: the chat log is on the wiki and the forum if you want to relive my typonese :)
[11:42] Fu Barr: so - today we're going to spend a little more time with the notion of events.
[11:43] Fu Barr: so without further ado - please try and 'take copy' this Alien Plant
[11:43] Fu Barr: then rez it from inv.
[11:43] paela argus: i love this plant
[11:44] Arielle Popstar: yes its really nice
[11:44] Fu Barr: please take copy this plant and rez it
[11:44] Koni Lanzius: ty sweetie
[11:44] Arielle Popstar: Hi Koni
[11:44] Fu Barr: now once you've rezzed it...
[11:44] Fu Barr: click on the sphere base once. and wait
[11:44] Alien plant: state: lit
[11:44] Alien plant: LAMP_TIMEOUT: 5.000000
[11:44] Alien plant: state: unlit
[11:44] Alien plant: LAMP_LINK_ID: 13
[11:45] Fu Barr: you'll see the 'light buld' in the flower go on and then off
[11:45] Fu Barr: the lamp will go off on its own
[11:45] Fu Barr: and in the meantime there's a bunch of debug data being show on your screen.
[11:46] Fu Barr: so let's ope sthe script and see what's going on
[11:46] Fu Barr: everybody got the script open?
[11:46] Fu Barr: i'll asume you have :)
[11:46] Fu Barr: okay - let's go
[11:47] Fu Barr: so first of all, at the top of the script i've added a version note. so i know what is different in this script from the previous one
[11:47] Wizard Atazoth: Alien plants are multiplying here ^_^
[11:47] Fu Barr: this is not something you have to do. it's something that i do for myself so in 3 weeks time i know what this thing does
[11:48] Fu Barr: i do recommend you do something similar with your own scripts
[11:48] Fu Barr: your free to decide what/how etc.
[11:48] Fu Barr: now, just like in the previous script there are a few CONSTANT variables at the top
[11:49] Fu Barr: we said Constants were variables that are set once and dont change. and we use CAPITALS to hint at that.
[11:49] Fu Barr: we see that there's an extra variable in this version of the script - s=which is the length of time to wait before the lamp goes out automatically
[11:49] Fu Barr: LAMP_TIMEPOUT
[11:49] Fu Barr: it's made up by me.
[11:50] Fu Barr: not something that is already defined in LSL
[11:50] Fu Barr: then, if you look we have the same 3 states as in the previous version default, unlit and lit
[11:50] Fu Barr: but, in the default one there's some significant changes
[11:51] Fu Barr: remember how in the first versio of this script we set the LINK_LAMP variable to 3
[11:51] Fu Barr: because that was the 3rd and final prim in the linkset...
[11:51] Fu Barr: and we needed to know which prim to change so it would 'light up'
[11:51] Fu Barr: well. in this version we're going it in a MUCH smarter way
[11:51] Fu Barr: let's read the code.
[11:52] Fu Barr: find //0. setup lamp
[11:52] Fu Barr: we'll start reading from there
[11:52] Fu Barr: i define 2 new variables
[11:52] Fu Barr: i end
[11:52] Fu Barr: i is short for increment
[11:52] Fu Barr: and end is short for.... end
[11:53] Fu Barr: the there's one of the if DEBUG things, ignore that and move to the line: while(i <= end)
[11:53] Fu Barr: what i'm asking the script to do here is do something while i is smaller or equal to end....
[11:53] Fu Barr: an dwho can tell me what end is?
[11:53] Fu Barr: or rather what value is held in endsaw the Barr: well the line where we define end says:
[11:54] Fu Barr: integer end = llGetNumberOfPrims();
[11:54] Fu Barr: so it stand to reason that llGetNumberOfPrims will return a value that's the number of prims in the linkset
[11:55] Fu Barr: and why do we need that number?
[11:55] Fu Barr: well because the way that i;m doing things now is...
[11:55] Fu Barr: i;m looping through all the prims in the linkset...
[11:55] Fu Barr: and when I find the prim that I've called 'bulb'
[11:55] Fu Barr: then I stick that link id into LAMP_LINK_ID
[11:56] Fu Barr: so that's my 'algorithm' for finding the right prim to 'light up'
[11:56] Fu Barr: loop through all the prims
[11:56] Fu Barr: and when you find the one called 'bulb' save it's number
[11:56] Fu Barr: lets see the code...
[11:56] Fu Barr: line 33
[11:57] Fu Barr: while i is less then the last link id,
[11:57] Fu Barr: line 37
[11:57] Fu Barr: if the link name if thelink at link id numerb i is equal to 'buld'
[11:57] Fu Barr: *biulb
[11:58] Fu Barr: then set LAMP_LINK_ID to whatever value i is
[11:58] Fu Barr: then continue the loop.
[11:58] Fu Barr: by increasing i to the next value
[11:58] Fu Barr: we have the script march past every link in the linkset and check the name of each link prim
[11:59] Fu Barr: once we find the right link, we store the id.
[11:59] Fu Barr: i hope this is clear to all
[11:59] Fu Barr: questions?
[11:59] Fu Barr: cool.
[11:59] Fu Barr: it doesn;t take a lot of imagination that a loop like this can be used to initialise all sorts fo things.
[12:00] Fu Barr: but for our simple plant thing - this is all we need
[12:00] Fu Barr: and then, we leave the default state beasue we force the script to move to the 'unlit' state
[12:00] Fu Barr: thats in line 46
[12:00] Fu Barr: and we never go back into the default state after than
[12:01] Fu Barr: so, when we get into the unlit state...
[12:01] Fu Barr: we have an evernt.
[12:01] Fu Barr: the 'state_entry' event
[12:01] Fu Barr: and there we do what we did last week - we switch off the buld.
[12:02] Fu Barr: i asle removed the switching off of the root prim (if you compatre the two scripts) because we dont have the green cylinder button in this plant.
[12:02] Fu Barr: then the script just waits.
[12:02] Fu Barr: it sits and does nothing
[12:02] Fu Barr: just ahnging about in the unlit state
[12:03] Fu Barr: until.... a new event happens
[12:03] albertlr Landar: unles you click it again.
[12:03] Fu Barr: you touch the plant - exactly
[12:03] Fu Barr: and like jeff said last week, we 'handle' this event in the event handler 'touch_end'
[12:03] Fu Barr: liine 70
[12:04] Fu Barr: in this block, if check...
[12:04] Fu Barr: if the touch happened to be on the root prim, then...
[12:04] Fu Barr: go to the stte 'lit'
[12:04] Fu Barr: *state
[12:04] Fu Barr: that's all the event handler does. and all it has to do.
[12:04] Fu Barr: it's the switch part.
[12:05] Fu Barr: wait till there's a click event, then do something
[12:05] Fu Barr: open it up and dive into the script with us :)
[12:05] Fu Barr: so now that we have line 74 sending us to 'lit' lets see what's in the lit state...
[12:06] Fu Barr: well again - there's always the 'state_entry' event handler. you always have one of those.
[12:06] Fu Barr: and the first bits are all the DEBUG printing information stuff. that now old news for us.
[12:06] Fu Barr: but look at line 90
[12:07] Fu Barr: i commented there: // 0. switch on lamp
[12:07] Fu Barr: and in line 99: // 1. setup timer event
[12:07] DJ Higher is online.
[12:07] Fu Barr: this is how i build my 'steps'
[12:07] Fu Barr: i write in human llanguage in a comment what the script needs to do... and then i write the code that does it.
[12:08] Fu Barr: that way i dont go nuts trying to figure out what to do.
[12:08] Fu Barr: in this case...
[12:08] Fu Barr: the script needs to put on the buld and then set the timer in motion
[12:08] Fu Barr: so lets read in the code...
[12:08] Fu Barr: the switching on is exactly the same as last week
[12:08] Fu Barr: we use llSetLinkPrimitiveParamsFast
[12:09] Fu Barr: function (more about htose in two weeks)
[12:09] Fu Barr: and we feed it the LAMP_LINK_ID so it know which of the prims in the link set to modify and we give it the modification parameters
[12:09] Fu Barr: this is the same as we've been doing all along
[12:09] Fu Barr: but in line 100 we do something new
[12:09] Fu Barr: in line 100 we actually FORCE AN EVENT TO HAPPEN
[12:10] Fu Barr: usually an event happens because soething happens in the world
[12:10] Fu Barr: you touch a prim
[12:10] Fu Barr: you collide with it you pay it money etc.
[12:10] Fu Barr: but a timer is something we have to set in motion ourselves
[12:10] Fu Barr: it's like pressing the button on a countdown itmer
[12:10] Fu Barr: *timer
[12:11] Fu Barr: and how long does it wait before it sets off the timer event?
[12:11] Fu Barr: well...
[12:11] Fu Barr: it waits LAMP_TIMEOUT seconds
[12:11] Fu Barr: which we've defined all the way at the top of our script
[12:11] Fu Barr: in our case 5.0 seconds
[12:12] Fu Barr: if you want to have it wait longer/shorter - you just change the value
[12:12] Fu Barr: so what happens after LAMP_TIMEOUT seconds apsses?
[12:12] Fu Barr: the script engine will fire the timer event...
[12:12] Fu Barr: and in line 103...
[12:12] Fu Barr: we see the timer event handler
[12:13] Fu Barr: all it foes... is send the script back inot its 'unlit' state.
[12:13] Fu Barr: and we know that the state_entry event hndler of the 'unlit' state... that puts off the bulb
[12:13] Fu Barr: and that's all there is to it.
[12:13] Fu Barr: 3 states and a couple of event handlers
[12:13] Danger Lytton is offline.
[12:13] Fu Barr: default for setting up the correct ID of the bulb
[12:14] Fu Barr: and lit/unlit states to light and put off the lamp
[12:14] Danger Lytton is online.
[12:14] Fu Barr: and a timer event and evnt handker to put off the lamp at the right time.
[12:14] Fu Barr: dassit.
[12:14] Fu Barr: end of.

{L_CODE}:
/*

    Fu's basic light switch

    v0.2
    - turn-off-the-lamp timeout
    - expanded setup

    v0.1
    - basic on/off toggle

*/


integer DEBUG = TRUE;

integer LAMP_LINK_ID;
float   LAMP_TIMEOUT = 5.0;

default {

    state_entry() {

        llOwnerSay("running: " + llGetScriptName());

        if(DEBUG){llOwnerSay("state: default");}

        // 0. setup lamp
        integer i   = 1;    // linked prims are numbered from 1
        integer end = llGetNumberOfPrims();

        if(DEBUG){llOwnerSay("Number of prims: " + (string) end);}

        while(i <= end) {

            if(DEBUG){llOwnerSay("Link ID: " + (string) i + ", prim name: " + llGetLinkName(i));}

            if(llGetLinkName(i) == "bulb") {

                LAMP_LINK_ID = i;
            }

            i++;
        }

        // 1. showtime!
        state unlit;
    }
}


state unlit {

    state_entry() {

        if(DEBUG) {

            llOwnerSay("state: unlit");
            llOwnerSay("LAMP_LINK_ID: " + (string) LAMP_LINK_ID);
        }

        llSetLinkPrimitiveParamsFast(LAMP_LINK_ID,

            // the UUID here is the OSgrid specific one for 'Blank Texture'

            [ PRIM_FULLBRIGHT,  ALL_SIDES, FALSE,
              PRIM_TEXTURE,     ALL_SIDES, "5748decc-f629-461c-9a36-a35a221fe21f", <1,1,0>, <0,0,0>, 0 ]
        );
    }

    touch_end(integer num_touches) {

        if(llDetectedLinkNumber(0) == LINK_ROOT) {

            state lit;
        }
    }
}


state lit {

    state_entry() {

        if(DEBUG) {

            llOwnerSay("state: lit");
            llOwnerSay("LAMP_TIMEOUT: " + (string) LAMP_TIMEOUT);
        }

        // 0. switch on lamp
        llSetLinkPrimitiveParamsFast(LAMP_LINK_ID,

            // like in the 'unlit' state, the UUID here is the OSgrid specific one for 'Blank Texture'

            [ PRIM_FULLBRIGHT,  ALL_SIDES, TRUE,
              PRIM_TEXTURE,     ALL_SIDES, "5748decc-f629-461c-9a36-a35a221fe21f", <1,1,0>, <0,0,0>, 0 ]
        );
       
        // 1. setup timer event
        llSetTimerEvent(LAMP_TIMEOUT);
    }
   
    timer() {

        state unlit;
    }
}


Top
 Profile  
 
 Post subject: Re: Fu Barr's 2018 Scripting class
PostPosted: Thu Aug 30, 2018 2:22 pm 
Furious Typer
User avatar

Joined: Tue Nov 24, 2009 9:48 am
Posts: 165
This is Session 3




[11:39] Fu Barr: so this week i've slightly changed my presentation - ii was going to do the fun collision portal with blinking lights and included batteries...
[11:40] Fu Barr: but i realise that i really need to talk about data first. so the portal thingy will be done next week :)
[11:40] Fu Barr: so - without further ado... please take a copy of this 'tube' and rez a copy near you
[11:40] Fu Barr: open the script inside and we'll get started.
[11:41] Data tube: running: Fu's data examples v0.1
[11:43] Fu Barr: okay so this week we're going to talk about 'data''
[11:44] Fu Barr: i realised it's all well and good speaking aout all the lifecycle and the states and the events etc.
[11:44] Fu Barr: all important
[11:44] Fu Barr: but you need to have a good handle on actual data too.
[11:44] Fu Barr: LSL/OSSL provides you with a huge amount of ways to hang yourself, or cut your fingers - as you prefer - with regards to data.
[11:45] Fu Barr: time we had a looksey at some of it.
[11:45] Fu Barr: please look at the top of the script.. lines 7 to 16
[11:46] Fu Barr: the first bit should be familiar to all - these are examples of the common data types you see in just aout every script out there
[11:46] Fu Barr: i've left one data type out of our discussion - the rotation
[11:46] Fu Barr: it's far too complicated for this set of classes.
[11:47] Fu Barr: it has to do with doing 3D math and rotating stuff in 3D.
[11:47] Fu Barr: but if you're not doing any of that stuff... well you dont need it. and if you are... chances are you dont need this introductory class...
[11:47] Fu Barr: in line 16
[11:47] Fu Barr: we see the use of 'list'
[11:48] Fu Barr: list is also a built-in thing that LSL/OSSLp rovides... but it's not a 'primitive' data type... it's a basic data structure
[11:48] Fu Barr: the difference between type and structure is that types for the most part hold ONE single value of a certain type.
[11:49] Fu Barr: and structures can hold more than one unit of data
[11:49] Fu Barr: of course they can also be empty
[11:49] Fu Barr: so far so good?
[11:49] Fu Barr: it seems so
[11:49] Fu Barr: remember - interrupt me when you have something to ask or if you're bored.
[11:50] Fu Barr: now, look at lines 30 - 31
[11:50] Fu Barr: in the default state there, i fill the two variables with data
[11:50] Fu Barr: the other variables are filled with data earlier up top
[11:51] Fu Barr: but these two.. until the script actually runs... i can't fill them with sensible data. or rather i can, but ive chosen not to
[11:51] Fu Barr: by filling them in the default state_entry event handler... i can use some 'live' data. I dont need to 'hard code' it into the script.
[11:52] Fu Barr: you guys didn;t have to fill in a notecard or modify the script with your names...
[11:52] Fu Barr: the script figures it out itself.
[11:52] Fu Barr: but that can only happen once it's up and running.
[11:52] Fu Barr: so that's why it's done in the start of the default state.
[11:52] Fu Barr: line 33
[11:53] Fu Barr: you see there that i've commented out the command to jump to the next state
[11:53] Fu Barr: please remove the // and save the script - it will run to the next state and you'll see stuff on your chat
[11:53] Fu Barr: if all went well
[11:54] Fu Barr: the script now moves to the 'data_dump' state
[11:54] Grid: Script saved
[11:54] Fu Barr: and you should have seen the 5 variables and their data displayed
[11:54] Fu Barr: and in two messages
[11:54] Snoots Dwagon: did yes
[11:54] Fu Barr: i've added the two messages here - to show you that you can skin a cat in various ways
[11:55] Fu Barr: look carefully at the code in the new state...
[11:55] Fu Barr: msg1 is created by adding strings to the variable...
[11:55] Fu Barr: msg2 is created by adding all the strings in ONE go, but i've used line breaks to make it easier to read.
[11:56] Fu Barr: it doesn;t matter technically.
[11:56] Fu Barr: but you will discover as you develop your own style... that you prefer one way over the other
[11:56] Fu Barr: it's also a good way to show that scripts can do the same thing... or try and solve the same problem but they can look really different
[11:57] Fu Barr: this is one example of coding style.. we'll see another example later on
[11:57] Fu Barr: now - it should be pretty obvious what the script does so far.
[11:57] Fu Barr: any questions?
[11:57] Fu Barr: please note...
[11:57] Arielle Popstar: its not obvious to me
[11:57] Arielle Popstar: whats it do?
[11:58] Fu Barr: okay - ari - where does it hurt?
[11:58] Arielle Popstar: lol
[11:58] Verna Avril: < got it so far
[11:58] Fu Barr: well the script so far has declared a few variables... filled them with some data nd shown you the data
[11:58] Koni Lanzius: ty sweetie
[11:58] Fu Barr: nothing else.
[11:58] Fu Barr: :)
[11:59] Arielle Popstar: ok
[11:59] Fu Barr: :)
[11:59] Arielle Popstar: its not going to rock my world yet?
[11:59] Fu Barr: the note i was going to ads.. was...
[11:59] Fu Barr: nope
[11:59] Arielle Popstar: ok
[11:59] Fu Barr: this is bout 'innards' this is about code plumbing
[11:59] Fu Barr: not the sexy bits
[11:59] Fu Barr: but it's v important to get straight
[11:59] Fu Barr: next week when we pull it all together
[12:00] Fu Barr: then it'll be sexy. but this stuff has to be shown on its own else you get confused with all the other pyrothechnics going on
[12:00] Fu Barr: one thing to note.. is the LACK of QUOTES round the variable names
[12:01] Fu Barr: if you add quotes, single or double... then the script engine see them as strings
[12:01] Fu Barr: not as variable names
[12:01] Fu Barr: also the (string) bits on lines 43 44 47 49 50 and 53
[12:02] Fu Barr: those are needed to force the variable to cough up 'strings' and not integers or flots...
[12:02] Fu Barr: the variable keeps the data and the type inside of it...but you can only add strings to strings... not numbers... so you need for 'coerce' or 'cast' the non-string stuff into strigns.
[12:03] Fu Barr: it's very easy if you dont think about it too much - lol
[12:03] Fu Barr: you can only add strings to strings
[12:03] Fu Barr: so if the variable contains a non-string well you have the cast it to string by adding (string) in front of if.
[12:03] Fu Barr: *Hit
[12:03] Fu Barr: it's just one of those things in LSL
[12:04] Fu Barr: in other languages you dont have this issue
[12:04] BOB-omb Key!: Winding da bomb...........
[12:04] Fu Barr: but in LSL you do. All you can do is be aware of it,
[12:04] BOB-omb Key!: Thank you for winding me... and for taking full responsibility for the things I blow up!
[12:04] Fu Barr: okay - time to move to the next state...
[12:04] Fu Barr: remove the // from the state stament on line 59 and save
[12:05] Fu Barr: you should see more stuff fly past now
[12:05] Grid: Script saved
[12:05] Fu Barr: list_dump is a very short state. not a lot of code... but it does some important stuff.
[12:06] Fu Barr: what it does is it takes the contents of all the variables and sticks in a a list. it's like taking ziplocks worth stuff inside and then putting git in a bag.
[12:06] Fu Barr: but there' one MAJOR difference with Real Life
[12:07] Fu Barr: the list COPIES the content in the variable into itself
[12:07] Fu Barr: the data in the variable stays there
[12:07] Fu Barr: and a copy is inserted into the list
[12:07] Fu Barr: this is very important to understand
[12:08] Fu Barr: in computer science it's called copy-by-value
[12:08] Fu Barr: so in the end there are TWO copies of the data in memory
[12:08] Fu Barr: one in the variable one in the list
[12:08] Fu Barr: if you change the variable.... it does not affect th copy in the list
[12:09] Fu Barr: if you change the copy in the list... it does not affect the copy ing hte variable
[12:09] Fu Barr: the are seperate.
[12:09] Fu Barr: have i repeated this enough times? *chuckle*
[12:09] Verna Avril: kk
[12:09] Fu Barr: so that's what the line 68 does.
[12:10] Fu Barr: you use square brackets to say, the stuff in here has to be copied into the list
[12:10] Fu Barr: [ data, data, data, ]
[12:10] Fu Barr: and the list will keep the ORDER of the items
[12:10] Fu Barr: order in the list is important
[12:11] Fu Barr: because the only way to get something back out of the list is by knowing the item number
[12:11] Fu Barr: as we shall see later, you can ask the script engine to give you item 4 in list MyList
[12:11] Fu Barr: or item 5 or 17 or what have you
[12:12] Fu Barr: it's like getting your coat back after a theatre show
[12:12] Fu Barr: no number no coat
[12:13] Fu Barr: the stuff on lines 70 and 72 - that's just blabla - it just runs though the list and dumps the data as strings into a variable and that variable gets dumped to your screen
[12:13] Fu Barr: it's just to let you guys show that stuff actually happned in line 68
[12:13] Fu Barr: now theres something you should notice...
[12:14] Fu Barr: a real difference between the output of msg1 and msg2 and the list dump...
[12:14] Fu Barr: who can see it?
[12:14] Fu Barr: look back in your chat histry - if i havent confused you all or put you to sleep
[12:15] Fu Barr: there's something extra added to each item in the msg1 abnd msg2 output
[12:15] Fu Barr: okay - i'll give the answer...
[12:15] Fu Barr: msg1 and msg2 somehow add the NAMEof thevariable
[12:15] Fu Barr: to the output
[12:16] Fu Barr: llDUmpList2String... it doesn't
[12:16] Fu Barr: it just adds comma's and that's it
[12:16] Fu Barr: the list has NO IDEA what the name is of the data inside of it
[12:16] Fu Barr: it just contains the data
[12:16] Fu Barr: i'm sorry to keep on banging on about this.
[12:17] Fu Barr: it's a thankless task to bore you like this - but somebody's got to do it :)
[12:17] Fu Barr: taking one for the team i am here.
[12:17] albertlr Landar: well we appreciate the walk through
[12:17] Fu Barr: right. on we go
[12:18] Fu Barr: remove the // from line 74 and save - you'll see a LOT of stuff go past - take a minute to look at it.
[12:18] Grid: Script saved
[12:18] Fu Barr: this state shows some of the basic things you can do with the data in a list
[12:18] Arielle Popstar: where do i see this stuff go past
[12:18] Verna Avril: on the screen? nothing has moved
[12:19] Fu Barr: in your 'chat'
[12:19] Verna Avril: nothing in chat
[12:19] Arielle Popstar: just said script saved
[12:19] Verna Avril: yes
[12:19] Fu Barr: you need to remove the // on line 74 and the ones before that too... one 59 and 33
[12:20] Fu Barr: anybody else having the same issue?
[12:20] Arielle Popstar: yes, did that
[12:20] Verna Avril: yes did that
[12:20] Fu Barr: hmm, strange
[12:20] Fu Barr: have others seen the list stuff fly past
[12:20] Fu Barr: just checking
[12:20] Fu Barr: nobody?
[12:20] Arielle Popstar: they asleep :)
[12:21] Fu Barr: sigh.
[12:21] Fu Barr: lemme 2x check
[12:21] albertlr Landar: Mine just says Data tube: running: Fu's data examples v0.1
[12:21] Verna Avril: i opened this script from the inventory when it ws given to me // should have put it in a prim? the open?
[12:21] Verna Avril: *then open?
[12:21] Fu Barr: yeah - you need to put it in a prim...
[12:21] Arielle Popstar: oh
[12:21] Fu Barr: i just ran it and it seems to work fine.
[12:22] Total Sorbet: yes works
[12:22] Verna Avril: the tube? or another box?
[12:22] Fu Barr: box tube - anything makes no difference
[12:22] Object: Script running
[12:22] Object: running: New Script
[12:22] Object: msg1: integer: 1, float: 5.000000, uuid: xxxxxxe: Arielle Popstar, colour: <1.000000, 1.000000, 1.000000>
[12:23] Fu Barr: remove the default script and put in mine :)
[12:23] Arielle Popstar: ok now i see
[12:23] Fu Barr: phew...
[12:23] Fu Barr: much relieved
[12:23] Fu Barr: :)
[12:23] Arielle Popstar: was thinking this was all invisible
[12:23] Total Sorbet: yay
[12:23] Total Sorbet: :D
[12:23] Fu Barr: has a drink of water
[12:23] Verna Avril: yes it worked
[12:23] Fu Barr: okay - so now that we're all on the same-ish page...
[12:24] Fu Barr: you can see all that stuff running past on your chat screen
[12:24] Fu Barr: have a look at is... it should look 'similar' but it's the output of several list related functions...
[12:24] Fu Barr: let have a looksey in the code and then you can trace the output later in your own time
[12:25] Fu Barr: so...
[12:25] Verna Avril: yes it read my dame from the owner of the prim
[12:25] Verna Avril: name
[12:25] Fu Barr: on lines 82-92 - the state now figures out how long the list is.. and then starts walking through each 'index' each position or data item in the list
[12:25] Fu Barr: it's a computer
[12:26] Fu Barr: so it's very good at doing stupid things
[12:26] Fu Barr: so walking past each item in a long or short list - that's something it's very good at
[12:26] Fu Barr: so we only have 5 items in the list at the moment
[12:26] Fu Barr: and what the while koop does is visit every one of then IN ORDER
[12:27] Fu Barr: each time it visits an item... it increases the counter by 1
[12:27] Fu Barr: that counter is held by variable 'i'
[12:27] Fu Barr: and each time it visits a data item... it tells you what the data item is
[12:28] Fu Barr: that's the llOwnerSays part
[12:28] Fu Barr: that's in seciton 0
[12:28] Fu Barr: in section 1, we do something fun with the data
[12:28] Fu Barr: wel copy all the original data in the list to a NEW list
[12:29] Fu Barr: because we're going to manipulate the list add stuff, remove stuff... and in the next state we want the original 5 data items back
[12:29] Fu Barr: the simplest way of making sure you get your old databack unchanged... is to do all the changes on a copy
[12:30] Fu Barr: so that's what we do... we copy the data.
[12:30] Fu Barr: so: config2 = config
[12:30] Fu Barr: and then in lines 96 and 97 we add stuff to the new list... now called config2
[12:30] Fu Barr: kepp in mind we now have THREE copies of most of this data
[12:30] Fu Barr: in the original variables
[12:31] Fu Barr: in the original list config
[12:31] Fu Barr: and now in the list config2
[12:31] Fu Barr: but by line 97, only config2 has the extra data items
[12:32] Fu Barr: lines 99 to 107 are boilerplate... boring... they just dump the contents of config2 to the screen
[12:32] Fu Barr: lets look at 110
[12:32] Fu Barr: this is interesting
[12:32] Fu Barr: remember how i said the only way to get to a data item is through its index or 'number'
[12:32] Fu Barr: well, this is a prime example
[12:33] Fu Barr: llList2Key will take a list and an index and return the data in that position as a 'key' data type
[12:33] Fu Barr: there's llList2Integer and llList2String and llList2Float.. etc. etc.
[12:33] Fu Barr: you get the idea.
[12:34] Fu Barr: now in 112
[12:34] Fu Barr: i do something 'dangerous'
[12:34] Fu Barr: i REPLACE part of the list with something else
[12:34] Fu Barr: ina REPLACEMENT you LOSE the information that was there in the first place.
[12:34] Fu Barr: gone. forever
[12:35] Fu Barr: so if i wanted to data back... i need to make sure... i had a copy made first
[12:35] Fu Barr: which is what i did in line 110
[12:35] Fu Barr: look carefully at line 122
[12:35] Fu Barr: it say...
[12:35] Fu Barr: [llGetKey(), llGetTexture(0)]
[12:35] Fu Barr: see those square brackets...
[12:36] Fu Barr: remember what we siad aout square brackets and lists...
[12:36] Fu Barr: so what i'm doing here..is i;m replacing data item 2 in my list with a list of two other items...
[12:36] Fu Barr: that''s what the function is saying
[12:37] Fu Barr: replace in config2, from position 2 to 2 with data with [llGetKey(), llGetTexture(0)]
[12:37] Fu Barr: *the data
[12:37] Fu Barr: so item 2 gets removed and two items get added
[12:37] Fu Barr: so the list gets longer
[12:37] Fu Barr: and the other data itms get NEW NUMBERS
[12:38] Fu Barr: in your own time... look through the log in chat and you'll see it happen
[12:38] Fu Barr: now on to line 124
[12:39] Total Sorbet: um line 124 is empty for me
[12:39] Fu Barr: the data that i rescued from index 2 before i did the replacing... i now put back into tjhe list
[12:39] Fu Barr: oops... i'm at:
[12:39] Fu Barr: 3. re-insert old item 2 at position 4
[12:39] Fu Barr: and the code is:
[12:39] Fu Barr: config2 = llListInsertList(config2, item, 4);
[12:40] Fu Barr: so just for those who are starting to feel the ice crack beneath thier feetsies
[12:40] Fu Barr: i'll go slow in explaining config2 = llListInsertList(config2, item, 4);
[12:41] Fu Barr: what i want to do is insert the data i saved back into the list. the data i save is in a variable i created called 'item'
[12:41] Fu Barr: the llListInsertList function... needs to knwo three things to do its job
[12:41] Fu Barr: it needs to know which list to insert into.
[12:41] Fu Barr: it needs to know what to insert
[12:42] Fu Barr: and it needs to know at which positino in the list to insert
[12:42] Fu Barr: that exactly what this line does:
[12:42] Fu Barr: config2 = llListInsertList(config2, item, 4);
[12:42] Fu Barr: config2 should now become whatever the result is of the llListInsertList() function
[12:43] Fu Barr: i can't explain it clearer than that - i;m sorry :(
[12:43] Total Sorbet: mmn llListInsertList() is like pushing your way into the bus queue...
[12:43] Fu Barr: now yes
[12:43] Fu Barr: exactly
[12:43] Total Sorbet: those towards end of list get pushed further away from start of list and make room for your new item(s)
[12:44] Fu Barr: exact
[12:44] Fu Barr: and if you come with a friend and both push in line... the people move back 2 positinos
[12:45] Fu Barr: anyhow - i hope if you run the script a few times and you compare the output in chat with the code... By the Power of Greyskull - you will hopefully understand!
[12:45] Fu Barr: now we come to the part where the more advanced scripters might find something interesting too...
[12:46] Fu Barr: the list datasctructure is the only 'built-in' one the LSL gives you
[12:46] Fu Barr: but there are many very useful datastructures out there.. and they can be used to sort and store data relevant to all sorts of things you are trying to solve
[12:47] Fu Barr: i'm going to introduce one such structure
[12:47] Fu Barr: it's called a 'map'
[12:47] Fu Barr: and it's super useful all over the place.
[12:47] Fu Barr: what a map does is it fixes the issue of a list that you can only pick data from it by its NUMBER
[12:48] Fu Barr: with a map you can pick data from a list by a NAME
[12:48] Fu Barr: which for most humans is the better way to do it
[12:48] Fu Barr: the idea is you have a 2nd list that's the same length as the first list...
[12:48] Fu Barr: and in the second list.. you keep the names of the data in the first list
[12:49] Fu Barr: as long as the index - the positions - of the name in list 2 and the data in lsit 1 stay synchronised... you're good to go
[12:49] Fu Barr: lets' look at the code...
[12:49] Fu Barr: uncomment 137 (//state map)
[12:49] Fu Barr: save and look at the chat results
[12:50] Object: running: New Script
[12:50] Object: msg1: integer: 1, float: 5.000000, uuid: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, name: Arielle Popstar, colour: <1.000000, 1.000000, 1.000000>
[12:50] Object: msg2: integer: 1, float: 5.000000, uuid: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, name: Arielle Popstar, colour: <1.000000, 1.000000, 1.000000>
[12:50] Object: list dump: 1, 5.000000, xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx, Arielle Popstar, <1.000000, 1.000000, 1.000000>...
12:50] Total Sorbet: line 132 for me
[12:50] Fu Barr: it should tell you exactly what's going on.. but let's look in the code and wrap up the lesson :)
[12:50] Fu Barr: line 160... it says: list settings = ["DEBUG", "seconds", "uuid", "name", "colour"];
[12:50] Fu Barr: notice the QUOTES
[12:51] Fu Barr: these are stings, not variables
[12:51] Fu Barr: *strings even
[12:51] Fu Barr: but they are the right order for the data in the 'config' list we filled above
[12:52] Fu Barr: now in line 173 i set: string setting = "colour";
[12:52] Fu Barr: i'm looking for the setting called colour
[12:52] Fu Barr: i search for the index of that item in the settings list... line 175
[12:52] Fu Barr: i stick it in variable i
[12:53] Fu Barr: then i use that number to find the value in config - line 17
[12:53] Fu Barr: we'll see next week (if i havent frightened you all away) how we use this stuff all the time - but in an easier 'black box' way.
[12:54] Fu Barr: so to recap - to find a data item in a list by its name... we use a second list to hold only name
[12:54] Fu Barr: the lists are kept in sync so if i find name at positino 3 i know the data will be at postion 3 in the other list
[12:55] Fu Barr: dassit. simple really :)
[12:55] Fu Barr: the final part lines 179 - 198
[12:55] Fu Barr: is a way to do this using only ONE list.
[12:55] Fu Barr: it's a bit like weaving the two lists together
[12:56] Fu Barr: it's called a 'strided list' and i leave it as an exercise to those who are interested to figure out. feel free to IM me for questions
[12:56] Fu Barr: dassit.
[12:56] Fu Barr: please fight a bit with the code
[12:56] albertlr Landar: Now you can use notecards to store data, and then retrieve it also is that not so Fu?
[12:57] Fu Barr: read it a few times... it might be a bit much to take in in one go - but it's really important to any scripting you might want to undertake
[12:57] Total Sorbet: ty fu will do
[12:57] Fu Barr: yes that's true - but you still need lists to manipulate data and do sooo many things in scripting.
[12:57] Fu Barr: you simple cannot do any serious scripting without lists
[12:58] Fu Barr: so that's why i decided to spend a whole lesson talking aout them
[12:59] albertlr Landar: Thanks for the explanations on how its handled


{L_CODE}:
/*
    Data - some examples

    (c)2018 Fu Barr @OSgrid
*/

// Data types: integer, float, key, string, vector (rotation)
integer DEBUG = TRUE;

float   seconds = 5.0;
key     uuid;

string  name;
vector  colour = <1, 1, 1>;   // <r, g, b>

// Data structure: list
list    config;

default {

    on_rez(integer r){

        llResetScript(); // Health and Safety regulations demand this.
    }

    state_entry() {

        llOwnerSay("running: " + llGetScriptName());

        // 0. now that we're running, get some relevant data
        uuid = llGetOwner();
        name = llGetDisplayName(uuid);

        //state data_dump;
    }
}

state data_dump {

    state_entry() {

        if(DEBUG) {

            string msg1  = "integer: "  + (string) DEBUG;
                   msg1 += ", float: "  + (string) seconds;
                   msg1 += ", uuid: "   + uuid;
                   msg1 += ", name: "   + name;
                   msg1 += ", colour: " + (string) colour;

            string msg2 = "integer: "  + (string) DEBUG
                        + ", float: "  + (string) seconds
                        + ", uuid: "   + uuid
                        + ", name: "   + name
                        + ", colour: " + (string) colour;

            llOwnerSay("msg1: " + msg1);
            llOwnerSay("msg2: " + msg2);
        }

        //state list_dump;
    }
}

state list_dump {

    state_entry() {

        // 0. Copy the data values from above into the empty list and show them
        config = [DEBUG, seconds, uuid, name, colour]; 

        string dump = llDumpList2String(config, ", ");

        llOwnerSay("list dump: " + dump);
       
        //state list_operations;
    }
}

state list_operations {

    state_entry() {

        // 0. setup loop variables and loop through list
        integer i = 0;
        integer list_end = llGetListLength(config);

        while (i < list_end) {

            llOwnerSay("list at index(" + (string) i + ") " + llList2String(config, i));

            i++;
        }

        // 1. copy original data into new list and add more data to end of new list
        list config2 = config;

        config2 += "another string";
        config2 += 3.14;

        i = 0;
        list_end = llGetListLength(config2);

        while (i < list_end) {

            llOwnerSay("list at index(" + (string) i + ") " + llList2String(config2, i));

            i++;
        }

        // 2. retrieve item at index(2) and replace with new data
        key item = llList2Key(config2, 2);

        config2 = llListReplaceList(config2, [llGetKey(), llGetTexture(0)], 2, 2);

        i = 0;
        list_end = llGetListLength(config2);

        while (i < list_end) {

            llOwnerSay("list at index(" + (string) i + ") " + llList2String(config2, i));

            i++;
        }

        // 3. re-insert old item 2 at position 4
        config2 = llListInsertList(config2, item, 4);
       
        i = 0;
        list_end = llGetListLength(config2);

        while (i < list_end) {

            llOwnerSay("list at index(" + (string) i + ") " + llList2String(config2, i));

            i++;
        }

        //state map;
    }
}

state map {

    state_entry() {

        /*
            A map is a classic datastructure where data values are 'mapped' on to named keys.

            Values can be anything, keys need to be unique.
           
            Typically, a map looks like this:
           
            key1 = valueX
            key2 = valueY
            key3 = ValueZ
            ...
        */

        // 0. Add a 2nd list of setting names to setup the keys for the existing config data list,
        //    then loop the two lists to show the mapping.
        list settings = ["DEBUG", "seconds", "uuid", "name", "colour"];

        integer i = 0;
        integer list_end = llGetListLength(settings);

        while (i < list_end) {

            llOwnerSay("map key:value pair " + llList2String(settings, i) + ":" + llList2String(config, i));

            i++;
        }

        // 1. Find index of a particular setting and then print its current value
        string setting = "colour";

        i = llListFindList(settings, [setting]);

        llOwnerSay("map lookup result: " + setting + ":" + llList2String(config, i));

        // 2. Now for something different: setting up a single strided list to use as the map.
        list strided_list = [];

        i = 0;

        while(i < list_end) {

            strided_list += llList2String(settings, i);
            strided_list += llList2List(config, i, i);

            i++;
        }

        llOwnerSay("map strided list: " + llDumpList2String(strided_list, ", "));

        // 3. pick a key:value pair from the new strided list-based map
        llOwnerSay("map strided list lookup result: " + setting + ":" +
                    llList2String(strided_list, llListFindList(strided_list, [setting]) + 1)
                  );
    }
}



** Put the script in an object/prim before running the changes in the lesson.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post a new topicPost a reply Page 1 of 1   [ 4 posts ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron


Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
610nm Style by Daniel St. Jules of Gamexe.net