_____       _             
  \_   \_ __ | |_ _ __ ___  
   / /\/ '_ \| __| '__/ _ \ 
/\/ /_ | | | | |_| | | (_) |
\____/ |_| |_|\__|_|  \___/ 

Like most MUDs the owners care about, writing zones for Hysteria is a bit different than writing zones for the standard codebase it's built upon. We've added many specific flags for mobiles, objects and locations that we use in our special little way. In addition, Hysteria uses object attributes to define a wide possibility of specific behaviors for objects that is completely independent of object flags, and nowhere near as limited.

In terms of world building, there is a fantastic guide to writing zones at ludd.luth.se, along with some good advice about how to make your zone the best it can be. I highly recommend reading it; however, when writing zones for Hysteria, there are some major differences. The guide is written around the specifics built in to Northern Lights. And, like any good MUD owners, they have customized and improved the heck out of the initial world format, in their own way. Naturally, their own way is not our own way. The end result: Some major descrepancies, when building for Hysteria.

This guide is intended to be a rework of that document (written completely independent of that document, no plagarism here, thanks) written specifically for Hysteria, with in-depth explanations of Hysteria-specific flags and functions, while still including the basics, in case you're new to zone building. I do give mad props to the folks at ludd.luth.se for their work on that document, which I've used extensively in my days of writing zones, dataing back to something like 1994 or 1995. So, off we go!

   ___           _          
  / __\ __ _ ___(_) ___ ___ 
 /__\/// _` / __| |/ __/ __|
