Conquer Club

KraphtOne wrote:16 bit system caps troop count at 32,767

Game 18370707

I can't possibly be the first person to notice this, but I didn't see anywhere that someone had mentioned it in the bug reports.
I noticed in this (impossible to ever end unless someone actually dies in real life) game that the troop count stops at 32,767 in the log.
Fine... I understand how 16 bit integers work...
Except that it's still DEPLOYING the actual amount of troops that it should...

2018-07-24 07:39:12 - KraphtOne: You notice the sets aren't increasing anymore?
2018-07-24 07:39:29 - KraphtOne: has been stuck on 32767 for several cashes
2018-07-24 07:39:44 - KraphtOne: something tells me you don't notice much...
2018-07-24 10:00:04 - KraphtOne: actually... the sets ARE increasing but it's saying they aren't
2018-07-24 10:00:38 - KraphtOne: because i'm about to drop 46,681 troops onto lake minstello 4...
2018-07-24 10:00:57 - KraphtOne: 2018-07-24 10:00:42 - KraphtOne deployed 32767 troops on Lake Minstello 4
2018-07-24 10:01:06 - KraphtOne: appears there is a bug

I understand that this is apparently a 16 bit java in the game log and it won't go over 32,767 without crashing... but how the hell can the java on the map do it? and more importantly how can one produce a number independently from the other?

If the game log can produce numbers independent of what is actually happening, meaning that in essence the game log is actually lying... What else is lying?

Are the dice stats lying? Clearly they aren't random numbers anymore. The system used to crash when it tried to pull 100,000 random numbers from random.org and now it can make an attack of 100,000 instantaneously...

Can we get some sort of clarity as to how this game actually works from the guy that we pay money to please...

Jdsizzleslice wrote:
My first assumption is that the java written for the game chat is different that the java for the gameplay. I also assume that the game chat doesn't take as much to run. However, I think it lies within the fact that you probably don't want the java for the game chat to be above 16 bits because it doesn't need to be. The game chat is really only text-related, while the gameplay is much more sophisticated. I think that the gameplay will send the binary string of numbers for the total number of troop deployment over to the game chat, and it is too big for the game chat java to read in, so it just chops off the 17+ bits it can't read, and only takes the lower 16. That's probably why you get 32,767 every time instead of a bunch of random numbers every time.

As far as it being related to dice stats, I'm unsure if the statistics pulls the data from the gameplay or the game chat. That would be nice to have some clarification on.

For those of you who don't understand how signed binary numbers and integers work, think of it like this. If the game chat is 16 bits, then if you raise 2^16, you get 65536. However, this is an unsigned binary maximum, and we are probably dealing with signed binary numbers, so you will have to account for that. Unsigned binary numbers only go in the "positive" direction, so signed numbers will allow you to go in the "negative" direction. Divide 2^16 by 2, and you have 2^15, which is 32768. But remember, computers don't start counting from 1, they start counting from 0, so we need to subtract 1 from our number, which 32767, your magic number.

KraphtOne wrote:And see, That's a possibility i considered as well. That the game is running on 32 bit and the log is only 16 bit.
But if both are reading the same thing then the 16 bit should crash, and it doesn't. It's not like it caps it at 32767 because I'm still able to deploy 40,000+
It shouldn't get the info and say "well i hear you but i can only go up to 32767". It should get the info and say "well i'm shutting this shit down because you just blew my mind"

Right?

I see what you're saying about it only reading so many 001011010's but the other numbers are still there. I'm not a programmer but I have a decent understanding of how it works. I don't see how it can just ignore the extra code. Like i say... How does this work? is my question...

Code: Select all

if (number > 32767)
    number = 32767
    *pass number to game chat*
else
    *pass number to game chat*


Extreme Ways wrote:Realistically changing it to an unsigned long long shouldn't make (much of) a difference space complexity wise, but this is such an important edge case that it probably will get overlooked.

1. Take binary string and convert it to a number
2. Take the number and parse through it, assigning ASCII characters to each number represented
3. Send each ASCII char one at a time to the game chat
4. Have the game chat print out each ASCII character, one by one

Jdsizzleslice wrote:

Extreme Ways wrote:Realistically changing it to an unsigned long long shouldn't make (much of) a difference space complexity wise, but this is such an important edge case that it probably will get overlooked.

Hmm. That is interesting. I'm not sure how that would work (I think), since the game chat would need signed code to complete other text-based operations besides just reading in information from the gameplay java.

The way I could see this fixed is seeing the gameplay sending only an ASCII character at a time to the game chat, but I'm sure it's been tried before.

1. Take binary string and convert it to a number
2. Take the number and parse through it, assigning ASCII characters to each number represented
3. Send each ASCII char one at a time to the game chat
4. Have the game chat print out each ASCII character, one by one

dgz345 wrote:what is this Java you keep talking about?

I'm 100% that this is PHP and javascript doesn't have shorts. but it might be because of the killing zones that are on some maps? that you might need a negative value. idk just guesses.

Extreme Ways wrote:

dgz345 wrote:what is this Java you keep talking about?

I'm 100% that this is PHP and javascript doesn't have shorts. but it might be because of the killing zones that are on some maps? that you might need a negative value. idk just guesses.

I feel like Java was also a guess but since most language have some sort of short/int/long/long long I figured we could just go on that route.

dgz345 wrote:

Extreme Ways wrote:

dgz345 wrote:what is this Java you keep talking about?

I'm 100% that this is PHP and javascript doesn't have shorts. but it might be because of the killing zones that are on some maps? that you might need a negative value. idk just guesses.

I feel like Java was also a guess but since most language have some sort of short/int/long/long long I figured we could just go on that route.

The 16-bit must come from the database as 16-bit is not standard in PHP or javascript

2^15-1 and the limit on certain database fields based on how they were set up. specifically the log has this limit, which has come up many times, and it is fixable but would require taking the site down for a time while the database is updated.

king achilles wrote:

2^15-1 and the limit on certain database fields based on how they were set up. specifically the log has this limit, which has come up many times, and it is fixable but would require taking the site down for a time while the database is updated.

king achilles wrote:It is possible but as to when such a maintenance to take the website down would be the next question.

Jdsizzleslice wrote:

king achilles wrote:It is possible but as to when such a maintenance to take the website down would be the next question.

That is what I was thinking. The last time I remember the site being down for maintenance was several years ago...