Please give us more riven slots and how to address it

[Omega]

There are over 300 weapons in the game, and with just 90 slots I feel like it's way too little. 

I understand it takes a lot of power and resources on DE servers to handle all the rivens as each one is fairly unique. I feel like there's some things that can be cut down on which would free up server space and therefore would be more possible for the riven cap limit to increase, or better yet be eliminated. 

My suggestions are as follows:

- eliminating different values for the same stats on a particular weapon riven (e.g. instead of having random values for damage for a particular weapon between 88.7% to 112.2%, just set a number in between those values that would apply to all rivens for that weapon; better yet give all rivens the current maxed value for a particular stat. This means you'll always get the same damage value if you roll the stat, only differing of you have a negative on the riven/2 positives vs 3 positives).  

- cutting down on the names. Instead of having rivens with the same stats but multiple names like "pleci-visican" "pleci-satiata" "visi-pleciata" "sati-visinent" just arrange the stats on the riven in alphabetical order and give all the rivens with the set stats the same name

- bonus suggestion is changing dispositions every 3 months based on global player affinity earned during the time period. It would be more streamlined and requires less processing if the other changes have taken place

Edited May 10, 2018 by VengefulMaelstrom

[xXHobbitXx]

how exactly do you relate riven mods and capacity to server space, damn i must sell my 1000 ammo case mods to make server room lol

[(PSN)haphazardlynamed]

Want to cut down on Server Storage?

Instead of having each player account track 90 riven slots, which may or may not be empty.

Have specific Instances of Riven's track their owner.

So, Make Rivens exist in a global data store independent of any single player account, when a Riven changes hands rather than copy it from one account to another, it remains in its allocated memory space and simply gets a new Owner nametag.

-Reverse the data association, now there's no wasted Storage from empty slots.

[sixmille]

I have this problem too, I'm nearing the cap and I don't even have one riven for each weapon. It makes me sad.

[(XBOX)dude1286]

If they were using a SQL database, all the rivens could be in the same table with user_id and riven_id being numbers, the keys to the table, and have the table be indexed on those two columns. Would be pretty fast for a player to access their rivens from the table and would be easy to move the rivens from player to player.

[Db0ys742]

This is just my take on it so don't if its wrong then whatever.

This is purely an example from my standpoint. 

Lets say that 50,000 players all had 90 riven mods. Now they have stated that each riven takes up its own database entry. So just off of this we have around 4,500,000 entries. This is a lot for them to store, and no your ammo case mods are not going to change this. Riven mods are "Unique" so each one gets it's own entry. Now for those who work with databases probably know that storing a new key for each mod is inefficient. The only way I see them fixing this problems is either scraping rivens or trying to make it so that instead of each individual riven mod taking an entry instead they get each weapon to take one or two entries with pre-defined rivens. Which is still a lot less then before, but either way DE will face backlash for it.

Also for those who don't see the problem with the Database and just want more slots. It's basically the same as saying you want the hema then going from a shadow straight to moon clan.(if it was possible)

[tCartmant]

51 minutes ago, Db0ys742 said:

Lets say that 50,000 players all had 90 riven mods. Now they have stated that each riven takes up its own database entry. So just off of this we have around 4,500,000 entries. This is a lot for them to store, and no your ammo case mods are not going to change this. Riven mods are "Unique" so each one gets it's own entry. Now for those who work with databases probably know that storing a new key for each mod is inefficient. The only way I see them fixing this problems is either scraping rivens or trying to make it so that instead of each individual riven mod taking an entry instead they get each weapon to take one or two entries with pre-defined rivens. Which is still a lot less then before, but either way DE will face backlash for it.

Someone who finally gets it. The Riven databases is probably in the hundreds of million rows. Adding just 5 to everyone is pretty damn significant database increase.

[LuckyCharm]

I've suggested op's changes in the past and I agree. 

Here's one fix that I suggested instead of making the rivens hold the stat increases and decrease numbers.. What if we used disposition? For example every weapon has a disposition that causes rivens to roll with x% stats on them. What If rivens were just calculated by [Stat x Disposition multiplier = final displayed stat] for example give rivens a base of 100% damage. [damage 100 x 4.0 = 400% damage] displayed on a weapon.

Sure that means that all rivens of that stat for that weapon will have the same stat increase, but that means the only data the rivens need to hold are which stats they increase or decrease, rather than all the % data, which can be calculated simply by a disposition multiplier on the weapon itself allowing DE to fine tune where they want each individual weapons stat increases to lie rather than calculating it with the 1-5/5 rating

[(XBOX)RPColten]

This is just a proposed solution to a player fabricated problem. It's neat to think about, but wholly unnecessary.

Rivens are by design not meant to be hoarded for each and every weapon or series. They are select improvements to individual weapons the player may find important, with the eventual necessary choice the player must make as to what weapons are most valuable to them. You the player are supposed to ask yourself which rivens, and by extension weapons, are most valuable to require an inventory slot.

It would be great to have rivens for each and every weapon series in the game so far, but that would kind of go against the entire design point of them.

[tCartmant]

54 minutes ago, LuckyCharm said:

I've suggested op's changes in the past and I agree. 

Here's one fix that I suggested instead of making the rivens hold the stat increases and decrease numbers.. What if we used disposition? For example every weapon has a disposition that causes rivens to roll with x% stats on them. What If rivens were just calculated by [Stat x Disposition multiplier = final displayed stat] for example give rivens a base of 100% damage. [damage 100 x 4.0 = 400% damage] displayed on a weapon.

Sure that means that all rivens of that stat for that weapon will have the same stat increase, but that means the only data the rivens need to hold are which stats they increase or decrease, rather than all the % data, which can be calculated simply by a disposition multiplier on the weapon itself allowing DE to fine tune where they want each individual weapons stat increases to lie rather than calculating it with the 1-5/5 rating

This doesnt change anything. It still has to store what the riven is and what stats it has. Your talking about the row size and not the number of rows. Row size to me really isnt the issue here. Row size, in either case, really isnt that large since its mostly int's/floats. 

[Eivy]

Id honestly be happy if we could send some to hold in the conversion... So basically if I opt to have it as one of the 4 rivens I wish to convert to a new, they hold in that pile, instead of needed 4 free riven spaces to do this.

 

[sixmille]

Somehow I don't think any of you are database experts. Yes we're talking about adding some additional load here but it's not as crazy as you may think, if they designed it well it should be easily scalable, and even then we're not in 2000 anymore, servers are cheap now.

Edited May 10, 2018 by sixmille

[tCartmant]

16 minutes ago, sixmille said:

Somehow I don't think any of you are database experts. Yes we're talking about adding some additional load here but it's not as crazy as you may think, if they designed it well it should be easily scalable, and even then we're not in 2000 anymore, servers are cheap now.

I am. I worked at google for 8 years. I think I know a think or two about storing data.  Thanks for your assumptions tho.

[LuckyCharm]

5 hours ago, tCartmant said:

This doesnt change anything. It still has to store what the riven is and what stats it has. Your talking about the row size and not the number of rows. Row size to me really isnt the issue here. Row size, in either case, really isnt that large since its mostly int's/floats. 

Wasn't the big issue they were claiming to have the fact that rivens having all unique stats ment each one had to be a unique entity? If all rivens had predetermined stats.. say all rivens with multishot and damage for rifles had the suffix satiata and the base for those was 100%damage/%60 multishot before weapon disposition, surely then all they need to store is the stats each suffix gives, each weapon that can use it, and then save the rest just like any other mod? Like player x owns a redirection mod, in the same way player x owns grakata satiata. 

Sure itd mean a ton of new mod entries into their database if you treated them as if they were mods but it'd also mean that accounts could be assigned rivens like mods in their database rather than store all the unique values? 

Im clearly no expert here, i have no idea how these things work. I just think Xweapon + Ysuffix =riven would be easier to store than Xweapon + 3× unique values that would require a new database entry each time 

(Makes me wonder how diablo does it since every weapon is unique stats)

[tCartmant]

3 minutes ago, LuckyCharm said:

Wasn't the big issue they were claiming to have the fact that rivens having all unique stats ment each one had to be a unique entity? If all rivens had predetermined stats.. say all rivens with multishot and damage for rifles had the suffix satiata and the base for those was 100%damage/%60 multishot before weapon disposition, surely then all they need to store is the stats each suffix gives, each weapon that can use it, and then save the rest just like any other mod? Like player x owns a redirection mod, in the same way player x owns grakata satiata. 

Ohhhh, I see what your saying.. Then yes it could save a bunch of room since they could create an entire table with all these "stats" so no matter how many rivens showed up, it would not matter. Unfortunately, I dont know if this something that could be changed now. I dont know about you but I would be pretty pissed if my rivens changed on me. I dont have GOD rivens per say but they do fit how my builds are now.

6 minutes ago, LuckyCharm said:

Im clearly no expert here, i have no idea how these things work. I just think Xweapon + Ysuffix =riven would be easier to store than Xweapon + 3× unique values that would require a new database entry each time 

(Makes me wonder how diablo does it since every weapon is unique stats)

If you dont care about how big a db/table is, you can just hash out the table. Depending how its called, lets say via userid, then each hash can be very maintainable and quick. Accessing billion row tables isnt a big deal if you don't mind buying the hardware needed to support it. 

DE seemed to indicate that they had no real desire to maintain an ever growing database like this.

[fr4gb4ll]

17 hours ago, xXHobbitXx said:

how exactly do you relate riven mods and capacity to server space, damn i must sell my 1000 ammo case mods to make server room lol

pretty simple: the only logical method of saving the information to a mod that can differs in stats like the riven do (in contrary to the normal one) - as a pure text string. or make the differenz a bit more clear, the "normal" mod could be seen as a static information, only needed to be stored once in the database - every user account that owns this mod (one time or more, then the amount would be the only non-static information that needs to be saved) would only use a pointer to the database entry of this mod. therefore, the amount of storage needed is rather easy to calculate, even with the counter for the amount of the mod, each player might have - and i guess this is only a 4byte value at best, likely only 2byte even (since this would be 65535 if unsigned Int is used - or does anyone have more of a mod inthe inventory these days?).

so, a "normal", static mod could be said as a one time only entry in the database and a riven mod, which (theoretically) can have any kind of values (in a defined range, ofc) of upto 4 stats, would need it's own storage, everytime... if we would take one million user, with each owning 90 riven mods (the max- limit today), you can do math when you think of the way the stats are put into a text-string... and regardless of how optimizd you do this, the amount storage space needed would be many times the one for the "normal" mods.

that said, if DE would change the way they store the user data on their server, they could remove the limit of the riven without too much additional storage space needed. keep in mind, i only speculate about the used method by DE by judging from their behaviour about the riven mods and the hard-limit to it, and also by the way most coders would handle the way of data-management of a game like warframe in a time where there weren't any riven mods at all (and i doubt they created their used method in perspective to the riven mods in the beginning).

if they would put into the database not the strings of each mod, but only the strings of the many different stats (without values) and beside that save the values of the mods (and the pointer to the entry too, ofc), most of the data could be stored in a more cheaply way (meaning, not much need for expensive hardware that runs big databases on it, but normal storage servers). a dual-way where only the riven mods would be handled this way would also be possible and they wouldn't need to change the old, non-riven method any time soon (though, they should to save some costs).

naturally, the whole issue might not even be because of extra costs, but because of other concerns (maybe they fear riven power-seller or something... who knows) - then it's a whole different story altogether... but as far as i remember, they excused the limit with the "extra cost" in the data management - and this is not a valid one in long terms for anyone who should know their job.

[LuckyCharm]

2 minutes ago, tCartmant said:

Ohhhh, I see what your saying.. Then yes it could save a bunch of room since they could create an entire table with all these "stats" so no matter how many rivens showed up, it would not matter. Unfortunately, I dont know if this something that could be changed now. I dont know about you but I would be pretty pissed if my rivens changed on me. I dont have GOD rivens per say but they do fit how my builds are now.

If you dont care about how big a db/table is, you can just hash out the table. Depending how its called, lets say via userid, then each hash can be very maintainable and quick. Accessing billion row tables isnt a big deal if you don't mind buying the hardware needed to support it. 

DE seemed to indicate that they had no real desire to maintain an ever growing database like this.

❤️ thanks for the info. As for changing rivens lots of my builds fit my rivens too, but well chances are they have a disposition change in the works after all these weapon reworks. Only time will tell.  Have a good day!

[-SSU-Tate.razay]

Sounds good,a constructive suggestion,upvote+1

[Loswaith]

On 2018-05-11 at 9:01 AM, tCartmant said:

DE seemed to indicate that they had no real desire to maintain an ever growing database like this.

Which in general seems rather strange given they would already be supporting that kind of database given frames, weapons, companions and cosmetics (each with mostly unique builds and colours/cosmetics).

One would be hard pressed to think a Riven mod takes more data storage than a Warframe, or at a push the same data as a weapon (both needing to store 8-10 mods and a colour scheme), even if they are just library IDs.

[(PSN)cdzbrbr]

This needs more attention. To a lot of veterans, me included, rivens are the thing to look for. The sheer price of capacity and acquisition is a barrier to most players, i don't see how yet another increase of 30 slots would hurt databasa when most of the player base won't make use of it.

[SweetScreams]

Needs to be addressed, hell many days the only reason to log on is to get a Riven. Having no room and simply destroying them is... Not something you want in a grind and collect type of game. Dont even care about the plat cost, im maxed at 90 and its not even close to covering the weapons I like to use. Then you have prime versions that come out, reworks, melee 3.0 is around corner etc. So whats bad today could be godly tommrow, dunno about you but ill be less than happy if im forced to throw away something only to see it become essential. Plenty of games store random rolled mods or weapons, that excuse that they don't have server space is a joke. Especially when... they are charging for the slots. If that was the case then the entire riven portion of the game would be a giant loss of money and would never of been implemented.