I just found out we have reached the number of status effects the game can handle right now. They are stored as bit shifts in 32-bit and we have 32 effects right now, so adding more will overflow.

Could we change the way they are defined to allow for more effects? I don't actually know why are they defined as bit shifts rather than a progression of numbers, maybe because of speed of calculations?

# Overflow

May 7, 3:36 am

I just found out we have reached the number of status effects the game can handle right now. They are stored as bit shifts in 32-bit and we have 32 effects right now, so adding more will overflow.

Could we change the way they are defined to allow for more effects? I don't actually know why are they defined as bit shifts rather than a progression of numbers, maybe because of speed of calculations?

Could we change the way they are defined to allow for more effects? I don't actually know why are they defined as bit shifts rather than a progression of numbers, maybe because of speed of calculations?

May 7, 6:33 am

Are we there already? I didn't know we'd get there so soon. Have you tried increasing it to 64? I guess they act like logical flags that make AND and OR operations fast and intuitive.

May 7, 6:37 am

Are we there already? I didn't know we'd get there so soon.

Yeah, I tried to add a nice new fungal disease and overflowed into POLYMORPHED.

Have you tried increasing it to 64?

I have no idea how.

May 7, 6:49 am

Yeah, I tried to add a nice new fungal disease and overflowed into POLYMORPHED.

I have no idea how.

I have no idea how.

Isn't there a "MAX_NUMBER_OF_STATES" variable somewhere in char.cpp?

May 10, 5:43 am

Isn't there a "MAX_NUMBER_OF_STATES" variable somewhere in char.cpp?

I didn't find anything like that, only this note:

DecreaseTemporaryStateCounter works only when State == 2 ^ n!

I'm not sure whether this will not require some rework on states. :/

May 13, 8:17 pm

I see there's a line https://github.com/Attnam/ivan/blob/master/Main/Source/char....

Which has a variable names

And states is defined here: https://github.com/Attnam/ivan/blob/master/Main/Include/ivan...

What happens when you increase states from 32 to 64 in ivandef.h?

Which has a variable names

STATES

And states is defined here: https://github.com/Attnam/ivan/blob/master/Main/Include/ivan...

What happens when you increase states from 32 to 64 in ivandef.h?

May 14, 2:01 am

What happens when you increase states from 32 to 64 in ivandef.h?

That only defines the number of states currently in game. You can see it was increased with each PR that added a new state. If you oncrease it beyond 32 and add a new state, you'll overflow into POLYMORPHED.

May 15, 12:10 am

You're right. I looked a bit harder in the code and saw that it stores and handles STATES as an integer data type, i.e. int.

Everywhere we see a "long" this is just short for "long int" which is the same as "int".

An "int" is only 32 bits long, and this is sufficient for our 32 states. Because individual states are defined like (1 << 3) which in binary is 1000, or the integer 8, once you define the 32nd state (1 << 31), you get the biggest size flag that you can represent with 32 bit integers. There is no (1 << 32), because that overflows to the (1 << 0)th state, or polymorphed, as you rightly observe.

What we need is for STATES to be represented at "long long", which is 64 bits long, giving us twice the number of available states. N.B. long long is the same as 'long long int".

EDIT:

~~In ivandef.h we might elect to define STATES as a long long thus:~~

a la the examples stated in https://stackoverflow.com/questions/208433/how-do-i-write-a-...

That won't do it either... STATES is just the number of states. Maybe each state needs to be declared

BUT, I don't know how far that will solve the problem, because I am not sure whether the rest of the code assumes STATES is long and therefore go bung, OR whether this simple change will be respected by the rest of the code, and it plays nice with STATES as long long.

Everywhere we see a "long" this is just short for "long int" which is the same as "int".

An "int" is only 32 bits long, and this is sufficient for our 32 states. Because individual states are defined like (1 << 3) which in binary is 1000, or the integer 8, once you define the 32nd state (1 << 31), you get the biggest size flag that you can represent with 32 bit integers. There is no (1 << 32), because that overflows to the (1 << 0)th state, or polymorphed, as you rightly observe.

What we need is for STATES to be represented at "long long", which is 64 bits long, giving us twice the number of available states. N.B. long long is the same as 'long long int".

EDIT:

#define STATES 32LL

a la the examples stated in https://stackoverflow.com/questions/208433/how-do-i-write-a-...

That won't do it either... STATES is just the number of states. Maybe each state needs to be declared

#define POLYMORPHED (1 << 0)LL???

BUT, I don't know how far that will solve the problem, because I am not sure whether the rest of the code assumes STATES is long and therefore go bung, OR whether this simple change will be respected by the rest of the code, and it plays nice with STATES as long long.

May 15, 6:31 am

Maybe this needs to be changed to

EDIT: Hmm, does not seem to work right...

unsigned long long int Config;

EDIT: Hmm, does not seem to work right...

May 15, 10:22 pm

Maybe this needs to be changed to

EDIT: Hmm, does not seem to work right...

unsigned long long int Config;

EDIT: Hmm, does not seem to work right...

It's tricky aye? Have a look at character::BeginTemporaryState. The States variable is type long int, or 32 bits. This is already a clue as to how extensive the changes might have to be.

The state variables are logical flags, represented by 32-bit integers.

These flags look like this:

LEPROSY = 0001 FLYING = 0010 SLEEPING = 0011

And so on. It allows the program to do fast operations like:

if(!(States&FLYING)){ trigger beartrap; }

I think if we want to increase the number of states, one option is to represent the states as long long (64 bits). This will only give us 32 more states unless there is a smarter way to do this.

Sadly my idea to do the following failed:

#define POLYMORPHED (1 << 0)LL

Maybe this is a good question to pose to zenith/emlai?