The botzilla project uses these core files and directories 
	botzilla.php
	logparse.php
	newlog.sh
	start.sh
	cls/
	logs/
	ziggi/
	perm_data/
	
	./cls
	  botzilla.class.php
	  botzillaLogParser.class.php
	  bz_test.class.php
	  FileStorage.class.php
	  ziggi.class.php
	
	./logs:
	  log
	
	./ziggi:
	 operator.class.php
	 reg.class.php

Core

botzilla.php is the script that is actually run when you start botzilla, and contains all of the setup variables. It's core classes are in cls/ and it's various plugins are stored in ziggi/. The other dirs start empty in the distributed version (heh, and maybe be removed), but they have importance to plugins only.

The bash script start.sh is the easiest way to start the bot. 

    $ ./start.sh

In cls/ are the core classes.
botzilla.class.php is the main connect script. Its primary functions are two-fold, and as the project maintainer, I've been fairly staunch about lot keeping it this way. This class's job is to connect and maintain its connection, and to feed input to and accept output from its ziggis (plugins).

ziggi.class.php is a base plugin interface (loosely, the "zilla generic interface") that plugins should extend to get its features.

FileStorage.class.php is a somewhat bad class that read/writes files. It's not used by the bot, but 1)is mine, ergo yours, and 2) is used in some of why plugins are in the repo, so wanted to provide the dependency.

bz_test.class.php is a test script for single ziggis (cuz restarting the bot just to test something sucks). More about that ... later!

Config

The variables in botzilla.php are pretty self explanatory,
$server and $port I left to my own settings (where btw, you cannot use the name 'botzilla', as it is mine).
$name is your bot's nick (Probably want something other than botzilla on freenode, else it won't connect).
$channels is an array of channel names to join at startup. If you channel requires a key to enter, then you might was to add it twice (the second time without a key), else when you say "#channel", the bot won't think it's in that channel (only "#channel passwd"). This is one of the minor fixes I've wanted to make.

Calling $botzilla->setOwners( array(/* of user nicks */) ) will put those individuals in a unique class of user, one that can shutdown/restart the bot. I have an operator class in the repo that handles many of the other functions that can be offloaded onto a plugin, but QUIT is still in the core bot for now.
The botzilla method addZiggis is where you would list the plugins that you want to load into the bot.

$botzilla->addZiggis(array
(
	array('reg.class.php' , array('access'=>BZUSER_ANYONE)),
	array('operator.class.php', array('access'=>BZUSER_OWNER)),
	'chuck.class.php'
));

Above is an example on how it can be used. Plugin files will be looked for in the ziggi/ directory. A method addZiggi exists as well for a singular load, but loading in bulk is generally less painful. Passed to addZiggis is an array of filenames (or an array of filename and additional parameters). In the absence of any parameters, the ziggi will load with permissions that only a "registered user" can execute it ( BZUSER_REGISTERED ). The line between core and plugin get a little blurry here, as my registration module is a plugin, but the core bot has to have knowledge of a user's status in order to know if he/she can access the plugin to beign with (ugh).

So in this example, reg (the registration plugin) can be accessed by anyone, whereas methods found in operator will be available only to those nicks that we've set as owners of the bot in this setup file. The plugin chuck (or dot-chuck as it is known to us via the command character) is a script that says a random Chuck Norris "factoid" into the channel. Because it was loaded without any parameters, only registered/known user's commands will be heard.

Logs

Logs are stored in logs/, though you may change the path definition if you want. The current working file is called log, and there is a bash script to help you manage them. The raw log is pretty unreadable, so running the script runs the parser, moves your current log, and starts a fresh one. Starting with just logs/log, running 
		$ ./newlog 17Jul08
will create logs/raw/17Jul08 (a copy of your log), and also a more human readable form of the log in a daily channel digest with paths like 
		logs/parsed/2008/07/16/bz
		logs/parsed/2008/07/16/bz2
		logs/parsed/2008/07/17/bz
		logs/parsed/2008/07/17/bz2