Home The Bridge

Can we get the item cap removed for Bridge resources?

Considering how quickly you can collect Magnesite and how much of it is needed to level up your bridge, it would be great if the 32767 item cap limit could be removed for Bridge resources.

For those of us who have our bridges finished, it would be nice to be able to keep stockpiling these resources for the inevitable Bridge update but it's currently impossible. I'm sure this is seen as a feature and not a bug by the developers but it's incredibly frustrating.

Comments

  • AviTrekAviTrek ✭✭✭✭✭
    It's a major technical challenge based on decisions made in the original game engine before STT was created. It's the fundamental maximum value for the data type they chose to use. It's annoying, but this is not something they are likely to ever address.
  • ArnieArnie ✭✭✭✭
    AviTrek wrote: »
    It's a major technical challenge based on decisions made in the original game engine before STT was created. It's the fundamental maximum value for the data type they chose to use. It's annoying, but this is not something they are likely to ever address.

    But they knew about it when the new feature was created do they should have kept the orders of magnitude suitable. Maybe divide the planned values by 10 or 100
  • ChaosChildChaosChild ✭✭✭✭✭
    Arnie wrote: »
    AviTrek wrote: »
    It's a major technical challenge based on decisions made in the original game engine before STT was created. It's the fundamental maximum value for the data type they chose to use. It's annoying, but this is not something they are likely to ever address.

    But they knew about it when the new feature was created do they should have kept the orders of magnitude suitable. Maybe divide the planned values by 10 or 100

    The original magnesite values required were 10x higher, they already had to reduce it once. That's how little thought and testing was put into it originally.

    Anyway, it shouldn't be a massive issue to change the data type of the relevant field, so long as the existing data is consistent with the new data type (which it would be). Changing it from integer to unsigned integer would double the maximum immediately with no performance or storage issues, and if the original database designers were at all competent that's how it would have been implemented.
  • AviTrekAviTrek ✭✭✭✭✭
    ChaosChild wrote: »
    Arnie wrote: »
    AviTrek wrote: »
    It's a major technical challenge based on decisions made in the original game engine before STT was created. It's the fundamental maximum value for the data type they chose to use. It's annoying, but this is not something they are likely to ever address.

    But they knew about it when the new feature was created do they should have kept the orders of magnitude suitable. Maybe divide the planned values by 10 or 100

    The original magnesite values required were 10x higher, they already had to reduce it once. That's how little thought and testing was put into it originally.

    Anyway, it shouldn't be a massive issue to change the data type of the relevant field, so long as the existing data is consistent with the new data type (which it would be). Changing it from integer to unsigned integer would double the maximum immediately with no performance or storage issues, and if the original database designers were at all competent that's how it would have been implemented.

    Suggesting unsigned int is everyone's favorite solution that shows how little they understand the problem. Magnesite grows so quickly it won't help. They could double the value and a week later people will be complaining about the 65k cap. All the while exposing them to the risks and complexities of a data type migration and needing to worry about what happens if they need to reduce values and go past zero.

    If you want to suggest going from 32 bit to 64 bit values sure that helps. But that is a larger change. And there may be other limitations in their engine that causes problems with that.

    Seeing how broken continuum was at launch, even attempting a migration like this is likely to break the game.

    I'd love to see increased values for everything too. But it's not going to happen.
  • Qu'ArthQu'Arth ✭✭
    Also, on the flip side of the 'They didn't test or think about this' coin, it's meant to be a pain-point or bottle neck. Most all mobile games of this style have multiple instances of that.
  • ChaosChildChaosChild ✭✭✭✭✭
    AviTrek wrote: »
    ChaosChild wrote: »
    Arnie wrote: »
    AviTrek wrote: »
    It's a major technical challenge based on decisions made in the original game engine before STT was created. It's the fundamental maximum value for the data type they chose to use. It's annoying, but this is not something they are likely to ever address.

    But they knew about it when the new feature was created do they should have kept the orders of magnitude suitable. Maybe divide the planned values by 10 or 100

    The original magnesite values required were 10x higher, they already had to reduce it once. That's how little thought and testing was put into it originally.

    Anyway, it shouldn't be a massive issue to change the data type of the relevant field, so long as the existing data is consistent with the new data type (which it would be). Changing it from integer to unsigned integer would double the maximum immediately with no performance or storage issues, and if the original database designers were at all competent that's how it would have been implemented.

    Suggesting unsigned int is everyone's favorite solution that shows how little they understand the problem. Magnesite grows so quickly it won't help. They could double the value and a week later people will be complaining about the 65k cap. All the while exposing them to the risks and complexities of a data type migration and needing to worry about what happens if they need to reduce values and go past zero.

    If you want to suggest going from 32 bit to 64 bit values sure that helps. But that is a larger change. And there may be other limitations in their engine that causes problems with that.

    Seeing how broken continuum was at launch, even attempting a migration like this is likely to break the game.

    I'd love to see increased values for everything too. But it's not going to happen.

    Oh, I agree, it's never going to happen. And doubling the cap would only ever be a stopgap anyway (but better than nothing). And yes, what should be a relatively straightforward upgrade would be quite likely to go wrong anyway.

    But I fail to see any situation where a player could have a negative quantity of any item in their inventory?
  • AviTrekAviTrek ✭✭✭✭✭
    ChaosChild wrote: »
    AviTrek wrote: »
    ChaosChild wrote: »
    Arnie wrote: »
    AviTrek wrote: »
    It's a major technical challenge based on decisions made in the original game engine before STT was created. It's the fundamental maximum value for the data type they chose to use. It's annoying, but this is not something they are likely to ever address.

    But they knew about it when the new feature was created do they should have kept the orders of magnitude suitable. Maybe divide the planned values by 10 or 100

    The original magnesite values required were 10x higher, they already had to reduce it once. That's how little thought and testing was put into it originally.

    Anyway, it shouldn't be a massive issue to change the data type of the relevant field, so long as the existing data is consistent with the new data type (which it would be). Changing it from integer to unsigned integer would double the maximum immediately with no performance or storage issues, and if the original database designers were at all competent that's how it would have been implemented.

    Suggesting unsigned int is everyone's favorite solution that shows how little they understand the problem. Magnesite grows so quickly it won't help. They could double the value and a week later people will be complaining about the 65k cap. All the while exposing them to the risks and complexities of a data type migration and needing to worry about what happens if they need to reduce values and go past zero.

    If you want to suggest going from 32 bit to 64 bit values sure that helps. But that is a larger change. And there may be other limitations in their engine that causes problems with that.

    Seeing how broken continuum was at launch, even attempting a migration like this is likely to break the game.

    I'd love to see increased values for everything too. But it's not going to happen.

    Oh, I agree, it's never going to happen. And doubling the cap would only ever be a stopgap anyway (but better than nothing). And yes, what should be a relatively straightforward upgrade would be quite likely to go wrong anyway.

    But I fail to see any situation where a player could have a negative quantity of any item in their inventory?

    Let's say a pack went live and hypothetically speaking had a bad price. Players bought the pack a bunch of times. With all the items players got they use some of the items to buy/build something else. Then TP realizes they screwed up and goes back and reverses all the purchases. But because players had lower quantities than before the pack launched, they end up with negative amounts.

    I know this is impossible because TP would NEVER make a mistake on a pack price. And if they did, they would NEVER retroactively reverse purchases. But just in case it happens...
  • ChaosChildChaosChild ✭✭✭✭✭
    AviTrek wrote: »
    ChaosChild wrote: »
    AviTrek wrote: »
    ChaosChild wrote: »
    Arnie wrote: »
    AviTrek wrote: »
    It's a major technical challenge based on decisions made in the original game engine before STT was created. It's the fundamental maximum value for the data type they chose to use. It's annoying, but this is not something they are likely to ever address.

    But they knew about it when the new feature was created do they should have kept the orders of magnitude suitable. Maybe divide the planned values by 10 or 100

    The original magnesite values required were 10x higher, they already had to reduce it once. That's how little thought and testing was put into it originally.

    Anyway, it shouldn't be a massive issue to change the data type of the relevant field, so long as the existing data is consistent with the new data type (which it would be). Changing it from integer to unsigned integer would double the maximum immediately with no performance or storage issues, and if the original database designers were at all competent that's how it would have been implemented.

    Suggesting unsigned int is everyone's favorite solution that shows how little they understand the problem. Magnesite grows so quickly it won't help. They could double the value and a week later people will be complaining about the 65k cap. All the while exposing them to the risks and complexities of a data type migration and needing to worry about what happens if they need to reduce values and go past zero.

    If you want to suggest going from 32 bit to 64 bit values sure that helps. But that is a larger change. And there may be other limitations in their engine that causes problems with that.

    Seeing how broken continuum was at launch, even attempting a migration like this is likely to break the game.

    I'd love to see increased values for everything too. But it's not going to happen.

    Oh, I agree, it's never going to happen. And doubling the cap would only ever be a stopgap anyway (but better than nothing). And yes, what should be a relatively straightforward upgrade would be quite likely to go wrong anyway.

    But I fail to see any situation where a player could have a negative quantity of any item in their inventory?

    Let's say a pack went live and hypothetically speaking had a bad price. Players bought the pack a bunch of times. With all the items players got they use some of the items to buy/build something else. Then TP realizes they screwed up and goes back and reverses all the purchases. But because players had lower quantities than before the pack launched, they end up with negative amounts.

    I know this is impossible because TP would NEVER make a mistake on a pack price. And if they did, they would NEVER retroactively reverse purchases. But just in case it happens...

    In that incredibly unlikely scenario, they'd just set the quantity of any items to zero. Which is what it should be anyway.
  • -:- AZ689-:- AZ689 ✭✭✭
    edited June 6
    ChaosChild wrote: »
    The original magnesite values required were 10x higher, they already had to reduce it once. That's how little thought and testing was put into it originally.

    If they hadden't changed that, it would have been impossible to upgrade the bridge to lv30, because the increase was so high, that you needed more than 32k Mag to buy an upgrade.
  • ChaosChildChaosChild ✭✭✭✭✭
    -:- AZ689 wrote: »
    ChaosChild wrote: »
    The original magnesite values required were 10x higher, they already had to reduce it once. That's how little thought and testing was put into it originally.

    If they hadden't changed that, it would have been impossible to upgrade the bridge to lv30, because the increase was so high, that you needed more than 32k Mag to buy an upgrade.

    That was why they changed it. Players had to point out to them that it was impossible to actually upgrade your bridge past a certain point (long before level 20). Which is just another example of how well things are tested before being released.
  • General MortarsGeneral Mortars ✭✭✭✭
    They changed the mag scale shortly after launch, I think by factor 10 iirc. Why not do it again?
Sign In or Register to comment.