Feature - Implemented Do not consider unspaded drops as unpickpocketable

S

slyz

Developer
In revision 8795, unspaded drops where changed to be marked as 's' so that they could have a 1% drop rate instead of a 0% drop rate. In the process, MonsterDatabase.shouldStealItem() was changed to always return false for unspaded drops.

There was a bit of discussion in this thread about changing MonsterDatabase.shouldStealItem() to remove unspaded drops from the unpickpocketable types, but it wasn't changed.

I can't think of any reason to prevent unspaded items to being pickpocketable, so here is a simple patch that removes line 582 of MonsterDatabase.java.
 

Attachments

If you are capable of asking that question, you are capable of looking at the the patch and answering it yourself and only commenting if you think there is something wrong.

Sheesh.
 
I was commenting on it. *coughs* :)

The fixes for pickpocket are included in the variable monster patch as well. As I've already posted that for perusal, I wasn't going to split out that part unless it was requested.
 
No, you were not commenting on the patch. The patch had - and still has - zero downloads. You did not download it and look at it. You assumed that there was a problem with it.
 
Theraze said:
Does this include both of the locations, or just the one?
Click to expand...
I simply removed the line from MonsterDatabase.shouldStealItem(), so that unspaded drops are treated like normal drops.

I didn't actually test the patch though, so I don't know if other places in the code should be changed. What is the second location you are referring to?
 
Re: Veracity - Size told me that it only applied to one location.

Re: slyz - Two things:
1) Line 582 should probably move up a line to 581 instead of being removed, if you want the prior pickpocket behaviour (all unspaded items always attempted to be pickpocketted). If you want it to only try to pickpocket if drop rate doesn't hit 100%, remove the line (582) instead.
2) Lines 656-658 force a 1% drop rate. Regardless of whatever you've set. In the unspaded patch, I do the following instead:
PHP: 
     case 's':
      if ( probability == 0.0f )
      { // assume some probability of an unspaded item
       probability = 0.01f;
      }
      break;
Basically, if it's set as unspaded and drop rate is set to 0, set drop rate to 1%. If it's been guessed as something else, don't screw with it.
 
I say revert the original change that caused this problem; having type 's' instead of type '0' for unknown drops accomplished absolutely nothing beyond breaking existing, perfectly valid scripts.
 
Well, the goal was to make it easier for people to be able to do s5, s10, s15, etc. s1 was just there so that the drop rate was set to something... The goal of the patch was to allow for varying the drop rate, while still saying that the drop rate isn't finalized yet...

However, if we're happy using information from the wiki for our drop rates, we don't need the ability to easily mark drops as not being fully spaded, but with a guess...
 
Last edited:
I agree. zarqon (and other script users) could just fix zlib to deal with type 0. I'm not sure why that wasn't the solution in the first place.
 
Well, the fact that has_goal skips 0 drops wasn't the actual issue... the issue is that there's a wide variety of unspaded items, and no easy way to setting partially spaded drop rates... *shrugs*
 
I can certainly see the value in being able to set "guessed" drop rates vs. well-spaded drop rates. However, I also agree that it probably isn't a good idea to make such a change unless and until it has been comprehensively dealt with everywhere in the code that it would need to be. From a user's standpoint, I'd be most interested in tacking on some confidence level information to drop rates, vs. specific "spaded" vs. "unspaded" categories. But I can see how this could be a massive amount of work for too little gain.
 
Only real way to do that with current code would be even more letters, for confidence level... As having one letter for unknowns was just shot down, the chance of adding ~5 seems... unlikely at best.

Guess your best shot for unspaded drops would just be to add whatever you find in the wiki and submit that for inclusion. If it's wrong, I'm sure people will exhaustively test it and verify the numbers...
...
Sorry, I'm just feeling depressive about this. It just seems sad to lose potential functionality when we know where the problem with it is and how to fix it.

*shrugs*

Anyways, I'll drop the topic now, unless specifically asked to comment. I think the unspaded drop topic is a good one to tombstone, unless the devs want to come up with some other way to do it.
 
StDoodle said:
I can certainly see the value in being able to set "guessed" drop rates vs. well-spaded drop rates.
Click to expand...
I don't. I don't want "guessed" values in our database.

Theraze said:
Guess your best shot for unspaded drops would just be to add whatever you find in the wiki and submit that for inclusion.
Click to expand...
That is, essentially, where we get our numbers - with the caveat that we only enter Wiki data if it looks like they are based on "enough" data to be believable, and that for percentages >= 5%, we round to the nearest 5%, since I don't believe that TPTB put in items at 29% and 42%, say, since that is simply more precision than is worthwhile.
 
I really think that estimated values can have worth. Take the Ghost, for example. It drops 5 White Pixels, maybe at 80-70-60-50-40. That's not confirmed, but it's definitely not 5x60. Ideally, I'd want to see that information in Mafia (with a warning that it's not confirmed), and I'd also want a pickpocket in scripting at +151% items (because who knows, it might help).

These drop rates are unlikely to become definite any time soon, because working out the individual rates of 5 identical items from a monster is a real bitch. The estimates are the best we're going to get for a pretty long while.

Note that I'm saying estimated, not guessed. They're not guessed, they're usually the upshot of quite a lot of work, they're just not quite definite enough to stop pickpocketing on yet.
 
You must log in or register to reply here.
Back
Top