I think it might be an efficient way to store important game flags. Normally every variable (even if it's just an on/off flag) takes up 16 bits. This way it only takes up 1.
When you see a / and % operator together, that's usually because someone is trying to split a number into two parts... the quotient and the remainder.
So say param1 is 37. Then we'll get 2 for the quotient (37 / 16), and 5 for the remainder (37 % 16). Then it will return what is in bit 5 of array index 2.
Looks like proc0_7 and proc0_8 are responsible for setting and clearing those bits.
I think did something similar when I made Cascade Quest, so that I could save space for game flags.
My decompiler wasn't able to ascertain any name for the variable.
I do have the ability to detect arrays, but I turned it off for the global script. I can detect arrays based on how the variable is used. But it just scans the current script for variable usage. To see how globals are used I need to scan all the scripts at once. It's probably not too hard to do that.
Just doing a quick string search, it looks like the next variable that is used anywhere after global114 is global128. So that suggests global114->global127 is an array. So ideally the decompiler would produce code like this:
...
gStopGroop
global114[14]
global128
...
And 14 spots of 16 bits each suggests SQ4 handles up to 224 game flags.
[edit... ninja'd by Lars :-)]
The piece of source code from PQ SWAT calls a Bset procedure, which presumably stands for "bit set". So "good" names (to stay true to the original source code) would maybe be Btest, Bset and Bclear.
I attached the SQ4 source code with those changes...