Feature - Implemented Add num_drops() (or analogue) to ASH

zarqon

Well-known member
For those situations where one monster drops multiples of the same item (i.e. sandworms, bloopers, et. al.), item_drops() doesn't provide enough information. The only other solution is quite bulky and not at all handy.

So, I propose adding the following to ASH:

num_drops( monster, item )
num_drops( item )


Returning the number of that particular item that a monster drops. In concert with item_drops(), this would give us almost all the information we would ever need about item drops (I say almost because we still don't know whether an item can be pickpocketed or not, but one thing at a time). I listed both out-of-combat and in-combat versions above, consistent with most mafia functions that are used for consult scripts.
 

jasonharper

Developer
That wouldn't be a very useful interface, since you can't find out the drop rate of the individual drops. What I have on my to-do list is an item_drops2() (or maybe item_drops_ex()?) that returns an array of records, holding an item, drop rate, and type of drop.

This would also need to deal with a class of drops that mafia currently can't represent at all: items that drop in a variable quantity, based on some modifier. We've currently got the consumables drops from clan dungeon bosses (based on +Item), hair from the Wumpus (based on +ML), and bricks from some BRICKO monsters (doesn't seem to be spaded yet). I'm assuming that scripters might be interested both in the expected number of drops, and the modifier that needs to be boosted to increase that number.
 

Bale

Minion
That WOULD be more useful. I trust it would return information on pp-only items also?

Kudos.
 

zarqon

Well-known member
If you would like to expand my "baby step" feature request to include all the missing information in one fell swoop, by all means have at it!

I think I'll make another small feature request later and see if it gets expanded to fulfill all my dreams, too. :)
 

Bale

Minion
Jason is like that sometimes. We ask for an inch and he gives us a mile. I think he hates half-assed solutions; it's always full-assed or no-assed with him.
 

lostcalpolydude

Developer
Staff member
bricks from some BRICKO monsters (doesn't seem to be spaded yet)
There's no definite relationship between bricko quantity and any modifier. Back when I was farming green brickos, the number of plain brickos that dropped each fight varied quite a bit with no change in my modifiers. It appears to be as random as crimbux.
 

jasonharper

Developer
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.
 

Bale

Minion
That is a weird restriction, but as you say it shouldn't cause much trouble and if necessary, foreach can be used to store the data in an record of the scripter's creation. I wouldn't worry about it much. The only sort of script that might want to save the data is dj_d's farming script and in that one he'd just be storing it in his own record as soon as he retrieves it, so this should work for him also.

Great function.
 

lostcalpolydude

Developer
Staff member
"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.
Don't forget that these rates can be modified by things like elvish sunglasses.
 

zarqon

Well-known member
Jason, this is excellent! I'm excited to start working this into my scripts.

Could you give an example of what sort of items would have a "0" type? Will this generally only be for new monsters?

@lostcalpoly: Isn't that the only pickpocket chance modifier?
 

heeheehee

Developer
Staff member
There's also that (a little bit evil) AT nemesis cave item... evil vihuela? There's probably some others scattered here and there.
 

Bale

Minion
According to the wiki, only those two items give a pickpocket bonus, but if two things can give a certain type of bonus it is absolutely certain that eventually a third will appear.
 

zarqon

Well-known member
In that case, could we get a numeric modifier for that?

Secondly, I just took a look at type "c" items, and I now have a couple more requests:

1) add "pasta guardian larva" or some such to the item_type() data. Currently, item_type($item[paranormal ricotta]) returns "";
2) add is_quest_item( item ). I was actually surprised to find this didn't already exist.

Basically, I want to include "c" items as part of the monster's value where possible. Shirts are easy enough, but the rest is a little tricky. Adding the above would help significantly.
 

jasonharper

Developer
Type "0" item drops would include new monsters, monsters which nobody bothered to go back and enter drop rates once they were spaded, monsters which can only infrequently be encountered and therefore haven't been spaded yet, etc.

I think there might be about 3 sources of +pickpocket chance now, although it's not a modifier that mafia tracks yet. I just wanted to note that the rate means something entirely different for a pickpocket-only item.

EDIT: is_quest_item() already exists, it's !is_displayable().
 
Last edited:

Bale

Minion
I think there might be about 3 sources of +pickpocket chance now, although it's not a modifier that mafia tracks yet.
OH! Legendary Regalia of the Groovelord. It wasn't listed on the pickpocket page so I forgot about it. Is mafia going to start tracking pp bonus? It might be nice to recognize the modifier even if you don't do much with it yet.
 
Top