Fix the bug that actually matters?

[Stormpeaks]

Y'know, I keep hearing that people aren't white knights, but I have yet to see a single negative thread that isn't met with the same set of people going "Tantrums! Hyperbole! Complaining about every little thing!"

The Caloric bug is one that prevents people from clearing. This is not a good thing. It would have been good if Square prioritized this one, but it appears that they didn't.

But it doesn't matter how outlandish or not a negative thread is. It's always "UGH, you're so emotional, so hyperbolic", with zero regard for the content. Has it occurred to any of you that the reason these troll threads are so funny is because they're probing for an actual game issue that you guys won't fall back on the Squeenix defensive for? You claim you're not white knights, but Jeebus there's nothing you won't call "over-emotional" or "overblown", at least not that I've seen.

It's always the same few people doing that honestly, thankfully there's really few of them, I'd say about 10 or less, they will whiteknight and defend the multibillion dollar company at all cost

[Shinkuno]

It's always the same few people doing that honestly, thankfully there's really few of them, I'd say about 10 or less, they will whiteknight and defend the multibillion dollar company at all cost

They like to claim the game has so much to do, yet they have time to sit in the forums 15 hours a day *think emoji*

Proper fixes take time. This is...news? Want them to do it fast and have more problems??

Or take their time and do it right?

Which is it??

I hope you dont genuinely believe making a random number not roll 0 takes time. If you do believe so, you are really detached from reality and probably think programming is black magic.

even Q&A cannot catch all bugs. thats unrealistic since Q&A is not testing on a live server.

from what appears to happen, its when the servers are under load according to the release, which since they did not say what kind of load, its likely the devs had to go over logs to try and determine how it happens and may not have been able to be replicated in their test environment. Since it has been cleared, clearly it was not happening 100% of the time, which are some of the hardest bugs to root out. the devs where I work see this with our software, and its called "unintended application". It cannot really be "tested" because its not a workflow the devs OR Q&A had thought of or would use. could they have caught it? sure, maybe, the number 0 one, most likely, this one I am not so sure because the test server, no matter how close you make it to live, will never be a live server.

They PRIDE themselves with their playtest team, to the point they mock the players when content releases overtuned and they release statements like "well our team cleared it" while its pretty obvious their playtest team doesnt actually clear the content, else the buffcap stuff would have been caught.

[TaleraRistain]

I hope you dont genuinely believe making a random number not roll 0 takes time. If you do believe so, you are really detached from reality and probably think programming is black magic.

This says to me you just jumped on the bandwagon around here of the armchair devs who were criticizing SE like this who turned out to be completely wrong about the issue. The problem wasn't a random number generator not rolling 0. The problem was the instance server wasn't getting the result from the lottery server so was defaulting to 0 in the absence of a result.

[BRVV]

This says to me you just jumped on the bandwagon around here of the armchair devs who were criticizing SE like this who turned out to be completely wrong about the issue. The problem wasn't a random number generator not rolling 0. The problem was the instance server wasn't getting the result from the lottery server so was defaulting to 0 in the absence of a result.

So they didn't even test their hardware setup?

[TaleraRistain]

So they didn't even test their hardware setup?

You don't test code in production.

"nyoooo there are no developers outside square enix that means everyone is a armchair dev"

It might suprise you, but developers exist outside of your favourite company too And it doesnt matter where the result came from, if 0 is a result that shouldnt exist, its really fucking easy to make the final output not be that number. Thats called exception handling and is really basic.

Setting a default like 0 to display when something goes out of allowable range is exception handling.

QA teams always get a lot of flack in situations like this but it's entirely possible they knew and reported this bug but higher ups decided to push through anyway.

This is a possibility as well. We are always at the mercy of the choices those paying the bills decide to make. And they don't always make wise ones.

[Shinkuno]

Setting a default like 0 to display when something goes out of allowable range is exception handling.

Not at all... imagine if during a transaction error your exception handling would be not abort the transaction, but removing the money from the sender and giving 0 to the receiver.

The exception handling for this case would be either reroll or set it to 1, which still unfair at least noone loses out and noone would even know if something went wrong cause 1 is a valid result after all.

Could their actual exception handling code set it to 0? Yes. Would i call it exception handling? No, cause you purposefully let through a bad result.

[Valkyrie_Lenneth]

Not at all... imagine if during a transaction error your exception handling would be not abort the transaction, but removing the money from the sender and giving 0 to the receiver.

The exception handling for this case would be either reroll or set it to 1, which still unfair at least noone loses out and noone would even know if something went wrong cause 1 is a valid result after all.

Could their actual exception handling code set it to 0? Yes. Would i call it exception handling? No, cause you purposefully let through a bad result.

They stated the results were valid, it was just an error from moving the result to the end user where a disconnect happened.



If you don't believe them well.... Conspiracy theorists thrive everywhere I guess. The XIV team is usually pretty transparent when it comes to problems, haven't given me a reason to doubt them yet.


If a transaction fails in commerce, you still see the money "withdrawn" from your account for a few days until the bank let's it fall off.

[TaleraRistain]

Not at all... imagine if during a transaction error your exception handling would be not abort the transaction, but removing the money from the sender and giving 0 to the receiver.

The exception handling for this case would be either reroll or set it to 1, which still unfair at least noone loses out and noone would even know if something went wrong cause 1 is a valid result after all.

Could their actual exception handling code set it to 0? Yes. Would i call it exception handling? No, cause you purposefully let through a bad result.

How exactly is the server that isn't doing the rolling supposed to do a reroll? The lottery server was doing the rolling. It had a valid result. That valid result was not being passed to the instance server due to a bug and in the absence of a result the code was displaying 0 for the end user.

[BRVV]

You don't test code in production.

Yes. Never claimed otherwise. You DO test however if your multi-server setup of a massive project spanning literal continents has servers that can actually communicate with each other

#worksOnMyMachine

[TaleraRistain]

Yes. Never claimed otherwise. You DO test however if your multi-server setup of a massive project spanning literal continents has servers that can actually communicate with each other

#worksOnMyMachine

Not, however, on the live systems. You have development and QA environments and the configuration on any of those could be out of sync with production or doesn't experience the same conditions that the production environment would. So then the bug only manifests when the live environment is working with the new code.