Ok, I'd like to think I wasn't being a wet blanket, but many of the methods you have been discussing are stepping off the wrong path. So before we begin, I'd like to give a quick tutorial on how JCS.ini utilises bitfields.

Diagram 1.1Ok, so each event in JJ2/BC/JCS/BCCS is represented as a 32-bit structure. Of these 32 bits, the event ID already ranges from 0 to 255, which takes up 8 bits. Then the "generic event properties" such as the Difficulty and Illuminate Surroundings takes up another 4 bits. This leaves us with another 20 bits we can use for the parameters. So how do we inform JCS how many bits each parameter takes? By specifying the bitfield in JCS.ini as shown above in diagram 1.1.

In the example above, parameter 1 uses 8 bits, parameter 2 uses another 8 bits, and parameter 3 uses yet another 8 bits. That's a total of 24 bits, so in fact 4 bits are being discarded because there is no space to store them.

What about the negative sign, you ask? Ok, a bitfield of 8 means it takes up 8 bits, and is an unsigned value (i.e. 0 to 255). But if it is given a negative sign, -8, it also takes up 8 bits but is given a signed value (i.e. -128 to 127). Either way, the number of bits taken by the parameter is 8.

As an example, lets take event 192 (gem ring), which is given the parameters Length:5 | Speed:5. So if we gave it a length of 7 and a speed of 1, it would look like the following:

Diagram 1.2This works perfectly fine. However, if were to read the same bitfield using a different parameter setting, of lets say, Length:-8 | Speed:-8 | Param3: -8, it would look something like the following:

Diagram 1.3As compared to diagram 1.2 before, this gives you a wrong reading for both length and speed. Not to mention that overflowing the 3rd parameter can have serious consequences. With that said, let's go through the problems and fix them one by one.

This does not happen only with event 46, but any event, as long as the bitfields are nonsensical like that. The first bitfield, 30, already pretty much overflows the buffer, so none of the 3 parameters would make any sense.

This rule is not valid. Maybe if you set the bitfields param1+param2 to equal to twenty, param3 would overflow back to the event number.

No, it was not negative. The number that was given is correct, just that your bitfield was specified incorrectly.

Ah ok, you corrected the above mistake. I didn't notice this earlier.

It is still wrong to assume all bitfields are of size 8. Some boolean values that do not need to be anything other than 0 or 1 can just have a bitfield of 1. Also, the bitfields need not be stored in a single byte. In fact they are usually spread out, eg, 3 bits in one byte and 5 bits in another byte.

Assuming all your bitfields here are of size 8, then param1+param2+param3+param4 will have a size of 32, which is the entire event. So param5 will overflow exactly one event length and end up back at param1. Same goes to param6. As long as the bitfields don't exceed 20, you can have as many parameters as you want.

Same as above. Param1 + param2 + param3 = bitfield > 20, so param4 overflows and is not safe to use. In fact param3 already overflows.

Again, your ranges are restricted only by your choice of bitfields for each parameter. Not all parameters would need an entire 8 bits since they would only need to represent minimal data.

That said, that effort has not gone to waste at all! You have correctly stated that events 1, 17, 29, 50, 52, 53, 60, 62 and 63 have no parameters, thus can be kept "unparametered" in JCS.ini. Equally correct is that events 42, 51 and 55 have exactly 1 bool value, which means only one bit is used out of the twenty. Thus they can have a parameter like Param1:1.

Also, the results of your previous experiment, while not using the correct bitfields, need not be completely discarded. You could convert the parameters to binary fields and then use analysis to figure out the appropriate bitfields to use for each parameter.