Bug - Not A Bug CCS not doing "steal"

I've tried under a number of different situations, but I can't get my DB to pickpocket upon winning initiative unless I set the autoattack from the Account menu in game.
My ccs clearly says

[default]
try to steal an item
skill saucegeyser

I even tried just setting the combat action to "saucegeyser" and setting special to "pickpocket before simple actions". Still no joy.

Cf: this thread

"pickpocket" seems to work while pickpocket reverts to try to steal an item.

The 'steal' action is intentionally ignored in cases where mafia thinks it's useless - monster has no pickpocketable drops, all drops are boosted to 100% or higher, monster is going to severely hurt you (unless there's at least one drop that's an explicit goal of yours), etc.

jasonharper said:

ignored in cases where mafia thinks it's useless

Click to expand...

While I can appreciate that functionality in zones that are completely spaded, it's obviously "broken" in areas that don't have complete monster/drop information. Jus' sayin'. I'm fine with the workaround. Thanks for the info.

Maybe it works this way already, but if not, maybe anything with a drop type of "s" should be considered pick-pocketable.

So, do we want anything that's still is spading to be considered worth trying to pickpocket? That's found in MonsterDatabase, shouldStealItem. Specifically, right now only 'p' (pickpocket only) items will always be attempted. We could move 's' up one line and it will always consider those items to be worth trying to get... Alternatively, 's' could just be removed, and its drop chance will be considered for the pickpocket opportunity as well.

Right now, it's placed in the section with 'n' (no pickpocket), 'b' (bounty), and 'c' (conditional) items. Obviously not where it should be, but I tagged it into the wrong spot.

So yes, the proper would be either placing it up one line, so those are always considered possible, or removed completely, so the drop chance is considered.

Since we do not know if it is in fact pickpocketable or not (I guess) I think the second option is best. But I may be completely wrong

I would prefer if pickpocket always fired on unspaded monsters.

I agree. I'm just not sure that is practical. Is there a clear set of indicators or would all unspaded monsters need to be flagged that way until they are fully spaded?

Depends on what we want to do. Right now, anything tagged with 's' will never try to pickpocket. This is not optimal, because the more information you can get about unspaded items, the better... including whether or not they're able to be picked.

If the drop is marked to always pickpocket, it just means that if safe, it'll attempt it. It'll mark the mob as one where the attempt is worthwhile, if safe to do so. Since it already has the danger check in, I don't think it would be bad to have it always at least try to pick these...

And it's drop by drop. However, if the mob has any drops that mafia things might be useful, it'll try to autopick.

So, did the "s for unspaded" patch actually have any benefit? It might be easier to just revert it, rather than track down all of its unintended consequences.

If an item is a condition with its 1% unspaded drop rate, it will still try to use disco combos and skills to increase drop rates, whereas with a 0% drop rate, it'll avoid using them because they won't help. Unspaded allows for guessing value levels without committing the values in a "don't need to check these anymore" kind of way.

As well, when considering which location is best to find an item, with a 0% drop rate, the location is considered no good for searching... A 1% unspaded drop is a valid location, making it work with has_goal and other such checks.

Theraze said:

If an item is a condition with its 1% unspaded drop rate, it will still try to use disco combos and skills to increase drop rates, whereas with a 0% drop rate, it'll avoid using them because they won't help.

Click to expand...

What, exactly, is the "it" you're referring to in that sentence? And what was keeping "it" from specially handing type 0 drops, just as it would have had to specially handle type p drops to avoid wasting item drop boosters on them?

SmartStasis. It calculates based on drop rate, calculates out what the chance is of a drop happening, and if all drops have reached/passed 100%, it stops trying to boost drop percentage... In a similar way, if drop rate is 0%, due to either base level or by lowering the drop percentage, it won't run the boost, as it's not worth it.

Edit: Anyways, the way the internal mafia code works, it goes straight off the percentage for 'normal' drops... as it stood, unspaded items were 'normal' items with a 0% drop chance. That's what meant they were unspaded. Because of that, they were never valid items, unless specifically a condition. Spaded allows for choosing how we want to handle pickpocketting, while allowing drop rate guesses to be in, and us to know that the drop rate isn't finalized... but might be that.

System runs like this, all in Persistence/MonsterDatabase:
shouldSteal runs, checks if dodge is likely and if so if the monster has any items that should be stealable using shouldSteal(monster.items) to check, if dodge is not likely it checks if any items would satisfy conditions and be stealable using shouldSteal(conditions).

shouldSteal(items) checks what your drop modifier is, then compares each items to see if it's stealable using shouldStealItem(item, dropmodifier).

shouldStealItem(item, dropmodifier) checks if the item is an item (false if not), then checks for specific overrides... pickpocket items are always yes; nonpickpocket, conditional, and bounty are always no. currently spaded items are in the same category as NCB items, but shouldn't be. then, if not caught by those exception categories, it checks against the drop rate modifier to see if the item is guaranteed to drop based on drop modifier, and rejects the pickpocket if it's guaranteed.
next, if the monster doesn't drop the item, it checks the items that the monster drops to see if maybe one of them is an ingredient for the item being compared. it compares each ingredient to shouldStealItem(item, dropmodifier) to see if it's a possibility. if any of those returns true, it returns true for the whole function.
then, as it doesn't drop the item requested or any ingredient desired, it decides that this item isn't worth trying to auto-steal on.

Am I getting this confused? I looked through this whole system several times trying to figure this out and tracing out why it was doing this. The solution seems easy... it's just a question of what's the best result, whether we want this to always pickpocket or work based on item drop multipliers. As it stood before, it would always try to pickpocket, regardless of how high you may get your item drop percentage, or if it's even possible. 0*drop multiplier or anything else will always be < 100, and evaluate as true...

Theraze said:

SmartStasis. It calculates based on drop rate, calculates out what the chance is of a drop happening, and if all drops have reached/passed 100%, it stops trying to boost drop percentage... In a similar way, if drop rate is 0%, due to either base level or by lowering the drop percentage, it won't run the boost, as it's not worth it.

Click to expand...

Personally, I think that this was really a bug with SS. It should have had special handling for items with a 0% drop rate, since that was intended to mean that the rate was unspaded. It was a bit weird to change mafia to fix SS, but I cannot deny that Sea pressure is capable of producing the 0 even if drop rate is spaded, so it is better this way. After all, it is bad if unspaded cannot be differentiated from an actual 0 under the Sea.

My accepted additions to farm.ash also skipped drops marked with 0. Currently it also skips those marked with s since that was a quickfix, I should probably fix that

But stating that nothing is worth to pickpocket because its droprate is marked as 0 is probably not the best way to go about it.

Actually, the way it worked was that anything with a 0% rate would always attempt to be done through mafia's automatic handling, and not attempted by any scripts that considered chances and didn't have specific hacks in for those cases.

Sidenote as I'm looking through this... somewhat oddly, while item_drops displays the straight count pulled from the value, there's no way to pull getPocketRates, which is the modified pickpocket item drop rate if I'm understanding what that function is properly (since NCB becomes 0 there)... sort of tempted to add a item_pockets command to read these or something like that. Would be good to be able to consider where it's best to try to pick an item, as opposed to where to go if drops are the only thing being considered.

Bale said:

but I cannot deny that Sea pressure is capable of producing the 0 even if drop rate is spaded

Click to expand...

I can. The values returned by item_drops_array() don't include any modifiers, and even if they did, a penalty that reduced the effective drop rate to zero wouldn't affect whether the type of the drop was "0" or not.

Ah. Not a problem then. SS should have been able to deal with that.