Add A Dial To Mods.

[TheLexiConArtist]

1 hour ago, Xekrin said:

This is the 'harder than we thought' part mentioned above.  You would have 1 mod yes, but internally it would have to save literally hundreds of combinations of that one mod, so that your boltor rank 6 mod doesn't affect your soma rank 10 mod.  Codewise, this would be a nightmare to work out.

Obviously, I and everyone else would love something like this, and they already stated (or inferred at least) that having duplicates is something they want to remedy,   If they can find a solution that doesn't increase the load time of the game / affect how the game performs, I'm all for it, I'm pretty sure they have people working on a solution, but it isn't a major priority and really shouldn't be right now.  Someday, hopefully, just not tomorrow.

It's not really something we can directly state for or against without actually knowing how DE handles things, but let's drop this into a theoretical storage model.

Say you have a Primary with 8 slots. In a DB the player's entry could be structured as such:

 

<surrogate key> - WeaponID - WeaponRank - Catalyst - Lens - Forma - ModSlots

Where Weapon ID is a many-to-one foreign key to a table of weapon bases; Weapon Rank, Catalyst and Forma are stored values for that instance of the weapon, Lens is a many-to-one key to a table of focus lenses (school + lesser/greater) and ModSlots is a one-to-many foreign key to a table of mod slot information for that instance of the weapon.

Mod slot information could be structured at the moment in this way:

 

<surrogate key> - SlotType - SlotNumber - Polarity - PlayerModID

Slot Type handles cases like Aura/Exilus/Stance slots (key to a table listing types). Slot Number is to order the slots (for the purpose of elements etc). Polarity is a key to a table listing possible polarities (including none). PlayerModID is a key to a mod owned by the player.

Player Mod information could be stored thus:

 

<surrogate key> - ModID - CurrentRank

ModID is a key to a base list of mods, from which it derives information like type, permission, drain, rarity, max rank, stats. Current Rank is the player's fused rank of the mod in question (realistically, a fusion level from which the rank is derived, since it needs to store between-rank fusion data).

 

So we have:

-Weapon data

-Mod loadout data

-Data for mods in loadout

 

All that would be necessary in this model to allow dialing down the mod is an extra field in the Mod Slot Information table (second code box), which would be the Applied Rank of the player's mod assigned to the slot. Obviously, this value would be prevented from exceeding the keyed player-owned mod's Current Rank, or the then-keyed base mod's Max Rank.

That's one new integer field in one table to enable using any arbitrary mod rank from zero up to maximum.

 

Like I said, this does gloss over some things, and without knowing specifics almost certainly doesn't correspond to actual server data paradigm, but it's a good enough approximation to show how straightforward it actually could be given the right sort of design.

_{I'm sorry. I get software engineer-y late at night sometimes.}

Edited March 2, 2016 by EDYinnit