Scripting Tutorial 03

From Osgrid Wiki
Jump to: navigation, search
[12:21]  Fu Barr: now, i figured that most of you might not have time to do homework, so i did my own homework - and i did it in stages so you can see how I approached the problem
[12:23]  Fu Barr: so without further ado i'm going to give you all the first version of my script and then we'll have a look at it
[12:23]  Fu Barr: everybody please wave at the Master :)
[12:24]  Fu Barr: that's Total by the way :)
[12:24]  Koni Lanzius: hi Total!
[12:24]  Total Sorbet hides
[12:24]  Fu Barr gave you Fu's door script v0.0.
[12:24]  Fu Barr: everybody got the script v0.0?
[12:24]  Total Sorbet: yes
[12:25]  Koni Lanzius: yes
[12:25]  Arya Paul: yes
[12:25]  Fu Barr: cool - so what this first version is doing is setting up the 'lay of the land'
[12:25]  Fu Barr: i need to start someplace
[12:25]  Fu Barr: every script needs to start someplace and i like to start TOP-DOWN
[12:25]  Fu Barr: meaning from the general idea to the little details
[12:26]  Fu Barr: in our door case that means that i will sketch in the states i think i need
[12:26]  Fu Barr: so what states do i need... well, the door will be open and closed.
[12:26]  Fu Barr: so that two states right there
[12:26]  Fu Barr: so i put them in
[12:26]  Object: Script running
[12:26]  Fu Barr: like we saw in lessons 1 and 2
[12:27]  Fu Barr: then I know from experience that i'll also need to do some initialization of stuff
[12:27]  Fu Barr: so i do that in the default state
[12:27]  Fu Barr: so now i have 3 states
[12:27]  Object: Locked.
[12:27]  Fu Barr: so now lets look at the code
[12:28]  Fu Barr: i've got a default state that does nothing more than run, tell me which version of my script is running and hands of control to the next state
[12:28]  Fu Barr: in my head the natural state of a door is closed
[12:28]  Fu Barr: so the default state goes to the closed state
[12:28]  Fu Barr: nice.
[12:29]  Fu Barr: in the closed state in need to setup some of the basic interaction with the bloody door
[12:29]  Fu Barr: at least let me click on it
[12:29]  Fu Barr: so i handle the touch_end() event
[12:29]  Fu Barr: it does next to nothing but the event handler now has a 'stub'
[12:30]  Fu Barr: a stub is a little bit of code that just exists as a placeholder - it's waiting to be expanded
[12:30]  Fu Barr: but as i;m going top->down
[12:30]  Fu Barr: i don't want to give it much detail yet
[12:30]  Fu Barr: i just need it to exist in a minimal fashion
[12:31]  Fu Barr: the other point of our door was that we wanted it to be lockable via chat
[12:31]  Fu Barr: *door
[12:31]  Fu Barr: so i put in a llListen() and a listen() event handler
[12:31]  Fu Barr: and here's a little 'trick' if you will
[12:32]  Fu Barr: the way i;m calling llListen() - with the "lemmein!" parameter
[12:32]  Fu Barr: this will _limit_ the listed
[12:32]  Fu Barr: *listen
[12:32]  Object: Locked.
[12:32]  Object: Locked.
[12:33]  Fu Barr: in other words it cuts the load on the server dramatically - because the listen() event handler wont fire on every chat event
[12:33]  Fu Barr: now
[12:33]  Fu Barr: notice that i'm using a COMMENT
[12:33]  Fu Barr: to remind myself that this is what i'm doing here.
[12:33]  Fu Barr: otherwise 3 months from now i might get confused what i read my code
[12:34]  Fu Barr: i will definitely forget that i was being clever, and doing a very early filter and i'm going to wonder why i'm not doing any testing inside the listen()
[12:34]  Jeff Hall: even more if u give code to another one(...)
[12:34]  Fu Barr: so there's a good example of how i think you should use comments
[12:34]  Fu Barr: exaclty
[12:35]  Fu Barr: so we've seen default and closed now let's go to open state
[12:35]  Fu Barr: open state really isn't interesting at this point in my development
[12:36]  Fu Barr: i just need it to indicate that the flow of my script got there and then it needs to 'close' the door again
[12:36]  Fu Barr: remember i don't have an actual door - so i need to have the script 'tell me' that the door has been 'opened'
[12:36]  Fu Barr: that's all the open state does - at this moment
[12:36]  Fu Barr: so there you have it, the basic layout of states for my door.
[12:37]  Fu Barr: no details, but all the bits are in place.
[12:37]  Fu Barr: this is called top-down programming.
[12:37]  Fu Barr: from general parts to details
[12:37]  Fu Barr: of course there is also bottom-up programming
[12:37]  Fu Barr: where you go the other way - but my brain prefers top->down
[12:38]  Fu Barr: any questions so far?
[12:38]  Jeff Hall: makes no sense to start from details to main idea i think
[12:38]  Jeff Hall: so i'm top-down too
[12:38]  Fu Barr: well- i can go into details about that, but say for example you use Visual Studio or some other IDE with intellisense or some code completing technology
[12:39]  Fu Barr: the IDE will force you to use the full function calls etc. it's get in your way and you'll be forced to work bottom->up
[12:39]  Fu Barr: anyhow - just as an aside for those who code outside of opensim :)
[12:40]  Fu Barr: so - now i'm going to drop v0.1 of the script
[12:40]  Koni Lanzius: Headmaster, i have a semi-related question: Are coding and scripting the same thing? :)
[12:40]  Fu Barr: will give you both v0.0 and v0.0 :)
[12:40]  Fu Barr: basically - yes
[12:40]  Koni Lanzius: ahh
[12:40]  Fu Barr: pun not intended!
[12:40]  Jeff Hall: just different platforms
[12:41]  Jeff Hall: programming logic is the SAME no matter which language u use
[12:41]  Fu Barr gave you Fu's door script v0.1.
[12:41]  Fu Barr: so - i think i dropped the script on everybody - who did i miss?
[12:42]  Fu Barr: nobody - nice. oh fae - before i forget
[12:42]  Fu Barr: you can read the transcripts of the previous sessions on the wiki:
[12:42]  Fu Barr: and *_02
[12:42]  Fu Barr: i really hope somebody is logging this session - with Foxx not here
[12:43]  Total Sorbet: i think i've got logging on
[12:43]  Fu Barr: okay so the next stage in me trying to explain how i go about building my scripts and how i think you should be looking at building yours - is to start thinking about 'making things generic'
[12:44]  Fu Barr: making things generic is one of the most powerful ideas in code.
[12:44]  Fu Barr: it's the doorway to patterns and solving 'types' of problems rather than one problem.
[12:45]  Fu Barr: but in our case it's about starting to think about structre and data and making things multi-purpose which will allow us to use less code. and less code means less opportunity for errors and complexity.
[12:45]  Fu Barr: lots of words - lets just look at the new code and see what i'm harping on about :)
[12:45]  Fu Barr: if you open v0.1
[12:46]  tuto3-01: Locked.
[12:46]  Fu Barr: so - first thing you'll notice is that at the top I've added a few lines of comment that tell me/remind me what this version changes over the previous one
[12:47]  Fu Barr: again this helps me not go crazy when i see my code 6 months from now
[12:47]  Fu Barr: there are many ways of doing this in the RL work - source code management and svn/git etc. etc. but in opensim - this will do just fine
[12:47]  Koni Lanzius: how do you indicate something as just text and not code? I see it is a different color
[12:48]  Fu Barr: now at the top of the script you now see a bunch of 'declaration'
[12:48]  Fu Barr: yes
[12:48]  Jeff Hall: use "//"
[12:48]  Koni Lanzius: ahh
[12:48]  Fu Barr: comments in code are prefaced with //
[12:48]  Koni Lanzius: good to know
[12:48]  Fu Barr: or you can use /* .... */
[12:48]  Fu Barr: the // comment style works from ONE line
[12:48]  Fu Barr: *for
[12:48]  Jeff Hall: for long pieces of codes yes
[12:48]  Fu Barr: the /* ... */ is for more lines
[12:49]  Fu Barr: the // comes from the language C++
[12:49]  Fu Barr: the the /* */ from the older C
[12:49]  Fu Barr: now...
[12:49]  Fu Barr: see how there's a bunch of variables up top?
[12:49]  Koni Lanzius: yes
[12:49]  Fu Barr: one integer
[12:49]  Fu Barr: and 4 strings
[12:50]  Fu Barr: notice how i've given them names according to a pattern
[12:50]  Koni Lanzius: variables are the integers and strings?
[12:50]  Fu Barr: ***_YYY
[12:50]  Fu Barr: yes
[12:50]  Fu Barr: integer is a number variable
[12:50]  Fu Barr: string is a words variable
[12:51]  Fu Barr: you cant stick a number into a string and still use it as a number for say math
[12:51]  Fu Barr: and you cant have a number 'word' in a n integer either
[12:51]  Fu Barr: so, as you can see there's a pattern to my variable names
[12:52]  Fu Barr: who wants to have a go at telling me what the names might mean
[12:52]  Fu Barr: nobody?
[12:52]  Fu Barr: ok - i'll just explain
[12:52]  Fu Barr: :)
[12:52]  Jeff Hall: i don't understand your question
[12:53]  Fu Barr: the first string is sec_passphrase
[12:53]  Fu Barr: the three other strings are names txt_something
[12:53]  Koni Lanzius: the names define the action of that bit of code, yes?
[12:53]  Fae Peep: does the passphrase unlock the door?
[12:53]  Fu Barr: the thing here is that I've added a little 'code' to each variable to help me understand which part of the script it belongs to
[12:54]  Fu Barr: exactly
[12:54]  Fu Barr: t unlocks the door
[12:54]  Jeff Hall: ooh lol
[12:54]  Jeff Hall: ok Fu
[12:54]  Jeff Hall: was tto obvious sorry
[12:54]  Fu Barr: so for the purpose of this script i've decided that all variables that have to do with 'security'
[12:54]  Fu Barr: get the preface code 'sec_'
[12:54]  Koni Lanzius: i see
[12:55]  Fu Barr: and all variables that are just text in my responses etc. i decided to call them 'txt_'
[12:55]  Fu Barr: what this help me do is REDUCE the need for comments
[12:55]  Fu Barr: no more orange
[12:55]  Jeff Hall: u could have used str instead txt too
[12:55]  Fu Barr: less orange makes for easier to read code
[12:56]  Jeff Hall: just a manner of taste
[12:56]  Fu Barr: yes - jeff - you're right i could have used anything i wanted but for this set of examples 'txt_' seemed more 'clear'
[12:56]  Jeff Hall: ill be silent now, its just too personal:)
[12:56]  Fu Barr: but of course you're right :)
[12:57]  Fu Barr: the point is that giving your variables sensible names help you read the code
[12:57]  Fu Barr: i've seen SO MANY scripts in LSL where the scripter writes the code TWICE
[12:57]  Fu Barr: once in the ocde and once inthe comments
[12:57]  Fu Barr: every line has an orange shadow
[12:57]  Fu Barr: this line does this and the next line does that
[12:57]  Fu Barr: it's moronic
[12:58]  Fu Barr: just write clean and clear code and read the effing code.
[12:58]  Fu Barr: no need to explain in comment what you did - i can read the code - so i can see what it does!
[12:58]  Fu Barr: what i want to know is WHY did you do something
[12:59]  Total Sorbet: good call
[12:59]  Jeff Hall: u have 2 schools FU if u permit: some will write very few and some will write more  unless you tell the obvious
[12:59]  Koni Lanzius: so the color code is orange text, green actual code and black is...?
[12:59]  Fu Barr: so if i cant figure out from the code why on earth is the scripter doing this here? the scripter should have realized, oops i;m doing strange things here - let's leave a comment so the next person (could be me in 6 months) will know what' made me do it in this way
[13:00]  Jeff Hall: some code can be very obscure and u wont complain about having too many comments unless u have sme  like: i will say something followed by llSay
[13:01]  Fu Barr: lol - jeff - of course it's always a judgement call, but on the whole if you use clear variable names and function names - you can reduce 80% of the orange in most scripts :)
[13:02]  Jeff Hall: i agree Fu but i  meant with long scripts, vehicles and all
[13:02]  Fu Barr: so - anymore questsions about the variable names thing?
[13:02]  Jeff Hall: but yes:)
[13:02]  Total Sorbet: i've seen some folk use a naming convention for globals vs locals?
[13:02]  Fu Barr: yes
[13:03]  Fu Barr: a well known one is blabla for globale and _blabla for locals
[13:03]  Fu Barr: locals get an underscore
[13:03]  Fu Barr: it's just more convention that programmers/coders/scripters develop in as they figure out what makes their lives easier at the codeface
[13:04]  Total Sorbet nods
[13:04]  Total Sorbet: g is a common one too
[13:04]  Fu Barr: of course what i;m showing you here is totally my own style/preference
[13:04]  tuto3-01: Locked.
[13:04]  tuto3-00: Locked.
[13:04]  Fu Barr: and i;m hoping that you'll pick up on the concepts and either agree with me, or develop your own style.
[13:05]  Matilda Charron: those boxes are locked
[13:05]  Fu Barr: basically all of this is called 'literate programming'
[13:05]  Jeff Hall: we call it sharing;)
[13:05]  Arya Paul: I, for one, as a total noob to this, very much appreciate your clear logic!
[13:05]  Fu Barr: thanks!
[13:06]  Fu Barr: okay lets go back into the meat of the script
[13:06]  Matilda Charron: 0.0 or 0.1?
[13:06]  Fu Barr: if we look at the states...
[13:06]  Fu Barr: 0.1
[13:06]  Fu Barr: nothing has changed in the top level - still 3 states
[13:07]  Fu Barr: if we look at the defaults state... literally nothing has changed
[13:07]  Fu Barr: nice. easy. next
[13:07]  Fu Barr: the closed state...
[13:07]  Fu Barr: state_entry() handler - same
[13:07]  Fu Barr: but the touch_end() has changed
[13:08]  Fu Barr: now the llSay() doesnt have the actual words to say n now use this same code in several 'languages'
[13:11]  Fu Barr: or rather: if i wanted to i could adpat the code to be multi-laguage
[13:11]  Jeff Hall: i have a question FU?
[13:11]  Fu Barr: shoot
[13:11]  Jeff Hall: the integer DEBUG = FALSE;?
[13:12]  Fu Barr: yes
[13:12]  Jeff Hall: i never used that yet
[13:12]  Fu Barr: hehe - i'm exactly getting to that now
[13:12]  Fu Barr: :)
[13:13]  Jeff Hall: k listening lol
[13:13]  Fu Barr: so, any questions about how I've replaced the literal words to say in the llSay() with a variable?
[13:13]  Fu Barr: cool
[13:13]  Fu Barr: you all sooo clevvah
[13:13]  Fu Barr: !
[13:13]  Fu Barr: :)
[13:13]  Fu Barr: now, the last thing that's changed is the listen() event handler
[13:14]  Arya Paul: so, if you are working on something more complex and reallize you need, say, a new would just go back to the top and add it there, yes?
[13:14]  Fu Barr: yes - exactly
[13:15]  Fu Barr: it means you dont have to go digging so much in your code
[13:15]  Fu Barr: and it also means you can reuse the same variable content in many places in your code
[13:15]  Fu Barr: once you start writing your own scripts you'll see how super impossibly handy it is to use variables
[13:15]  Total Sorbet: hehe
[13:16]  Fu Barr: so, now to answer jeff's question
[13:16]  Jeff Hall: i can vouch on that too:)
[13:16]  Fu Barr: about the DEBUG variable
[13:16]  Fu Barr: this is one of the main 'concepts' about code/scripting that i want you to learn this session
[13:16]  Fu Barr: and that's the notion of 'debugging'
[13:17]  Fu Barr: often your script will go through various states of broken
[13:17]  Fu Barr: it doesn;t bloody work like you expected it to
[13:17]  Fu Barr: grrrrr. stupid machines!
[13:17]  Fu Barr: but...
[13:17]  Fu Barr: there is hope.
[13:18]  Fu Barr: the first thing to know is sometimes you just forgot a comma someplace. that's just how it is. and yes, you will have lost 5 days trying to find where the comma is missing - but you win some you lose some
[13:18]  Fu Barr: 2. sometimes you just aren't doing the right thing
[13:19]  Fu Barr: the function you are using isn't the right one.
[13:19]  Arya Paul: that happens to me with the opensim software...and I'm sure when you find it, you do the same HAPPY DANCE
[13:19]  Fae Peep: sometimes it says error in line whatever to give you a clue.... well hopefully
[13:19]  Fu Barr: the idea you had of how to solve a certain problem - you just haven't figured it out yet
[13:19]  Fu Barr: that's totally acceptable too.
[13:19]  Arya Paul: the saving grace is LOGIC
[13:20]  Fu Barr: sometimes you're just doing new stuff. nobody has done this before, and you need to make mistakes to figure it all out. that fine too.
[13:20]  Fu Barr: the point is all code has flaws and mistakes and that's OK.
[13:20]  Fu Barr: but there's one thing that is PARAMOUNT in fixing this stuff and that is INFORMATION
[13:20]  Fu Barr: you need to know EXACTLY what is going where.
[13:20]  Fu Barr: which numbers are in what variable
[13:21]  Fu Barr: that strings are being sent into the event handler
[13:21]  Fu Barr: if you don't KNOW what the information is that is sloshing around your code - forget it
[13:21]  Fu Barr: you will never get the code to work
[13:21]  Fu Barr: and unfortunately the code editing environment in the viewers - it's toog: crash?
[13:30]  Total Sorbet: yeah all of us it would seem
[13:30]  Total Sorbet: good?!
[13:31]  Fu Barr: states are your friends
[13:31]  Matilda Charron: I was using states the other day and then gave it away
[13:31]  Matilda Charron: alright, well I thought i read something about them being a problem and not working so well
[13:31]  Fu Barr: okay i'm going to open v0.1 again and get back to explained the DEBUG thing on line 40
[13:32]  Jet rapture is Online
[13:32]  Fu Barr: so like i was saying pre-creash.... i want to know what's going on.
[13:32]  Fu Barr: so i;m asking the script to tell me who's doing the talking on the chat channel
[13:33]  Fu Barr: if you remember in the 1st session we looked at the meaning of the parameters of the listen() event handler
[13:33]  Fu Barr: the 'key uuid' part the 3rd parametr... that's the variable that hold the UUID of the avatar or prim or linkset that did the chatting
[13:34]  Fu Barr: so what i;m asking the script to do is tell me what the value is INSIDE of that variable.
[13:34]  Fu Barr: i;m adding a bit of text myself
[13:34]  Fu Barr: this: closed::listen() Passphrase spoken by:
[13:34]  Fu Barr: it means that in the state closed
[13:34]  Fu Barr: in the listen() event handler
[13:34]  Fu Barr: the passphrases was spoken... etc.
[13:35]  Fu Barr: now this is more of my inventions
[13:35]  Fu Barr: i like it this way
[13:35]  Fu Barr: but you can do it your way
[13:35]  Fae Peep: can anyone get in with the correct passphrase?
[13:35]  Fu Barr: you can just dump the value with llOwnerSay() - no extra informatino
[13:35]  Fu Barr: well in this version - yes
[13:36]  Fu Barr: so that is jeff - what the DEBUG does
[13:36]  Fu Barr: the DEBUG variable controls wether or not my debugging aids are going to echo to the coder
[13:37]  Fu Barr: if i switch the DEBUG variable to FALSE - then the script stays silent
[13:37]  Fu Barr: if i set the DEBUG variable to TRUE - well the the script start to be chatty :)
[13:37]  Fu Barr: so while i'm developing the script i want to KNWO what's going on so it's set to TRUE
[13:38]  Fu Barr: when the script is ready i can set it to FALSE
[13:38]  Fu Barr: and when i know its a good script and i;ve been using it for weeks
[13:38]  Matilda Charron: will the script be still listening even if false?
[13:38]  Fu Barr: then i can remove the whole DEBUG stuff from the script entirely
[13:38]  Fu Barr: yes
[13:39]  Matilda Charron: ok so what goes into the default state entry
[13:39]  Fu Barr: matilda - the listening has nothing to do with the DEBUG :)
[13:39]  Jeff Hall: ok is your custom way Fu i see well:)
[13:39]  Fu Barr: matilda - anything you like :)
[13:39]  Matilda Charron: the debug is within an listen event
[13:42]  Fu Barr: okay - well let's go to the next version of the script v0.2!
[13:42]  Fu Barr: yay!
[13:43]  Matilda Charron: I need 0.2 pls
[13:43]  Koni Lanzius: thank you Fu :)
[13:43]  Fu Barr: matilda - i must about to give out v0.2 :)
[13:43]  Matilda Charron: lol ok Fu
[13:44]  Fu Barr gave you Fu's door script v0.2.
[13:44]  Fu Barr: right - i'm going to give you guys a few minutes to read through the script
[13:45]  Fu Barr: then i;m going to run through it a little faster as a lot of the basics we've covered
[13:46]  Fu Barr: brb - going to put on socks - getting a bit chilly :)
[13:46]  Arya Paul: where ARE you that it's chilly??
[13:49]  Arya Paul: are your feet warm now?
[13:50]  Fu Barr: everybody have a look at the new scripts v0.2?
[13:50]  Jeff Hall: u have 2 options now
[13:50]  Fu Barr: yes nice and cosy, woooooohm
[13:50]  Jeff Hall: u can lock or unlock
[13:50]  Arya Paul: yes, we were studying it. We were not talking about the weather....... ;)
[13:50]  Fu Barr: well you have one option - locking door :)
[13:51]  Jeff Hall: haha Arya and Mati:)
[13:51]  Fu Barr: now if you look first at the variable section
[13:51]  Fu Barr: at the top
[13:51]  Fu Barr: you'll see some more variable NAMES ins CAPS
[13:51]  Fu Barr: this is a very very old convention
[13:51]  Fu Barr: think 1960's old
[13:51]  Fu Barr: and it's one that I have taken form the C language
[13:52]  Fu Barr: and it is a way of showing that the value in that variable never changes
[13:52]  Fu Barr: technically it could. after all it's a variable
[13:55]  Fu Barr: sec_latch = "open"
[13:55]  Fu Barr: or
[13:56]  Fu Barr: sec_latch = "closed"
[13:56]  Fu Barr: but there's a tradition in code to do this sort of thing using a constant. why?
[13:56]  Fu Barr: because you can list the constants op first and then you have a overview of the possible values the latch can have
[13:57]  Fu Barr: it's more of the self-documenting stuff we're spoken about earlier
[13:57]  Fu Barr: *we've
[13:57]  Fu Barr: look at line 31
[13:57]  Fu Barr: sec_latch = SEC_UNLOCKED
[13:58]  Fu Barr: first of all i'm using my sec_ convention
[13:58]  Fu Barr: so i know this is a security related thing
[13:58]  Fu Barr: then i;m using the CONSTANT - so having looked at the SEC_ stuff op in the variables, i have an immediate 'feel' for the other possible values
[13:59]  Fu Barr: to my mind it just makes the code easier to understand
[13:59]  Jeff Hall: when u assume 'sec ' relates to security  and not other things
[13:59]  Fu Barr: well exactly - and given that that is the convention is set in place in this script - yes you're absolutely right
[14:00]  Fu Barr: in some other script i might have some other convention - whatever works to make the code clear _in_ the code. without comments :)
[14:00]  Fu Barr: now the next thing that is different is in the closed state
[14:00]  Jeff Hall: u are from other school with comments and its fine really:)
[14:01]  Jeff Hall: i comment more , for me and for other people
[14:01]  Fu Barr: who wants to have a go at explaining why there are suddenly TWO listens in the state_entry()?
[14:02]  Fu Barr: lol - nobody?
[14:02]  Jeff Hall: they expect different answers
[14:02]  Fu Barr: :) :)
[14:02]  Fu Barr: yes, they do
[14:02]  Greybeard Thinker is Offline
[14:02]  Fu Barr: but why am i doing that - i could also handle that issue in the listen() event handler?
[14:03]  Fu Barr: common guys - it's in the comment :)
[14:03]  Fu Barr: what am i trying to avoid?
[14:03]  Matilda Charron: lol
[14:03]  Matilda Charron: the wrong answer
[14:03]  Fu Barr: let's back up a bit
[14:03]  Fu Barr: remember how llListen()
[14:03]  Arya Paul: I'm reading the comment...just not following it :(
[14:03]  Fu Barr: has a bunch of parameters
[14:04]  Fu Barr: each of these parameters is needed to make llListen work
[14:04]  Fu Barr: how does llListen work? well it's like a big ear in the server
[14:04]  Fu Barr: it listens to EVERYTHING
[14:04]  Fu Barr: by default
[14:05]  Fu Barr: and if we're chatting our heads off - it'll call the event handler all the time!
[14:05]  Fu Barr: this will make the server unhappy
[14:05]  Arya Paul: so it's listening for the lemmein or keepmeout?
[14:05]  Fu Barr: lots of possible lag. not in one script, but if there's a bunch of them... and a lot of people in one place... like wright or some other plaza... it adds up
[14:05]  Fu Barr: exatly.
[14:06]  Fu Barr: so what i;m doing is using seperate listens to FILTER what the server reacts to
[14:06]  Fu Barr: the server doesn;t mind LISTENING
[14:06]  Fu Barr: it's the firing an event handler to deal with the listening that is 'expensive'
[14:07]  Fu Barr: so if i can fileter the listen to INGORE everything except that i want to hear....
[14:07]  Fu Barr: which is do by using the 4th parameter ofu're right matilda
[14:10]  Fu Barr: but, that means i;ve already fired the listen() event handler
[14:10]  Matilda Charron: then there would be only one listen
[14:10]  Fu Barr: indeed
[14:10]  Fu Barr: but in this case I;m showing how you can minimize that. And also I;m doing it like this because it gives me a good reason to talk about these things.
[14:11]  Fu Barr: different ways to skin the proverbial cat, but this gives me more edumerkational leverage :)
[14:11]  Matilda Charron: do many ppl use more than one listen?
[14:11]  Jeff Hall: i try to not doing Matilda
[14:11]  Fu Barr: so here we havce a thing in the code of our script which is directly related to understanding not 'programming' but how opensim works
[14:12]  Fu Barr: like we said in class the first, some things are general programming some things are directly related to the opensim environment - this is one of those :)
[14:13]  Fu Barr: so - now let's look at the listen() event handler that goes with this and see what it does...
[14:13]  Fu Barr: so matilda - what does the listen() handler look for?
[14:14]  Fu Barr: you mentioned it before :)
[14:14]  Jeff Hall: hey dan welcome didnt see u
[14:14]  mattie mcbride is Online
[14:14]  Fu Barr: anybody else not have door scripts up to v0.2?
[14:15]  Fu Barr: good.
[14:15]  Jeff Hall: we all have i think, apart dan maybe:)
[14:15]  dan banner: i have them
[14:15]  Jeff Hall: k
[14:15]  Fu Barr: okay - well what the listen() is doing...
[14:16]  Fu Barr: is simple checking the 'msg' variable it go passed form the llListen() functions.
[14:16]  Jeff Hall: waiting for a string...instead waiting for a freind (rolling stones)
[14:16]  Fu Barr: the important thing to see is that although there are TWO listens there's only ONE listen() eventhandler :)
[14:16]  Fu Barr: you might have a bunch of listens... still only one handler
[14:17]  Fu Barr: and still the relevant information from the listen will be passed into the listen() handler though those 4 parameters :)
[14:17]  Fu Barr: it makes the world a nicely 'structured' and organised place :)
[14:17]  Fu Barr: hehe - np :)
[14:17]  Jeff Hall: yes but what is the purpose really?
[14:17]  Fu Barr: jeff - purpose of what?
[14:18]  Matilda Charron: yes interesting
[14:18]  Jeff Hall: i will usually have one listen handle and  will analyse messages , simply?
[14:18]  Fu Barr: okay - well that's exaclty what i was trying to explain - lol - obvioulsy i didn;t do it well :)
[14:19]  Fu Barr: you are right jeff.
[14:19]  Fu Barr: that's how you can do it in many situations
[14:19]  Fu Barr: but if you only have one llListen() like so: llListen(0, "", NULL_KEY, "");
[14:19]  Fu Barr: you now are listening to ALL the people and all the chat
[14:20]  Matilda Charron: right
[14:20]  Fu Barr: and your listen() handler is going to fire MANY times
[14:20]  Matilda Charron: ok
[14:20]  Fu Barr: and then your whole if() then tree is going to be walked by the script engine MANY times
[14:20]  Fu Barr: which is fine.
[14:21]  Fu Barr: but i'm trying to show another way of doing this to show that you can be more considerate of server load
[14:21]  Arya Paul: so, an efficiency thing
[14:23]  Fu Barr: no no dakrfyre - you're comment is right on target - it allows us to explain more stuff
[14:23]  Fu Barr: *your
[14:23]  Fu Barr: so why am i now using negative channels in this situation?
[14:23]  Fu Barr: *not
[14:23]  Fu Barr: hint: remember this is a lockable door...
[14:23]  Matilda Charron: because you have the msg string in two listens
[14:24]  Fu Barr: not some communucations between two linksets or parts of a puzzle....
[14:24]  Arya Paul: folks using the door will be on 0
[14:24]  Fu Barr: the thing is...
[14:24]  Fu Barr: exacctly
[14:24]  Arya Paul: it won't hear them
[14:24]  Fu Barr: the use scenario is people moving about in my build...
[14:25]  Fu Barr: and they get some hint that they need a passphrase to unlock the door
[14:25]  Fu Barr: it's going to break the 'game' or RP or whatever is they have to chat like so:
[14:25]  Fu Barr: see - that just dissappeared in channel -1234 - LOL
[14:25]  Fu Barr: like so: /-1234 do_something
[14:26]  Fu Barr: and then stuff happens so i (unfortunately) have to be listening on channel 0
[14:26]  Fu Barr: which then gives rise to wanting to be as efficient as possible
[14:27]  Fu Barr: which leads me to now want to fire the listen() event handler all the time... which leads to to two listens etc. etc. etc.
[14:27]  Fu Barr: *not
[14:27]  Matilda Charron: mm
[14:27]  Arya Paul: good point
[14:27]  Fu Barr: now there's one more minor thing in this version of the script...
[14:28]  Darkfyre Algoma: ohh i thought we all just used /1 or /-1 as a general rule, my bad
[14:28]  Fu Barr: there a new 'placeholder' bit where it says // TODO: swing door shut
[14:28]  Fu Barr: i'm starting to think about the actual doorness of my door.
[14:28]  Fu Barr: so i've put in the place where i want it to swing.
[14:29]  Fu Barr: i'll leave it as an exercise to you all to run through the flow of the states, and to understand why i;m using the state_exit() event to do the door swinging :)
[14:29]  Fu Barr: right any more questions about this versio of the script?
[14:30]  Arya Paul: Will there be a test? ;)
[14:30]  Fu Barr: lol
[14:30]  Fu Barr: nope - but i may ask you to make a version 0.4 - after I show you mine...
[14:30]  Fu Barr: lol
[14:31]  Jeff Hall: what do u want exactly?
[14:31]  Fu Barr: so i'll drop v0.3 and we'll discuss that one and then I'll show you my working v0.4 and call it a day. I'll leave you with homework to make your own v0.4
[14:31]  Matilda Charron: the state_exit() is that so it goes back to the default state?
[14:32]  Fu Barr: lol - jeff I just want to try and explain things is such a way that people get a better understanding of how scripting works :)
[14:32]  Fu Barr: okay - v0.3 coming up!
[14:32]  Jeff Hall: no i meant what do you want us to do Fu?
[14:32]  Arya Paul: to do fu?
[14:32]  Fu Barr gave you Fu's door script v0.3.
[14:33]  Arya Paul: sounded funny :)
[14:33]  Fu Barr: nothing Jeff - just in your own time have look at how i used state_exit()
[14:33]  Fu Barr: very simple :)
[14:34]  Fu Barr: now this script adds Access Control
[14:34]  Jeff Hall: ok ill have a look;)...wasn't sure if u wanted us to send script
[14:34]  Fu Barr: nope, not yet :)
[14:34]  Fu Barr: access control is fun. because that way you have in and out crowds and maximum opportunity for DWAAAMAAA! *chuckle*
[14:35]  Fu Barr: the access control function is very simple
[14:35]  Fu Barr: if you're rr: find something in a list, count the items in a list, stick this list into that list etc. etc.
[14:39]  Fu Barr: and as we do more advanced things we'll see much more of using the list, but for now all we want this list to do in our script is keep track of a bunch of avatar names
[14:39]  Fu Barr: much like a clipboard with a list of names.
[14:39]  Fu Barr: if you're on the list, you get to lock/unlock the latch
[14:39]  Fu Barr: anybody have questions on the idea of a list variable?
[14:40]  Fu Barr: cool.
[14:40]  Arya Paul: is this what Groups use, so you can or cannot get, say, a discount on a dress?
[14:40]  Jeff Hall: maybe mention the separator$
[14:40]  Jeff Hall: ?
[14:40]  Fae Peep: so i would add ["Fu Bar", "Fae Peep] to the list
[14:40]  Fu Barr: yep
[14:40]  Matilda Charron: haha
[14:40]  Fae Peep: "Fae Peep"
[14:40]  Fu Barr: but close the quotes and good use of the comma
[14:41]  Fu Barr: i think that's what jeff meant too :)
[14:41]  Fu Barr: now - let's skip into the code at line: 95
[14:41]  dan banner: whos "Fu Bar"?
[14:41]  Fu Barr: if(sec_acl_check(uuid)
[14:41]  Fu Barr: that line
[14:42]  Fae Peep: well i would have to spell it correctly too i suppose
[14:42]  Fu Barr: here we come to the last major 'basic programming' concept we haven't touched upon yet in our classes
[14:42]  Fu Barr: the user-defined function
[14:42]  Fu Barr: until now, we've been using the functions that LSL has given us.
[14:43]  Fu Barr: it's a fabulous set of functions etc. all good. but sometimes I want/need to organise my own code and i need to make my own functions.
[14:43]  Fu Barr: let see how that is happening in this version of our door script
[14:43]  Fu Barr: so - we're in the closed state
[14:44]  Fu Barr: and we're in the listen handler
[14:44]  Fu Barr: and what i want to code to do is decide if the avatar that spoke the lock/unlock code is allowed to use the lock in the first place
[14:45]  Fu Barr: is that clear....
[14:45]  Fu Barr: i need to decide if the speaker of the passphrases is on my list of OK to use avatars
[14:45]  Fu Barr: *passphrase
[14:45]  Jeff Hall: yes
[14:45]  Fu Barr: now the best way to code this is to simply say what you want to code to do, and then worry LATER how you're going to do it :)
[14:46]  Fu Barr: so - i want the code to do:
[14:46]  Fu Barr: if(avatar on the bloody list) then do the locking stuff
[14:46]  Fu Barr: but checking the avatar on the list is a bunch more stuff
[14:46]  Fu Barr: so i hide it
[14:47]  Fu Barr: in a 'function'
[14:47]  Fu Barr: which needs to have a proper name:
[14:47]  Jeff Hall: add a black list with UUID avatars
[14:47]  Fu Barr: in my case its security related and it checks the ACL (access Control List) so i named by function:
[14:47]  Jeff Hall: (i never did that lol )
[14:47]  Fu Barr: sec_acl_check()
[14:48]  Fu Barr: but the function - like the regular LSL ones, needs a parameter (info) to work
[14:48]  Fu Barr: it needs to know WHICH avatar to check
[14:48]  Fu Barr: so lucky me!
[14:48]  Fu Barr: the listen() event handler gives me the UUID of the person speaking!
[14:48]  Matilda Charron: haah well you won't get in Fu
[14:48]  Fu Barr: it's in parameter number 3 (key uuid)
[14:49]  Matilda Charron: Bar and Barr lol
[14:49]  Fu Barr: listen(integer channel, string name, key uuid, string msg) { ... }
[14:49]  Fu Barr: see ?
[14:52]  Fu Barr: it tell the script engine 3 things.
[14:52]  Fu Barr: 1. there's a function called sec_acl_check
[14:52]  Fu Barr: 2. it needs a key parameter
[14:52]  Fu Barr: 3. it will return an integer
[14:53]  Fu Barr: in other words: if i stick in a uuid of an avatar into the function, the function will give me back a number.
[14:53]  Fu Barr: is that clear?
[14:53]  Fu Barr: so now lets look into the guts of the function
[14:54]  Fu Barr: first there's a debug thing so i can check what the actual value is that goes in
[14:54]  Fu Barr: like we saw in the previous versions of the script, i can control that with the DEBUG value
[14:54]  Fu Barr: moving on...
[14:54]  Fu Barr: the way i want to check is:
[14:54]  Fu Barr: go through every one of the names on the list and see if this name is on it
[14:55]  Fu Barr: so to do that, i use a list function that simple 'searches' a list for a particular value
[14:55]  Arya Paul: is their name on the list?
[14:55]  Fu Barr: :)
[14:55]  Fu Barr: exactly
[14:55]  Fu Barr: i;m asking the script engine to look if this person is on the list
[14:56]  Fu Barr: look at line 30
[14:56]  Fu Barr: llKey2Name(uuid) does the magic
[14:57]  Fu Barr: llKey2Name() is the LSL funcion that takes a UUID and gives me the name of the user back
[14:57]  Arya Paul: hey, even I know that one :) (key2name)
[14:57]  Fu Barr: so in goes something like: 8a420211-8f62-41cc-9f30-ab7248d5548f
[14:57]  Fu Barr: the value insode the uuid variable which is got from the listen
[14:58]  Fu Barr: and then llKey2Name turns that in to: Fu Barr
[14:58]  Fu Barr: now, once i have that name then i can feed that value into the find me this name in the list function
[14:59]  Fu Barr: and that's what the llListFindList() function does
[14:59]  Fu Barr: and just for the sake of being complete and i'll just do it this one time
[14:59]  Fu Barr: i'll run past the exact syntax on the functions...
[14:59]  Fu Barr: so this is what happens:
[15:00]  Fu Barr: llKey2Name() gives me the name of the avatar from the uuid
[15:00]  Fu Barr: then llListFindList() needs the list to lokk in: sec_acl and then sub-list it needs to find: the avatar name (haystack, needle)
[15:01]  Fu Barr: and if llListFindList actually finds the name in the list it will return the POSITION in the list
[15:01]  Fu Barr: so if your sec_acl is: ["fu Barr', "somebody Else"]
[15:01]  Fu Barr: looking for "fu Barr" with llListFindList() will give you 0
[15:02]  Fu Barr: because the 0-eth position in the list has my name
[15:02]  Fu Barr: if you were looking for "Somebody Else" the llListFindList would give you 1
[15:02]  Fu Barr: but if it DIDN'T find the name
[15:02]  Fu Barr: it returns -1
[15:03]  Fu Barr: which is code way of saying - bugger this went wrong
[15:03]  Fu Barr: so s that why some of the code lines are more indented than others? because they are a part of the code nesting in the whole?
[15:05]  Fu Barr: exactly
[15:06]  Fu Barr: and coders will indent to make the code UNDERSTANDABLE to humans
[15:06]  Fu Barr: the script engine itself doesn;t give a rats arse
[15:06]  Fu Barr: it only look sfor the semi-colon at the end of a line
[15:07]  Fu Barr: you could remove all the whitespace from the code and the engine would happily run the code
[15:07]  Fu Barr: the next coder will then tear you a new one... coz it's impossible to work with
[15:08]  Fu Barr: total has a fun script which does exactly that - it obfuscates your code so the next coder cant 'steal' your genius ideas
[15:08]  Fu Barr: even if there's full perms on the script - it's such a mess that a human can't possibly work with it, unless they spend a good deal of time getting the script back into its original state
[15:09]  Total Sorbet:
[15:09]  Fu Barr: the final thing in my function here... is what to do in the case that i dont want to use the ACL
[15:10]  Fu Barr: or if the ACL is empty?
[15:10]  Fu Barr: so if we look at line 28
[15:10]  Fu Barr: i check if the ACL has any items
[15:10]  Fu Barr: in otherwords: if there's nobody in the list, don't bother checking
[15:11]  Fu Barr: and now we understand the return values
[15:11]  Fu Barr: id you on the list say TRUE he's on the list
[15:11]  Fu Barr: if not on the list say FALSE he not on the list
[15:11]  Fu Barr: and if we go back to line 95
[15:12]  Fu Barr: we not understand that the if() gets a TRUE or FALSE value to the question is this person on the list
[15:12]  Fu Barr: and then the code is the old stuff
[15:12]  Fu Barr: from version 0.2
[15:12]  Fu Barr: dassit
[15:12]  Object: Script running
[15:12]  Fu Barr: the main idea in this version of the script - user-defined functions, the nesting of function calls and the list variable
[15:13]  Fu Barr: so there you have it.
[15:13]  Fu Barr: the last of my 3 introductory classes.
[15:13]  Fu Barr: this one was pretty long
[15:13]  Fu Barr: but basically you should have enough knowledge to start coding your own stuff
[15:13]  Fu Barr: dont forget - the LSL wiki is your friend
[15:14]  Fu Barr: it has all the details of all the functions
[15:14]  Fu Barr: and examples too
[15:14]  Fu Barr: now just to show off and prove this all works... i build a version 0.4
[15:14]  Fu Barr: *built
[15:14]  Arya Paul: Sorry.,,,dinner on the table..thank you, Fu...will catch up on the wiki
[15:15]  Fu Barr: so here's my door script in a door
[15:19]  Fu Barr: thanks for all your patience today - really long session i know... but hope it was clear and worth the time :)
[15:19]  Fu Barr: i do suggest you have a look at the final script - it has all the 'healthy code' prectices in there :)
[15:19]  Fu Barr: lots of fibre!
[15:20]  Total Sorbet: hehe
[15:20]  Fu Barr: total - perhaps dump the logs on Foxx bode's nuggin - he's got access to the wiki
[15:21]  Total Sorbet: i missed the first few mins tho
[15:21]  Darkfyre Algoma: wow the Wiki is being updated
[15:21]  Total Sorbet: ill send him what i got tho
[15:21]  Fu Barr: yeah - darkfyre - the transcripts of the two previous sessions are there :)