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 email@example.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.
Entries in Variable scope (2)
17:13] Antonius: Hello!
[17:14] Pilot: G'day Ant.. Slept in mate, sorry... lol
[17:14] Antonius: Well G'day Pilot!
[17:14] Pilot: What's happenin'?
[17:14] Antonius: I was just trying to get up on the board a script model I did for Jorie.
[17:14] Antonius: Can you see it?
[17:15] Antonius: Here's the link if not: http://screencast.com/t/0OAJqXnFn
[17:15] Pilot: Idle, wait for permission, Stance, Attack....?
[17:15] Antonius: It's a weapon script.
[17:16] Pilot: Can't see it mate, lol.
[17:16] Pilot: hahaha
[17:16] Pilot: Looks good.
[17:16] Antonius: draw sword
[17:16] Antonius: On Guard!
[17:16] Pilot: Geeze louize mate, I was only kiddin'
[17:16] Pilot: lol
[17:17] Antonius: Seems to work.
[17:17] Antonius: You can configure the model to add in your own animations.
[17:17] Pilot: But ya don't need to ask permissions each time you draw it.
[17:18] Antonius: That was the happy animation. Watch when I miss.
[17:18] Antonius: I sigh....
[17:18] Antonius: Then when I put it away.....
[17:18] Antonius: sheath sword
[17:18] Antonius: Peace bro.
[17:18] Pilot: lol...
[17:19] Pilot: Bringin' a knife to a gun fight, lmao.
[17:19] Antonius: Yes you're right about the permission test. But sometimes it can be simpler to simply do the test all the time.
[17:22] Antonius: I'm waiting for Jorie to give me feedback on the weapon model and then I'll give it away.
[17:23] Antonius: It shows how you can use the configuration feature.
[17:23] Pilot: I'll have to look at weapons soon, but over the last week it has been mayhem here.
[17:24] Antonius: Take a look at the configuration: http://screencast.com/t/MwDfRABz
[17:25] Pilot whispers: You got a weapons "configurator" (lol
[17:28] Pilot: Now, this configuator,lol.. looks good!
[17:29] Antonius: You can configure the State Variables of any state in this way.
[17:31] Pilot: This tool is in 1.0.3?
[17:31] Antonius: It's already in v1.0.2.
[17:31] Antonius: Do you understand how to setup configuration for a State Variable?
[17:32] Antonius: It's that Configure checkbox column in the state variables editor
[17:32] Pilot: Oh.... Oops, no mate, I just setup varibles anywhere I can mate... lol... Here comes my lack of knowledge again, lol.
[17:33] Pilot: Geeze louize...
[17:33] Antonius: There's a section on it in the docs for full details: https://miceonabeam.fogbugz.com/default.asp?W112
[17:34] Pilot: Holy smoke!!!
[17:34] Antonius: It's great when you have a state that you want to re-use, you can set up one or more of it's state variables to be configurable.
[17:34] Pilot: lol.. Never used that!
[17:35] Antonius: Then when you import or copy the state, you open up the Configuration Wizard to set values for the variables using a form!
[17:36] Pilot: Didn't know what it was about! As I was finding my way, the check box didn't come up, lol.
[17:38] Sally: hey everyone °?°
[17:38] Pilot: G'day Sally
[17:38] Sally: Gday Mate!!
[17:38] Antonius: Hello Sally & welcome!
[17:39] Antonius: I was just talking with Pilot about the State configuration feature in MiceOnABeam.
[17:39] Pilot: Stone the crows... Ant, lookout! Another Aussie, lol.
[17:39] Antonius: It's a bit more advanced topic.
[17:39] Sally: lol yep
[17:39] Antonius: Are you from downunder Sally?
[17:39] Sally: yep
[17:39] Sally: live in the usa tho
[17:39] Pilot: Can't hide it, lol.
[17:40] Pilot: Poor bugger...
[17:40] Pilot: Could be worse...
[17:40] Pilot: Could be in Canada, lmao....
[17:40] Sally: yeah .. could live in New Zealand
[17:40] Pilot: (Antonius is Canadian), lol.
[17:40] Antonius: Be careful. Beavers can bite.
[17:41] Pilot: New Zealand??? holy smoke!! Wouldn't wish that onya mate!
[17:41] Sally: oh you should be enjoying your summmer ... all two weeks of it !
[17:41] Pilot: lol.
[17:41] Antonius: We've had lots of hottish weather here this summer 25-35C, but Pilot tells me that's cold.
[17:42] Sally: yeha we'd still be wearing our coats at that temperature
[17:42] Pilot: Bloody freezin' mate. We have had those temps all weekend and it is winter here.
[17:42] Antonius: ha-ha. Well, we're hardier that way.
[17:43] Pilot: I'm inland and a few hundred miles NW of Sydney Sal, fyi :)
[17:43] Antonius: So Sally, have you used MiceOnABeam much?
[17:43] Sally: I have started playing with it
[17:43] Sally: I think the learning curve may pay off
[17:43] Sally: so what's the news .. when is 1.03 coming out?
[17:43] Antonius: Still working on it & a fair bit to do yet. I'm planning for a Fall release.
[17:44] Antonius: Did you see the Sneak Peek of v1.0.3 features?
[17:44] Sally: yeah they seem good
[17:44] Sally: are you building the check for undeclared variables in that one?
[17:45] Pilot is only a noob scriptor and have done some experimenting. It's really good.
[17:45] Antonius: I'm just working on the "undeclared identifiers" feature now. The error reporting system is done and should make life much easier too for users.
[17:45] Sally: oh cool
[17:46] Antonius: Probably going to put in a Join Point feature too so diagrams can be cleaner.
[17:46] Pilot: You makin' fun of me again Ant??
[17:46] Antonius: No Pilot, feedback from customers such as yourself is critical for me.
[17:46] Pilot: :) (just havin' a dig again Ant, lol)
[17:46] Sally: you know with it being a visual environment my general feedback is .. I need more visual feedback ... like .. show me if there are state variables and functions defiend
[17:47] Sally: like look at that model there on the weapon ...
[17:47] Antonius: Yes Sally I agree. So you're saying you would like another icon showing on the state to tell you that it has variables/functions defined for it.
[17:47] Sally: there is no way to tell if there is a state variable or function defined at the top layer
[17:48] Sally: unless i go in and check
[17:48] Antonius: Good point.
[17:48] Antonius: I will look into that.
[17:49] Antonius: Sally, do you set the options to display Entry/Exit & Guards & transition actions?
[17:49] Sally: yep I do
[17:49] Antonius: I often start out with that, but end up turning it off due to excessive clutter.
[17:50] Antonius: That would be my only concern. Would you prefer an icon, or info on the state like the entry/exit action indication?
[17:50] Sally: icon .. the info is truncated anyway
[17:51] Antonius: Ok. Should not be difficult to do.
[17:51] Sally: Join point would be good do you mean on simple states?
[17:52] Antonius: The Join point will be like an Entry Point, but can be created as a component inside a state's decomposition.
[17:53] Antonius: So then you can have multiple transition into it, with a single transition out. Also like a Choice Point, except there will be no guard conditions on the transitions leaving the Join Point.
[17:53] Sally: that would be good ... help clean up a lot
[17:54] Pilot's head spins....
[17:54] Antonius: Yes. I'm also hoping to add in the ability to have multiple bends in a transition.
[17:52] Sally: im still on the learning curve ... the biggest issue I struggle with is the scope or lifetime of variables
[17:54] Antonius: So to your question on variables...
[17:55] Sally: if I have a listen event that transitions me to another state ... the listen params .. are only available to the transition action but not to the target state right?
[17:55] Antonius: The scope of a state variable is confined to the state in which it is defined and all states contained within that state.
[17:55] Sally: right
[17:55] Sally: and event params?
[17:56] Antonius: Event parms are directly accessible in the transition with the event (& new in v1.0.3 in transitions leaving a Choice Point where there is a single event transition into it).
[17:57] Antonius: However, the event parms are also automatically saved and you can access them via the built-in EVENT_XXX functions.
[17:57] Sally: the last event? ... is accessible in the target state?
[17:57] Antonius: So if you transition to another state, you can still access the event arguments there using these functions.
[17:58] Sally: awesome
[17:58] Antonius: Yes, the most recent event is always saved.
[17:58] Sally: that makes things easier
[17:58] Antonius: Yes. See the following section in the docs.: https://miceonabeam.fogbugz.com/default.asp?W33
[17:59] Sally: thanks
[17:59] Sally: sorry for hogging the floor Pilot °?°
[17:59] Antonius: No problem Sally. We all learn from each other!
[17:59] Sally: the docs mention Internal Self Transitions ... how do you make those?
[18:00] Sally: wherein, the entry and exit actions aren't fired
[18:00] Pilot: Sal, I'm listenin' mate, don't you worry, lol.
[18:00] Antonius: Internal self transitions are like regular self transitions except they bypass executing the exit & entry code of the state.
[18:01] Sally: right so what's the trick for making one °?°
[18:01] Antonius: You create them using the Transition Tool and clicking and dragging from the border of the State Editor for the state in question.
[18:01] Antonius: ... to another point on the border.
[18:02] Sally: ok so they still appear as arc on the outside of the state?
[18:03] Antonius: No, they appear only on the inside. Take a look at this: http://screencast.com/t/G2fuf3pV2OWa
[18:03] Pilot whispers: (Crikey! Don't ask me....)
[18:04] Sally: for the life of me i can't get that to work do you have to drag inside the state?
[18:05] Antonius: Select the transition tool....click and hold the mouse button on a spot on the INSIDE border....drag to another spot on the inside border.... and then release the mouse button.
[18:06] Sally: oh damn !!
[18:06] Sally: I just realized what I was doing wrong ...
[18:06] Antonius: ??
[18:07] Sally: I have been trying to do them on states without going inside the state
[18:07] Antonius: Ahhh. Yes that would be it. :-)
[18:07] Sally: like on that model there ... for state waitfor permisison
[18:07] Sally: I would try to do the drag right there
[18:08] Sally: but I need to Open the state first
[18:08] Antonius: Yes since the self transition is inside the state.
[18:08] Sally: doh !! °?°
[18:08] Sally: hehehe
[18:09] Antonius: It's not unreasonable what you thought to do. There is a UML feature which allows you to see what's inside the state from outside the state!
[18:09] Antonius: It shows a miniature graphic of the decomposition from the outside.
[18:09] Sally: right !
[18:09] Pilot faints.......
[18:10] Antonius: Poor Pilot.... LOL
[18:10] Sally: giggles
[18:10] Antonius: That's a great fainting aninmation Pilot!
[18:10] Sally: you need some vegemite mate :0
[18:10] Pilot: Ah man..... lmao... Got for it you 2!!! Good stuff!
[18:10] Pilot: I need you 2 to keep talkin' lmao...
[18:11] Antonius: When my talking gets too complex, Pilot routinely faints. :-)
[18:11] Sally: hehehe
[18:11] Pilot: :)
[18:11] Pilot: Well, you know how stressed we Aussies can get, lol....
[18:12] Antonius: I think our view here in Canada is how relaxed you all are. Paul Hogan, etc.
[18:12] Pilot: :)
[18:12] Sally: whats a good way of exiting a state without an LSL event taking place?
[18:12] Sally: or .. does that mean that that state is probably useless?
[18:13] Antonius: You're getting advanced there Sally. I think Pilot will faint for this one too.
[18:13] Pilot: Keep talkin' you pair, lol.
[18:13] Antonius: There are certain cases where you might want to do that.
[18:14] Pilot: An undefined event will take you out of a state won't it?
[18:14] Antonius: Normally an event takes you out of the state. But you can use a transition to a Final State to automatically generate an internal Completion Event for the state.
[18:15] Antonius: Then you can exit the state by having a transition set to the Completion Event.
[18:15] Sally: ahhhhh
[18:16] Sally: but you would need at least one internal state inside that state right?
[18:16] Antonius: So that means that you can transition out of a state that internally transitions (during the same event) to a Final State.
[18:16] Antonius: It can be the Final State component.
[18:16] Sally: so you could just draw a final state icon inside a state
[18:17] Antonius: yes. and transition to it either from the Initial Point or via an Entry Point.
[18:17] Sally: then exit via a completion event
[18:17] Antonius: Correct.
[18:17] Sally: cool
[18:18] Antonius: Of course never have your completion transition redirected back to the state, as then you could end up with an infinite loop!
[18:19] Sally: right
[18:20] Antonius: I think I described this usage somewhere in the docs- just can't think exactly where right now.
[18:20] Sally: any thought to making nested actions? °?°
[18:20] Antonius: Nested actions?
[18:21] Sally: like for instance .. I might want to give inventory to detected ... but then for the Item I might want to get the name of the first notecard in the inventory (which could also be an action)
[18:21] Pilot whispers: Just passed a photo of my project to Sally...
[18:22] Antonius: Hmmm. Might be complex to do.
[18:22] Sally: So you could have an Action GiveSomething with an Action Get NotecardName assigned to the item
[18:23] Antonius: What you can do of course is do the first action and assign the value to a variable and then when configuring the second action, enter in the variable name containing the value from the first action.
[18:23] Sally: thats a good way to do it
[18:23] Sally: that project looks pretty complicated Pilot °?°
[18:24] Antonius: Of course you can always define your own action too that combines these two things.
[18:24] Sally: right .. and just add a parameter for the type of thing you are looking for, for instance
[18:25] Pilot: Minimum of typed code Sal, all done visually :)
[18:25] Sally: cool bananas °?°
[18:25] Antonius: yes. Defining your own action is only for experienced LSL users I would say though.
[18:26] Antonius: Well Aussies, I think that's it for today.
[18:26] Sally: oh I know what I was going to ask .. when I look at the generated code ... how do you come up with the state numners? °?°
[18:26] Sally: I know I shouldn't be trying to figure out whats happening in the code °?°
[18:26] Antonius: The code generator assigns them.
[18:27] Sally: hard to break ol habits
[18:27] Antonius: No you certainly can read the generated code (don't use the optimized version for this though).
[18:28] Antonius: I actually designed it that way so people could read it.
[18:28] Antonius: This section in the docs covers the layout of the generated code: https://miceonabeam.fogbugz.com/default.asp?W94
[18:28] Sally: book marks it ;)
[18:28] Sally: well thanks Ant, that was really helpful, and this tool has so much potential °?°
[18:28] Pilot faints.....
[18:28] Sally: next time I'll ask you about inter-prim communication :P
[18:29] Antonius: np! Very nice meeting you Sally!
[18:29] Sally: thank you °?°
[18:29] Antonius: Pilot you can now form an Aussies MOAB group!
[18:29] Pilot: That door project I gave you Sal will operate as many doors within listening range ... Thanks Sal :)
[18:29] Sally: and Im looking forward to the HTTP IN component .. lol
[18:30] Antonius: I'll take note.
[18:30] Antonius: Do you play rugby Sally?
[18:30] Sally: not me °?°
[18:30] Pilot: Geeze Ant!!
[18:30] Sally: windsurfer
[18:30] Antonius: I thought I'd ask for Pilot. :-)
[18:30] Sally: hahaha
[18:31] Sally: ok im a geek girl
[18:31] Pilot: Fair dinkum mate.. Ya don't ask Aussie girls that!
[18:31] Sally: btu i dont play ruggers
[18:31] Pilot: Maaaaaate....
[18:31] Pilot: lmao
[18:31] Pilot: That's like askin' them their age, lmao.
[18:31] Pilot: They belt ya for that!
[18:31] Pilot: lmao.
[18:31] Antonius: I'm learning proper Aussie etiquette. Forgive me. My niece plays rugby.
[18:31] Pilot: hahaha
[18:32] Sally: or the Aussie comeback for asking that would be .. no Do you play Netball?
[18:33] Antonius: I'll have to look that one up.
[18:33] Pilot: Ah well... lmao.. Been great.... Great to meet you Sally....
[18:33] Sally: great to me you two too
[18:33] Sally: catch ya's later °?°
[18:33] Antonius: Bye guys! Have a great week. If you have any questions, don't hesitate to ask if I'm online or send them to firstname.lastname@example.org
[18:33] Pilot: No worries mate.....
[18:34] Sally: cheers
[18:34] Pilot: Hooroo you two :)