How much data a riven mod cost you?

[844448]

Any tenno anywhere who study computer and things related to it, I want some insight on how heavy a riven can cost in data considering how many stats you can get in random

For time saving, there are 30 stats with 2 name combination (prefix/suffix)

With this many of stats, what is the biggest amount of data on one mod can cost you?

[The_Mustachio]

1.21 gigawatts 

[Renegade343]

Just now, The_Mustachio said:

1.21 gigawatts 

That's for electrical engineers.

[The_Mustachio]

1 minute ago, Renegade343 said:

That's for electrical engineers.

88 mph then?

[Renegade343]

1 minute ago, The_Mustachio said:

88 mph then?

Mech eng?

[The_Mustachio]

Just now, Renegade343 said:

Mech eng?

I guess we need to go back to the future then. 

[RealJustBoo]

Then the Answer is, of course... 42.

[-AoN-CanoLathra-]

About 7 data.

 

 

 

Seriously though, it should pretty simple. One possible form:

• weap: int
• name: string
• stat1: short
• stat2: short
• stat3: short
• stat4: short
• val1: short
• val2: short
• val3: short
• val4: short
• disp: short

In this form, a short is used for each possible stat that can be on a riven, with each possible stat being assigned a number. If the engine can also do single bytes, then they could use that instead (because there are fewer than 255 possible stats, with 00000000 being no stat).

After that, a short is used for the value of each stat. It would be stored as 10x its in-game value, thus preventing the need for a data type that can use a decimal point. stat4 would always be the negative stat, and thus val4 would have to either be stored as a signed short or be understood by the code to be a negative value.

The weapon type is stored as an int, or perhaps as a string, due to the large number of available weapons. If it is an int, it has a set size. If it is a string, then the size depends on the number of letters used, with each character being a byte (assuming standard ASCII text). The name is certainly a string, but we know exactly how long that is per-riven, assuming the weapon name is not considered part of the riven name (at least when being stored)

Finally, disp, or disposition, though I am unsure if this is stored per-riven or as a global value for each weapon. It would be a short, unless it is a single byte.

So, total size, assuming worst case scenario, and a structure similar to the one showed here, is (2*9)+64+15=~97 bytes per riven. The 64 is a place-holder, since I don't know how weapons are named in the code. If they have the same name as the one shown to us, the max would be 16 IIRC, but they probably have some sort of internal codename that is much longer (like 'corpusPumpShotgun', or 'infestedDualCleaver').

So, that's my best guess. Somewhere around 100 bytes for the raw data of each riven. Note that this doesn't include the size of whatever container all of these values are in, and is only the best way I can think of to make one of these. For all I know, DE made each one a 2048 byte string.

[taiiat]

2 hours ago, 844448 said:

With this many of stats, what is the biggest amount of data on one mod can cost you?

well, nobody would store something in the largest way possible. :p

 

anyways, let's take a gander.

