Impossible to set globalaccum with high decimal values?

(Shaderman) #1

Hi.

I want to use a globalaccum to (bitwise) store 32 states of entities. Now that I don’t want to set every single bit with “globalaccum x set y”, I tried to set a single decimal value of 2239882046 (representing 32 bit: 10000101100000011110001100111110).

If I now test the map (with devmap or in a pk3) on my local computer everything is ok. When I put the pk3 on our ETPro 3.1.0 server and connect with my client, the content of the globalaccum is screwed up :frowning:

I verified this with the printglobalaccum command: globalaccum 0 is set to 2239882046 in the script. Running the map on our server, the log prints out a value of 2147483647 and if I run run the map local it shows a value of -2055085250 for the same globalaccum!

Even if printglobalaccum prints out different values, the states of this globalaccum seem to work fine when the map is run local and the initial value is lower (maybe 30 bit) even though it doesn’t work when run on a real server.

Is it a bug or a feature? I appreciate any help :stuck_out_tongue:

(nUllSkillZ) #2

Have you tried to set it bitwise?

BTW here are the actions for bitwise operations with accum’s:


accum <n> bitset <m>
accum <n> bitreset <m>
accum <n> abort_if_bitset <m>
accum <n> abort_if_not_bitset <m>
(The Wanderer) #3

the numbers are the same binary value. It has to do with the way computers represent negative numbers. Negative numbers are represented using a 1 as the leftmost bit. The maximum positive value you can represent with 32 bit number is 2^31 -1 which is basically a 0 followed by 31 1s. Your number is bigger than that which is effectively making it negative. Don’t worry too much if this doesn’t make sense. If all you doing with that value is bitwise operations you’ll be fine.

(Shaderman) #4

Thanks for your replies!

@nUllSkillZ: I didn’t want to set each single bit because I need 128 bit capacity in total. This would result in lots of lines in my script which I tried to avoid :eek: Another idea was to read 4 cvars from the server and fill 4 accums (bitwise) with these values.

@The Wanderer: I know what you’re talking about and tried to test this. Considering the sign of signed/unsigned integers (playing with bit #32), I never got a result of -2147483648 or 2147483647 (the min and max values of a signed int) :eek2:

I successfully tried to split up those 32 bit twice in my script and will work with 8 accums (using the lower 16 bit now) to store my information. This way I should be easy to store cvar values in those accums, too :smiley: