I see you haven't read my profile.

Ok, now i understand.:p

LOL, I ran into a... somewhat... big... parameter value scale :/ This may be the clue to my problem with creating water... what is a parameter value like "4" compared to this?
Everyone who has 1.10o JCS: do the following:
-Replace event 46 of JCS.ini (you may want to back up the original event 46 by putting ';' in front of it; JCS will ignore that line in the file then) with this: 46=046|046||Unknown1XXX:30|Unknown2:10|Unknown3:10 |Unknown4:10
-Load the level 'Binnen.j2l' in JCS and go to pos (123;93)
-Put your pointer on it
-Read the status bar

;p

For those who don't have 1.10o JCS or are too lazy to reproduce wicked fun:
A screenshot! (... a screenshot that only works when my computer is online ;p)



EDIT: And I seem to have found a very weird 'BatteryCheck Rule': all events' parameter #3 has the event number as their value.

isnt that because it's a negative value

Well, you are right: on that paramter some values happen to be below zero... though actually that number was not negative

EDIT: and that rule I stated above is only true if you set all event parameter value ranges in jcs.ini to 10... I think the paramter values are only accurate for JCS.ini value ranges of -8 to 8 (which results in ranges from -128 - 127 to 0 - 255 in JCS) as I think these values are stored as a singe byte in the j2l file, and thus only support 256 different possibilities. Stuff looks a lot more 'normal' right now, as I can't find any values above 100 very fast atm and there are no stupid rules ;p

EDIT2: actually there is a rule: parameters 1 + 5 and 2 + 6 are always identical, but I think that simply means BC (or 1.10o? don't feel like checking) uses only 4 parameters... I'll just leave 5 and 6 out.

Wait... so let me get this straight:
The parameters of 1 are always identical to the parameters of 5.
Same for 2 and 6.

Therefor you just don't use 5 or 6?

BC, definitely.

Yeh, I will check now if this causes problems by removing parameters 5 and 6 from JCS.ini, then making a new event with params 1-4 set, then saving, and then putting back params 5 and 6 and reloading BCCS and the level... I'll be back soon ;p

EDIT: I did:
-Removed params 5 and 6 from event 46 in JCS.ini and saved
-Loaded BCCS and Binnen.j2l and selected a random event 46 and remembered its values (didn't copypaste it)
-Created a new blank level and recreated the previously remembered event 46 in it
-Saved the level, closed BCCS and put the params back in JCS.ini
-Loaded BCCS and my blank level and checked the event I put there

Result:
Although I did not (enable me to) specify parameters 5 and 6, they had values identical to parameters 1 and 2 respectively. All 5th and 6th parameters can be taken out of the ini file =)

EDIT: Parameter 4 happened to be 'automatically set' too, so I removed that one from the ini file too.

Results of the investigation of Binnen.j2l after some nice hours of work:

--Unique event parameter combinations--
--Parameter ranges--
High positive values are most probably all ID parameters. I'm surprised by the number of big ranges though: that means at least one event in the level had a value for that parameter lower than -64 or higher than 63...

I don't even know what all this stuff means but it looks extremely cool. :D Keep up the cool work!

Yeah you're doing good<3

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.

Would this mean a level saved using a JCS INI using altered bitfields would not work on another jj2 using a different JCS INI?

@birdie: as JJ2 doesn't use jcs.ini (only JCS does) I'd say it works fine on JJ2. But maybe JCS saves the file differently if you save it with another ini file... then stuff may be totally messed up, as I know now ;p

@neo: At least, that explains stuff ;p I already realized that I'd have to re-do the whole thing again as event 38's first parameter *could possibly* have some value around 200, though that won't be shown in BCCS because the -8 creates a range of -128 to 127. With your information however, I'm going to remove the parameters of events that clearly have no parameters and of course I'll make the boolean parameters really booleans. This piece of information you gave was just exactly what I needed to finish my work ;p now I can try to fit things in correctly and investigate each parameter one by one ;p I'll need another two couple of hours, but now that I started this I want to finish it too ;p

EDIT: replied to birdie and corrected the 'two hours' thing

@Birdie: Pretty much what jerry said. If you mess up your jcs.ini, then the level will be saved according to the jcs.ini and jazz2 will read it wrongly. Jazz2 stores its parameter bitfields internally rather than referring to a Jazz2.ini or JCS.ini.

It would be a better Idea probably if it used jcs.ini, but whatever.

Gosh! More progress!

I cleaned up the event list a bit and I'm testing the events one by one now.

[Events] section of BCE*.ini:
*Yeh I got it renamed. Read the following page to see it being announced.

gj Jerrry

=D thanks.. I'll make sure that post is updated if I found out some things again ;)

...any progress?

Not at the moment.. I got very much homework these days and thus there's no time for BCCS. I'll be back working on it next Friday

Whoosh, big progress today. Worked out the battery holder upgrade and the water pump and tried to find the correct amount of bits for some events. Some information on the events and their parameters:


Water
Water blocks are made with the Water event. You will have to give it an ID and of course you must specify its dimensions. The first boolean, Filled, decides if the water block is 'filled' at the start of the level, so that there is water in there. The second boolean, Mode, allows you to switch bedween two modes: the first one (0) has a diagonal end at the top right corner, the second one (1) has an all-straight vertical right end.
The Water event needs the Water Options event somewhere in the level to work. In the Options event, the color of the water (maybe among other settings) is decided. I still have to figure out its parameters, maybe I'll try to do so tomorrow.
You can fill an empty water block and you can flush a full water block with a Water pump. For this event to work, you must specify a Global ID and the IDs of the water blocks that must be changed. In this case, the Global ID refers to the Global ID number of a Battery holder. When you put a battery in it, the pump is activated and will fill the water block with the ID you entered for the 'Empty water ID' parameter and will flush the water block with the ID you entered for the 'Full water ID'. This will look like one water block is being filled with water from another.
Liferafts can be placed on water by putting them on the place you want them to float on the water and setting their Water ID number to the same value as the water block you want them to float on. It turned out it doesn't matter if the Liferaft event is placed in the level under the water surface, it will automatically be moved to the water surface.

Battery holders
Battery holders have an ID number. When you put a new battery into the battery holder, all objects on the level that have the same Global ID will be activated. If there is a Battery holder update event in the level with the same Global ID, the Battery holder with that ID will have a small device connected to it which enables the battery holder to take infinite energy from the battery you put in.

Eyecandy events
It turned out that there are events in the game that only add some eye candy. The monitor event will show a monitor with some person displayed on it. The Leaking energy event will show a small fireworks-like animation now and then. The effect is similar to what you get if you cut a wire while its plug is in the wall (use scissors with plastic on them please, don't die). The Dripping Water doesn't seem to harm you.

It could melt the plastic. STILL DON'T TRY IT.

Heheh, my dad had to cut a wire once, and before he cut it he put the plug in XD the plastic indeed melted, but I'm glad it didn't melt far enaugh to hurt him. It was an awesome effect, though ;p

enough*

...seriously man :( I tried teaching you how to spell that like 2 years ago

Oop yes ur right ;p normally I spell it correctly.. I were just still a little bit sleepy I think ;p

This is how I check the event's parameters. I make a list of all used combinations of bits (using the knowledge I got from Neo's post) and then try to pick out the parameters... For the water pump this was rather easy as there was always a battery holder somewhere near that matched the first six bits and there were always two water events near that matched their first six bits with the second or third six bits of the pump... and it happened the one which matched the second six bits was always the water event whose Filled parameter was 1 ;p it's just a huge puzzle, but not impossible.

I found that if you give the water options event (which happens to change nothing else than the color of the water) two parameters of 8 bits, changing the first parameter will only change the water surface and changing the second will only change the rest of the water. Also, setting both parameters to the same value will cause the water to be completely in the same color. Because there are 256 values possible for each parameter, I'd say the value refers directly to a palette entry.

-If there is anyone who could think of another way this parameter is used, please say so.
-If you know a way of getting the palette for the Binnen-tileset, then say so as knowing the palette would really help me to check if the water options parameters really refer to palette entries.

EDIT: thanks to n0 for reminding me about F12 I got the palette =) Now checking the parameter values
EDIT2: checked and I were right.

-I *was* right, grammar now!

Whoa me has done that wrongly all time to now! Why you not said it?

Oh well, I'm back working on BCCS... now investigating the elevators.

were I right froze the hell over

I added a parameter '?:1' to each finished event and checked if it worked differently with that parameter set to 1. It turned out the monitors can be horizontally mirrored too =)

Too bad they cant be flipped vertically (monitor on the celling XD )

Well you can set it to hanging=1... if you put it on a tile just below the ceiling it will be looking like it's haning on there.

Look my little control room:

Oh, thanks

...and progress?

See post #57. Stuff will get harder now, as I'll need to find out what those parameters do. Some, for example the second and fifth of the umbrella, are behaving very weird IMO, I'm just not sure what they really do.

Progress report plz.

No progress because of school. New progress will come soon.

are you in summer school or something?

Well, test week until today. Now I'm free :D Only got to go back to school two times, first to recieve the tests I made the past week and then again for returning the schoolbooks. I'll try to finish some events before I go for a two week holiday in Egypt on the 12th. People that already have the 1.10o JCS may just replace the [events] section of their ini files with the stuff I got already, then they wouldn't have a 'clean' BCCS, but at least some events work.