- villa 10s
- coconut 1m Partially inactive during summer.
- Jameson 8m making the eternal black firmament my side bitch
- RealHumanBean 1m Something?
- waddlerafter 0s youtu.be/jZitWKRvTtU
- rurouni003 6s
- Lukas 1m
- shaggy 1m
- MrJDucky2 11s
- Napoleon 3m Bad bish is bad.
- FancyPenguin 1h
- Rapidvalj 1m
- Malanth 3m
- BCingyou 3s
- Meoris 8s https://www.youtube.com/watch?v=Vn5OMaPiX2M
- Baguette 1h ye boi
- Ostheim 6m
- SacredWest 2h
- SniperComZero 1m
- Grey0 20s
- Dawnshot 1m https://youtu.be/qg_7saEbnwE
- ZaCyril 41s https://youtu.be/9r4WD60uM18
- Newbs21 2m We're all crazy here!
- Kanuin 6h
- himble 8h youtu.be/og243Dom4Sw
- Riri 30m
j Johnny 16m New Code Written Nightly. Not a GM.
- jsmith225 1h
a Cerberus 11h Head Builder & GM when I need to
- Chrissl1983 7h working on my @history for too long...
And 33 more hiding and/or disguised
Connect to Sindome @ moo.sindome.org:5555 or just Play Now

Babble-On Scripting Manual, Part 1
Scripting for Dummies

Table of Contents:
1. LambdaMOO background
2. Command Structure
3. Command Reference
4. Tying it all together


Babble-On is designed to be a higher layer of abstraction on top of the 'normal' way we add on to the MOO: LambdaMOO code.

Understand that it is not designed to replace coding. Like any well designed programming language, it can be used or abused in many different fashions. The language is therefore designed in such a way that it is difficult to really 'hurt' the MOO. That is to say it's intentionally crippled.

It is of course not impossible. If you work at it, and really go out of your way to abuse it, it does have the potential to cause serious problems.

For this reason we do not allow players to run scripts. Ever.

I did however anticipate in designing Babble-On that there would be a need to 'parse' the script without running it. That is to say, do everything we're going to do to run the script, and then stop just short of actually carrying out the task, which is of course safe for anyone to do.

And so armed with this manual, and the ability to know if you've written the script right, I hope to put in your possession the plow and mule necessary to make this place come alive.

Thank you all very much for your contribution. It will always be remembered.

And thank you Johnny for your constant guidance, for without it we would not all be here doing this.

� �

Chapter 1: LambdaMOO Background

...and Pavel Curits said, "Let there be objects, and let them all be called upon by their unique name or number." And thus LambdaMOO was born.

In LambdaMOO, you have objects. EVERYTHING is an object. Your character is an object. The Drome is an object. Hookie is an object. Those shipping crates you run around with are object. Beer is... well beer is beer. And don't fuck with that. But those little shots of whiskey you throw back are definitely objects. You get the idea.

Objects are always of some 'type'. Types are always denoted by starting with a $.

For instance:
Characters are of the $player type.
Hookie is of the $npc type.
The Drome is of the $room type.

To find an object, you must know it's type. We'll go more into depth about this later.

For right now, that's what you need to know that's specific to LambdaMOO. For those of you who have programmed in LambdaMOO, you know this is a gross oversimplification of what's really going on. For those of you who haven�t, treat it like the law, for it is all you need to know about this.

Chapter 2: Command Structure

[font=courier]find me a mother fucking $npc called "Chaim" and call that stupid ass dickweed "%chaim"[/font]
That is an actual line from a script.

Scripts are just long lists of commands with one command per line. Like a story, they're executed from beginning to end as they're read.

The first word on the line is the command your executing. Examples of commands are find, create, move, rename, describe, tell, force, and things like that.

Everything after the command is the 'arguments' that you pass to that command.

Understanding how arguments work is vital to using commands effectively.

Here's an example of a command and some arguments:

[font=courier]tell %player "You suck dude."[/font]

In this example, tell is the command, and it's being given the two arguments: %player and "You suck dude.". %player is who we want to tell. "You suck dude." is what we want to tell him.

%player is a variable. All variables start with %.

