You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Feature Pickpocketability for Conditional Item Drops
- Thread starter Saklad5
- Start date
Not really, as there are loads of n0 and c0 items.
I assume you’re saying type/rate. I was talking about the “type” field specifically, not the “rate” field. If “type” is 0, my understanding is that pickpocketing is unspaded. Is that correct?
I’ve been quite busy recently, so I may not get to writing a patch anytime soon, but I would like to make sure I understand where this request sits. Correct me if I misunderstand.
The current idea is to leave existing fields untouched, but add a new field for pickpocketing. The condition field will continue to serve as a redundant source for pickpocketing information, but that behavior will be considered deprecated and may be changed in the future, as it cannot accurately represent all the possible values. Scripts will be expected to access the new pickpocketing field for that information, but failing to do so won’t cause any new problems.
The new field will be populated accorded to the condition field (this won’t be a part of KoLmafia, but rather a one-time regex I apply when putting together the patch), defaulting to unspaded if existing information is ambiguous (anything marked as conditional, for instance).
The current idea is to leave existing fields untouched, but add a new field for pickpocketing. The condition field will continue to serve as a redundant source for pickpocketing information, but that behavior will be considered deprecated and may be changed in the future, as it cannot accurately represent all the possible values. Scripts will be expected to access the new pickpocketing field for that information, but failing to do so won’t cause any new problems.
The new field will be populated accorded to the condition field (this won’t be a part of KoLmafia, but rather a one-time regex I apply when putting together the patch), defaulting to unspaded if existing information is ambiguous (anything marked as conditional, for instance).
Personally I still am unconvinced this is worth any time at all, with the basic question unanswered:
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.
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.
the dictator
Member
Many scripts do not operate that way. It doesn’t matter too much, anyway. The information can be added later.
So, change the scripts?