Ok, r8356 adds item_drops_array(monster) and item_drops_array(). They return an array (in no particular order) of:
record {
item drop;
int rate;
string type;
}
The 'type' field has these currently possible values:
"" - normal item drop, base drop rate in the 'rate' field.
"0" - (that's a zero) no drop rate information available, 'rate' will be zero.
"n" - not pickpocketable, but otherwise drops according to 'rate'.
"c" - conditional drop. Implies non-pickpocketable, but has a further implication that there is some condition you have to meet: a specific class, a specific quest state, having Torso, etc.
"p" - pickpocket-only. Currently 'rate' will always be zero, because when this type of item was originally added, it was believed that they all had a flat 5% chance. Once non-zero values start appearing, note that they are flat rates, NOT affected by normal item drop modifiers.
"b" - bounty item, 'rate' is meaningless.
There is no current support for items that drop in quantities greater than one, but I'll predefine some types for them:
"I" - item drops in a quantity depending on your item drop modifiers (clan dungeon bosses, for example).
"L" - quantity depends on your monster level modifier (Wumpus).
"M" - quantity depends on your meat drop modifiers (no current examples, but I suspect we'll see this eventually).
"U" - mechanism for determining quantity is not known.
The meaning of the 'rate' field is not yet defined for multiple drops.
Note that new types may be added at any time; it would be safest to treat any unrecognized type the same as a type "0".
Here are a couple of samples of output:
Code:
> ash item_drops_array($monster[giant sandworm])
Returned: aggregate {item drop; int rate; string type;} [4]
0 => record {item drop; int rate; string type;}
drop => spices
rate => 10
type =>
1 => record {item drop; int rate; string type;}
drop => spices
rate => 10
type =>
2 => record {item drop; int rate; string type;}
drop => spices
rate => 10
type =>
3 => record {item drop; int rate; string type;}
drop => spice melange
rate => 0
type => n
> ash item_drops_array($monster[blooper])
Returned: aggregate {item drop; int rate; string type;} [3]
0 => record {item drop; int rate; string type;}
drop => white pixel
rate => 80
type =>
1 => record {item drop; int rate; string type;}
drop => white pixel
rate => 70
type =>
2 => record {item drop; int rate; string type;}
drop => white pixel
rate => 60
type =>
Note that there is currently a weird restriction on this function: about the only thing you can do with its return value is iterate over it with a foreach loop. You CANNOT currently store the return value in a variable, because you have no way of declaring a variable of the appropriate type. This is a problem that hadn't arisen before, because no built-in functions dealt with records at all. I'm not too worried about this restriction in this case, since iteration is almost certainly what you're going to want to do with the results anyway, and you can always call the function again if you need the value again. I see three possible fixes to handle any future library functions that use records:
1. Add the records as built-in types - effectively their names would become new reserved words. I dislike doing that, because every new reserved word is a chance to break existing scripts.
2. Change the rules for records so that they can be assigned from any record type with exactly the same field types and (probably) field names. This would allow you to define a compatible record yourself, with whatever name you wanted; there could perhaps be a built-in file supplied that you could import to get a canonical definition of the record type.
3. Add something like C's 'typeof' operator, that would allow you to declare a variable that matches the type of an arbitrary expression - even if you can't directly write the name of that type. I can't think of any other uses for such a feature, however.