Trainers cap?

I was just working on my Galaxy Gallivanting Vash and pusher her up some levels when I looked at my trainers. All 5 of my trainers are either at 32767 or just a few below, the 3 lesser trainers are all tied at that amount. I made no attempt get them to be all equal and I find it extremely unlikely that its a coincidence. Is there some kind of item count cap that I've hit that is keeping them all around the same number?
«1

Comments

  • DavideBooksDavideBooks ✭✭✭✭✭
    edited August 6
    Yes.

    Once they get that high, use them as replicator rations.
  • Yes there is, and you are looking at it.
  • ~peregrine~~peregrine~ ✭✭✭✭✭
    32767 = 2^15 - 1. Why the 15, I wonder? 🤔
    "In the short run, the game defines the players. But in the long run, it's us players who define the game." -- Nicky Case, The Evolution of Trust
  • The number pertains to how the game is coded. There is a magic number that computers can't go beyond, it has been awhile since I've done programming, but I think that is the number.
  • VesmerVesmer ✭✭✭
    32767 = 2^15 - 1. Why the 15, I wonder? 🤔

    Good ole short integers. My limited CS skills say it's for memory efficiency and database storage optimization. 0 has to be accounted for in the binary combinations.

    Wikipedia:
    Short integer
    Signed: From −32,768 to 32,767, from −(2^15) to 2^15 − 1

    It’s really strange why the cap is 32767 cause you know, number of items can’t be negative. So it should be 65535 (2^16-1) at least.

    And I won’t even ask why on Earth they use SMALLINT (or whatever it’s called in the type of database they use) instead of normal int. Because there could be no reasonable explanation. Memory consumption optimization? Cmon, it’s not the 80s.

  • When they coded it, the original dev picked one of the integer types. 2^15 - 1 because they need to also store "zero". The reason it includes both positive and negative numbers is they use the first binary digit determines positive/negative. 16 digits in this int type, the first pos/neg, the next 15 are binary digits for the number. e.g. 00000000000001101 = 13

    3AM so i might have made a mistake somewhere in there. :)
  • VesmerVesmer ✭✭✭
    The question is why they interpret 2 bytes as a signed value. They could easily interpret it as an unsigned.
  • I think it is ok to assume that 32,767 of anything is more than enough to store. It is quite unlikely that it would ever again become a scarce ressource for this player once she hit the limit.

    Any change to the db would raise the risk of problems for hardly any benefit. At some point the cap would be reached again by many players, just at an even more astronomic figure.

    I do not see an issue here.
  • VesmerVesmer ✭✭✭
    Well, 32767 is not enough to store credits. And merits. And dil. Why trainers and items should be any different?

    I see no problem in using 32-bit or 64-bit integers from the very beginning to store quantities. History teaches us that such memory size “optimizations” sooner or later lead to problems (like using 32 bits for time stamps)

    And I see an issue every time someone’s using signed integers for objects of unsigned nature.
  • VesmerVesmer ✭✭✭
    And I don’t see big problems for a database in changing ‘smallint’ to ‘int’ in CREATE TABLE statements. Of course, if they have a couple of spare gigabytes of space to use, which they should have.

    Problems may be in the client code though, if they use short int variables (I don’t see any reason why they would use them instead of regular int variables)
  • Dirk GundersonDirk Gunderson ✭✭✭✭✭
    Vesmer wrote: »
    Well, 32767 is not enough to store credits. And merits. And dil. Why trainers and items should be any different?
    For ingame currencies the question is hypothetical as - at least proven for credits - this cap does not apply.

    For anything else, if I were the ressource manager of the dev or db team, I would not want them to spend a single working day on this topic as it has hardly any relevance in comparison to many other issues, e.g. the 1000 items cap which pretty likely is a db problem as well.

    Sure, it could have been done better in the first place, but now it is as it is and imho it is not worth spending effort on it.

    This, 100%. Any opportunity to create bugs should be avoided unless the payoff at the end is worth it, and nobody has needed, currently needs, or will ever need to use more than 32,768 trainers, ship schematics, or starbase components in a single day/week/month, ever.
  • FlemmingFlemming ✭✭✭✭✭
    edited August 6
    I just realized I stopped collecting Starbase Components at that number for the Away Team source components. I will have to start replicating with that fuel more often.
    Intentionally Left Blank
  • VesmerVesmer ✭✭✭
    There’s no opportunity to create bugs in changing type of a column in a database from smaller int to bigger int. It’s not the change of database schema, it’s trivial.

    4 unsigned bytes would have the cap 4294967295. Significantly bigger that 32767, innit? I doubt such limit would ever be reached by any player, so “At some point the cap would be reached again by many players” is not the case. Would there be any benefits from such change? Sure. I’m personally sitting on 32767 of many starbase components wasting additional income of these components for nothing. Other people have 32767 of trainers and whatever else wasting additional income of such items for nothing.

    So I just don’t get you people who says “it’s ok, let’s leave it as it is”
  • Vesmer wrote: »
    So I just don’t get you people who says “it’s ok, let’s leave it as it is”

    Because there's no actual benefit to raising that limit. If you've made it to that large of a supply, you're never going to exhaust it. If there's no benefit to the players and no monetary incentive to DB, there is no reason to change it.
  • AviTrekAviTrek ✭✭✭✭✭
    Dump thousands into the replicator at once. Then you're fine for months.
  • AviTrek wrote: »
    Dump thousands into the replicator at once. Then you're fine for months.

    Which requires spending credits. I have to pay to get rid of this junk.
  • Odo MarmarosaOdo Marmarosa ✭✭✭✭✭
    If you're replicating 2* items, you're not making a serious dent in your material supply.

    If you're replicating 5* items, you're running out of credits in short order.

    Once 32767 is reached in any resource, it's probably going to stay there, never dropping low for long. I have given up on making a lasting dent in trainers, nanopolymer, schematics etc. I've used almost exclusivly 4* replicator rations for months and my total supply has only increased.
  • AviTrekAviTrek ✭✭✭✭✭
    All it takes is one 5* item to make a significant dent. Sure you may not want to replicate 5 5* every day. But you should easily be able to replicate one a week. I probably replicate a couple a week just because I can't be bothered to farm expensive items and I have more rations she credits than I know what to do with.
  • Amphistaff wrote: »
    If you can't spend 9-10k credits to replicate a 2* item (or even lower, 3k for a 1* item) you're playing this game VERY wrong.

    It's not about being able to afford it. Credits translate to Honor since you can buy the 10x pulls with Credits. I'm being charged Honor because there is no way to get rid of useless items.
  • Captain ZloggCaptain Zlogg ✭✭✭
    edited August 10
    32768 digits including zero
    32768 is 4096 x 8
    it's cube root is 32
    it is 8^5
    in binary it is 1000000000000000 (16 digits)
    in hexadecimal it is 8000
    It's one of those interesting multiples of 8 with many uses
  • It probably wouldn't cause a problem in the database (if they're even using a SQL DB and not something like Mongk where you don't even have to worry about the types), but it could cause problems elsewhere. The two possibilities I can see are:

    1) UI layout - they have a fixed max on how many characters they need to display, and if they increase that they'll have to redo the UI that displays it. Could be trivial, but probably not (anyone see the rendering/layout issues from the last update?)

    2) If they're sending this stuff in a binary format over the network, that's most often (but not always!) in a manner where the size of data fields matter. That would require updating the client code to handle receiving the data with the new size and the server to handle sending it with the new size. Again, that *could* be trivial depending on how they have things organized, but that's also a very easy place to introduce a bug. Plus, you'll need to make sure everything that's working with that format handles it, which might be in lots of places (even if it's only displayed in one).

    These days, unless there's some other unknown performance issue, that probably shouldn't have been a short int - 5 32- or 64-bit fields vs 16-bits would not make or break your bandwidth/memory/disk usage. But like others have said, it's done and if it isn't causing legitimate problems (costing someone 50 honor to use the replicator is not a legitimate problem in this instance), leave it alone. Maybe add some logic to the reward drops (for gauntlet at least) to lessen or remove the chance of trainers if you're maxed, but I'd say that's be it.
  • VesmerVesmer ✭✭✭
    They send data between clients and server in JSON format, it’s obvious from iampicard. So there’s no issue from this point of view.
  • SkittishSlothSkittishSloth ✭✭
    edited August 13
    One thing I'd like to add - it might sound a little condescending when I say some changes should be "trivial". I've been a software developer for almost 20 years. Every project I've worked on, no matter how big or small, has always started where changes of almost any size would be trivial to make without affecting the existing code. Adding new features would require minimal changes to what's already there.

    This inevitably lasts at most a week. Then it's more fragile than a house of cards on a Jenga stack. If you move your hands too close to the keyboard things break in code that hasn't changed since day 1.

    I say it with affection and more than my fair share of "how things should be" vs the reality of actual coding.
  • Vesmer wrote: »
    They send data between clients and server in JSON format, it’s obvious from iampicard. So there’s no issue from this point of view.

    That's mostly what I'd expect- binary formats are pretty much only used for super-high performance stuff (like stock transactions or real time gaming). Even then some times it's still just optional - one way of calling it goes binary, the other goes JSON (or - Qod forbid - XML).

    However, the client code might still expect it as a short int, so if something comes through that's bigger it'll either crash, cap it at the short int max (what we're at here), or do some overflow thing where you end up with negative trainers. So there's no worry about the data format itself, but it's still an issue for reading it.
  • VesmerVesmer ✭✭✭
    Vesmer wrote: »
    They send data between clients and server in JSON format, it’s obvious from iampicard. So there’s no issue from this point of view.

    That's mostly what I'd expect- binary formats are pretty much only used for super-high performance stuff (like stock transactions or real time gaming). Even then some times it's still just optional - one way of calling it goes binary, the other goes JSON (or - Qod forbid - XML).

    However, the client code might still expect it as a short int, so if something comes through that's bigger it'll either crash, cap it at the short int max (what we're at here), or do some overflow thing where you end up with negative trainers. So there's no worry about the data format itself, but it's still an issue for reading it.

    I doubt they use short ints in the code. Why would they? 32-bit ints work faster on 32 and 64-bit processors than 16 or 8-bit ints. I used 16-bit ints in one project, but it was embedded stuff with AVR microcontroller that had “huge” memory of 2 kilobytes. There it was logical to use 16-bit, but here? I see no reason.

    So I believe it’s a limitation from database side. Probably they tried to save the db space, though they saved about 2 gigabytes at most

Sign In or Register to comment.