Investigating The Magic of 32,767 and what it means?

[KraphtOne]

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]

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...

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]

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.

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...

[Jdsizzleslice]

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...

I think that the gameplay is the main java code being ran, and the game chat is secondary. The gameplay will send information to the game chat, but the game chat can only take in so much data. The reason that 32767 is the real maximum is due to a term in programming called overflow.

If an overflow were to occur, the code would actually take the number 32768 and make it equivalent to 0. The current game chat java is probably designed to only take in 16 bits so no overflow occurs, and thus no random garbage is output.

I know Wikipedia can sometimes be a bad source, but read this article. It may give you a bit of information regarding the thought process by overflow: https://en.wikipedia.org/wiki/Integer_overflow

As far as it communicating that there will be more troops deployed than what will be output to the game chat, you would probably have to reduce the size of the maximum to 2^14 (16384) in order to introduce a flag bit. The flag bit will tell you whether or not you are over your limit, which will serve your purpose. However, this leaves you only 15 bits to actually output the data, and therefore the new max would be 16383.

Realistically speaking, you're right. It is a bug, one they are probably aware of. However, rarely do games get to the point where more than 32767 troops are deployed, so it really comes down to a simple question and choice:

a) Spend more money and have a 32-bit game chat that can output almost any feasible number that any game will reach for deployment, or

b) Spend less money to have a 16-bit game chat that can output a max of 32767 that will be able to cover almost any game that will reach that number for deployment.

I would be willing to bet that most would be willing to live with the bug that rarely occurs, that only affects game chat text to spend less money.

[Jdsizzleslice]

Another way you can think about it is like an if-else statement, logically:

Code: Select all

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


This may not be representative of what it is actually doing, but it may give you an idea of how it may go about passing the number to the game chat.

[Extreme Ways]

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.

[Jdsizzleslice]

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

[Extreme Ways]

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

A signed long long (if necessary) still represents 9,223,372,036,854,775,807. If that number isnt big enough, it's surely too much of an edge case. Idk the code of chat, but it seems like a crafted string depending on a few vars.

[dgz345]

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]

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]

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

[Extreme Ways]

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

Ah, I understand. You mean a x-bit value is sent to the backend but only 16 bits in the db, hence when the data is fetched again from the db... it's only a 16-bit value.I thought you were going on about something else.

[king achilles]

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.

[Jdsizzleslice]

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.

So this theoretically could be fixed the next time the website is down for scheduled maintenance?

[king achilles]

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

[Jdsizzleslice]

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...

[Mad777]

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...

Will be nice to assess how long it would take, if the benefit are huge then maybe this to be consider, as long as it is advertise well ahead of time and ensuring all game clock to be freeze while the site is down.

[KraphtOne]

Look my point is that how lazy is this set up? You have a game log that doesn’t even match what is happening in the game.

Try searching for how the dice work here...

There are people that understand these mechanics that could maybe improve things...

[iAmCaffeine]

You're trying to address issues that have been known about and ignored for a long time. They aint about to change that now.

[uyumaykimaw]

Game 19940246

I have described the problem in the game chat.

Here is what was in the game log:
2020-07-22 21:44:15 - SupaArmy reinforced ? with 32767 troops from ?

Here is what I wrote in the game chat describing the problem:
2020-07-22 21:39:21 - uyumaykimaw [self]: snapshot round 131
2020-07-22 22:01:59 - uyumaykimaw [self]: snapshot round 132
2020-07-22 22:09:06 - uyumaykimaw: what is going on? yellow now has 57689 on Des Moines....that should not be possible
2020-07-22 22:11:28 - uyumaykimaw: my snap after my turn and before yellow turn shows the largest yellow adjacent stack to Des Moines is Waterloo with 1194 troops
2020-07-22 22:12:47 - uyumaykimaw: yellow had a drop of 68.....and then somehow managed to fort to it, according to the log, 32767
2020-07-22 22:16:17 - uyumaykimaw: this means the mix amount yellow should be able to have on Des Moines now is 1168 - 1(had to leave 1 on Waterloo) + 68drop + 32767 reinforcement = 34028
2020-07-22 22:16:39 - uyumaykimaw: *max amount
2020-07-22 22:21:51 - uyumaykimaw: the 57,689 total troops in the stack could very well be that if the fort was much larger than the 32767 shown in the log as the reinforcement of course.....but it means the log is in error as to the actual size of the reinforcement it seems to me

oops my calculation is off but there is still a problem....1194 on Waterloo, not 1168

uyumaykimaw

[Otnal]

Any game in which the number exceeds 32,767 for single deploy or reinforcement that is all CC shows(maxed out). Play enough large escalating games and you will see this all the time. It's not an error, simply as high a CC can count