[Mosch0512]

Stacked on #2 (the formula comparison test); this PR's base is that branch, so the diff shows only this change.

Why

The item formulas (how requirements grow with the item level, what excellent and ancient items get more, the price's excellent bonus) are fixed numbers in the game logic. To exchange them with the item stat file of the MuMain client, they have to be configuration data. This PR adds that data, with the values the server computes today. The game logic doesn't read it yet, so nothing changes for players; that follows in a separate pull request, which the comparison test of #2 checks.

What

Data model

• GameConfiguration: ExcellentDropLevelBonus (25) and AncientDropLevelBonus (30), and ItemStatProfiles.
• ItemStatProfile: a named set of item formulas, in the parts of the client's item stat file. The profile default writes every part, the others only what differs from it. It has the level growth of the level requirement, what an excellent item needs more, the strength per option level, and:
  • ItemStatTerms, one for each stat the profile writes (damage, magic power, block rate, defense, magic defense): the level bonus table, the excellent part (base × times ÷ drop level + add + drop level ÷ divisor, with the item's own drop level) and the ancient part (value × times ÷ d + add + d ÷ divisor, d = drop level + ancient bonus; AncientAfterLevelBonus adds the level bonus to the value), each "not written", "none" or with values; for magic power also PerLevelAfterHalving;
  • ItemRequirementFormula, one per stat requirement: add + base × (drop level + item level × level weight) × percent ÷ 100, where the drop level includes the ancient or else the excellent bonus; or "keep the base value". LevelRequirementBasis takes the item's level requirement instead of the drop level; no built-in profile uses it yet.
• ItemDefinition: StatProfile, ExcellentBonus (a fixed excellent bonus instead of the profile's term; 0 = the term) and ExcellentRaisesLevel (true).
• The new enums ItemStat, ItemStatTermState and ItemRequirementStat (stored in the database, so new values may only be appended).
• GameConfigurationHelper.Enumerables, captions in en/de/zh-CN, and localized summaries for the admin panel.

Built-in values (src/GameLogic/ItemFormulas/BuiltInItemStatProfiles.cs): the profiles with today's server numbers, also where the client differs (e.g. a leadership formula and 4 strength per option level). Only armor, book and shield compute differently than default. Of the others, the wing profiles name the level bonus tables of their items, sceptre has no magic power growth after halving (0 instead of 2, as in the sceptre rise tables), orb and scroll keep the base stat requirements (their items have no slot, so the server doesn't raise them today), and helper and weapon write nothing. They live in the game logic because the next step falls back to them when a configuration has no profiles.

Initialization and update

• Items/ItemStatProfiles.cs creates the profiles which a configuration doesn't have yet and gives each item without a profile the one of its kind, following the client's profile rules with the server's item data (ammunition, sceptres, books, shields, weapons, armour slots, the wing tiers, orbs, scrolls, helpers; the Horn of Fenrir and requirements given by item level as in the client). It runs once for every version, after the version's initializer.
• The mandatory configuration update "Add item stat profiles" (base class plus 0.75, 0.95d and Season 6) does the same for existing databases. It only adds data: profiles which exist (by name) and items which have a profile stay as they are.

Persistence

• Migration AddItemStatProfiles: the three tables, and the new columns. Existing databases get the bonuses 25 and 30 and ExcellentRaisesLevel true, set by hand as in AddItemRuleFlags. A profile which items use can't be deleted (Restrict, as the castle siege references).
• Regenerated: BasicModel and EF model, the compiled models of EntityDataContext and PlugInConfigurationTypedContext, and GameConfigurationLoader.Generated.cs.

Testing

• dotnet build src/MUnique.OpenMU.sln -p:ci=true, then the whole solution with dotnet test --no-build -p:ci=true. All tests of Persistence.Initialization.Tests pass, including the formula comparison of test(items): pin today's item requirement, power-up and price formulas for every item #2. The only failures are the same as on the base without this change: 16 web tests and 3 Discord tests, which fail on Windows. CompiledModelTests and GameConfigurationLoaderGeneratorTest pass.
• ItemStatProfilesDataTest, for 0.75, 0.95d and Season 6 unless noted:
  • a new database has the profiles and the bonuses, and every item has a profile;
  • the profiles which compute differently follow today's checks exactly: armor = the armour slots, book = a book rise, shield = group 6;
  • each item's damage, block rate and defense level table is its profile's table;
  • the number of Season 6 items per profile, so that no item moves silently between profiles which compute alike;
  • made-up items get the profile of their kind (Season 6);
  • the update gives a database without profiles the same data as a new one, and a second run changes nothing; on Season 6 it keeps a changed profile and a changed item profile, and gives a removed profile back to its items.
• Broken on purpose: a wrong wing table and a wrong shield rule. Both were caught.

[Mosch0512]

Merged upstream as MUnique#1290.