MUG Office Hours Transcript September 17th, 2012
17:13] Antonius: Hello!
17:14] Sasha: hi
17:14] Antonius: and welcome
17:14] Sasha: ty :)
17:15] Antonius: Hi Caitna!
17:16] Antonius: Hi & welcome!
17:16] Caitna: Hiya :-)
17:16] Caitna: I actually made it this time! Been wanting to for ages
17:16] Antonius: So how are you both doing this evening?
17:16] Sasha: I am fine!
17:16] Antonius: I'm glad you could make it.
17:16] Sasha: Just got moab pro last night :)
17:17] Antonius: Yes. Thanks for that! Really appreciated. Have you used the free version much?
17:17] Caitna: I've had it for ages, but haven't used it much yet, and I need to get started using it :-) I know enough about scripting to know that MoaB was a MARVELOUS package for me
17:17] Sasha: A little
17:17] Caitna: I opened a couple of the demos with the free version, and knew right off it was exactly what I needed
17:18] Sasha: I decided to buy the pro version before getting too involved in it tho :)
17:18] Antonius: Caitna, is your experience with scripting/programming in general or with LSL?
17:19] Caitna: Not much at all with LSL, one reason I decided I needed a package that would let me do things primarily visually
17:19] Caitna: I've scripted for Neverwinter Nights for many years, but it's a linear/single thread script language
17:19] Antonius: Yes & MOAB will help here. You do still need to understand the basics of LSL in terms of variable types and control statements such as if..then..else. See: http://bit.ly/OXo4Nb
17:20] Caitna: So the multithread/parallelism in LSL is proving difficult in the "getting my thoughts in order and doing a rough outline" stage
17:20] Caitna: /me nods "MoaB's links to the lsl wiki on functions was definitely something I took note of in a positive way :-)
17:21] Antonius: Well as far as parallelism is concerned, remember that each script is a single process in effect, that is driven by events from the world.
17:21] Caitna: /me nods
17:21] Antonius: Only when you start to group together scripts to build a larger project do you get into the multi-threaded issues.
17:22] Caitna: I've been digging into UML info on the net, as it seems to be set up very similarly to MoaB
17:22] Antonius: Yes, I took a subset of UML, the state machine part, and used that in MOAB. See: http://bit.ly/Ul4FK9
17:23] Caitna: there's a fair amount of stuff available on using UML so I can sort of look up as I go along :-)
17:23] Caitna: Excellent, that will help me a lot :-)
17:24] Antonius: At some point I'd like to expand and add a bit of the structure part of UML to MOAB so that you can capture multiple scripts within MOAB and have MOAB generate the communication code. It's ambitious but doable.
17:24] Caitna: THAT would be marvelous :-)
17:24] Antonius: Have you both gone through the online documentation for MOAB?
17:24] Sasha: yes
17:24] Caitna: briefly, and a while back, but I can follow along fine I think
17:25] Sasha: I went thru and made the tutorial door from scratch
17:25] Antonius: Excellent Sasha!
17:25] Antonius: There's lots of info there on how to use the individual modeling concepts.
17:25] Caitna: /me nods "MY problem is the very first steps
17:26] Antonius: I have some getting started info on the online documentation
17:26] Antonius: Let's see if I can bring it up here...
17:27] Antonius: Maybe take a seat so that you can see this better.
17:28] Antonius: This is the main page of the documentation.
17:28] Antonius: If you haven't done this Caitna, start from the Start Here section.
17:29] Caitna: Yes, I went as far as midway into the tutorial light switching script
17:29] Antonius: The 10 Steps to Creating Your First MiceOnABeam Script should help you get started.
17:29] Antonius: Ok that's great then.
17:30] Caitna: It's more... ok, I have an idea I want to write a script to do: switch panoramas in sync across 9 different object faces, but can be easily expanded by a secondary user, so, probably a NoteCard Config
17:31] Caitna: It needs to work across a single linkset, but not interfere with similar scripts running in an arbitrary number of linksets in the vicinity... So... where do you start in terms of basic organizing a project?
17:31] Antonius: Well you should definitely take a look at the door tutorial since it shows you how to setup reading a notecard in MOAB.
17:32] Caitna: A way to look at it and figure out how many and what sort of states, etc. And yes, a pointing to a resources is as good as an explanation *blushes*
17:33] Antonius: Well sometimes people have trouble getting started because the project they want to do is fairly large.
17:34] Antonius: I always recommend starting with some smaller part of the project and build up from there. Step by step. At each step, you test things out, correct errors, etc. Then when that part works, you add in the next set of features.
17:34] Caitna: There, bookmarked. And, heh, I suspect I'll end up with a fair bit of fancy in this :-)
17:34] Caitna: /me nodsnods
17:34] Antonius: That's the way much software development is done.
17:34] Caitna: I tend to like the modular successive refinement approach myself, so this is good :-)
17:35] Antonius: Yes that's exactly right Caitna.
17:35] Antonius: So for your project, you have to first define some basic behavior that you'll start off with.
17:38] Antonius: I would first tackle displaying a texture on a single prim and changing it as per your requirements. Then link a second prim to work in sync with it. You'll have to decide on a communication scheme, perhaps for a master prim that takes the user command and either sends link messages the other prims to set the texture or preferably uses llSetLinkPrimitiveParamsFast to do the job (relevant child prims would have had to identify themselves to the master during initialization in this case)
17:35] Caitna: Is the "least active" state the best to do for a base state?
17:36] Caitna: Or the state that it sits in for the most time?
17:37] Caitna: ie, on rez, I expect it to usually be "powered down", windows closed, scenery dark. Then, when you turn the environment system on, the windows open up and there's a scene, and a bit of lighting... and it waits for you to tell it to change the scenery
17:37] Antonius: Remember that states are just points in time when the script is waiting. It has finished processing it's current event and is waiting for the next one.
17:38] Caitna: /me nodslistens
17:39] Antonius: Ok, so yes, there's often a state after on-rez, that results in some script resetting or initialization.
17:40] Antonius: After that if you're waiting for use input, then you would have moved to another state for that.
17:41] Caitna: ok *nodslisten*
17:41] Antonius: Sometimes features will cycle you through a set of states and then return you to the wait-for-user-input state.
17:41] Antonius: I think I should show you an example. Hold on.
17:41] Caitna: /me nods again and works on applying that
17:43] Antonius: Ok so this is the Secure Door model that's covered in the video tutorial.
17:43] Caitna: /me works on following things
17:44] Antonius: Note that on script initialization or on rez, the script will re-read the notecard, leaving and returning to the state for each line read.
17:46] Antonius: To read a notecard, you have to wait for dataserver event which provides one line of data at a time.
17:44] Antonius: Once the notecard has been read, it moves to the Closed state.
17:44] Antonius: In this case the notecard contains the names of avatars authorized to enter through the door.
17:44] Caitna: hmm... ok, why is that better than just doing it inside the state?
17:45] Antonius: What do you mean inside?
17:46] Caitna: /me thinks * right, right. I'm too used to linear... the states are mostly just traffic signs for the program flow, the actual wiork gets done in the connections, more or less the opposite to "normal" old style flow charts,. Sorry
17:47] Antonius: Yes they are sort of traffic lights or stop signs, where you have to stop, and wait for some signal (i.e., an event) in order to continue.
17:47] Caitna: /me nods
17:48] Caitna: I'm picking it up :-) It's a very different design philosophy, but much better
17:48] Antonius: In this case the ReadNotecard state has to wait for the dataserver event. Once it receives that event, it process the data supplied in the event, and then returns back to the ReadNotecard state to fetch another notecard line.
17:49] Antonius: Sasha, are you following along ok?
17:49] Sasha: just fine :)
17:50] Caitna: Anwyays, so, in this case, the entry code is the GetNextLine action, then the exit code is the dataserver response/return?
17:51] Antonius: Action code can be in *either* the transition or in the state itself as Entry Code or Exit Code. The former gets executed *every* time the state is entered, and the latter is executed *every* time the state is left.
17:51] Antonius: So in this case the ReadNotecard state has Entry Action code that makes an ll function call to read a line from the notecard and then sits and waits for SL return with a dataserver event with the data.
17:51] Caitna: But in terms of the charting, they're considered to be part of the transition, not the State?
17:52] Antonius: No, they're considered to be part of the state, and fall within that state's variable scope in fact (if it had any State Variables).
17:53] Caitna: OK, good, yes, variable scope was why I was asking :-0
17:53] Caitna: scope mismatch on variables can cause you more trouble... urgh
17:54] Antonius: Yes you can define variables for each state or Composite State with all the states contained within the latter having access to the Composite State's variables. The Top State is basically a Composite State.
17:55] Antonius: So the scope is hierarchical corresponding to how you nested your states.
17:55] Sasha: global
17:55] Caitna: /me nods "Just meant, that's why I wanted to be sure about the "location" of the entry and exit points
17:55] Antonius: Right. Note that nested states should be used sparingly; only when there's some common event that you need to factor out, or for hiding the details of the implementation which makes for a much clear model diagram.
17:57] Antonius: Sasha, so yes variables defined for the Top State are in effect global to the design. You can also define globals with the Custom Globals menu option in the Script menu.
17:57] Caitna: well... like in my case, I was figuring a per room variable for the label of the panorama view that is in place, and a global for the room Power on/power off state
17:58] Antonius: Caitna you will find that some key variables that you would traditionally use, become actual states in an event driven model.
17:59] Caitna: *thinks and then* Ahh, ok, yes, like, power on and power off
17:59] Antonius: In general a program's "state" is the value of all it's variables at a given point in time.
17:59] Caitna: in power off, the only signal it waits for is to turn on, in on, it has multiple control options, so it would be a state, not a variable to be checked
17:59] Caitna: OK, got it
18:00] Antonius: So what you can do is think of the most important variables that you would think of having, and perhaps these may become actual states in the MOAB model.
18:01] Antonius: Yes, Power Off and On seem like reasonable states to have.
18:01] Caitna: Hmmm
18:01] Antonius: The On state can then have the feature stuff inside it.
18:02] Sasha: as the off state does not need it
18:02] Sasha: ?
18:02] Caitna: and, since when the new textures get applied and rez, the windows will close and I'll likely put some sort of special effects/lighting stuff, then reopen... that would be a State as well
18:03] Caitna: As a nested state... inside "On" state, so that the variable in "On" for the panorama, will carry down into the "change scene" state"...?
18:03] Antonius: Depends what events the Off state has to respond to. If it's a single event that moves it to On, then it's probably not a Composite State.
18:05] Caitna: I'd think Off wouldn't be, but the On state would have control inputs to read and then to move into the change state, and then back out to the On state... is there an easier way to carry vars between scopes than nesting?
18:05] Caitna: /me blushes "Or do we want to stick to the door example for now Sorry, didn't mean to monopolize things
18:07] Antonius: You can't explicitly check the state you are in if you are a substate, but this should be self evident, as a substate can only be within one outer state. Of course that outer state itself can be within another one and so on,
18:08] Antonius: If a var has to be common to more than one scope, then move it up higher in the hierarchy, possibly to the highest level, the Top State or Custom Globals.
18:09] Caitna: hmm... *nods* OK, I think I've got the logic there
18:09] Antonius: Again, Composite States should be used sparingly. You will find that most of your variables are either at the Top level, or defined in states at the next level down.
18:10] Caitna: yeah, I was thinking next level down, but, if I make the panorama label global, it would set (or perhaps read and set?) the "Current" panorama label
18:10] Antonius: To complete the door example shown, once the notecard has been read, the script moves into the Closed state where it *waits* for a touch event.
18:11] Caitna: touch end is the "click" to select event, yes?
18:11] Antonius: Yes, when you click on a prim, it generates a number of touch events. I use the touch_end event here.
18:11] Caitna: ie, when the left mousebutton is released
18:12] Antonius: Yes.
18:12] Caitna: Safer, lets you option out by sliding off it before you release the mouse button
18:12] Caitna: Instead of "oh drat I clicked the wrong thing" XD
18:13] Antonius: The touch_end event is then processed, and you're led to a Choice Point which checks the data from the event, i.e. who did the touching, and checks it against the list of avatars previously read from the notecard.
18:14] Caitna: Relatively simple list parsing functions available?
18:14] Antonius: In this model this list is clearly global since it has to be accessed across the model.
18:14] Caitna: /me nods
18:15] Antonius: LSL is a fairly primitive language. You can do a few things with a list like search, delete, insert. Not much else.
18:16] Caitna: /me nods "Okies. That sucks LOL> I'm used to doing bitmap variable access XD
18:16] Antonius: If the avatar's name was found on the list, then the script proceeds to the Opened state, and waits there, *either* for another touch event or a timeout event both of which will return the script to the Closed state and close the door.
18:17] Antonius: In the Entry Code of the Opened state, I have code that starts up a timer. In the Exit Code of the state I cancel the timer.
18:17] Caitna: Out of curiosity, is this setup such to break something if a touch end and a timer expiration both happen at the same time?
18:18] Caitna: It's obviously not a security issue, since anyone that dedicated can just cam around, but, I'm wondering to what level do I have to worry about good error-trapping?
18:18] Antonius: No, in fact multiple events can always happen at the same time. The SL run-time system maintains it's own queue or list of events that are waiting to be processed by the script.
18:19] Antonius: Only *one* event is processed by a script at a time, and that processing *cannot* be interrupted until the event processing has completed.
18:20] Sasha: the event queue
18:20] Caitna: So it's not going to happen LITERALLY simultaneously regardless of when they're triggered... a single cycle difference is imperceptible to a person, but the computer knows the difference perfectly well
18:20] Antonius: So if the timer & touch events came in at the same time, one will be put in the event queue (right Sasha!) first followed by the other one.
18:20] Caitna: whispers: So, cooperative multitasking, with good queue control, Has good points and bad points, but in THIS case it's a Good Thing :-)
18:22] Antonius: If touch came in first then the script would process that and move to the Closed state. At that point the MOAB model will get the timer event, but since there is *no* transition that leaves the Closed state with the timer event set for it, the timer event will then be ignored.
18:22] Caitna: /me nods Excellent
18:22] Antonius: Now if it was the other way around, the timer event was put first in the event queue, then yes, in Closed you would then process the touch event and move back into the Opened state!
18:23] Sasha: as we have all seen happen :)
18:23] Sasha: close..OPEN!
18:23] Antonius: If you didn't want that to happen, then you would have to put in some de-bounce code that would ignore the touch in the case where it came too soon after the timer event.
18:24] Antonius: So true Sasha! That's why I put in debounce code in my new MOAB Universal Door, so that multiple touches will not open/close the door.
18:25] Caitna: I'm thinking probably not worth the effort for this, but might be in some situations
18:25] Caitna: ahh, well, if YOU wanna put the work in XD
18:25] Sasha: :)
18:25] Antonius: Yes. Which reminds me, would either of you like a free MOAB Rotator or Slider?
18:25] Sasha: yes!
18:25] Caitna: Thogh I suppose No TP areas make it relevant well enough
18:25] Caitna: /me smiles "I actually bought them both already XD
18:26] Caitna: But thanks! :-)
18:26] Sasha: The rotate for me plz
18:27] Caitna: Well, as it stands, there's only so much use "security" can be, because someone can Cam whereever they want, and unless the region is set to disallow TPs, or to have a single access point only, they can just double click right past any doors
18:28] Caitna: But if the place is set to disallow free TPing, it might be worth it for a really secure door
18:28] Antonius: Oh I see.
18:29] Antonius: Caitna did you buy the copy versions?
18:29] Caitna: /me gigles "Not one of the strangers that have wandered into my house have used the door to get there XD
18:29] Caitna: Yep! :-) I wanted them to build with :-)
18:29] Caitna: so they're Copy/Trans OK :-)
18:29] Antonius: Ok.
18:30] Antonius: Sasha do you want to try out the MOAB Role Play Door here?
18:30] Sasha: nah
18:30] Caitna: THAT looks very cool by the way
18:30] Antonius: It's bashable!
18:30] Sasha: I just TP thru doors
18:30] Sasha: /me giggles
18:30] Antonius: Just set yourself to run.
18:30] Sasha: or cam
18:30] Caitna: Most people just TP through doors :-)
18:31] Antonius: Hmm. You don't have much mass :-)
18:31] Caitna: Can you set them to respond to key items in inv? That sounds like a massive parsing job...
18:31] Antonius: There you go.
18:31] Sasha: ouch
18:31] Antonius: It works with projectiles too.
18:31] Antonius: lol
18:32] Antonius: I will help. It works with multiple people bashing it too.
18:32] MOABUniversalRPDoor V1.0.0: Damage increased by 29.31 %
18:32] MOABUniversalRPDoor V1.0.0: DOOR BASHED OPENED!
18:32] MOABUniversalRPDoor V1.0.0: Automatic partial repairs completed: 10 %
18:32] Caitna: I love the lockpicking thing, VERY cool
18:33] Antonius: It's now bashed open so people can walk through.
18:33] Sasha: door fail
18:33] MOABUniversalRPDoor V1.0.0: Automatic partial repairs completed: 10 %
18:33] Caitna: One thing, as far as universality of doors.... iris doors are a type this doesn't have
18:33] Antonius: Authorized people can then repair it.
18:33] Sasha: will it regen over time?
18:33] Antonius: Yes it does iris doors too.
18:33] Caitna: That's EXTREMELY cool for roleplaying areas *nodsnodsnods*
18:34] MOABUniversalRPDoor V1.0.0: Partial repairs completed: 10 %
18:34] Caitna: ohh! You should include that in the ad copy. I Looked :-)
18:34] MOABUniversalRPDoor V1.0.0: Automatic partial repairs completed: 10 %
18:34] Antonius: Yes, you can set it for automatic repairs.
18:35] Caitna: I do have hopes of building Roleplaying areas eventually, so that's a VERY cool feature
18:35] Antonius: It's in there! It lists all the door types it can do.
18:35] MOABUniversalRPDoor V1.0.0: Automatic partial repairs completed: 10 %
18:35] MOABUniversalRPDoor V1.0.0: Partial repairs completed: 10 %
18:35] Caitna: Ahhh! There it is! :-)
18:35] Antonius: You can of course customize all the timeouts
18:35] MOABUniversalRPDoor V1.0.0: Partial repairs completed: 10 %
18:35] Sasha: :)
18:35] Sasha: cute
18:36] Antonius: It can also be lockpicked and you can get a key for the door.
18:36] MOABUniversalRPDoor V1.0.0: Partial repairs completed: 10 %
18:36] Caitna: VERY cool. Is there sound support? though frankly not real high on my priority list
18:36] MOABUniversalRPDoor V1.0.0: Automatic partial repairs completed: 10 %
18:37] Second Life: Items successfully shared.
18:37] MOABUniversalRPDoor V1.0.0: Automatic partial repairs completed: 10 %
18:37] MOABUniversalRPDoor V1.0.0: whispers: DOOR FULLY REPAIRED!
18:37] Antonius: Yes sound too. I sent you the key Sasha, Wear it.
18:38] Sasha: thats a BIG key
18:38] Antonius: Yes. lol
18:38] Caitna: Did it actually clean the rubble up and my display is just horribly lagged (Which it seems to be)
18:38] Caitna: Ahh, ok, I caught up. that is EXTREMELY cool
18:39] Antonius: It's supposed to clean up the rubble. I think I may have found a bug :-(
18:39] Caitna: Ahhh. Heh
18:39] Antonius: That shouldn't happen.
18:39] Caitna: Yeah, the rubble cleaned up, my redraw was just slow
18:39] Sasha: I broke it
18:40] Sasha: LMAO
18:40] Antonius: Yea!
18:40] Sasha: now its jammed
18:40] Sasha: kinda cool
18:40] Caitna: One thing I have issues and problems with, is that for vehicles, everything MUST be in a single linkset
18:41] Antonius: It can be linked no problem and still works.
18:41] Antonius: Rotated too. No path cuts required too.
18:41] Caitna: oohhhhh
18:41] Caitna: Can you trigger the "damaged/stuck" state by a remote signal?
18:42] Caitna: the NovaTech TARDIS system has a script package that among lots of other things, you can induce damage/malfunciton states via script
18:42] Caitna: it would be very cool if the Doors all got stuck, or some at random got stuck, from entering the tardis wide "Damaged" state
18:43] Antonius: No. I could add that. There is a MOAB Door Server you can buy from which you can control the door. You can open/close, lock and unlock. I could add Damage to that too.
18:43] Antonius: The server's neat too since you can wear it as a hud and use it to teleport to all your doors on the sim.
18:44] Antonius: Well I think I've run out of time tonight. I hope you both found it useful!
18:44] Sasha: Well i must go. this has been most informative
18:44] Antonius: Thanks so much for coming!
18:44] Sasha: Thanks Ant!
18:45] Antonius: If you have any questions you can always IM me or send an email to support@miceonabeam.com
18:46] Caitna: Will Do :-) Thanks so much!
18:46] Caitna: /me smiles and goes to play XD
18:46] Antonius: My pleasure Caitna. See you again soon.
Antonius Frentis