Everyone that entered the lottery should have a second chance - it wasn't fairly done

[Milus]

They need to double the number of wards in every zone and be for private housing only

[MellowMink]

They need to double the number of wards in every zone and be for private housing only

That first part is probably significantly easier said than done. It would be nice if the ratio of free company wards to personal ones wasn’t so ridiculously high though.

[TaleraRistain]

This isn’t true. Every single auction was wrong. Even if you personally wouldn’t have won, it was done wrong. Every “0” was not counted in every auction. So each auction had someone who would automatically never have stood a chance at winning. Also, that means the winning number was off by 1 person, so it should have been the next highest number if it actually added “0” person in, and if you moved “0” person to an actual spot they should have had, of “1”, then the winner should have been the person who had the number below the winning number as advertised. The whole entire auction was wrong for every single house. The ONLY way to fix that is to wipe the slate clean, reset everyone to where they were with housing right before the auctions began, and redo the first auction.

That's not what happened at all

Say you have a server here doing the lottery and these are the results

A - entry 3 wins
B - entry 2 wins
C - entry 1 wins

And then on a separate server is the housing data and when it works right, it should look like this

A - entry 3 wins ------------------------------------ A - my new proposed owner is entry 3
B - entry 2 wins ------------------------------------ B - my new proposed owner is entry 2
C - entry 1 wins ------------------------------------ C - my new proposed owner is entry 1

What happened here is this

A - entry 3 wins - - - - - - - - - - - - - - - - - - - - - A - error
B - entry 2 wins - - - - - - - - - - - - - - - - - - - - - B - error
C - entry 1 wins - - - - - - - - - - - - - - - - - - - - - C - error

They could have coded it so "error" was just a null but nulls in coding can be seriously bad juju, so instead they coded the error case to return 0 as a default value and assign no winner. But the winners are still recorded on the lottery server and so they can retrieve that data and award the winners their prize appropriately. And they can fix the issue that caused the servers not to communicate so the issue doesn't occur again on future lotteries.

[Packetdancer]

They could have coded it so "error" was just a null but nulls in coding can be seriously bad juju, so instead they coded the error case to return 0 as a default value and assign no winner. But the winners are still recorded on the lottery server and so they can retrieve that data and award the winners their prize appropriately. And they can fix the issue that caused the servers not to communicate so the issue doesn't occur again on future lotteries.

The analogy I've used in a few threads so far is that the lottery server has the list of winners, but when it called to to tell the placards who won, sometimes it got a busy signal... and just never left a message or called back. So for the placards it got through to, yay, the results are correct! For the placards it didn't get through to, it still has correct results stored on the lottery server, but it never got around to telling those placards.

What they need to do, in essence, is change things so that the lottery server can be told to basically retry any phone-calls that it didn't get through on, so as to actually tell the remaining placards who their winner is.

[Hasrat]

They need to double the number of wards in every zone and be for private housing only

NA and EU have whole new data centers and worlds in the works. Probably wouldn't expect new wards for anywhere until populations balance out again after those come online.

[TaleraRistain]

The analogy I've used in a few threads so far is that the lottery server has the list of winners, but when it called to to tell the placards who won, sometimes it got a busy signal... and just never left a message or called back. So for the placards it got through to, yay, the results are correct! For the placards it didn't get through to, it still has correct results stored on the lottery server, but it never got around to telling those placards.

What they need to do, in essence, is change things so that the lottery server can be told to basically retry any phone-calls that it didn't get through on, so as to actually tell the remaining placards who their winner is.

Hahah I like the busy signal analogy

You want to be careful with retries, though, because you don't want it to just keep trying into infinity. One of our teams is dealing with exactly that right now because something tried 300 times before someone went "Waaaaaaaaaaaaaait a second"

So probably a limited number of times to retry and then it would still need to throw an error and alert some process that something wasn't working correctly

[Packetdancer]

You want to be careful with retries, though, because you don't want it to just keep trying into infinity.

Oh, do I have Bluetooth-related horror stories about things with... uh... interesting retry behavior.

