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
Once they get that high, use them as replicator rations.
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.
3AM so i might have made a mistake somewhere in there.
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.
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.
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)
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.
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”
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.
Which requires spending credits. I have to pay to get rid of this junk.
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.
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.
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
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.
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.
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