/ \/  \ (_| \__ \ | (__\__ \
\_____/\__,_|___/_|\___|___/

First of all, you don't need a special program to write zone files. Any average text editor will work. If you're a *nix user, I use Vim. If you're a Windows user, Notepad works well. In the end, it's just a plain ol' text file with a .zone extension. And there lies the first thing we'll cover: Basic formatting.

Ultimately, the file will need to have the .zone extension, meaning that when it's added to the game's list of zones, the compiler will look for "name.zone" For example, the Eden and Exile quest on Hysteria is in the "dheaven" zone. The file name in the ZONES directory is dheaven.zone.

Now you have your file, you're ready to begin writing. The absolute first things that must go in your new zone are some mandatory includes, which look like this:

#include "undef.h"
#include "cflags.h"
#include "objattrib.h"
#include "exits.h"

These should be the first four lines of your file. They'll simply make it easier to reference the stats that will be defined for your locations, objects and mobiles. Which, not coincidentially, are the three parts in to which your zone must be broken, like this:

%mobiles

%objects

%locations

These three sections will contain your definitions for (gasp!) objects, mobiles and locations (shocker, eh?). Also note that everything in your file will be considered part of the zone, so be careful when you're writing. Incorrect entries or a missed ; here and there can cause "segmentation faults" during zone building and can take hours to track down and fix. If, however, you want to add informational comments to your file, you can do so using the standard C comment format of /* to open a comment and */ to close it. Note that if you open a comment with /*, you MUST have a */ at some point, since the zonebuilding process will ignore EVERYTHING in comments, regardless of whether it's your copyright/left information or actual pieces of your zone.

Still with me? Great. Let's start building.

              _     _ _           
  /\/\   ___ | |__ (_) | ___  ___ 
 /    \ / _ \| '_ \| | |/ _ \/ __|
/ /\/\ \ (_) | |_) | | |  __/\__ \
\/    \/\___/|_.__/|_|_|\___||___/

Mobiles, or Non-Player Characters (NPCs) are the dudes you interact with in a zone. You kill em for fun, you give em stuff or talk to em for healing or quest objectives, etc. Every mobile in the game is defined in some zone file so the game knows how strong the mobile is, where it is, how much it'll move around and so on. As an example, we'll look at our friend the Dirty Traveller who roams around outside of Cairhien:

Name            = traveller
Pname           = "Dirty Traveller"
Location        = n_road4
MFlags          { CanCast }
PFlags		{ }
SFlags		{ }
Strength        = 91500
Damage          = 350
Armor           = 20
Speed           = 1
Aggression      = 0
Description     = "
A traveller from a far off land walks along here."
Examine		= "
He looks somewhat road worn and weary."
End             = traveller

Fun huh? It's really not bad. We'll hit it line by line:

Name:

The "internal" name of the mobile. The name the game will use to interact with the mobile, not the name players will use. This MUST be identical to the "End" field.

Pname:

The "everyday" name of the mobile, which players will use to interact, and what is displayed in-game anytime the mobile does something, such as moving from room to room, or shouting in glee after killing a player.

Location:

The starting location of the mobile. This is the "internal" name of the room the mobile will start from when the game is first booted. Note that mobiles do not return to their start rooms on repop unless they've been killed. We'll talk a bit more about locations and the "internal" name in a bit.

Mflags:

These are "Mobile" flags, which will define certain behaviors and attributes of your mobile. If none of these apply to your mobile, you can omit this field completely. These flags include:

Thief:	Mobile will steal stuff from you
StealWeapon:	Mobile will steal your wielded weapon
Flee:	Mobile will attempt to flee from a fight
Bar:	Mobile will prevent player from exiting that direction. (BarNorth BarSouth BarEast BarWest BarUp BarDown)
NoGrab:	Mobile won't let you pick anything up in that room
GrabHostile:	Will attack if you try to pick something up
PickStuff:	Mobile will pick up stuff it finds
NoSteal:	Can't steal from these Mobiles
Cross:	Won't attack if you're carrying a holy item
Blind:	Mobile will try to blind you during combat
Cripple:	Mobile will try to cripple you during combat
Deaf:	Mobile will try to deafen you during combat
CanCast:	Mobiles can cast spells just like players
Good:	Mobile's alignment is Good
Evil:	Mobile's alignment is Evil
GoldThief:	Mobile will try to steal your gold
Animal:	If spoken to, animal will simply grunt
Monster:	If spoken to, the mobile may attack
Hunter:	Mobile actively hunts players in the zone

Pflags:

The valid pflag for Hysteria is:

NoHassle: Mobile is peaceful and cannot be attacked

If you don't want your mobile to be peaceful, you can omit this field completely.

Sflags:

Only one sflag as well:

Female: The mobile is a chick.

Again, if you don't want the mobile to be femm, leave this field out.

Strength:

This is the mobile's hp. The traveller is a tough dude, so the figure here is definitely somewhat high. A more entry level mobile would have around 6,000 strength. Unless you want -really- easy mobs, I wouldn't go below that figure, and unless you're building a special mob, you don't want to go above 100,000. Also keep in mind that the CanCast mflag will DRAMATICALLY increase the difficulty of killing said mobile.

Damage:

How hard the mobile can hit. And this is base damage. Any weapons wielded by the mobile will increase the damage (we'll get in to that more later). Low end damage is around 20. 350 is on the higher end.

Armor:

The mobile's armor count. Like damage, any armor worn by the mobile will add to this figure, so this is just base armor. Please note that a mobile should NEVER have more than 90 armor.

Speed:

This is basically how much the mobile will move around, between 0 and 100. If you don't want a mobile to move the room it starts in, set this to zero (0).

Aggression:

Will the mobile try to attack a player, unprovoked? Also a 0-100 range with 0 being the mobile will not attack players unprovoked and 100 being the mobile will essentially attack on sight.

Description:

What the mobile looks like in the room.

Examine:

What the mobile looks like when a player examines him or her. Note that the opening quote for both description and examine MUST be on the same line as the = sign. If you don't want your mobile to have an examine, you can omit this line, though it is discouraged.

And there's your mobile!

   ___ _     _           _       
  /___\ |__ (_) ___  ___| |_ ___ 
 //  // '_ \| |/ _ \/ __| __/ __|
/ \_//| |_) | |  __/ (__| |_\__ \
\___/ |_.__// |\___|\___|\__|___/
          |__/           

So we have our mobiles. Great! Now we want to add cool stuff for them to wield, wear, have laying around; we may want to throw in some doors and so forth. All of these are objects, and all objects are defined in a format similar to mobiles. Objects, however, are a bit (read: a lot) more complex.

There are, essentially, four kinds of objects: Run of the mill objects (food, scrolls, containers, etc), armor, weapons and doors. We'll go through these in depth, one by one. It won't be so bad, I promise.

General Items:

We'll cover general items first, since all other items follow the same format and rules, just with a few added fields and guidelines. So, let's fetch us an object. For this, we'll use the vial in Dark Heaven:

Name                    = vial
Pname                   = "vial"
AltName                 = glass
Location                = IN_ROOM:nature
Oflags                  {}
Size                    = 3
Weight			= 1
State                   = 0
MaxState                = 0
Desc[0]                 = "A small glass vial"
Examine                 = "
It's a hollow glass vial. It brings back images of ... bloodtests... or..
Huh. The memory is gone.  Wonder what that was about?"
End                     = vial

For objects, Name and Pname work, basically, the same as they do for mobiles. But objects also have a third name field called "Altname" which will allow you to specify an alternate name by which the player can interact with the object. This is useful espeically in cases where the description may suggest more than one possible name, like above. In this case, "A small glass vial" can be used, picked up, dropped, examined, etc, using either "vial" or "glass."

Location, as you can see, is a bit different. We'll explore this, again, in a bit more depth when we get to locations, but for now, you do need to know there are five possible location types for objects:

IN_ROOM:roomname as displayed above. This will place the item on the ground in the specified room.
CARRIED_BY:mobilename - the object will be carried by the specified mobile.
WORN_BY:mobilename for objects you want a mobile to be wearing
WIELDED_BY:mobilename if you want a mobile to be wielding a weapon, and finally
IN_CONTAINER:objectname for objects in sacks, bags, etc.

This brings us to Oflags. Hoboy. There are lots of these. Like Mflags for mobiles, Oflags are flags dictating specific properties and behaviors of items. So, let's take a look at em:

Destroyed:	Object is invisible to players until something is done. This is a special flag we'll discuss in detail below.
NoGet:	This object cannot be picked up.
Openable:	Can be opened or closed.
Lockable:	Can be locked/unlocked.
Pushable:	Can be pushed.
PushToggle:	Pushing will toggle it between two states.
Food:	Can be eaten to restore hp/mv/mana
Armor:	This item is Armor. Requires "Wearable" flag. See below.
Wearable:	Item can be worn. Requires Wflag field. See armor section.
Lightable:	Item can be lit.
Extinguish:	Once lit, can be extinguished.
Key:	Will open locked items.
GetFlips:	Toggles to different state once moved. Details below.
Lit:	Item is providing light
Container:	Can put other items in this item (bags, sacks, etc).
Weapon:	Item is a weapon.
Protected:	Item cannot be looted or stolen.
Good:	Item enhances alignment toward good.
Evil:	Item enhances alignment toward evil.
Boat:	Lets you go on water.
Gold:	Just a bunch of gold coins.
InStore:	Item is for sale in a store. Requires "Original" flag.
AcidProof:	Item is immune to acid
BurnProof:	Item is immune to fire
Original:	Original item in a store.
Potion:	Item can be quaffed.

Size:

How big is the item? For containers, how much can it hold?

Weight:

How much does it weigh?

State:

What state is the object in? Value from 0-3. All objects can have up to four states, each with its own description. This requires a bit of an explanation, but we need to cover the last two fields first.

MaxState:

This coincides with the State field above. Since objects can have as many as four states, this field will specify what the maximum State value can be for this object. This also requires some explanation. Let's finish off these last two fields, then we'll cover object states in a bit more detail.

Desc[x]:

This one goes hand in hand with the State field. This is the description for each of the object's possible states.

End

As with objects, the end field must be identical to the Name field.

Now that we've covered all of those, we're going to take a closer look at the State, MaxState and Desc[] fields. Here's how this works:

Again, each object can have as many as four states, 0, 1, 2 and 3. Most objects simply have one state, state 0, with the corresponding Desc[0]. But sometimes an object needs to have multiple states to work properly. To illustrate this, we're going to look at the chest in Frobozz:

Name            = Chest_chairman
Pname           = chest
Altname         = steelchest
Location        = IN_ROOM:chairman
Oflags            {NoGet Container Openable Lockable}
State           = 2
MaxState        = 2
Size            = 20
Desc[0]         = "Fastened to the floor is an open sturdy steelchest."
Desc[1]         = "Fastened to the floor is a closed sturdy steelchest."
Desc[2]         = "Fastened to the floor is a locked sturdy steelchest."
End             = Chest_chairman

So this chest starts in its MaxState of 2. This means that by default, the description of the chest will be the Desc[2] line. Once the chest has been unlocked, it is set to State 1 and the description changes to Desc[1]. Once it's opened, Desc[0] is displayed.

Other objects often have two states, 0 and 1, which can be toggled back and forth using the "PushToggle" or "GetFlips" flag. The State settings for a boulder that could be pushed aside to reveal an exit may look like this:

Oflags		= {PushToggle}
State		= 1
MaxState	= 1
Desc[0]		= "A large boulder has been pushed aside, revealing a hole in the wall."
Desc[1]		= "There is a large boulder blocking the east wall."

In this case, initially the boulder blocks the wall. Once it has been pushed, the Desc[0] is displayed. Since it's a toggle, if it is then pushed again, it will reset back to the Desc[1]. GetFlips work pretty much exactly the same way, except that instead of a push or move triggering a state change, picking the object up will set it to its lower state.

Now, two flags which have some specific dependencies are the NoGet and Destroyed flags. Items without the NoGet flag automatically get " is here." appended to the end of the description. In the case of the vial referenced above, the Desc[0] is simply "A small glass vial" while the description in the location would be "A small glass vial is here." This is done specifically so that you see the full item description in your equipment and inventory, as opposed to simply seeing the object's name. As a result, any items you want players to be able to pick up need only to be a description of the object, since " is here." will be added automatically. Since items with the NoGet flag are designed specifically to prevent players from picking them up, appeneding " is here." is not necessary. End result: If the item has the NoGet flag, you need to specify the full description, as in the example of the chest above.

Destroyed means the object is invisible to players. They cannot see it, and therefore cannot interact with it. Destroyed objects usually require some special action to be performed for the object to be "created" (basically meaning the Destroyed flag is removed). If you have objects that require this behavior, you'll need to include some comments containing a description of what type of action will cause the object to be created so the appropriate code can be added.

Weapons and Armor

I mentioned before that weapons and armor are a little different. They follow the same basic rules as normal objects, but have a few required flags and extra fields. To illustrate these differences, check out the Invincible body armor:

Name            = invincible
PName           = invincible
AltName         = bodyarmor
Location        = IN_ROOM:Love
Oflags          { Wearable Armor AcidProof Resilient }
Wflags          { Body }
Attrib          = A_HEAVYARMOR
Damage          = 5
Armor           = 100
HP              = 26
Mana            = 26
Desc[0]         = "
&+WInv&*inci&+Wble &+cbody armor&*"
End             = invincible

You can immediately see the differences. As before, we'll hit the specifics one by one:

Oflags:

Both the Armor and Wearable flags must be set on all armor objects. The Weapon flag must be set on weapons.

Wflags:

All wearable objects must have one, and only one, Wflag. Wflags specify where on the body the object is worn. Valid wflags are Finger, Neck, Head, Face, Torso, Waist, Body, Back, Legs, Feet, Arms, Hands, Wrist, Shield, Floater, Held, Eyes and Ankles. Since these are self-explanitory, I'll mention only that any object wearable on Finger, Floater, Held or Eyes cannot have any armor value. Wflags do not apply to weapons.

Damage:

The amount the object will increase your damage. For weapons, this should stay under about 60. For items, this should never be more than 5.

Armor:

The protective value of the item. There's a fairly intricate points system used to determine how much armor an item should have, but as of this writing, I can't find my copy, and Corwin hasn't sent me his yet. I'll update this with it when it is available. This field does not apply to weapons.

HP and Mana:

Your HP and Mana will be increased by these values. The points system mentioned above governs this as well. For now, it should never be above 15. I really need to find that file.

Attrib:

Attrib works similar to flags, in that it will specify a specific armor or weapon type. All weapon and armor objects must have an appropriate attribute set. Specific weapon attributes are:

	A_SHORTBLADE 
	A_LONGBLADE 
	A_BLUNT 
	A_SPEAR 
	A_AXE

	A_LIGHTARMOR 
	A_MEDIUMARMOR 
	A_HEAVYARMOR

A Word on Equipment Stats

We have meticulously combed through every piece of equipment on the game to ensure we do not have weapons that are too powerful or armor that's too protective. As a result, please try to keep your object stats reasonable. Try not to make them too heavy, but try to avoid making them too light. Take care when assigning damage, armor, hp and mana to equipment as well. Also, because we're taking great pains to ensure balance is maintained, your objects will be reviewed before your zone is compiled in to the world, and if your objects are out of whack, they will be adjusted. If you submit a zone, then find the object stats have changed once they're in the game, this is why.

   __                 _   _                 
  / /  ___   ___ __ _| |_(_) ___  _ __  ___ 
 / /  / _ \ / __/ _` | __| |/ _ \| '_ \/ __|
/ /__| (_) | (_| (_| | |_| | (_) | | | \__ \
\____/\___/ \___\__,_|\__|_|\___/|_| |_|___/

Now, I know I said we'd cover doors as well, and we will. But they get their own section, and to really understand how doors work, we need to cover locations first. Fortunately, locations are very easy. As before, let's look at some actual locations from within the game:

temple d:donation s:csq@faerlyn e:alt@faerlyn w:cloud@newbie ;
lflags {Peace FastMana FastHeal NoMobiles}
The Temple Of &+rHysteria^
   You stand in the Temple of &+rHysteria&+w, a huge stone structure with
walls decorated with ancient carvings and runes, some so old that even
the crusaders no longer know their meanings.
   Large pillars open to a grey square to the south.  The wall to the east
seems almost transparent.  A large white cloud floats just outside the
temple to the west.
^
donation u:temple;
lflags { Peaceful NoMobiles }
Donation Room^
  This is the donation room, feel free to use any items you find here.
^

What you're looking at are two locations in the start zone; the Temple of Hysteria and the Donation Room. The first line is the "internal" name referred to above, followed by where the exits will take you. The "internal" name is the name you will use to place objects in that room, as well as the name you use to create exits to this room from other rooms, as in the case of donation above.

Valid exit directions on Hysteria are n, e, s, w, u, and d, and for the sake of simplicity, it is recommended you always list your exits in the order stated. Note that any exit directions your room doesn't have can be left out.

Taking a closer look at the exits from temple, we see a few things which should be explained. The exit "d:donation" specifies an exit to another room within the start zone (in this case, donation). The other exits link to rooms in other zones. To do this, we use "location@zone" where location is the internal name of the room and zone is the name of the zone. Hence, alt@faerlyn and cloud@newbie, etc. The exits line must end with a semicolon (;). Also note that it's a very good idea to make your exits work both ways: if you can exit the temple down to get to donation, it is only logical that you should be able to exit donation up to get back to the temple.

The next line is (you guessed it) for Lflags, or Location flags. We really like flags, eh? Like all other flags we've discussed up to this point, these will specify the conditions of the room we're in. I guess now is when I list the lflags one by one, with a convenient little description of what the lflag means...

Dark:	This room is always dark. You will have to have a light source to see in this room.
Hot:	Room his hot. You'll need protection to enter.
Cold:	Room is cold. You'll need protection to enter.
Death:	The dreaded deathroom. Player dies on entry.
CantSummon:	Can't summon someone out of this room.
NoSummon:	Can't summon someone in to this room.
NoQuit:	You cannot quit from this room.
NoMobiles:	Mobiles will not enter this room. Good for setting up boundries for your zone's mobiles, so they don't go wandering in to another zone.
NoMagic:	Spells do not work in this room.
Peaceful:	Can't perform hostile actions or spells in this room.
Soundproof:	No sound will enter this room.
OnePerson:	Only one person in the room at a time.
Private:	No more than two people can be in this room at a time.
OnWater:	Need a boat to go here.
UnderWater:	Room is under water. Need special equipment to enter.
OutDoors:	Room is outdoors, will get weather messages. Light is real.
TempExtreme:	HOT in the day, COLD in the night.
NegRegen:	Stats (hp, mana, mv) will decrease in this room. Spellups will ignore players in NegRegen rooms.
NoRegen:	Stats (hp, mana, mv) will not heal in this room. Spellups will ignore players in NoRegen rooms.
NoInvis:	Players cannot be invisible in this room.
Maze:	Room is part of a maze. Scope doesn't work.
FastHeal:	HP heals quickly here.
FastMana:	Mana heals quickly here.
NoExit:	Cannot quit, portal, nexus, recall or be summoned out of this room.
Store:	This location is a store.
Equipment:	Only weapons and armor can be sold in this store (Used with Store flag).
Potion:	Only potions can be sold in this store (Used with Store flag).
Magic:	Only magical items can be sold in this store (Used with Store flag).
Graveyard:	On death, instead of dropping a corpse here, corpse is dropped in the graveyard, like when the player hits a deathroom.
CityLight:	Room is illuminated by city lights at night.

Fun stuff, yeah? A few things of note: Try to make your rooms as realistic as possible. If the room is outside, make sure it has the OutDoors flag. If it's outdoors, but in a city or village where there's substantial light at night, make sure it has both the OutDoors and CityLights flag. Take care when using the NoRegen and NegRegen rooms. Those can be evil. Moving on, then...

The next line is the title of the room. This is the description that will be shown when the exits are displayed. This line must end with a ^. Beyond that is the actual description of the room. Please try to be as descriptive as possible to make your zone really enjoyable. The room description must also end with a ^ on a new line.

Which brings us back to doors...

Alright, so we're back to doors. Doors are unique in that if you're going to have one, you have to have two, and they must be linked. Also, doors hide exits, so the exits behind them must be referenced in a specific manner within the location. Here's a common example of a set of doors:

Name      = Door1StChamber
Pname     = door
Location  = IN_ROOM:hall
Oflags    {Openable Lockable NoGet}
Linked    = Door2StChamber
State     = 2
MaxState  = 2
Desc[0]   = "The door is open."
Desc[1]   = "The door is closed."
Desc[2]   = "The door is locked."
End       = Door1StChamber

Name      = Door2StChamber
Pname     = door
Location  = IN_ROOM:storage
Linked    = Door1StChamber
Oflags    {Openable Lockable NoGet}
State     = 2
MaxState  = 2
Desc[0]   = "The door is open."
Desc[1]   = "The door is closed."
Desc[2]   = "The door is locked."
End       = Door2StChamber

Notice the doors are linked to each other via the Linked field. This means that when you open one door, causing its state to be changed, the other door will automatically change to match. Also notice that doors pretty much always need to have the NoGet flag. You really don't want players picking up your doors and carrying them around. Now, to understand the whole "hidden exit" thing, take a look at the room Door2StChamber is in:

Storage s:^Door2StChamber;
lflags {}
Storage Chamber^
   This is just a small store room, filled with empty crates and boxes, some
marked 'Fragile' and others 'Feel Free to Shake and Break'.  There is a single
doorway in the south wall.
^

See how the exit is referenced as "s:^Door2StChamber"? The little ^ thingy means that, instead of a standard exit, there's an object there. Since Door2StChamber is linked to Door1StChamber, when the door is opened, it will automatically open that door as well, and the exit will become a standard exit. Pretty simple, yes?

Some final thoughts...

There you have it. The formatting part really isn't that tough. Writing good locations and descriptions can be deceptively difficult, though. It can also be challenging to keep your zone organized. A disorganized zone can lead to mismatched or illogical exits. Again, you want to be as realistic as possible, including with the layout. If you're standing in a shop, and you exit s, e, e, n, w, w, you should end up back in the shop, not the middle of a forest or in an alley somewhere. Something I've found helpful is to sit down before you start writing out locations and map out your zone on a piece of paper. Use that as a guide when writing your locations to ensure you don't end up with the dreaded mismatched and illogical exits.

It is also recommended that you make your zone as interactive as possible. Try to give all of your objects and mobiles examine descriptions. It's never fun to examine a mobile and get "A typical, run of the mill Piper" or examine an object and be told "You see nothing special." Make your objects special. Keep your mobiles from being typical. Add puzzles, with subtle hints in object and location descriptions. Puzzles in zones are strongly encouraged. If your puzzles will require "specials," that is, extra code to make things happen when you use an item or open a door, etc, include a file with your zone that describes what should happen, what messages players should get when what actions are performed, etc. Be as specific as possible. If you're not sure if something can be done, ask a Messiah+.

Finally, when building your zone, you'll be writing a lot of text. I mean, a lot. Read and re-read your zone. Double and triple check for spelling errors, syntax typos, etc. Some typos can prevent the zone from compiling properly and can take literally hours to track down. It's tedious, difficult and time consuming, so please, take great care when building your zone. Help keep your local MUD Coder happy!

Questions? Comments? Contact hysteria "at" mephie "dot" ws.

Copyright (c) 2005 Jay Krueger.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. Click here to view the license. (AKA "Copyleft")