Feature Pickpocketability for Conditional Item Drops

Saklad5

Member
According to the wiki (which cites this post by CDMoyer), there are four fields in the item drops array: item, rate, condition, and pickpocketability. However, KoLmafia currently conflates the last two, assuming that having a conditional and being pickpocketable are mutually exclusive. This was true by default when pickpocketing was implemented, but is inaccurate for both new content and edited old content.

Since conditional drops are an extremely important part of gameplay, and getting them sooner is a significant advantage, item_drops_array() should be corrected to reflect this by having a fourth string field for pickpocketing, and no longer including that information in the condition field. This is a breaking change, of course, but it is a very important one.

This will also make it much easier to disseminate pickpocketing data, as it will be possible to store that information even if the drop rate remains unspaded. If anyone running KoLmafia successfully steals something (or has logs of them stealing something), then we now know it is pickpocketable.
 

Saklad5

Member
Alternatively, in order to avoid breaking scripts, a new function could be added with this behavior that extends the old one. I feel that is a bit of a slippery slope, though.
 

heeheehee

Developer
Staff member
Wouldn't we just need to add a new possible value for type, e.g. "nc" to reflect "not pickpocketable" + "conditional"? (or, some unused character)
 

Darzil

Developer
On that page the line "For example, shirts drop conditionally based on whether you have Torso Awaregness. In older content, shirts could not be stolen, but in the Knob revamp, pickpocket can steal shirts." I believe is misleading.

What actually happened there is in the Knob revamp the shirts were no longer conditional on Torse Awaregness and can drop even when you are not aware of your Torso, are not conditional, and can be pickpocketed. I believe.
 

heeheehee

Developer
Staff member
What actually happened there is in the Knob revamp the shirts were no longer conditional on Torse Awaregness and can drop even when you are not aware of your Torso, are not conditional, and can be pickpocketed. I believe.

I don't think that's the case. Some shirts were made no longer conditional on Torso when the Thinknerd warehouse quest got rolled out (2014).

(the revamp happened years before that)

Either way, I'm pretty sure some conditional items can be pickpocketed; I just don't remember which. Also, one of the twitch events probably shows all the flags one can stick on an item...
 

Darzil

Developer
Well, that's all good.

So I guess what we need is to know which items are affected, and decide if we want to change the existing setup or add a category for the minority of items that are conditional and pickpocketable.

I think if you set safePickpocket to false (default is true) it'll always try to pickpocket, so anyone wanting to help Saklad5 spade what can now be pickpocketed should set that.
 

Saklad5

Member
Well, that's all good.

So I guess what we need is to know which items are affected, and decide if we want to change the existing setup or add a category for the minority of items that are conditional and pickpocketable.

I think if you set safePickpocket to false (default is true) it'll always try to pickpocket, so anyone wanting to help Saklad5 spade what can now be pickpocketed should set that.
Alternatively, I can just throw together a script that parses out every pickpocketed item in the session logs. It wouldn’t take long to figure out what can be pickpocketed. Figuring out what can’t be pickpocketed, that’ll take a while.

Another thing to note: if something is stolen using Rave Steal, it must be non-exclusively pickpocketable. If it was pickpocket-only or unpickpocketable, it couldn’t be stolen.

In the meantime, we don’t need that data before implementing this feature. We can simply have a fourth value for pickpocketed conditional items: unknown. It works for unspaded drop rates, it’ll do fine here. That’s basically the current state of affairs for conditional pickpocketing, after all.
 
Last edited:

Saklad5

Member
Wouldn't we just need to add a new possible value for type, e.g. "nc" to reflect "not pickpocketable" + "conditional"? (or, some unused character)

The problem with that is that it makes future changes even more difficult. For instance, there is currently a “bounty” value in conditional. We may want to specify other conditions in that field eventually (perhaps actual conditionals that can be interpreted as booleans), and adding yet more combinations like that for pickpocketing would quadruple the possible values, like so:
  • nc: not pickpocketable + conditional
  • pc: only pickpocketable + conditional
  • yc: pickpocketable + conditional
  • 0c: unspaded pickpocketability + conditional
