Hidden secondary attributes in mods

No idea, and not sure if it matters. Just here to declare this conundrum:

Schrodinger’s mod.

You can only slice a lvl 15 mod, so all secondary stats are visible at that moment

"Gifafi;c-1743860" wrote:
kyno, do you know if you are slicing a white/grey mod to gold or silver ( aka best/top), will/can a grey mod end up with just as good secondaries as a gold that you slice once? ty

I'm not kyno, but I assure you it's the same. A golden mod is a golden mod, no matter how it started

I remember hearing that it's not predetermined, or hidden, from the player. Pure random.

Eg. If you upgraded a mod to 15, and got 4 rolls on speed. If the game/server crashed and the mod didn't keep the upgrades, it may not roll 4 times on speed like it did before.

"JoryG87;c-1743695" wrote:
You can only slice a lvl 15 mod, so all secondary stats are visible at that moment

This.

I think Rafaelcb means if it's decided from the beginning which secondary attributes will be changed with each round of slicing. So if a grey 5-dot mod drops, does it already have a database table that contains not only the 4 secondary attributes that can be unlocked, but also all information about how the secondaries will change once it's sliced to green, to blue etc.

From my very limited understanding of databases, this would require a bigger table and slow down queries compared to letting RNGesus decide what happens upon slicing. If I had to guess, I'd say it's an RNG calculation at the moment of slicing. Probably done by the server rather than the client, otherwise it would be too vulnerable to manipulation.

"Darth_DeVito;c-1743761" wrote:
I think Rafaelcb means if it's decided from the beginning which secondary attributes will be changed with each round of slicing. So if a grey 5-dot mod drops, does it already have a database table that contains not only the 4 secondary attributes that can be unlocked, but also all information about how the secondaries will change once it's sliced to green, to blue etc.

From my very limited understanding of databases, this would require a bigger table and slow down queries compared to letting RNGesus decide what happens upon slicing. If I had to guess, I'd say it's an RNG calculation at the moment of slicing. Probably done by the server rather than the client, otherwise it would be too vulnerable to manipulation.

If that is the case, does it matter?

You cant influence them in anyway, so if it is predetermined by RNG or decided when you upgrade the result is still the same from our perspective.

Also from the little bit of understanding I have, what you are saying would be incorrect. The mod database would always have to have the spots for each stat, or the allocated size of the data table would "change". Meaning they would have each mod having a holding location whether or not it had been upgraded, so it could easily be predetermined by RNG when the mod is "created". But my experience is in MYSQL databases and it's very limited, so I could be wrong.

"Kyno;c-1743772" wrote:

"Darth_DeVito;c-1743761" wrote:
I think Rafaelcb means if it's decided from the beginning which secondary attributes will be changed with each round of slicing. So if a grey 5-dot mod drops, does it already have a database table that contains not only the 4 secondary attributes that can be unlocked, but also all information about how the secondaries will change once it's sliced to green, to blue etc.

From my very limited understanding of databases, this would require a bigger table and slow down queries compared to letting RNGesus decide what happens upon slicing. If I had to guess, I'd say it's an RNG calculation at the moment of slicing. Probably done by the server rather than the client, otherwise it would be too vulnerable to manipulation.

If that is the case, does it matter?

You cant influence them in anyway, so if it is predetermined by RNG or decided when you upgrade the result is still the same from our perspective.

True. The outcome for us is the same, unless one believes that praying to RNGesus might help :)

"Kyno;c-1743772" wrote:
Also from the little bit of understanding I have, what you are saying would be incorrect. The mod database would always have to have the spots for each stat, or the allocated size of the data table would "change". Meaning they would have each mod having a holding location whether or not it had been upgraded, so it could easily be predetermined by RNG when the mod is "created". But my experience is in MYSQL databases and it's very limited, so I could be wrong.

You need separate entries for the multiplicators of the secondary stats, yes. Plus two values that determine rarity and tier. But if you predetermine how those multiplicators will change with every slice, wouldn't you need an additional row of multiplicator data for each possible tier? If it's RNG determined, you could simply change the values for current tier and the one multiplicator that has increased.

"Darth_DeVito;c-1743796" wrote:

"Kyno;c-1743772" wrote:

"Darth_DeVito;c-1743761" wrote:
I think Rafaelcb means if it's decided from the beginning which secondary attributes will be changed with each round of slicing. So if a grey 5-dot mod drops, does it already have a database table that contains not only the 4 secondary attributes that can be unlocked, but also all information about how the secondaries will change once it's sliced to green, to blue etc.

From my very limited understanding of databases, this would require a bigger table and slow down queries compared to letting RNGesus decide what happens upon slicing. If I had to guess, I'd say it's an RNG calculation at the moment of slicing. Probably done by the server rather than the client, otherwise it would be too vulnerable to manipulation.

If that is the case, does it matter?

You cant influence them in anyway, so if it is predetermined by RNG or decided when you upgrade the result is still the same from our perspective.

True. The outcome for us is the same, unless one believes that praying to RNGesus might help :)

"Kyno;c-1743772" wrote:
Also from the little bit of understanding I have, what you are saying would be incorrect. The mod database would always have to have the spots for each stat, or the allocated size of the data table would "change". Meaning they would have each mod having a holding location whether or not it had been upgraded, so it could easily be predetermined by RNG when the mod is "created". But my experience is in MYSQL databases and it's very limited, so I could be wrong.

You need separate entries for the multiplicators of the secondary stats, yes. Plus two values that determine rarity and tier. But if you predetermine how those multiplicators will change with every slice, wouldn't you need an additional row of multiplicator data for each possible tier? If it's RNG determined, you could simply change the values for current tier and the one multiplicator that has increased.

Yes I was just referring to the fact that a mod would have a column for each of the various points of information, meaning that you need 4 spots to either hold the secondaries or a placeholder before they are upgraded. The slice would be an operation not requiring anything more than function to pick a spot 1-4 and then act on it with the appropriate multiplier/scale.

kyno, do you know if you are slicing a white/grey mod to gold or silver ( aka best/top), will/can a grey mod end up with just as good secondaries as a gold that you slice once? ty