You're not wrong, though; a simple "okay try sending it again" could create more problems, you'd want to do something like "try again in 5 minutes, if that fails, try again in 15, if that fails, try again in an hour" so that if there's an error state lasting a while -- remote database offline, network switch has died, datacenter has been pulled into an extradimensional vortex, wolves have eaten the network cables, or (least likely of all) you're using SQL Server willingly -- you aren't just pelting it endlessly, but don't entirely give up. Basically, the same sort of re-queue-and-retry logic that (most) e-mail servers use when they can't connect to a remote host. But yeah, there's a point at which you definitely want it to stop retrying, put the results in a "pending" queue to be dealt with manually and start waving a flag going "HELP! HUMAN! I'M NOT SURE WHAT TO DO WITH THESE!"

[DragonFlyy]

That's not what happened at all

Say you have a server here doing the lottery and these are the results

A - entry 3 wins
B - entry 2 wins
C - entry 1 wins

And then on a separate server is the housing data and when it works right, it should look like this

A - entry 3 wins ------------------------------------ A - my new proposed owner is entry 3
B - entry 2 wins ------------------------------------ B - my new proposed owner is entry 2
C - entry 1 wins ------------------------------------ C - my new proposed owner is entry 1

What happened here is this

A - entry 3 wins - - - - - - - - - - - - - - - - - - - - - A - error
B - entry 2 wins - - - - - - - - - - - - - - - - - - - - - B - error
C - entry 1 wins - - - - - - - - - - - - - - - - - - - - - C - error

They could have coded it so "error" was just a null but nulls in coding can be seriously bad juju, so instead they coded the error case to return 0 as a default value and assign no winner. But the winners are still recorded on the lottery server and so they can retrieve that data and award the winners their prize appropriately. And they can fix the issue that caused the servers not to communicate so the issue doesn't occur again on future lotteries.

This. So much this. Even possible that the error WAS a null, but an INT in most programming languages can't be null so it either errors out (would've crashed the server) or defaults to 0.

[Packetdancer]

This. So much this. Even possible that the error WAS a null, but an INT in most programming languages can't be null so it either errors out (would've crashed the server) or defaults to 0.

To elaborate a little on this: NULL is, in many systems, literally just an alias for 0. Things don't crash because the value is NULL. Things crash because anything stored in a computer's memory, when represented as a pointer ("this is where the data is stored", as it points to the spot) is represented as a number (where in memory it is), and if you try to access a memory location which happens to be set to NULL... you're basically saying to go get whatever's at memory location 0. But there's no function there at memory location 0 to call, there's no valid data there to read. So if you use NULL as an address for any sort of memory access, things go boom. This is why a pointer being set to NULL is used to mean "this pointer doesn't point to anything, e.g. is not valid/is empty". That's great, but if you forget to check "is this NULL" before using a pointer...

The program Oops.exe has stopped operating.

In other words, that's how you get a STATUS_ACCESS_VIOLATION error dialog on Windows, an EXC_BAD_ACCESS on macOS, or a SIGSEGV signal on Linux/UNIX.

But if you assign NULL to an integer... well, NULL is just another way to say 0, so you just get an integer with a value of 0. Perfectly safe.

There are exceptions, of course; "nil" in some languages is a special case, such as how things cannot be nil in some languages unless you tack a '?' on the end of the data type to make it nullable. In those languages, there is a difference between an Int with a value of 0 and an Int? with a value of nil; the first one is explicitly "I contain a value, and it is 0" while the second one is "I contain no value".

But older languages do not make that distinction; "I contain no value" and "I contain a value of 0" are generally the same thing. Hence why a placard containing no value contains (and displays) a value of 0.

[Nihility]

they aren't going to undo won homes.

I think the only thing they can do fairly to everyone that was involved is along the lines of
reduce FC exclusive to like 10
open up 3-4 new wards(meaning every district so actually 15-20 + all the vacant small/medium in ishgard 11-18)
give the first lottery exclusivity to those that participated in the nightmare lottery as an apology(people will cry about being not allowed but then again they always do and if they didn't care to enter the first lottery what is their argument?)
then go back to the normal lottery/results pattern they initially intended... with the errors fixed of course