FIXED: Forage issues

[Irreverent]

As a result of changes done awhile ago in the forum logic, you need to have the sum of your forage per zone be <= 100. Current database loads all chances at 100% on each item. So you will only get the first rare ever from a forage attempt.

Here is the code to check and make sure nothing is > 100% for an entire zone:
select * from forage where zoneid in (select zoneid from forage group by zoneid having sum(chance) > 100) order by zoneid

You'll need to then adjust them accordingly so that they sum up to <= 100

[gaeorn]

Actually, the above statement is incorrect. The numbers are not a %. They are a relative value. However, there was (until I submitted a fix today) a problem where the sum could not be greater than 255 or it would roll over and return the wrong item.

[Irreverent]

Well, this may be where the database vs. developer's intentions are different? Cause on loot tables its supposed to be %, so it would make sense that its % here as well.

I couldn't care less as I have painstakenly already updated the table to make all the drops available again. But sounds like the wiki for the table needs to be updated.

So now "chance" is just an abritrary weighted value?

[trevius]

Looks to me like is just works exactly the same as loot drop chances have always worked. Basically, it just totals up the forage chances as put in the DB and then randoms between 1 and the the chance total for the zone. If the random number is less than the chance of that particular item being checked, that is the item that gets foraged.

The numbers are all just relative to one another. So, if you have 10 items that you want to have equal drops in a zone, you can do this:

item 1 - 10 = 10 chance each for 100 total chance

Or this:

item 1 - 10 = 100 chance each for 1000 total chance

Either one of those will have the exact same results in drop/forage rate. By having it this way, it makes it easier to manage in most cases as you won't have to review the entire forage list for the zone and make sure the totals add up to 100 every time. If you wanted to add an 11th item to the above list with 100 or 10 chances set that has equal drop/forage rates as the others in the zone, you would just add 1 more item and set it to the same chance as the others. By doing it this way, it ensures that there is no chance that doing the addition wrong will hose up some of the forages from being forage-able.

It is the same way for lootdrop entries and I love it that way. I used to have to count up how many loots I wanted, then divide 100 by that count, then put them each in at that amount and make sure they totaled to 100. That was before I realized that it does not need to total 100. Now, I just set them to 100 or 50 or whatever I want their drop rate to be relative to how many items are in the entry. If needed, you can still do it the hard way and total it to 100, but it is not necessary, which is cool IMO. This way gives much more choice, flexibility and less room for error.

[gaeorn]

None of the code actually required you to put in percentages. The editor that cavedude wrote prefers you keep the numbers as percentages so everything is easier to read. To that end, the editor makes it fairly easy to adjust the numbers to percentages.

Because the code never required percentages, I had to make sure it still worked using other values than percentages. I simply missed that one variable was defined as an int8, causing a problem for totals greater than 255, which is now fixed in the svn. Because 100 is not greater than 255, changing the totals in the db to 100 did resolve your problem.

[Irreverent]

Gee, now you tell me after I hand-updated all 745 rows in the forage table! :)

But anyway, thanks again for the whole teams work!

Now that I have a basic C++ knowledge and can compile on my own now...all those bugs I put on hold...watch out! :)