Hidden secondary attributes in mods

I have a question about the secundary attributes of Mods.

When we get a mod the secondary attributes are already all there, with all their evolutions, but they are hidden?

In other words, I do the split from blue to purple, the secondary attribute is already set and will not be hidden after the split?

Replies

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

    Schrodinger’s mod.
    I demand Grand Arena Elo ratings.
  • You can only slice a lvl 15 mod, so all secondary stats are visible at that moment
  • Kyno
    19360 posts Moderator
    JoryG87 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.
  • Kyno
    19360 posts Moderator
    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 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 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.
  • Kyno
    19360 posts Moderator
    Kyno 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 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
  • Gifafi 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
  • Kyno
    19360 posts Moderator
    Gifafi 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

    This.

    Max stats are the same no matter what and are possible through slicing.
  • Blackbeardpepe
    919 posts Member
    edited January 8
    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.
  • 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.

    This...

    Consider when they had to correct those errors on mods and essentially rerolled them and couldn't bring them back to what they were cause it wasn't saved anywhere. So our mods have free will, not a predetermined future that has no means of changing...
Sign In or Register to comment.