Expanded customization options for plat?

[motorfirebox]

So here's something I'd be willing to pay plat for: the ability to separately customize dual weapons. For instance, putting different skins on each of your two Dex Furis, and color them separately. Likewise with melee weapons (DUAL ZOREN 4EVA). I know there's concern about database bloat with expanded customization options, and I'm sure there would be a lot involved in separating dual weapons in that way. So... make it pay for itself. I'm not sure if it would be better on a per-weapon basis or pay once to unlock it for all weapons—I'd prefer the pay once model, but I'd probably shell out for a few of my favorite duals.

I'm sure there's other stuff this concept could be applied to, like maybe split customization for bows and quivers. Or separate energy customizations for different Waframe powers.

There might be concern about giving paying players options that non-paying players simply don't have. This would be an alteration not just of customization options, but what customizations are even possible. Personally I don't see a lot of difference between this and something like Tennogen or deluxe skins—it's just another level of customization.

[VenomousValentine]

Hard agree. It would pay for itself. Databade concern is bullS#&$, and its a sorry excuse. 

[Jiminez_Burial]

Has DE said that increasing database size is an issue for something like this?  It's not the same situation as with Rivens.  You'd still be referencing existing data when choosing to separate appearances between your pistols.  

[grindbert]

database size is bait. they probably have more data on a single computer of a 3D designer or animator than 10 databases full of entries which weapon has what skin individually would have. the amount of space you would need in order to save which weapon of which user has which skin and color combination would be laughably small compared to the storage that's available for pennies nowadays.

it's not the size, it's not the amount. 

the only reason why a software company might ever want to limit the size of their database is if they INCREDIBLY AND MASSIVELY #*!%ed up their code base when they built it. maybe some parts are static that shouldn't be, maybe it's not modular in some regards. however, if that's the case, it needs to be reworked asap (as any serious software company would do) because the problems it could cause down the line would be colossal. 

Edited February 21, 2020 by grindbert

[motorfirebox]

I mentioned database bloat because it was brought up as a concern back when people were asking for more customization slots. Given the volume of new customization options that have come out since then (including more customization slots), I think they've probably resolved whatever issue they were having. But it was a concern then, so I figured it'd be best to give a counterargument for it now, just in case.