TH Rates and Future TH Reconfigure

[The-Aerec]

@TeoTwawki @Xaver-DaRed - Place to continue our discussion on TH and what to do.

TLDR: TH and droprates are currently all over the place.

We have discussed both:

Eden's Methodology:
Instead of droprate being numeric they defined rates into grouped categories like: Common, Rare, Etc. And defined the numeric values for the pools elsewhere.

Limitbreak's Methodology:

Opposite of Eden's defined these rarities with numbers and put those numbers into the mob_droplist section for droprate.

Other Methods: ???

Both LB and Eden's methods are the communities general consensus on what the 'actual' way SE does TH:

What rarity is this item? -> Base drop rate is defined.
Was TH applied? -> Affect that base rate dependent on set level of TH from the following graphs:

[The-Aerec]

I mentioned as a first pass, we can implement the above system. And write a script to change all droprates into their closest current rarity, then change how TH is fundamentally calculated.

We would then have to implement the proc system. (And probably a way to override that proc system, thinking of ASB and servers who will want to customize. Probably just a main.lua setting to switch from proc to highest th method.)

[KnowOne134]

Edens number section is still in the droplist.sql as

CREATE TABLE `mob_droplist` (
  `dropId` smallint(5) unsigned NOT NULL,
  `dropType` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `itemId` smallint(5) unsigned NOT NULL DEFAULT '0',
  `rarity` smallint(4) unsigned NOT NULL DEFAULT '0',
  `groupId` tinyint(3) unsigned NOT NULL DEFAULT '0',
  `groupRate` smallint(4) unsigned NOT NULL DEFAULT '0',
  KEY `dropId` (`dropId`)
) ENGINE=MyISAM DEFAULT

INSERT INTO `mob_droplist` VALUES (1,0,1455,3,0,0);

[TeoTwawki]

Copy pasta of previous thread on a PR, for reference:

The-Aerec:
Are we converting all droprates to the Eden / Limitbreak implementation of rarity bases? (I'm guessing yes since that is the retail accurate way)

---

TeoTwawki:
not exactly. We're making our rates fit into what seems to be the most logical rate "bucket" for a base with no TH, and at some later future date we'll work out wtf exactly we want to do about the old incorrect dsp TH implementation and what kind of table format we want to hold it all in. This has been the plan since before any servers made their own implementations, and I dunno what exactly they do since I haven't looked at their code at all.

---

The-Aerec:
iirc Eden uses a non numeric entry in their drop tables: ie: Common, VC, Rare etc

And then based off those groupings affects the base droprates with the TH affects table that was shown in another MR recents.

Limitbreak changed all the droprates in a similar manner except instead of a string they used the: Common = 240, Rare = 100 etc method where everything that was determined to fit in those pools are assigned that pools respective numerical base droprate.

I think we talked about each of these in the ASB discord.

---

TeoTwawki:
eventually I think I want presets instead of raw numbers, but with an option for a "custom" alternate drop rates that don't fit the retail values.

I believe this same system SE uses for drop rates matches what they do for other systems like harvesting. We already used those terms back in the day on old wiki without knowing the numbers behind them - I bet the numbers fit and SE reused the same table for multiple things.

---

The-Aerec:
Yea I believe either the Eden/Lb way is fine.

I think Edens is much easier. Just reference the rarity level and then you can adjust what those rarity levels mean elsewhere. Making it easier to modulize and customize if people want to.

---

Xaver-DaRed:
I stand in the oposite side. i would rather have all values be numeric. No need to just know the tier rates is one. the other for consistency, since the "paired" drops, like okote or dring dont have a % rate that fit a tier

As for the reason asking to change this to fit those tiers, its because the task of converting all drops to a fit proper tier is abysmal.
However, if adding or editing just a few, the effort to check them an do a good judjement on what tier they should have is much lower

The-Aerec:
Can probably write a script to fit everything in the sql to their closest tier for now? And then update as we go for any outliers? or once we have more confirmations. (If we are converting the system that is)

---

TeoTwawki:

I stand in the opposite side. i would rather have all values be numeric.

I was thinking maybe sql variables to sort of macro it. so the numbers don't go away, just a little abstracted. Like when you cast something to a lua variable and then reuse that variable in a dozen places. SQL can actually do that. I haven't mocked up an example yet been workin irl to much to think about things.

---

The-Aerec:
I think this is pretty much Edens way of doing it. But once again we can easily writeup a script to go throught he sql and fit the current data to a 'Rarity' as a first pass. Then as users PR things in that have drops, just request for them to verify actual drop rates. (Although Limitbreak did a vast amount of the work for us there up to ToAU) So we could start with their #s and then fit the rest.

---

TeoTwawki:
I think we have a long way to go on manually correcting rates yet tho, even if a script replaced existing values to nearest official rate many would still be wrong. I'm sure we'll have many future PRs either way. We're kind of Cluttering crits PR now. If we need to we can make a discussion topic for further TH things if they aren't for the purpose of aiding his PR.

[TeoTwawki]

1 proposed methodology for LSB:

-- Variables
SET @very_common = 240;
SET @common = 150;
SET @uncommon = 100;

INSERT INTO `mob_droplist` VALUES (1, 0, 0, 1000, 18856, @very_common);

Actual naming convention (should we abbreviate? "VC" for "very common"?) to be debated if we decide to go ahead with this.

[TeoTwawki]

do you intend to continue with this?

yes, but not right away. I hope people don't try to rush change in. And what you are describing is the direction we're headed except with extra data to support customization of drop rates. An override or adjustment column most likely.

(so that one can make a specific mob have non standard rates, without affecting all mobs rates or all TH tiers, because we have that feature now and I don't want to eliminate it)

[TeoTwawki]

Basically I'd like ppl to get accustomed to using the presets instead of copy pasting whatever old wiki or ffxidb say before we go doing anything big at the core side.

[paladindamarus]

Awesome. I'm happy to push the treasure_hunter.sql file if you want, since I started working on one anyway. It will just be an added file with no code calling it, so it's probably safe to put in place early if you're happy with that

[TeoTwawki]

on the fence about it: someone might decide to hook it up for us if they see it, or worse, pepper me with "is it working yet?" / "its broke! I see the table but.."

[paladindamarus]

Fair: I'll create it, and whenever you want it, ping me and I'll push it. Not that it's a hard table to produce, at least.