You are reading the Wyvern Autobag Command reference. Good luck!

We are not, at present, planning to provide a Wyvern User's Guide. Wyvern is meant to be a game of discovery through trial, error, and perhaps consulting player-created Wikis. However, the in-game autobag command is complicated enough that it warrants publishing the manual.

Contents

• Intro
  • Shortcuts
• Overview
• Autobag Syntax
  • Naming Conventions
  • Autobag Subcommands
• INTO subcommand
  • How Autobag Rules Work
  • Specifying Bags
    • Multiple Bags
    • Name Matching with LIKE
    • Naming Your Bags
  • Rule Conditions
    • Name Matches
    • Exact Match Example
    • Quantity Match
      • Combining Conditions
    • Type Match
    • Property Match
    • Inverted Property Match
    • AND rules
    • OR rules
    • NOT rules
  • Mixing AND, OR, and NOT
    • Precedence
    • Grouping Conditions with Parentheses: ()
      • Grouping Example
      • Simplifying Our Example
  • Final Notes about Rule Conditions
• LIST subcommand
  • Canonical Form
• RENAME subcommand
• DELETE subcommand
• ADJUST subcommand
• Hints
  • Error Messages
• Autobag Todo List
• Suggestions

Intro

Wyvern provides a powerful command called "autobag" that lets you place items in bags automatically when you pick them up. The command is a bit complicated to use, but it's well worth learning. It's one more step along the road to becoming a Expert HoFer.

Shortcuts

By popular demand, we've provided some shortcuts for popular autobag rules. The current shortcuts are listed in the table below.

To use a shortcut, all you have to do is type "autobag shortcut arrows" (or whatever the shortcut is), and it takes care of setting up the rule for you. You can use "autobag list" and "autobag delete" to manage your rule list.

Current shortcuts:

If you want more control over which items go in which bags, you can use the autobag mini-language, which is described below. It's a lot of reading, so if it seems scary, you may be better off finding another player to help you write your rules.

Overview

At a high level, "autobag" works like this:

1. You set up rules for which items go in which bags
2. You can add, delete, rename, or swap rules
3. When you pick up an item, all your rules are checked
4. If one of the rules matches, the item goes in that bag

We'll go into how all this works shortly, but to whet your appetite, here are some examples. See if you can figure out what they do. If you can't, don't worry! We'll explain it all. By the time you finish reading this web page, you'll know how to make all of these rules, and even more complicated ones if you need them.

Example 1

  AUTOBAG INTO quiver WHERE name LIKE "arrow" CALL RULE "normal arrows"

Example 2

  AUTOBAG INTO "elixir pouch" WHERE type is potion CALL RULE "potions"

Example 3

  AUTOBAG INTO "Master Wizard's Reagent Pouch", "reagent pouch"
     WHERE type is "reagent"
       AND NOT (name LIKE "dragon heart" or name LIKE "dragon claw")

Example 4

AUTOBAG

   INTO "quiver of holding 1", "quiver of holding 2", "backpack"

   WHERE

     ((name like "arrow") and name like "slaying"
      and quantity <= 100)
      AND
      item is not cursed
      and (item is blessed or item is uncursed)
      and not item is unpaid

    CALL RULE "this is one crazy rule!"

Autobag Syntax

The autobag command is actually a mini-language, similar to mail filtering. The basic syntax looks like this:

   autobag <subcommand> [arguments]

Naming Conventions

We're following the Unix operating system naming conventions above:

• When you see the syntax for a command, the first word is always the command verb — in this case, "autobag".

• When you see something in <angle brackets>, it means it's required.

• When you see something in [square backets], it means it's optional.

So in this syntax snippet:

autobag <subcommand> [arguments]

it means that you always need to provide a subcommand, but some subcommands don't need arguments.

Incidentally, "arguments" to commands are just extra information you pass along to the command. For instance, if you type "get all from corpse", the command verb is "get", and the arguments are "all from corpse". Simple!

Autobag Subcommands

Autobag has five subcommands. You specify which subcommand to use with the second argument. For example, if you type autobag list, then autobag is the command, and list is the subcommand.

The most interesting and complicated subcommand is "into", which creates a new autobag rule. We'll cover all of the subcommands in the sections below.

INTO subcommand

Every rule has three parts:

1. A name, which you specify with CALL RULE
2. A set of conditions, which you specify with WHERE
3. A set of bags, which you specify with INTO

  autobag INTO <bag> [, bag]* WHERE <conditions> CALL RULE "<name>"

For the rest of this manual, we'll often put the bag names in purple, the rule conditions in green, and the rule name in red, just to make things a bit easier to read.

How Autobag Rules Work

If you have more than one rule, it will check each rule in order. The first rule that "matches" the item you picked up wins. If none of your rules match, the item just stays in your top-level inventory.

As a quick example, let's say you have three simple rules defined. We've broken the rule sections into separate lines, for readability. Keep in mind that in the game, you always have to type out the entire rule on one line.

Here are our example rules:

autobag
    INTO "quiver"
    WHERE name LIKE "arrow"
    CALL RULE "arrows"

  autobag
    INTO "backpack"
    WHERE name LIKE "tiny round shield"
    CALL RULE "shields"

  autobag
    INTO "elixir pouch"
    WHERE name LIKE "potion"
    CALL RULE "potions"

1. First it tries your "arrows" rule. The "arrows" rule says that if the object's name is like "arrow", put the object in your first quiver.

   In this case, the potion of healing's name is definitely not like "arrow", so we move to the next rule.

2. Next, it tries your "shields" rule. This rule says that if the object's name is like "tiny round shield", put it in your first backpack. The potion is not a shield, either, so we move on.

3. Last, it tries the "potions" rule. This rule says that if the object's name is like "potion", stuff it in your first bag called "elixir pouch". The name "potion of healing" is like "potion" (later we'll define that that means, exactly), so the Autobag system puts the potion in your elixir pouch!

   Of course, if you don't have an elixir pouch, it doesn't do anything. You just wind up carrying the potion.

Specifying Bags

The first thing to know is that you usually only need to specify one bag. The object can only go in one bag, so the other bags you mention in the rule are just backups, in case the first bag fails.

A bag can "fail" for 2 reasons:

1. It's full, and has no room for the new object.
2. Or, the bag's not in your inventory.

autobag
    INTO "doggy's mouth"
    WHERE name like "biscuit"
    CALL RULE "nice doggy"

Multiple Bags

autobag
    INTO "quiver of holding", quiver
    WHERE name like "arrow"
    CALL RULE "arrows"

Note that it doesn't matter what order the quivers appear in in your inventory. The order in the rule does matter. You could have a regular quiver in your inventory before the quiver of holding, but your rule says to try the quiver of holding first, so that's what it does.

Notice that we didn't put any quotation marks around the second bag name. We just said quiver, with no quotes. In general, you only need to use quotes around a name if there are spaces in it.

Finally, bag names are matched with LIKE, which means that the game only uses partial matching, not exact matching. The next section discusses this in more detail. It's important!

Name Matching with LIKE

1. quivering blob corpse
2. quiver
3. quiver of holding

The multi-bag example above looked like this:

autobag
    INTO "quiver of holding", quiver
    WHERE name like "arrow"
    CALL RULE "arrows"