Variables are special types of arguments. They get substituted with values when the script is run. In our example, %player is going to get substituted with the player who called the script. That's because %player happens to be a variable that's available in every script. It's value is the object of the person who the script is running for.

You can also create your own variables. This is done by using a command which takes a variable name to set a result to.

Let's use an example. One command that creates a variable is the 'create' command. The 'create' command takes 2 arguments: The type of object to create, and the variable to assign the new object we just created to. It might look like this:

create $npc "%badguy"

Note that %badguy is in quotes here. That's because you don't want the script engine to try and substitute %badguy here; You want to pass the string in so it knows what variable to set it to.

After that line, whenever you use the %badguy variable, it will automatically be substituted with the new $npc you created. For example:

create $npc "%badguy"
describe %badguy "A really ugly dude."
force %badguy "emote glares around the room coldly."

Arguments can be "quoted strings", numbers (1234567890), %variables, or $types.

So here's the fun part: If a argument doesn�t start with a ", a number, a %, or a $, it's ignored.

This means that you can put in any amount of words to help you read/remember the commands. For instance:

find $npc "Chaim" "%chaim"

This is functional, but not very pretty. Let's add some filler words to make it more readable.

find me the $npc named "Chaim" and call him "%chaim"

Both lines are identical. One is much easier to read. So whenever you see a a line with a lot of words on it, remember: Only the quoted strings, %variables, $types, and numbers matter. Everything else is to help you figure out what it's doing.

Chapter 3: Command Reference

This is a list of all the supported commands. The arguments are listed by their expected type, being one of the following:

OBJ: Object or Type
STR: A quoted string
INT: A number
ANY: Any of the above

Here are the commands:

pause INT seconds
�Pauses for that many seconds.
�Ex: pause 14

find OBJ type, STR name, STR variable
�Attempts to find a object which is a parent of type, and has a name which matches the 'name', and assign the result to the 'variable'. If it's unsuccessful, it will raise an exception, halting the script.
�Ex: find $player "Epsilon" "%player"

move OBJ what, OBJ where
�Moves 'what' to 'where'.
�If this is a player in a room, it will automatically make them look.
�Remember to tell the appropriate people that 'what' has moved.
�Ex: move %player $dream_room
� � � �move %item %player

rename OBJ what, STR name
�Changes the name and aliases of 'what' to 'name'.
�Ex: rename %coupon "Buy-one-get-one-free coupon"

describe OBJ what, STR description
�Changes the description of 'what' to 'description'.
�Ex: rename %item "A flimsy coupon which is long past the expiration date."

create OBJ what, STR variable
�Creates a copy of 'what' and sets the result to the 'variable'.
�Ex: create $dream_room "%room"

// <anything>
�A comment in the script.

set STR variable, ANY value
�Assigns the 'value' to the 'variable'
�Ex: set "%message" "Your going to regret that."
� � �set "%dude" %player

if <expression>
��<expression> can be any command and arguments which return a meaningful value.
� <expression> supports multiple commands separated by the 'and' and 'or' keywords
� If the expression is true, the next part is executed.
��If the expression is false, and there�s an else the else part gets executed.
� If the expression is false, and there�s an elseif, the elseif gets evaluated like an if.
��if's must have a matching 'endif'.
��Ex: if match %message "want" and match %message "beer" or match %message "brew"
� � � �// The 'and' happens first, so this matches on 'want' and 'beer', or 'want' and 'brew'
� � � �force %npc "say Yeah, I'll have a beer."
� � �elseif match %message "vodka" and match %message "want"
� � � �force %npc "say Sure, I'll take a shot."
� � �elseif match %message "gin"
� � � �force %npc "say Nah, I don't like gin."
� � �else
� � � �force %npc "say Do they serve that here?"
� � �endif

�Used with an if to denote the part that get's executed when the if expression is false.
�See if for example.

�Used to end an if.
�See if for example.

elseif <expression>
�Used with an if to make another check if the if is false.
�See if for example.

match STR what, STR pattern, INT case-matters = 0
�Returns true if 'what' matches the 'pattern'.
�If the pattern is case-sensitive, pass in a 1 for case-matters.
�Ex: if match %phrase "yes"
� � �if match %password "Red Dog" 1
� � �See if for more examples.

