This is all just a side-effect of the website not understanding sub-coin pricing precision, which was introduced in Release 221. When Fuzzy comes back and updates the site to understand sub-coin, all will be back to normal.
3 Likes
Thanks for taking the time to explain it better Uacko. I knew I’d seen the convo but couldn’t find the rest of it and I certainly didn’t want to try to speak for any of you guys.
Well, I thought it was more the other way around, Simoyd’s idea, Fuzzy helped out with adding a nice user interface. Simoyd told me he worked on the scanner stuff and site idea for years, ah well, I must be mistaken then…
Then why is the scanner not multiplying the budget of baskets by 100 like it does with the rest of the coin values???
I can’t say definitively this is what is happening, but it is an educated guess based on my knowledge and the behavior we are seeing. I suspect that the scanner reports the budget in coin units because that is the inherent unit of the budget – it is not possible to set a budget to a sub-coin amount. Probably Simoyd expected Fuzzy to fix the site quicker, and therefore decided on the least hacky bandaid that wouldn’t result in requiring multiple updates, data migrations or periods of inconsistent data once the site was updated.
All my suppositions could be wrong, we should probably just wait to hear from Simoyd or Fuzzy.
But it’s also not possible to set any of the other coin values with a sub-coin amount why treat this one differently?
Only reason I could possibly think of is that the db field does not allow for large numbers but that would also mean that we can never have correct sub-coin values in baskets in this db…
Huh? Am I missing something?
It’s an interesting point. It’s messy, but so is floating point money.
The actual budget of a request basket should never be anything but a whole coin amount. It’s not TOO surprising if the data isn’t reported or stored in the same format as other currency values, here.
Simoyd or someone who has spent some time analyzing the game could determine and/or confirm this. I wasn’t thinking of this as a root cause but, it’s addressable without the missing web developer.
It seems it was great for just about long enough to build some trust, but at the moment that trust and reliance are actively harming the economy.
Perhaps at some point simoyd will take it on himself to fix it.
1 Like
Didn’t know the scanner and the website we are covering here were part of Wonderstruck’s endeavours?
And yes, I was talking about the website. The website does not allow sub-coin values, therefor Simoyd multiplied the coin values by 100…
But didn’t do that for the baskets…
But the scanner is retrieving the data, can manipulate it all it wants before sending it off to the website/db??
Why do it with price values but NOT with basket budgets??
The game changed the price variable to a double from an integer (or maybe they’re still using int idk) so the website and the tool have to take that in to account. The website just hasn’t been patched yet to do that, the scanner client has been, that’s where the “incorrect” numbers are coming from, it’s a display issue. Better to have correct data in the database than start modifying that.
Budgets are still whole numbers (integers), but prices are not.
Think about this for a second tho. How does the website know any of the budgets in the baskets AT THIS MOMENT?
isn’t the scanner sending this information? Isn’t the scanner capable of doing a simple multiplication before sending it off?
And the website/db apparently does only handle integers, hence the times 100 trick. Why not use it for baskets?
Yes the scanner could fix it in theory, but that’d be really hacky and bad practice, no self respecting programmer would fix a front end (display) issue by modifying the format it’s sending the data in. Also then the database would have numbers in two different formats, it’d have to store the scanner version information to determine if the number is in which format.
Fixing it in the scanner end would also introduce loads of problems when it wouldn’t be able to send the sub-coin info, does a 0.5c rock basket become 0c or 1c?
1 Like
But it’s already doing exactly that by multiplying the prices by 100!
But he did tho!
All coin values are now in the db times 100, EXCEPT for basket budgets…
It’s already doing that by multiplying it by 100 so it becomes 50…
??
One of the key functions of any API wrapper is ensuring that data is properly formatted between source and destination.
In any case, this should be a really easy fix on the scanner end to ensure all data is in the same format. Then all the website needs to do before displaying is dividing by 100 and showing the decimal…
That 100 is supposed to be displayed as 1.0c (or just simply 1c), that’s how the issue is fixed. And that part of the code isn’t in @Simoyd’s hands but @fuzzylkd’s.
But you want it to change that 50 back to 0.5, what does the scanner send to the server that can only handle the whole numbers? That’s the only way to fix the display issue with the scanner client, how do you do that by only sending whole numbers?
Yes to be clear I’m talking about the fact that the game APIs are providing some data in values intended for later use as decimal values, and some that are intended for use as integers.
Addressing this in a patch for the API wrapper (scanner client) between the game and the site is well within the normal realm of API programming.
This addresses the site hiding request baskets, and/or misreporting quantities.
The decimal display issue is definitely a front end issue and I’m not suggesting he try and inject decimals. Without having the DB structure available it may not even be possible.
There is no display issue with the scanner client, there’s a website display issue and a website/db that wasn’t build to support decimal values.
No matter what, we have a website that is not displaying coin values correctly since they are times 100, the scanner also send basket budgets without the times 100 resulting in the website to not function properly for many baskets (and displaying wrong buy amounts for ALL baskets).
Ensuring all values are times 100 solves a small part of the problem. Baskets that are now missing will be once again be shown and lo and behold all baskets will report the correct buy numbers.
Then when Fuzzy has time he can change the display of all coin values by dividing them by 100 and displaying the coin values correctly once again.
1 Like
Yes I was talking about this issue specifically, the front end was probably supposed to be updated way way sooner so this whole thing would be a non-issue.