$Id: README 69 2004-11-29 01:04:21Z alan $

Changes in release 69

item.pl works with current mallstore.php
recipes.pl works with current Recipe.pm

This is a very big upgrade, since my svn repository has been down for a
while and lots of changes have accumulated.

Lots of clan functionality added.
Using items/drinks/food reports the text returned.
Adventuring/fighting interfaces added.
Some messy code for making meat paste/dense meat stacks is floating
in invbot.pl.

--------x-----------------x---------------------x----------------x-------

Changes in version 0.5:

recipes.pl: there was an error for names that had to be rewritten which
resulted in the action being dropped for these recipes.  This has been
fixed.

--------x-----------------x---------------------x----------------x-------

I try to keep most commands implemented in KoLBot.pm try at a low
level.  For instance, if you ask it to log in, it will try in the most
economical way it can, and throw an exception if it fails.  It does
not include code to keep trying until it is verified that a log in has
occurred.  This is the same for it's other features, in this way it is
like the IP.

The KoLBot::ensure wrapper takes this almost to the other extreme.  This
wrapper will continue calling the function until it doesn't "die", if the
function dies with ^NOTLOGGEDIN, the wrapper will attempt to login, until
it thinks it is, and then call the function again.  Ad infinitum.
This functions works best with reading.

The other way I've used the ensure function is (see invbot.pl)

$bot->ensure( sub {
  while (1) {
    if($state->{mode} == 1) {
      get_mail();
      $state->{mode} = 2;
      save_state();
    }

    if($state->{mode} == 2) {
      $state->{mode} = 3;
      save_state();
      do_something_not_to_be_repeated_if_successful();
    }

    if($state->{mode} == 3) {
      check_last_one_for_success();
      if(failed) {
        $state->{mode} = 2;
        save_state_to_file();
	redo;
      }
      $state->{mode} = 4;
   }
....
}});


# AWMNOTES

Things one can measure reliably: 
	things that are mailed (new chefbot code),
	things received in mail
Things you can't
	success of cooking
	making an offer
	accepting an offer
	using an item
	cooking/mixing/crafting/etc.

It is currently impossible to measure your inventory accurately
online.  Rationale: you can look at the inventory, but you do not know
if someone has just sent you an item (if you are trying to compare
your inventory against some other known state).  You can then go look
at your mail, but after you leave here and get there, another mail may
have arrived. Possible solutions: 1. time stamps. Right now these seem
to vary at least from servers to DB server (mail times), making this
impossible.  Even so, the accuracy on the mail is to a minute,
accurate enough for people, but not bots who may be handling many
items at a time.  2. Ignore all but.  If only those on your contact
list (setable) could send you kmail, you could block everyone, get
your inventory and mail, and then re-allow incoming mail.  This might
take significant overhead, though.

Explore using offer (for small amounts of meat) to transfer to/from,
it should also provide a verifyable state (NO, it doesn't)
Why not: I offer an item to someone, get a HTTP error.  I don't know
if I really offered it.  Can't look at inventory for old reasons.  Can't
look at meat either, to see if they took it.  If the offer isn't there,
they could have accepted already, or it might not have gone through.

There are no years in KMail, so they are all assumed to be in 2004.
This might be bad, but could be fixed by using using the ID numbers, come
2005.

invbot.pl design notes: every function should behave such that if it
is ^C'd or dies somewhere, when recalled will still make sure each
thing is done once, and exactly once (to the best of its ability)
