I was wondering if either of you guys could give me a breakdown on how the “buffer_index” is defined and what exactly is a “bitset” I’ve been trying to develop more elaborate scripts and don’t quite understand these two peramiters of the accum command. I thought I could figure it out but have been unable to.
Hope you can help
Not quite sure what you mean exactly with the buffer_index thing, i assume you are refering to the number directly after accum in the script commands.
Every entity has 8 “buffers”, just think of them as little boxes, into which you can store numbers, check against the value of the box, or set individual parts of the box (bitset).
These boxes are 32 bit integers.
Now for a short lesson in binary arithmatic.
The binary system has only two numbers, 0 and 1, i.e. it’s base 2, with decimal being base 10.
Decimal (as i’m sure you are aware 
) counts like so:
0…1…2…3…4…5…6…7…8…9…10…11…12 etc…
whereas binary goes like this:
0…1…10…11…100…101…110…111…1000 etc…
Therefore 0 = 0, 1 = 1, 2 = 10, 3 = 11
For every new column you add in decimal, you are multiplying by 10 how much this column is worth, in binary it is 2. So, for a 32 bit integer we have 32 columns (in binary).
bitset, allows you to set the value of column X to 1, and bitreset allows you to set it to 0, this allows you to store 32 different on or off states, so if all you need to know about parts something is whether they are on/off, dead/alive, etc… then you can use bitset, and bitreset + the various check functions to your advantage, rather than using a single accum buffer for each one.
Half the stuff i’ve mentioned here is either:
a) not relevant really
b) something you already knew
c) something i haven’t explained all that well 
Any more questions, feel free to ask, i’m quite happy to ramble on about complete nonsense…
And one thing budding scripters should be aware of is that any accums made in one entity cannot be accessed in another entity. For example, if you have an entity called “Rocket_Top” and one called “Rocket_Bottom” - any accums used in rocket_top cannot be altered or read by the Rocket_bottom entity.
This is the main reason why the game_manager script tends to get quite large, as it serves as a good way of tracking variables for everything. You simply call functions in the game_manager to set accums and then use other functions in it to activate other entities according to the accums.
As you may want to have a complex level, using accums can be limiting, as you only get 8 per entity and so that means only 8 in the game_manager too - this is why using bitset and bitreset is iseful because you can have 32 true/false variables for each accum, more than enough.
Ok…Hmmm…Let me see If I get this right.
I can assign 8 different actions variables (buffer_index or <n>) to each entity.
I assign these variables with the “set” command.(1, 2, 3, 4, etc…)
Each action is defined as either “on” or “off” by the use of “bitset” and “bitreset” respectively.
I can add variables to the “set” state by using the “inc” command to progress the entities life to an advanced state within the entities base definition.
No two entities can be share a linked functionality state. (work in tandem)
I should always be careful when asking a programmer to explain something to me.
and last but not least, make sure their is lots of beer nearby when trying to decipher what I have been told.
you have 8 buffers, you can either use set to set them to specific numbers, OR treat them as 32 little switches, i wouldnt recommend trying to use both at the same time, it’ll only confuse you :razz:
Great, thanks djbob, I’ll try to put it all into action now.
I can’t wait for Enemy Territory release, the additions to the Engineer class should add a ton of game-play possibilities.
Hope it all goes smooth for you guys through the upcomming crunch time.
Map on