Bug Integer overflow (?) on meat in Hagnk's

Mafia worked fine when I had 1.x billion in Hagnk's, but now that I have 2.6 billion there (thanks, guy who bought that Dark Jill!) mafia can't figure it out. I haven't ever had that much meat in inventory to test if it's a problem there, too.

I assume this is a Java signed integer overflow problem. I can convert some to dense meat stacks once I clear hardcore, but in the meantime it's an issue.

First world troubles, I know...

Show off...

Incidentally a workaround for this issue would be to send <Your Total Meat> - ( ( 2^32) / 2 ) to darkcodelagsniper.

Looks like the solution is to convert inventory/storage/closet meat to long instead of int. That means changing a bunch of other code to handle long instead of int. Some of it can probably just be cast to an int (any time there is division), but some of the refactoring looks more complicated.

AFAIK Kol uses a 64-bit unsigned int for storing meat, and the Java long primitive is 64-bit signed. So it would still be possible to run into this problem after hitting 9,223,372,036,854,775,807 meat. Which is maybe a bit unlikely, but if you're expending effort solving the problem it may as well use a matching integer type to the base game.

KoL caps your meat at 2^32 - 1, partly to limit the damage from infinite meat bugs I believe. An unsigned int would be sufficient for this case, but Java doesn't have that.

Item counts are capped at 2^24 - 1, though that's not relevant to this discussion.

lostcalpolydude said:

KoL caps your meat at 2^32 - 1, partly to limit the damage from infinite meat bugs I believe.

Click to expand...

Oh ok, that makes sense. My assumption of 64-bit unsigned was anecdotes from the 2004 meat-vortex bug, and it's logical they'd lower max meat after that.

At least this isn't as involved to fix as substat gain overflow, which would require refactoring AdventureResult.count to a long and fixing all the cases where an implicit cast would occur. Although I have done that locally, it's really not worth the additional codebase bloat to cater to the 0.1% of users that might run into this issue, so I haven't committed these changes to the repository.

Likewise, I don't think this issue is worth fixing.