MUG Meeting Transcript November 7th, 2011

[16:57]  Miguel: I'll assume I'm late, huh?
[16:57]  Antonius: Oh Hi!
[16:57]  Antonius: Welcome.
[16:57]  Antonius: No it starts at 17:00
[16:57]  Miguel: How's it going?
[16:57]  Miguel: Ohh right!
[16:57]  Miguel: Duh
[16:58]  Miguel: Stupid time change
[16:58]  Antonius: Pretty good. Going through my test cases. Tedious, but I'm getting through them.
[16:58]  Miguel: Nice
[16:58]  Antonius: How are things with you.
[16:59]  Miguel: Not too bad. Just got hme from the office. So trying to relax a bit
[16:59]  Miguel: I need to get the updated beta for v1.0.3 on this comp
[16:59]  Antonius: Understand.
[17:00]  Antonius: yes please download v1.0.3Beta2. The bug with functions took me by surprise, but was an easy fix.
[17:00]  Devildog: hey miguel
[17:00]  Antonius: Hey Devil.
[17:00]  Miguel: Hey Devildog
[17:00]  Antonius: Have you guys met before?
[17:02]  Devildog: I can't get my head around mice on a beam
[17:02]  Devildog: not the whole thing about the basic concepts
[17:02]  Devildog: I took your advice
[17:02]  Devildog: on looking up the basic things on scripting
[17:03]  Devildog: and came across a problem
[17:03]  Devildog: dont understand even how a script works
[17:03]  Miguel: Devildog was a tenant on one of my sims for like 36 mins
[17:03]  Miguel: hehe
[17:04]  Antonius: You keep good records Miguel.
[17:03]  Devildog: integers vectors all that stuff
[17:03]  Devildog: and I have gone through it in 2 months
[17:03]  Devildog: even pulled scripts apart
[17:03]  Antonius: Ok we can review some of the basics now.
[17:04]  Devildog: and I DONT UNDERSTAND ANYTHING
[17:04]  Antonius: Don't worry Devil. We'll get you started.
[17:04]  Antonius: You mentioned, integers, vectors, etc.
[17:05]  Antonius: Do you understand the concept of variables?
[17:05]  Miguel: Beta2 installed
[17:05]  Antonius: Great Miguel.
[17:05]  Antonius: The first thing you must understand is what variables are.
[17:06]  Antonius: ok?
[17:06]  Devildog: well I know what they do in the script
[17:06]  Devildog: the problem I am having though is where to put them. there is 7 of them
[17:07]  Antonius: Variables are like little boxes that store information.
[17:07]  Antonius: There are different types of information, so there are different types of variables.
[17:07]  Antonius: The key ones to first understand are integers and strings.
[17:08]  Antonius: Integers are whole numbers (no decimal). Strings are text like "hello"
[17:09]  Antonius: You can name those boxes so that you can refer to what's inside them.
[17:09]  Antonius: Those become variables in LSL: each has a name for a box that contains some value.
[17:09]  Antonius: You put a value into a variable with an LSL assignment statement: myVariable = 22;
[17:10]  Devildog: the problem I am having though
[17:10]  Devildog: is putting it all together
[17:10]  Devildog: in mice
[17:11]  Devildog: and also writing the code itself
[17:11]  Devildog: cause there is so many variables functions
[17:11]  Devildog: integers blablabla
[17:11]  Antonius: I understand. But if you start step by step, you'll get it. Sometimes when looking at more complex scripts it can get overwhelming if you don't truly understand the basics.
[17:12]  Antonius: So, did you understand what I said about variables?
[17:12]  Antonius: In order to help you I need to find out what key parts of the basics that you're missing.
[17:12]  Devildog: yeh I did but when I do it in lsl code try to change a script or even put it in mice on a beam I get frazzled
[17:13]  Antonius: Ok. Next functions.
[17:13]  Antonius: You can group a bunch of LSL statements together and give it a name, the function name, and then refer to that name in other places of your code, and all the LSL statements in that function will get executed.
[17:14]  Antonius: Any questions on that?
[17:18]  Devildog: llsettexture
[17:18]  Devildog: <1.0,0.0,0.0>:
[17:19]  Antonius: Yes, that's a built-in LSL function that sets the texture of a prim. You can also create your own functions in LSL too.
[17:20]  Antonius: Inside a function you can put most any LSL statements, and they will get executed line by line whenever you refer to the function's name in your code.
[17:21]  Antonius: In LSL directly, you define a function by specifying it's name, followed by a list of parameters if any that contain information that will be accessible by the function. Then you have an open brace followed by the lines of code in the function. It all ends with a closing brace.
[17:22]  Antonius: So it looks like this: myFunction() {...lines of LSL code...}
[17:22]  Antonius: You don't have to pass any parameters to the function if you don't need to.
[17:23]  Antonius: Functions are useful because they save you from duplicating code all over the place, if you have to do the same sequence of things from different places in your script.
[17:23]  Antonius: Questions?
[17:24]  Devildog: no not yet
[17:24]  Antonius: Ok good.
[17:25]  Antonius: The third key thing you need to know about LSL is the use of control statements.
[17:25]  Antonius: After control statements, we'll go right into MiceOnABeam.
[17:25]  Devildog: oh control statements
[17:25]  Devildog: hmm haven't learned that one might be my key
[17:26]  Antonius: Yes. When you write lines of LSL code, you sometimes don't want to execute each line one after the other.
[17:26]  Antonius: Sometimes you want to check something first before executing one or more lines of LSL code. To do that you use an if..then..else control statement.
[17:27]  Antonius: Are you familiar with that?
[17:28]  Antonius: An "if" statement tests the value of an LSL expression that evaluates to TRUE or FALSE.
[17:29]  Antonius: If the expression is TRUE, then the block of LSL statements enclosed by the following braces {...} gets executed.
[17:29]  Antonius: If not, the block of LSL statements does NOT get executed.
[17:30]  Antonius: You can also add an "else" block of LSL statements that gets executed if the "if" test was FALSE.
[17:30]  Devildog: right i worked on a couple texture change scripts
[17:30]  Devildog: with an else and if
[17:30]  Devildog: on a integer
[17:31]  Antonius: Well the expression for an "if" statement works on an integer but you should think of it as being either TRUE or FALSE.
[17:32]  Antonius: So remembering what we said earlier about variables, if I had a variable called "name", and I want to say hello to the person if his name was "Devil", I could write the LSL statement:
[17:33]  Antonius: if (name=="Devil") {llSay(0,"Hello Devil");}
[17:34]  Devildog: but if its else it's you or miguel who touched it
[17:34]  Devildog: that will say it
[17:34]  Devildog: if goes basically to owner
[17:34]  Devildog: else go to everybody else
[17:34]  Antonius: Yes, so you can add to the statement: else {llSay(0,"Hello everyone else");}
[17:35]  Antonius: Do you understand the code I wrote?
[17:35]  Devildog: yes
[17:36]  Antonius: Great. There are other control structures, but you really only need to understand the "if" statement to get started.
[17:36]  Antonius: So now you should understand the basic concepts of variables, functions and control statements.
[17:38]  Antonius: Now I want to get into MiceOnABeam and talk about states.
[17:38]  Devildog: my problem though is having to write the same code in mice and drawing stuff lol plus I have noticed that the code itself in mice is way much type than a regular lsl script in sl why is that?
[17:38]  Antonius: Devil: At this stage you shouldn't even look at the generated code that MiceOnABeam produces. You should just focus on your visual model.
[17:38]  Antonius: Hey Miguel. Are you still there? I hope you don't mind this review here.
[17:39]  Miguel: Not at all. Its apparent it's needed. I'm testing the Beta anyway ;)
[17:40]  Antonius: Thanks Miguel.
[17:43]  Antonius: Well, now that you have the very basics of LSL understood, I want to start with MiceOnABeam basics.
[17:43]  Devildog: ok
[17:44]  Antonius: The first things to understand is what states are.
[17:44]  Antonius: When you write a script, you are basically telling SL how to respond to the various events that can happen in SL.
[17:45]  Antonius: Events are things like an avatar touching, bumping into something, sensing something around you, etc...
[17:46]  Devildog: ok
[17:46]  Antonius: But not all these events tend to happen at the same time. In many cases, there is only a small set of events that can happen, (or rather that you're interested in) at any one time.
[17:47]  Antonius: So take for example my registration box for MOAB. The first event it's interested in after it is rezzed is a touch event. It's not interested in, and will ignore other events (other than on_rez).
[17:48]  Antonius: Once the box is touched the script then it's interested in other events, such as the response from a dialog box.
[17:48]  Antonius: Or at a later time, the chat input that a user enters to provide his email address.
[17:49]  Antonius: At each of these different times, a different set of one or more events need to be handled.
[17:50]  Antonius: To specify each of these different times, you create a STATE for each one of them.
[17:50]  Antonius: You need a state when you are WAITING for one or more specific events to occur.
[17:50]  Antonius: If you're always waiting for the same set of events all the time, and want to handle those events in the same way, then you only need ONE state.
[17:52]  Antonius: Hey Sally!
[17:52]  Sally: hiyas °?°
[17:52]  Antonius: Just working here with Devil giving him some of the basics of MOAB.
[17:52]  Sally: okies
[17:53]  Antonius: Miguel here is also testing out the beta.
[17:53]  Sally: yeha its coming on nicely
[17:53]  Antonius: Great. Did you download the beta2?
[17:53]  Sally: nope
[17:54]  Antonius: Sally: I put the fix in for the problem you found and made a few of the changes you requested.
[17:54]  Miguel: Hi Sally
[17:54]  Sally: oh cool .. can just download from the web site?
[17:54]  Sally: Hi Miguel °?°
[17:54]  Antonius: Did you not get my email for beta2?
[17:55]  Sally: no didnt get the email
[17:56]  Antonius: I'll resend the email to you after this meeting.
[17:56]  Antonius: Remember to uninstall the previous MOAB release manually before installing beta2
[17:56]  Antonius: I hope you did that too Miguel.
[17:56]  Sally: okies
[17:56]  Sally: ok thanks
[17:56]  Miguel: Yeah, of course ;)
[17:57]  Antonius: Miguel if not, you may find two entries for MOAB in your Add/Remove Programs. You should uninstall them both then re-install beta2.
[18:00]  Antonius: So let's get back to understanding what states are used for.
[18:00]  Antonius: To recap: If you're always waiting for the same set of events all the time, and want to handle those events in the same way, then you only need ONE state.
[18:01]  Antonius: But if in a script you have to handle different events at different times, or you want to handle certain events in different ways at different times, then you use a state for each one of those situations.
[18:02]  Antonius: Hello Abal!
[18:02]  Antonius: Welcome.
[18:02]  Abal: hi hi
[18:02]  Antonius: I'm just reviewing the concept of states in MiceOnABeam.
[18:02]  Abal: i new trying to learn script think maybe MiceOnABeam help
[18:03]  Abal: okay me listen
[18:03]  Sally: Hi Abal °?°
[18:03]  Antonius: No problem. Abal, you should also take a look at the MiceOnABeam Basics video tutorial: http://bit.ly/mRRhq2
[18:04]  Abal: okay
[18:04]  Antonius: The online documention is available at: http://bit.ly/tltSQR
[18:04]  Devildog: and learn basic LSL integers and such and if and else
[18:05]  Antonius: So we were talking about states and how they are used to specify which SL events you're interested in at any one time.
[18:05]  Antonius: Let's take a look at the Door Script up on the screen here. http://screencast.com/t/FO5z1KNgH  It's the same model that's covered in the video tutorial.
[18:06]  Antonius: You can see that there's 3 states in this script model.
[18:06]  Antonius: The first state that the script goes into is the ReadNotecard state.
[18:07]  Antonius: The transition from the top left Initial Point tells the script which state to start off in.
[18:08]  Sally: you need that even if you have event transitions that only go to the readnotecard state from external?
[18:08]  Antonius: So why do we have a ReadNotecard state? Well when the script starts it wants to read some information from a notecard in the prim's inventory.
[18:08]  Devildog: well my girls going to bed I gotta jet sorry
[18:08]  Devildog: dang it lol
[18:08]  Devildog: ok well I guess I will tincker around
[18:09]  Antonius: That's ok. Devil. we made a good start here, and can continue from here.
[18:10]  Sally: the only transitions in are changed and on rez which go to read note card .. why so we need the initial state pointer?
[18:10]  Antonius: Sally: You're right, in that the Initial Point can be bypassed by an incoming transition.
[18:10]  Sally: ok so its not essential in this case?
[18:11]  Antonius: Well, what if the script was reset?
[18:11]  Miguel: Back, sorry was afk.
[18:12]  Antonius: Sally, in that case the Initial Transition would be taken.
[18:12]  Sally: which is like state_entry?
[18:12]  Antonius: Yes, the very first state entry.
[18:13]  Antonius: So the ReadNotecard state is concerned with getting data from a notecard so it's interested in the dataserver event.
[18:14]  Antonius: At this point it does not care about touch_end events.
[18:14]  Antonius: That's why ReadNotecard is a separate state.
[18:15]  Antonius: Once all the lines in the notecard are read, then we take the Done transition over to the Closed state and we are ready to operate the door.
[18:15]  Sally: if someone tocuhed while it was in read note card it would just ignore that right?
[18:15]  Antonius: That's correct Sally.
[18:16]  Antonius: Once we're in the Closed state then we are waiting for a touch_end event when someone touches the door.
[18:16]  Antonius: When it occurs we transition to the Choice Point where we test the name of the avatar who knocked against the list of valid names that we previously read in the ReadNotecard state.
[18:17]  Antonius: If the person is on the list, then we proceed to the Opened state.
[18:18]  Abal: what be timer?
[18:18]  Antonius: In the Opened state, we wait for two types of events: another touch_end or a timer event. In both cases we close the door and return to the Closed state.
[18:18]  Abal: oh person go in then door close if touch or timer
[18:18]  Antonius: Abal: When the door is opened when the script moves into the Opened state, the script starts a timer via a function call.
[18:19]  Antonius: When that timer expires, the timer event is sent back to the script where it can be handled.
[18:19]  Abal: okay
[18:19]  Antonius: In this case, we want to automatically close the door after so many seconds.
[18:20]  Antonius: So we can see how we need to handle a different set of events in each of the three states.
[18:20]  Abal: me need study to be smart cookie
[18:21]  Antonius: And in the case of the touch_end event we want to do something different (either open or close the door) depending on the state we're in when we receive the that event.
[18:22]  Antonius: Any questions on states?
[18:22]  Abal: oka how many states can have one script?
[18:23]  Abal: is limit
[18:23]  Antonius: In the free version of MiceOnABeam you can have a maximum of 5 states. In the Professional Version you can have an unlimited amount.
[18:23]  Sally: or limited by memory limit of a lsl script
[18:23]  Antonius: Sally is right-on.
[18:23]  Antonius: You should only use a state when you need one, as each one will use up more LSL memory.
[18:23]  Abal: oh this good
[18:24]  Abal: can one script talk other script?
[18:24]  Antonius: Yes Abal. There are a number of functions by which scripts can talk to each other.
[18:25]  Abal: so two objects in sl that talk
[18:25]  Abal: oh
[18:25]  Antonius: Bascially they can hear each other's chat on private communication channels, or they can send special link messages to each other.
[18:26]  Abal: this good then get past limit
[18:26]  Antonius: Yes Abal. In fact that's what many scripters have done.
[18:26]  Antonius: They create many smaller scripts that communicate to get the job done.
[18:27]  Abal: team work script
[18:27]  Antonius: However SL realizes that they have been shooting themselves in the foot with this, as there is considerable overhead to having many little scripts running.
[18:27]  Miguel: hehe yeah
[18:28]  Abal: each script take memory from sim
[18:28]  Antonius: Yes, memory and cpu processing time.
[18:28]  Abal: oh
[18:28]  Abal: sim people be mad
[18:29]  Antonius: Just the switching back and forth between the many little scripts is an overhead.
[18:28]  Antonius: I hope they will be allowing larger scripts in the future.
[18:29]  Sally: what I would love . .. it the ability to directly call functions in one script, from another
[18:29]  Sally: have been asking for that for years
[18:30]  Sally: went in too-hard basket due to security implications
[18:30]  Antonius: Yes, the classic Invoke. The problem with that model is that you can easily deadlock scripts
[18:31]  Antonius: Also I'm not sure it simplifies things overall. You end up having to put timeouts on the invoke in case the other script doesn't respond.
[18:31]  Sally: that would be nasty given that scripts aren't alway run each frame
[18:31]  Antonius: But on the other hand, it can simplify a model by reducing the number of states you need.
[18:32]  Sally: or .. if i can't have libraries .. I want arrays °?°
[18:32]  Abal: can  MiceOnABeam take script into tool then display logic?
[18:32]  Antonius: Abal: No not currently. It would be a very complex task to do. But I do get asked it alot.
[18:33]  Abal: oh me thoght me be original
[18:33]  Sally: most of my code is bloated because there is no array type
[18:33]  Sally: would be 1/4 the size
[18:33]  Antonius: Yes, LSL is really missing some fundamental language elements.
[18:34]  Antonius: They had a plan a couple of years back to support C#. Now that would be wonderful!
[18:34]  Antonius: But that won't happen now.
[18:34]  Abal: this good tool
[18:34]  Abal: me study
[18:34]  Abal: when next class?
[18:34]  Antonius: We meet most Mondays at 17:00 SLT.
[18:35]  Abal: okay
[18:34]  Sally: so i have a philosophical question .. why can't the "top level state variables and functions" be called "global variables and functions" .. because they are right?
[18:35]  Antonius: You're right, they're global to the entire model.
[18:35]  Antonius: But since the same interface is used to specify them, they go by the same name.
[18:36]  Sally: I'm not sure if it's a pure state engine thing .. but if the "state Variables and Functions" option was named "Global Variables and Functions" , it might make it more clear what's happening
[18:36]  Antonius: Ah, but your comment only applied to the top level.
[18:37]  Sally: yes only for the top level state
[18:37]  Antonius: State variables and functions are local just to the state (& insides) where it is defined.
[18:37]  Sally: except from the top level
[18:38]  Antonius: So calling them global would confuse things. I suppose if you're suggesting that the editor name for the top level say Global Variables and Functions, that might be an idea.
[18:38]  Antonius: Interesting.
[18:38]  Sally: no no only call the menu option "Global" at the top level .. leave it as State everywhere else
[18:39]  Antonius: MOAB does also have the Custom Globals feature where you can enter in variables & functions in freeform LSL that are also global to the entire model.
[18:38]  Abal: i need state say good people yes if no zap
[18:39]  Antonius: Abal: Well you can modify the door script model to do just that!
[18:39]  Abal: oh
[18:40]  Antonius: You would just put the LSL code to zap in the No transition from the TestIfAuthorized Choice Point.
[18:40]  Abal: take picture
[18:40]  Antonius: Abal: Here is a link for the door script picture: http://screencast.com/t/FO5z1KNgH
[18:40]  Abal: thank you
[18:40]  Sally: the biggest problem i still have is understanding when variables are in scope or not
[18:40]  Sally: if i'm on a transition out of a state .. state variabels are not available in the transition Action?
[18:41]  Antonius: That's correct Sally, although State Variables/Functions from HIGHER level states would be visible.
[18:41]  Abal: is there library for tool
[18:43]  Antonius: Abel: There are a few examples that you can browse: http://www.miceonabeam.com/model-library/
[18:43]  Abal: thank you
[18:43]  Sally: so .. need to set higher level variable in the exit action .. if you want to see them outside a given state
[18:44]  Antonius: No, the variables are visible if they are defined within a higher level state (container).
[18:44]  Sally: right but if you wanted to update those form a lower level state ..
[18:45]  Sally: need to update them in the exit action of the lower level state
[18:45]  Antonius: You can modify them from anywhere within a lower level (contained) state or transition.
[18:45]  Sally: otherwise everything in the lower level state goes out of scope
[18:45]  Sally: right
[18:46]  Antonius: A lower level scope sees everything in the higher level scope within the nested state hierarchy.
[18:47]  Antonius: Take a look at the new State Explorer in the v1.0.3Beta It shows the state hierarchy of a model with nested states.
[18:47]  Sally: yep i got that but outbound transitions ... do not have access to the state variables in the state they are outbound from
[18:47]  Antonius: Maybe the scoping will be clearer looking at that tree indentation of composite states.
[18:47]  Sally: thats the thing that i get confused on every time
[18:48]  Antonius: That is correct. Since you have left the state, you can no longer see it's variables.
[18:48]  Sally: so what is a transition?
[18:48]  Antonius: It represents a trigger for an SL event.
[18:48]  Antonius: To respond to an event, you must have a transition for it.
[18:49]  Sally: right but
[18:49]  Sally: you can have a transition without an event too
[18:49]  Sally: like going form an Exit Pointto a final state
[18:49]  Antonius: Yes, there are continuing transitions, but they are connected back to a transition with a real event.
[18:50]  Sally: or a decision point?
[18:50]  Antonius: Yes, but if you trace the transition going into the Choice Point, you should find a transition with a real event somewhere!
[18:51]  Sally: right
[18:51]  Abal: like listening to smart people even though no know what say
[18:51]  Antonius: Remember, between events the script sits and waits in a state somewhere, and it takes a transition with a real event specified to get the ball rolling.
[18:52]  Abal: can script read screen?
[18:52]  Antonius: Abal: What do you mean by "read screen"?
[18:53]  Abal: if there be pop up can it respond?
[18:53]  Sally: can listen for a dialog channel response
[18:53]  Antonius: Abal: yes you use the llDialog function: http://wiki.secondlife.com/wiki/LlDialog
[18:54]  Abal: ohh
[18:54]  Antonius: Once a transition is triggered it can be connected to other transitions and will follow the path till it gets to another state.
[18:54]  Sally: right but .. if you are in a state outbound transition ... you don't have access to the event params ?
[18:55]  Antonius: Depends on the transition type Sally. See: https://miceonabeam.fogbugz.com/default.asp?W33
[18:55]  Antonius: If a transition has a defined event then the arguments can always be referenced directly in your transition code.
[18:55]  Sally: i like the new Event Params are available feature (in v1.0.3Beta)
[18:55]  Sally: although I need to check it but it appeared that the old Event(STR).. construct stopped working
[18:55]  Sally: will need to check
[18:55]  Antonius: Oops. I hope not.
[18:56]  Antonius: Well folks. I think that's it for tonight.
[18:57]  Abal: thank you teach
[18:57]  Antonius: My pleasure Abal.
[18:57]  Sally: OK thanks °?°
[18:57]  Abal: nice to meet sally and miguel
[18:57]  Antonius: If you have any questions, don't hesitate to email support@miceonabeam.com. I'm always happy to answer.
[18:58]  Sally: okies will do
[18:58]  Sally: I made a couple of components .. a readNoteCard One and a ChatCommandsList one that lets you have a list of valid chat commands instead of wiring up lots of branches from a choice point
[18:58]  Antonius: Sounds good Sally! Why don't you submit it to the library? http://www.miceonabeam.com/community-library/
[18:58]  Sally: I was going to
[18:58]  Sally: am working on an inter Script Communication Component too
[18:59]  Sally: which i think will be handy
[18:59]  Antonius: For sure.
[18:59]  Sally: okies .. see you later °?°
[18:59]  Antonius: Thanks again to both of you for trying the beta. Much appreciated.
[19:00]  Sally: its fun °?°
[19:00]  Antonius: Bye for now.