notmatch STR what, STR pattern, INT case-matters = 0
�Returns false if 'what' matches the 'pattern'.
�If the pattern is case-sensitive, pass in a 1 for case-matters.
�Ex: if notmatch %phrase "Fuck" 1
� � �See 'if' and 'match' for more examples.

tell OBJ what, STR message
�Tells 'what' the 'message'
�Ex: tell %player "You feel sick."

force OBJ what, STR action
�Forces 'what' to do the 'action'
�Ex: force %npc "emote waves goodbye."

avatar OBJ who, OBJ type, STR variable
�Knocks out 'who', creates a copy of 'type', set's their .avatar to it, and sets the 'variable' to it.
�The result is that the player does will be echoed by the avatar, and everything the avatar sees the player sees, while their real body remains asleep elsewhere.
�Very useful for making the player appear to move without actually moving them.
�Ex: avatar %player $dream_avatar "%avatar"

unavatar OBJ avatar, STR variable
�Changes the avatar's person's .avatar back to themselves, revives them, destroys the avatar, and sets the person to the variable.
�Ex: unavatar %avatar "%player"

Chapter 4: Tying it all together.

"My doctor says I have a malformed public duty gland and a natural deficiency of moral fiber, and that I am therefore excused from saving universes." - Ford Prefect

Confused yet? How about we do some example scripts so you can get a feeling for what's going on here.

Recall that the variable %player is always available in a script, and is set to the object that the script is running for. Let's use the daydream example.

The goal is to write a script that makes the player have a daydream while they're sitting on the Mag-Lev.

To accomplish this, we'll simply tell the player having the daydream a message, pause for a little bit, tell him another message, pause, message, pause, and on like this until the day dream is done.

So, the script might look like this:

tell the %player "Your mind wanders, and you find yourself thinking about the past."
pause for 15 seconds
tell the %player "Friends and family, events from long ago and recent occurrences, lovers, enemies, places you lived all flash through your mind like first person perspective documentary about your life being played in non-linear order."
pause 20 seconds
tell %player "Your jolted from your reverie as the train hits a bump, jarring you in your seat, snapping you back to your senses."

It really can be as simple as that.

Want more? Try this one on. This is a dream sequence for a ex-convict. It makes use of the 'avatar' command and the $dream_avatar to create a 'dream-double' of a player so the player appears to be moving around and acting through this dream-double, while the player's body remains unconscious and safe at home. The $dream_avatar has all of it's commands except for 'look' disabled, so players can't do anything except for look at things.

// Check the command references. The // commands is a comment.
// Create a prison cell and set it up first.
create a new $room and call it "%prison"
rename the %prison so it's now called "Prison Cell"
describe the %prison like this: "A dank musty concrete cell with iron bars."
// Now avatar the player and move his avatar into the Prison Cell.
avatar the %player as a $dream_avatar and call his avatar "%avatar"
move the %avatar into the %prison
// Move forces them to look, so we don't need to do anything to make them see where they are.
// Now let's mess with this guys head.
pause for 25 seconds
tell %avatar "All around you the loud voices of inmates banging on the walls and hooting and hollering reverberate around the cold hard walls and floor."
// The script goes on for a while, doing pauses and tells, until finally were ready to end the dream, so we...
unavatar the %avatar and give me back my "%player"
force the %player to ".scream at the top of my lungs!"

Nice ending, huh?

Well I hope you get the idea... at least enough to start asking questions.

So far we've covered in light detail the important aspects of 'player centric' scripts.

In my next post I'll go more into depth about some of the more advanced commands and give examples of their usage, and introduce you to 'NPC centric' scripts, which are designed to run based around an NPC doing something rather than something happening to a player, and how the two are different, but still the same.

I'll also have for you by then your @test-script commands in place, and I'll discuss their usage.

For now, you can feel free to open up your local editors and start plugging away using what you've been given here. Remember that I've not talked about NPC-centric scripts, so don't start making assumptions about how to do things like NPC interaction with players when the NPC is allready in existance. You don't use find to do it. In fact, find should only be used on very rare occasions. For 99% of your scripts, you'll be basing them around either the player, or a NPC, not 'finding' what your looking for and working from there.

And of course, feel free to post your scripts, questions, comments, and screams of agony.


(Edited by Kevlar at 2:51 am on Sep. 14, 2002)