there is a minimum of 8 bits worth of Stats on the Rivens.
(i don't have an estimate off the top of my head for the number of bits for the Riven Multiplier. i think it would have to be an 8bit Float but there may be a way to store it as a smaller Integer. since i don't have an estimate for this i'm not including it in my calculations, add a 4-8bit range onto the Riven values at the end to account for this part.)
minimum of 4 bits for the Rank of the Mod.
minimum of.... 16bits for what Weapon it is for.
minimum of 4 bits for the Polarity.

what that means is that the minimum amount of Database space a Riven could possibly take, is 32 bits.
this compared to any 10 Rank Mod, which would take 18 bits. (2 bits for the Rank, 16 bits for the ID/name.)

 

note that this doesn't account for keeping track of how many of __ you have, which non Rivens have to track while Rivens don't (though instead Rivens have to track another set of the same Bits rather than just having 2x so it's more expensive there too). so non Rivens would have another bit for how many of them you have.
the real kicker here, is that 2 Rivens costs exactly double the data space, while 2 of the same normal Mod, costs nothing.

and note that i use the term 'Bit' loosely - realistically some of these data values have to be larger than a single Bit per possible data value (how many of something you have, and the types of Stats that Rivens have).

 

 

(Edit: sorry for all the edits, changed my mind after i was done to write the exact minimum Bits necessary, rather than just tallying the number of data points)

Edited June 29, 2019 by taiiat

[(PSN)Hikuro-93]

It's not the IS units, sure, but I'm pretty sure a riven takes more or less 1 catalyst, or potato if you prefer. The blue kind.

[Azlen]

The problem is DE's BS excuse for riven limits due to server space. They are so tiny in space. If you need an example of this, think back to games like Diablo 2/3, Path of Exile for example. All these games can roll seemingly limitless stat combos across hundreds of thousands of items. There are set ranges and set modifier types. Sure that leads to potentially millions of different riven stat combinations, but the game never needs to remember anything besides what it CAN be, and what it currently is. Then it generates on re-roll.

DE should have merely said they want to control the balance of one account having too many rivens. The community at large would have been MUCH more satisfied by that answer. But instead, anyone who knows anything about how data is stored knows that DE's server space excuse is a big load 

[TaylorsContraction]

they can be stored as a blob or a xlob, each taking only a few bytes of space.

let us look into it in a bit of depth.

we have 4 possible stats that are floats so they will be represented by 8 bytes each.

then mr, mod rank are tiny ints, but let's assume unoptimized so also 8 bytes each.

now the complicated part,  mod name.  this is not just a simple string,  but rather somehow acts as a set of references to actual mods from which a name is generated as well as the mod's splash art. but that simply means it has at most 4 pointers to mod id's in the mod table. now that alone would not require much memory, let's say another 8 bytes each.

 

so we are looking at about ~70ish bytes of data assuming de is doing a join on the mods table and tossing in the disposition.  that's not much,  but what if instead of a join they just pull the additional mod data into the blob, we'll then it'll be a little more.

okay let's assume 100 bytes, this is just a guesstimate. with 90 rivens that's 9kilobytes of data,  doesn't seem like much,  but we're just guessing here.

multiply that by tens of thousands of players and the traffic starts to add up as well as the data size.  but I doubt it's hitting the terrabyte range though,  I mean even 10 million playerswould amount to

10^6 * 9kb ~ 9 gigs of data,  just for rivens.  in terms of data storage that's nothing but this is just a guess.  we don't know what additional data is stored that can be impacting this.

[k05h]

vor 7 Stunden schrieb 844448:

Any tenno anywhere who study computer and things related to it, I want some insight on how heavy a riven can cost in data considering how many stats you can get in random

For time saving, there are 30 stats with 2 name combination (prefix/suffix)

With this many of stats, what is the biggest amount of data on one mod can cost you?

I do coding for a living and do run the dropchance.guru website where you can find a short video on how rng works. 

There are two parts of your question:

First is the stat generation of a riven. That are like most things in Warframe mulitple layers of random number generator. First toss of the dice returns number of buffs and if a curse will be applied. Next toss of the dice is for each buff and maybe a curse the buff and curse type. Next toss will be for each buff and curse type the final amount that is in a given range. - This might happen to a certain extend on your local machine. Even if this happens on DE's servers that is not that complex. There are even service providers that offer rng operations on demand.

Second part: Once everything is calculated you might end up with something like this:

{
    "_id": "5d17e36627b0b75be5c3d0cd",
    "player" : "k05h",
    "weapon": "zhuge",
    "stats": {
      "cc": "3.2",
      "cd": "5.12",
      "td": "2.2",
      "fs": "-3.7"
    },
    "rerolls" : 0
}

This is 215 byte of raw data. Lets say we have 250 million rivens to take care of. That will lead to around 54GB of raw data. Put that in a nosql database of your choice, slap on a few indexes for faster retrieval and you will end up with a 100GB database that could on your above average smartphone.

You might add some clever routines to remove items of inactive players from the primary database to keep everything efficient.

Final step would by replicating / copying the database to multiple geographical locations to allow faster access depending on the players locations. I would guess 5-7 copies around the globe but there great services out there that do that for you.

From a data and architecture standpoint that is not an expensive endavour But that is all theory because I am not the engineer who designed it with effiency and scalability in mind. Many software projects tend to grow "ugly" in a rather non-efficient way. This might be the case for riven storage because a hard cap on rivens is a way to keep data stored small.

Edited June 29, 2019 by k05h

[(PSN)haphazardlynamed]

3 hours ago, k05h said:

I do coding for a living and do run the dropchance.guru website where you can find a short video on how rng works. 

There are two parts of your question:

First is the stat generation of a riven. That are like most things in Warframe mulitple layers of random number generator. First toss of the dice returns number of buffs and if a curse will be applied. Next toss of the dice is for each buff and maybe a curse the buff and curse type. Next toss will be for each buff and curse type the final amount that is in a given range. - This might happen to a certain extend on your local machine. Even if this happens on DE's servers that is not that complex. There are even service providers that offer rng operations on demand. 

Second part: Once everything is calculated you might end up with something like this:

{
    "_id": "5d17e36627b0b75be5c3d0cd",
    "player" : "k05h",
    "weapon": "zhuge",
    "stats": {
      "cc": "3.2",
      "cd": "5.12",
      "td": "2.2",
      "fs": "-3.7"
    },
    "rerolls" : 0
}

This is 215 byte of raw data. Lets say we have 250 million rivens to take care of. That will lead to around 54GB of raw data. Put that in a nosql database of your choice, slap on a few indexes for faster retrieval and you will end up with a 100GB database that could on your above average smartphone.

You might add some clever routines to remove items of inactive players from the primary database to keep everything efficient.

Final step would by replicating / copying the database to multiple geographical locations to allow faster access depending on the players locations. I would guess 5-7 copies around the globe but there great services out there that do that for you.

From a data and architecture standpoint that is not an expensive endavour But that is all theory because I am not the engineer who designed it with effiency and scalability in mind. Many software projects tend to grow "ugly" in a rather non-efficient way. This might be the case for riven storage because a hard cap on rivens is a way to keep data stored small.

In laymans terms:

if you're a smart programmer, its not a big issue.

but there's no guarantee that DE was smart about it.

 

-my guess is they weren't; they started out small and WF has expanded way too fast.

 

Edited June 30, 2019 by (PS4)haphazardlynamed

[(PSN)Lollybomb]

17 minutes ago, (PS4)haphazardlynamed said:

In laymans terms:

if you're a smart programmer, its not a big issue.

but there's no guarantee that DE was smart about it.

 

-my guess is they weren't; they started out small and WF has expanded way too fast.

 

Kinda like how it sounds like Sony really wasn't that smart about accounts on the backend that introducing name changes apparently risks breaking tons of stuff.  I'd like to know what stops them from just adding a 64bit GUID field to every account, plus the custom name field.  After that, introduce a new version of whatever API calls games and systems use to retrieve user info.  Games that don't get updated to use the new methods will simply pull the old data using the old methods, and new games/games that get updated pull the new data.

But that's neither here nor there.

[844448]

Not sure if you guys are having fun or having a rough time with all of those codes

[stormy505]

8 minutes ago, 844448 said:

Not sure if you guys are having fun or having a rough time with all of those codes

You kinda asked for this tbf.

In laymen terms (from what I can understand) the space it takes isn't... That bad? If you code it for scalability and efficiency. But, it's also DE so doubt.

"the real kicker here, is that 2 Rivens costs exactly double the data space, while 2 of the same normal Mod, costs nothing." Is also an important note, so the excuse that they need to keep in mind future players is valid.