The entire point of records is to avoid this sort of thing.

If the game itself has separate values for each, it is only logical that KoLmafia should have the same.
 

Darzil

Developer
To help spading, r18778 logs any item pickpocketed that we'd expect not to be due to how it is flagged in datafiles.
 

Darzil

Developer
I appreciate the concern about the inaccurateness of this, given what we now know of KOL, but as it might be many hours of changes, would be good to know how much of an issue it is!
 

Saklad5

Member
I’m not sure what you mean.

Looking at records more closely, I don’t think adding a field would actually be a breaking change. Removing pickpocketing info from the conditional field will be, though.

If you are talking about how urgently this issue should be addressed by someone like yourself, the answer is “not very”. I was actually thinking of coding the change myself, assuming we all agree on it. It should be pretty simple: add another field to the record in each function that uses it, update the item drop file using regex substitution, and that should be about it. Then fill in the data as it comes in.
 
Last edited:

Darzil

Developer
The coding is a bit of a pain, as they aren't fields, but leading character encoded on the item count.

It's pretty much only used in MonsterData though, so maybe not a huge deal anyway (well, as long as you are careful not to change anything in a way that breaks any existing scripts that use it).
 

Saklad5

Member
The way I see it, there are two ways to handle this:

A. Leave the condition field unchanged, and just add a pickpocketing field. This shouldn’t break any scripts, but it’s confusing and probably will have to get removed eventually anyway. Scripts certainly shouldn’t be using the old behavior if they can help it, after all.

B. Remove the pickpocketing-related values from the condition field as well as adding a dedicated pickpocketing field. This would cause current scripts to think that pickpocket-only and non-pickpocketable (but still non-conditional) items are pickpocketable, since that is what a blank currently means (as opposed to simply meaning non-conditional). This isn’t a major issue in my opinion, primarily since it would be trivial to fix in scripts. I could easily be very wrong about that, of course, I’d definitely rather do it this way.
 
The way I see it, there are two ways to handle this:

A. Leave the condition field unchanged, and just add a pickpocketing field. This shouldn’t break any scripts, but it’s confusing and probably will have to get removed eventually anyway. Scripts certainly shouldn’t be using the old behavior if they can help it, after all.

B. Remove the pickpocketing-related values from the condition field as well as adding a dedicated pickpocketing field. This would cause current scripts to think that pickpocket-only and non-pickpocketable (but still non-conditional) items are pickpocketable, since that is what a blank currently means (as opposed to simply meaning non-conditional). This isn’t a major issue in my opinion, primarily since it would be trivial to fix in scripts. I could easily be very wrong about that, of course, I’d definitely rather do it this way.

Please don't break user space, or um... don't break existing things. Unless there is a reason to remove it, marking it as deprecated (or some portion of it be deprecated) causes the least trauma. Please take into consideration the existing user base and why Python had such a fracture regarding 2.7 and 3.
 

Saklad5

Member
Please don't break user space, or um... don't break existing things. Unless there is a reason to remove it, marking it as deprecated (or some portion of it be deprecated) causes the least trauma. Please take into consideration the existing user base and why Python had such a fracture regarding 2.7 and 3.
We could leave the condition field as is, add the new field, and just stop including pickpocketing as a condition from now on. How’s that?
 

Saklad5

Member
To help spading, r18778 logs any item pickpocketed that we'd expect not to be due to how it is flagged in datafiles.
I just used Rave Steal to get a banana peel from a jungle baboon, and I’m not seeing anything special in the log. I’m using r18792, and I confirmed that that drop is currently categorized as unspaded.
 

Darzil

Developer
I just used Rave Steal to get a banana peel from a jungle baboon, and I’m not seeing anything special in the log. I’m using r18792, and I confirmed that that drop is currently categorized as unspaded.
Nothing unexpected there, it is not marked conditional or non pickpocket or fixed.
 

Saklad5

Member
It is marked as unspaded, though, so that is important information.

As far as pickpocketing goes, conditional and unspaded are equivalent right now.
 
Top