Data Access Conditions

I don't own the data contained in these tables. It is, to the best of my knowledge, all owned by Aardwolf and distributed only at the pleasure of Lasher. It has been built up into these databases by many more people than just me, and I don't feel that I have any particular right to impose conditions on it's usage. However, I do have some requests, if you make use of it. You're not required to follow them, but I would appreciate it.

  1. If you use the data, it would be appreciated if IWuvAard was mentioned somewhere, whether it be in code comments or documentation.
  2. It is entirely possible for people to use this access to easily harvest the majority of IWuvAard's data and create new sites based on it. I would appreciate it, however, if this did not occur. It is my belief that many people working on one site will lead to a 'better' and more accurate database than many people working on many sites. If you wish to see changes to IWuvAard's database, feel free to ask for administrator access. :)
  3. As a rider to the above: if you just want to reformat the data into your own webpage, feel free. I realize that I might be confusing people here, so let me be a little clearer. If you want to have a new web-interface to IWuvAard, then please feel free to build it. You can query the database at each page generation, if you like, or you could make your setup "pull" database changes nightly, so each night your database would be updated from IWuvAard. What I don't particularly like is the idea of 'forking' the database; so that there are disparate copies around. If you want something changed in the data itself - see the above suggestion and ask for administrator access - you could change it on IWuvAard and benefit everyone. :) If it is the structure of the database that you don't like, then feel free to e-mail me and talk about it. It is entirely possible that changes can be made - I'm not that terribly good at database design, I suspect, and I'll welcome suggestions.
  4. This access is not guaranteed to remain, I'm afraid. I don't know what kind of traffic the server will see from it, nor what kind of load from the queries. I'm willing to find out, but if the server load gets too extreme (there are a lot of clients out there, if the who command is any indication) then the access may have to be removed. Please, take care when you design your SQL queries; especially if you are embedding them in a script that will be distributed to many people. :)

As a final note, if you do take this access and run with it (in scripts or webpages), please let me know what you are doing. I'm curious to see what people come up with. Also, if you would like your script hosted on IWuvAard for people to download, feel free to ask. I'm fairly certain that something could be arranged.


Where are the speedwalks?
They are coming. The speedwalks table is not currently designed in such a way that makes it easy to export anonymously. I take Lasher's requests seriously, and I have to be sure that any speedwalk added through the website is validated by an administrative user before it becomes accessible to everyone - through the website or through anonymous access. This requires changes to the speedwalks table and to the speedwalks section, changes that I will make in the future. I can't promise when - I am busy these days. But it will be coming. :)

What about write access?
There have been some ideas suggested in regards to allowing write/update access to anonymous database users. Obviously this has important concerns that need to be completely addressed before such access is enabled. At this point, I'm afraid that all actual updating of data in the database must be done through the webpages at IWuvAard - this ensures a certain data consistency. If you want to have your scripts call the webpages at IWuvAard with data (POST or GET), feel free to ask me if you need help figuring out how they work - I'll help as much as I can.

Database iwuvaard running on

This database contains the working data for IWuvAard. Anonymous read-only remote access to some of the tables has been enabled in order to help support the creation of client-side database-querying scripts.

Read-only login name: 'guest'
Read-only password: 'iwuvaard'

Example MySQL database connection command-line:

 mysql -u guest --password=iwuvaard iwuvaard


Example PHP database connection code:

dbh = mysql_connect ("", "guest", "iwuvaard");
mysql_select_db ("iwuvaard", $dbh);

Example PERL database connection code:

use DBI;
$dbh = DBI->connect("dbi:mysql:database=iwuvaard;", "guest", "iwuvaard");

Data Dictionaries

Explanations of the accessible tables, what they are used for, and their specific column types/names follow. Table keys are bolded and underlined in the tables below.


This table is fairly obvious - it contains the same information as the areas command on Aardwolf displays. The only extra field is 'virtual', which is used in the speedwalks section of IWuvAard. 'Virtual' areas are areas that are not actually in Aardwolf, but are in IWuvAard to facilitate the grouping of speedwalks (i.e. the 'Shops' virtual area). For any queries dealing with this table I suggest excluding anything that is flagged as a virtual area.

Field Type Null Default
id int(10) No
from_level int(10) No 0
to_level int(10) No 0
level_lock int(10) Yes NULL
builder text No
name text No
virtual tinyint(3) No 0


This is a simple 'mapping' table. It maps damage names such as 'slime' (an alias) to 'acid' (the actual dtype).

Field Type Null Default
id int(11) No
dtype text No
alias text No

This beast of a table contains all the information from the IWuvAard equipment section. I'm not going to explain every field, as I think the majority of them are pretty clear on their own. 'equip_id' is a numerical identifier of the specific piece of equipment (only in the IWuvAard database, not in Aardwolf itself). 'submitted_by' is the ID of the user that submitted the piece of equipment to the databased. 'updated_on' is a timestamp for the last date that this piece of equipment was updated/edited on.

Field Type Null Default
equip_id int(11) No
submitted_by int(11) Yes NULL
updated_on datetime No 0000-00-00 00:00:00
name text No
keywords text Yes NULL
area_name text No
location text Yes NULL
type text No
weapon_type text Yes NULL
flags text Yes NULL
weapon_flags text Yes NULL
wear text No
weight smallint(6) No 0
level smallint(6) No 1
value int(11) No 0
avg_ac smallint(6) No 0
damage text Yes NULL
avg_damage smallint(6) No 0
damage_type text Yes NULL
extra_information text Yes NULL
ac_modifier smallint(6) No 0
hr smallint(6) No 0
dr smallint(6) No 0
save smallint(6) No 0
intelligence smallint(6) No 0
wisdom smallint(6) No 0
strength smallint(6) No 0
constitution smallint(6) No 0
dexterity smallint(6) No 0
luck smallint(6) No 0
hp smallint(6) No 0
mana smallint(6) No 0
moves smallint(6) No 0


This table contains the mobdeaths data. This is basically a straight import from various invocations of the mobdeaths command in Aardwolf. Mob name and mob level are self-explanatory; area_id is a reference to the area that this mob can be found in (see the iwuvaard.areas table).

Field Type Null Default
id int(11) No
mob_name text No
mob_level int(11) No 1
area_id int(11) No 0


This table contains a list of socials. I believe that it is pretty self-explanatory - the 'social' field is the name of the actual social, s_id is the numerical ID of the social (not in Aardwolf, only in the database), add_time is the timestamp of when the social was added to the database. Fields 1 through 7 contain the relevant line from the shelp command on Aardwolf. The 'creator' field contains the name of the social creator/author, if it is known.

Field Type Null Default
social varchar(16) No
s_id int(11) No
add_time datetime Yes NULL
field1 text Yes NULL
field2 text Yes NULL
field3 text Yes NULL
field4 text Yes NULL
field5 text Yes NULL
field6 text Yes NULL
field7 text Yes NULL
creator text Yes NULL