However, if the quiver of holding is full (or you're not carrying it), the game goes on to the second bag, which is specified simply with quiver (quotes don't matter since it's just one word.)

But look at your inventory — your first bag that matches "quiver" is actually the quivering blob corpse.

Why? Because bag names are matched with LIKE, which checks if the name you specified is a substring of the object's short description.

An object's "short description" is the text you see when you're looking at it in your inventory, or on the ground. It includes modifiers like "(unpaid)" and "(cursed)".

A substring means that string A appears anywhere inside string B. So "quiver" is a substring of "quivering blob corpse" — it starts at the beginning. "blob co" is also a substring of "quivering blob corpse", for what it's worth.

So, our rule, which failed to find a "quiver of holding" (because you weren't carrying one, or it was full), tries to find a bag matching quiver, and finds the corpse. You can't put things in corpses, only take things out, so the bolt doesn't go in any bags.

You can get around this problem by giving your bags very specific names.

Naming Your Bags

Rule Conditions

We'll work our way up from simple conditions to complex ones. The simplest (and most common) rule is to match something's name. As we described in Name Matching with LIKE above, name matching can use LIKE to do partial matching. It matches what you type against the object's short description.

Name Matches

autobag
    INTO backpack
    WHERE name like "dragon claw"
    CALL RULE "dragon claws"

Added rule 'dragon claws' as rule #1

You can see your rules by typing "autobag list". We show a little command session below, where the commands you type are in brown, and the game output is in black:

autobag into backpack where name like "dragon claw" call rule "dragon claws"
  Added rule 'dragon claws' as rule #1

  autobag list
  1.   dragon claws

  autobag list 1
  Autobag Rule: dragon claws
    Bags to add to: "backpack"
    Conditions:
      name LIKE "dragon claw"

Exact Match Example

We change the rule to use "=" instead of "like":

  autobag
    INTO backpack
    WHERE name = "dragon claw"
    CALL RULE "dragon claws"

Some computer languages use '==' instead of '=' to test for equality. Since autobagging is a simple language, we've tried to make it easy for everyone, and you can use '==' if you prefer.

Quantity Match

At first, you might think "well, I'll just pick up rocks and put them in my Rock Pouch", like so:

  autobag
    INTO "rock pouch"
    WHERE name like "sling stone"
    CALL RULE "sling stones"

You can fix this by checking the quantity of the item you're picking up. Here's a rule that does it:

  autobag
    INTO "rock pouch"
    WHERE name like "sling stone" AND quantity <= 50 
    CALL RULE "sling stones"

Notice that we used a new operator, AND, to combine two conditions. We'll talk about the AND operator a bit more later on.

Note: If you're an experienced Wyvern player, you might be wondering what the heck a Rock Pouch is, and where you can get one. Well, as it happens, we decided while writing this tutorial that it would be a useful thing to have, so we made one. Look for it in your local shop!

Note about that note: As we were writing this tutorial, we found an ancient comment in the Wyvern source code for Slings, dating back to June 10th 1998, that said "we need sling stone pouches". It took the autobag command to convince us to make one!

Combining Conditions

  autobag
    INTO "drop item"
    WHERE name like "sling stone" AND quantity > 50 
    CALL RULE "drop too many sling stones"

You can use the following comparison operators for matching quantities:

• < (less than)
• > (greater than)
• <= (less than or equal to)
• >= (greater than or equal to)
• != (not equal)
• <> (not equal — same as !=)
• = (equal to)
• == (equal to: same as =)

Type Match

1. Name match, which checks an item's description
2. Quantity match, which checks an item's quantity

The autograb command currently supports seven types: food, magic, armor, weapons, missiles, and treasure.

The autobag command goes a step further and supports many more types. Here is the current list:

To do a type match, use the following syntax:

  TYPE IS <type>

We will eventually update autograb have finer-grained types to match the autobag types.

Property Match

• cursed
• blessed
• uncursed
• kept
• unpaid

The syntax for matching a property is:

  ITEM IS <property>

  autobag
    INTO "uncursed armor bag"
    WHERE type is armor AND item is uncursed
    CALL RULE "uncursed armor"

  autobag
    INTO "cursed armor bag"
    WHERE type is armor AND item is cursed
    CALL RULE "cursed armor"

  autobag
    INTO "blessed armor bag"
    WHERE type is armor AND item is blessed
    CALL RULE "blessed armor"

Inverted Property Match

You can write this with two rules. You want to put stuff that's NOT cursed into the "uncursed stuff" bag, and cursed stuff into the "cursed stuff" bag.

One of the rules introduces a new operator called, appropriately, NOT. The rules look like this:

  autobag
    INTO "cursed stuff"
    WHERE item is cursed
    CALL RULE "cursed stuff"

  autobag
    INTO "uncursed stuff"
    WHERE item is NOT cursed
    CALL RULE "non-cursed stuff"

There are actually two flavors for using NOT with property matching, both of which have identical results:

  NOT item is <property>

  item is NOT <property>

AND rules

You can chain as many conditions together as you want by putting AND between each of them.

For example, if you type:

  autobag
    INTO "blessed quiver"
    WHERE name like "arrow" AND item is blessed AND quantity < 100 
    CALL RULE "blessed arrows"

1. The object's name has to match "arrow"
2. AND the object has to be blessed
3. AND the quantity has to be less than 100

OR rules

For example, if you want to put items that are blessed or cursed in a special bag, but not if they're uncursed, then you can do this:

  autobag
    INTO "blessed/cursed"
    WHERE item is blessed OR item is cursed
    CALL RULE "blessed and cursed stuff"

1. Is it blessed? If so, it bags it.
2. Is it cursed? If so, it bags it.

NOT rules

1. I like spinach.
2. I like spinach — NOT!

To use NOT, let's say you only want to autobag item if they're not cursed. You can write the rule like this:

  autobag
    INTO "uncursed"
    WHERE item is NOT cursed
    CALL RULE "blessed and uncursed stuff"

However, the more general version is "NOT item is cursed". You can think of it like this:

1. the test is item is cursed
2. to invert it, put a "not" in front, like this: NOT item is cursed

  autobag
    INTO "quiver"
    WHERE quantity NOT <= 100
    CALL RULE "this rule is broken!"

  autobag
    INTO "quiver"
    WHERE NOT quantity <= 100
    CALL RULE "this rule works!"

  autobag
    INTO "quiver"
    WHERE quantity > 100
    CALL RULE "even better!"

Probably the easiest way to get it right is to remember two things:

• You can't stick a NOT keyword in any old place in your rule.
• You can always stick a NOT in front of a condition.

  autobag
    INTO "quiver"
    WHERE name like arrow and NOT NOT NOT NOT NOT item is cursed
    CALL RULE "this rule is weird!"

Mixing AND, OR, and NOT

  autobag
    INTO "small pouch"
    WHERE type is reagent AND name like "clover" OR item is cursed
    CALL RULE "this rule is tricky!"

1. It could mean that if you pick up an an object, autobag it into your small pouch if it's a reagent whose name is like "clover", or if it's any cursed object at all.

2. Or, it could mean that if you find a reagent, autobag it into the "small pouch" if its name is like "clover", or if the reagent is cursed.

   (type is reagent AND name like "clover") OR (item is cursed)

The second interpretation assumes that OR is stronger, and makes a single condition out of the two around it, like this:

   (type is reagent) AND (name like "clover" OR item is cursed)

So which one is it?

The first interpretation is the correct one! AND is in fact stronger than OR. So in the tricky rule above, all cursed objects would go into your small pouch. Probably not what you wanted, is it?

Precedence

The NOT keyword has an even higher precedence than AND or OR. However, it's used differently. AND and OR go between two other conditions, linking them together. NOT goes before a condition, inverting its meaning.

It's usually best if you write complex rules using parentheses, to make sure your meaning is clear. This is especially true if you mix AND and OR in the same rule.

Grouping Conditions with Parentheses: ()

  autobag
    INTO "weapons"
    WHERE type is weapon
    CALL RULE "weapons to sell"

  autobag
    INTO "weapons"
    WHERE (type is weapon)
    CALL RULE "weapons to sell"

  autobag
    INTO "weapons"
    WHERE ((((type is weapon))))
    CALL RULE "weapons to sell"

Parens become useful when you want to mix AND and OR in a complex rule.

Grouping Example

1. You want all your arrows of slaying to go into a quiver called "magic quiver".

2. But you only want blessed and cursed magic arrows to go there.
   If they're cursed, you want them to go into "cursed quiver".

3. All other arrows go into "quiver of holding".

1. arrow of slay demon
2. arrow of slay dragon
3. silver arrow

1. One rule that matches all uncursed/blessed slaying arrows, and puts them into "magic quiver".

2. A second rule that matches all cursed slaying arrows, and puts them into "cursed quiver".

3. A final rule that matches all other arrows, putting them in "quiver".

  autobag
    INTO "magic quiver"
    WHERE 
      (name like "arrow" AND (name like "slaying" OR name like "silver"))
      AND item is not cursed
    CALL RULE "uncursed slaying arrows"

  autobag
    INTO "cursed quiver"
    WHERE 
      name like "arrow" AND (name like "slaying" OR name like "silver")
    CALL RULE "cursed slaying arrows"

  autobag
    INTO "quiver"
    WHERE name like "arrow"
    CALL RULE "all other arrows"

autobag list
Your autobag rules:
1. uncursed slaying arrows
2. cursed slaying arrows
3. all other arrows

Simplifying Our Example

  autobag
    INTO "magic quiver"
    WHERE type is arrow AND item is slays AND item is not cursed
    CALL RULE "uncursed slaying arrows"

  autobag
    INTO "cursed quiver"
    WHERE type is arrow AND item is slays
    CALL RULE "cursed slaying arrows"

  autobag
    INTO "quiver"
    WHERE name like "arrow"
    CALL RULE "all other arrows"

Notice that you don't need parentheses if you're not mixing AND and OR in the same rule.

Not only are these rules simpler to read than the first three, they also cover any new types of slaying arrows that are added to the game, because they're matching on a property, not the item name.

Unfortunately, knowing which items have common properties that you can test for is impossible without asking a Wizard. If you are trying to do complex matching on object names, and you think you could use a new property to make your rule simpler, ask any Wizard to clone and examine the objects you're trying to match, to see if there are any props you can take advantage of.

If there aren't any, or no Wizards are available, feel free to mail Rhialto in the village post office. It's easy for us to add properties to objects, and this kind of suggestion is very welcome.

Final Notes about Rule Conditions

Here are a few last things to keep in mind as you write your rules:

1. Don't try to pack too much into a single rule. You can often achieve the same results by setting up a series of rules that check for more and more general cases.

2. Prefer type and property matches to name matches. Name matches are slower than type and property matching. Name matching is also more error-prone. We sometimes change the names of objects in the game, and if you're matching an exact name, your rule may break when we change the object.

3. Ask for help if you need it. The autobag minilanguage is very rich; it's similar (in miniature form) to SQL, which is used to query and administer databases. If you master the autobag language, you're well on your way to learning how to be a computer programmer!

LIST subcommand

    autobag list

    autobag list <number>

  Your autobag rules:
  1. cursed reagents
  2. uncursed dragon claws and hearts
  3. drop >50 sling stones
  4. tiny shields

autobag list 3
Autobag Rule: drop >50 sling stones
  Bags to add to: "drop item"
  Conditions:
    (name = "sling stones") AND (quantity > 50)

Canonical Form

For example, these two sets of conditions are exactly the same:

  name like dog or name == fish and item is not cursed

  (name LIKE "dog") OR ((name = "fish") AND (NOT item IS cursed))

Here are the choices we make in canonical form:

• all keywords are uppercased (such as AND, OR, NOT, LIKE, IS, WHERE, ...)

• parentheses are always shown for rules composed with AND and OR, so you don't have to remember the precedence

• names always have quotes around them, except for property matches, since we currently think it's clearer not to have quotes for "ITEM IS unpaid". We may change our minds about this, but it won't affect your rules, just how they're printed out.

• NOT is always moved in front of the rule, so "item is not cursed" becomes "NOT item IS cursed".

• canonical form always uses '=' instead of the synonymous '==', and '!=' instead '<>'.

1. If if you don't write your rules in canonical form, you'll see them in canonical form with "autobag list <num>", which may be a bit surprising.

2. If you're writing a rule and it just doesn't seem to be working, you might try writing it in canonical form, since it's clearer. You may find rule mistakes faster that way.

RENAME subcommand

If you decide to rename a rule, use the RENAME subcommand. The syntax is simple:

  autobag rename <number> <name>

  autobag rename 6 runes into rune bag
  Renamed "test" to "runes into rune bag".

DELETE subcommand

  autobag delete <number>

If you accidentally delete a rule you needed, you can always rewrite it.

ADJUST subcommand

If a rule matches but then fails, the Autobagger keeps evaluating more rules in your list, until finds a rule that succeeds, or it runs out of rules.

The consequence of all this is that the order that your rules appear is very important. If you have a rule that's too general early in your list, it may apply to objects you didn't expect it to.

Here's a simple example that should help illustrate:

autobag into "cloak of thieving" where type is magic call rule "magic items"
Added rule 'magic' as rule #1.

autobag into "reagent pouch" where type is reagent call rule "reagents"
Added rule 'reagents' as rule #2.

autobag list
Your autobag rules:
1. magic
2. reagents

autobag list 1
Autobag Rule: magic
  Bags to add to: "cloak of thieving"
  Conditions:
    TYPE IS "magic"

autobag list 2
Autobag Rule: reagents
  Bags to add to: "reagent pouch"
  Conditions:
    TYPE IS "reagent"

Unfortunately, this set of rules doesn't work that way. The problem is that reagents are (or can be) marked as "magic", so the first rule will kick in before the second rule ever gets a chance. Any reagents that are marked by the game as "magic" will get stuffed into your cloak, using the rules above.

The solution: just adjust rule 2 into spot 1:

autobag adjust 2 1
Rule 2 adjusted to position 1.
Your autobag rules:
1. reagents
2. magic

Hints

1. Typos that make that autobag system unhappy. It will spit out error messages at you.

2. Typos that cause otherwise well-formed rules to do something different from what you intended. These are harder to find!

For example, while I was writing the system, I spent over an hour tracking what I thought was a bug, only to discover that my rule was broken. I had written:

  autobag
    INTO "backback"
    WHERE name LIKE "sword"
    CALL RULE "sword testing"

The moral of the story is: review your rules carefully, since they can do unexpected things (or nothing at all!)

Error Messages

autobag into backpack where type is magic
You have a syntax error in your rule:
Encountered "<EOF>" at line 1, column 33.
Was expecting one of:
    "or" ...
    "and" ...
    "call" ...

The error above says that it encountered <EOF> but was expecting "or", "and", or "call". That means it was parsing your rule definition, and it got to the end ("EOF" means End Of File), and was still waiting for some more input.

In this case, there are actually three possible keywords you could have typed. The last thing in the rule is type is magic, so you could have put an AND or an OR there to continue the conditions, or a CALL RULE there to finish the conditions and name the rule. So it was expecting "or", "and", or "call". Make sense?

If you look at the second line of the error message, it says "line 1, column 33". This can be helpful information. The line number will always be line 1, since you enter the entire rule on one line. But the column number is how many characters into the rule definition it got before it puked. If you trace along what you typed, counting characters until you get to that column, you'll see where your mistake is located.

Let's look at another error message. If we type in the rule:

autobag into blah
You have a syntax error in your rule:
Encountered "<EOF>" at line 1, column 9.
Was expecting one of:
    "where" ...
    "," ...

The weirdest error messages are when you forget to type in a bag name, property name, or other string. For example, if we type "autobag into where", it was expecting a bag name between the "INTO" and the "WHERE", and gives a weird message:

autobag into where
You have a syntax error in your rule:
Encountered "where" at line 1, column 6.
Was expecting one of:
    <STRING_LITERAL> ...
    <TYPE_LITERAL> ...

Someday we'll try to improve the error messages, but in the meantime, hopefully this is enough to get you started. Again, if you have a lot of trouble with a particular rule, make sure you mail Rhialto at your local post office, and give as much detail as you can.

Autobag Todo List

1. The ability to temporarily disable and re-enable rules.

   For instance, if you're walking through an area that has a bunch of reagents that you don't want to pick up, but you DO want to pick up other items, it'd be nice to disable some of your rules for a while.

   You can always work around it by turning autograb off.

2. The ability to "borrow" autobag rules from other players. Some players may have autobag rules that you want to use, and it would be convenient to have an "autobag borrow" subcommand that lets you use a rule from another player.

   You can always ask the player to do an "autobag list <num>" and send you the rule conditions.

3. Getting rid of Coin Purses.

   Coin purses are useful — when you pick up coins, they automatically go into your coin purse. However, they use a low-level game mechanism that requires you to drop the coin purse on the ground to get coins out of it.

   Fortunately, buying and selling automatically uses your coin purse money, so you should rarely need to get coins out of your coin purse.

4. Adding new triggers for rules.

   Your autobag rules are only evaluated when you pick up an item, or get an item out of a container on the ground. It would be nice to extend the minilanguage to allow you to say "WHEN" <some trigger>, for example "WHEN given", so when people give you things, they get autobagged automatically.

   For now, you have to drop something and pick it up again to get it autobagged, if it entered your inventory in some way other than picking it up.

5. Better error messages.

   As we described in the Error Messages section, the error messages tell you what's wrong, but in a fairly hard-to-read format. It's possible to use the parser to give better error messaging. We'll do this if people are getting really confused over the current error messages.

6. Auto-selling

   This isn't part of autobagging per se, but it would be a nice feature to be able to say "sell all from bag X".

Suggestions

If you have a rule that isn't working, first try rewriting it in a different form. If that doesn't work, talk to a Wizard or HoFer, and see if they can give you suggestions on how to make it work. If your rule still doesn't seem to work, it may be a bug in the autobag system. If you find a bug, email Rhialto at the village post office, and let him know which character and rule name are having trouble.

If you like the Autobag system, and there's a particular feature that you really wish it had, feel free to mail Rhialto and let him know. Some features may be easy to add, and some may be very hard, but he'll be happy to consider any suggestions that you come up with.

Enjoy!