1) Key (key.dat)
The key is just a normal criminal-file (type 5), but instead of transforming into a character, it has an itr (y: 1000) which can hurt a box. After this, the key disappears. The amount of damage that each key does to the box depends on the number of keys. You just have to divide the standard HP value of each object (which is 500 HP) through the number of keys and add one to this value. Then the lock will open only after you have collected all of the keys.
<bmp_begin>
file(0-0): sprite\sys\key.bmp w: 79 h: 79 row: 1 col: 1
<bmp_end>
<frame> 100 key
pic: 0 state: 0 wait: 10 next: 0 centerx: 39 centery: 79
bdy:
kind: 1101 x: 26 y: 20 w: 23 h: 39
bdy_end:
<frame_end>
<frame> 101 key
pic: 999 state: 0 wait: 2 next: 1000 centerx: 39 centery: 79
itr:
kind: 0 x: -5000 y: 1079 w: 10000 h: 10 injury: 126 zwidth: 500
itr_end:
<frame_end>
2) Lock (lock.dat)
The lock itself is dependent on the source code. The frames 180, 186, 220, 222, 224, and 226 are the first frames of the falling and injured sequences. This means that every time that Frame 152 of this type 5 dat.-file is hurt, the object will go to one of these frames. In all these frames, a bdy (y: 2000) is noted, an essential part of opening the box later on.
But before the object goes to frame 152, it creates the file box.dat using an opoint. This file also includes the pictures of the box.
The strange thing about this is that the Character always hits the invisible file lock.dat, but the file box.dat determines if you can open the lock or not.
<bmp_begin>
file(0-1): sprite\sys\keycri.bmp w: 79 h: 79 row: 2 col: 1
weapon_hp: 500
weapon_hit_sound: data\035.wav
<bmp_end>
<frame> 150 deep
pic: 999 state: 0 wait: 0 next: 151 centerx: 39 centery: 79
<frame_end>
<frame> 151 deep
pic: 999 state: 0 wait: 2 next: 152 centerx: 39 centery: 79
opoint:
kind: 1 x: 39 y: 79 action: 0 oid: 301 facing: 0
opoint_end:
<frame_end>
<frame> 152 box_attack
pic: 999 state: 0 wait: 10 next: 0 dvx: 550 dvy: 550 dvz: 550
centerx: 39 centery: 79
bdy:
kind: 0 x: 21 y: 30 w: 36 h: 50
bdy_end:
<frame_end>
<frame> 180 falling
pic: 999 state: 0 wait: 1 next: 152 dvx: 550 dvy: 550 dvz: 550
centerx: 39 centery: 79
bdy:
kind: 0 x: 34 y: 2079 w: 10 h: 10
bdy_end:
<frame_end>
<frame> 186 falling
pic: 999 state: 0 wait: 1 next: 152 dvx: 550 dvy: 550 dvz: 550
centerx: 39 centery: 79
bdy:
kind: 0 x: 34 y: 2079 w: 10 h: 10
bdy_end:
<frame_end>
<frame> 220 injured
pic: 999 state: 0 wait: 1 next: 152 dvx: 550 dvy: 550 dvz: 550
centerx: 39 centery: 79
bdy:
kind: 0 x: 34 y: 2079 w: 10 h: 10
bdy_end:
<frame_end>
<frame> 222 injured
pic: 999 state: 0 wait: 1 next: 152 dvx: 550 dvy: 550 dvz: 550
centerx: 39 centery: 79
bdy:
kind: 0 x: 34 y: 2079 w: 10 h: 10
bdy_end:
<frame_end>
<frame> 224 injured
pic: 999 state: 0 wait: 1 next: 152 dvx: 550 dvy: 550 dvz: 550
centerx: 39 centery: 79
bdy:
kind: 0 x: 34 y: 2079 w: 10 h: 10
bdy_end:
<frame_end>
<frame> 226 injured
pic: 999 state: 0 wait: 1 next: 152 dvx: 550 dvy: 550 dvz: 550
centerx: 39 centery: 79
bdy:
kind: 0 x: 34 y: 2079 w: 10 h: 10
bdy_end:
<frame_end>
3) Box (box.dat)
The most complicated dat.-file is box.dat because it includes more source-dependent code than any of the other data files. In Frame 0 (state: 10) you have to note a bdy (y: 1000). If a key is activated now, the itr can damage the box and let it jump to frame 20 (hit). But because the box still has more then zero health points, the timer doesn't work yet. State: 10 is necessary to hurt the same attack several times (cause normally the attack belongs to your team if you hit it one time). If the box takes all of the damage from the keys and it has less than zero health points, the timer is automatiucally activated (the value of hit_a is not important here, it just shouldn't be zero). The object jumps to frame 100 and is repeated indefinitely.
The itr (y: 2000) which is noted here is the opposite of the bdys in the injured and falling frames in the lock. If you now hurt the lock with the character, the itr can damage a bdy, and because of the source code, frame 10 (hiting) is activated, causing Deep to be created.
In this dat.-file you also note the images of the box.
<bmp_begin>
file(0-1): sprite\sys\keycri.bmp w: 79 h: 79 row: 2 col: 1
<bmp_end>
<frame> 0 key-health
pic: 0 state: 10 wait: 5 next: 999 centerx: 39 centery: 73
bdy:
kind: 0 x: 34 y: 1073 w: 10 h: 10
bdy_end:
<frame_end>
<frame> 10 opening
pic: 1 state: 3 wait: 5 next: 11 centerx: 39 centery: 73
<frame_end>
<frame> 11 opening (akt deep)
pic: 1 state: 3 wait: 2 next: 12 centerx: 39 centery: 73
opoint:
kind: 1 x: 39 y: 73 action: 0 oid: 1 facing: 0
opoint_end:
<frame_end>
<frame> 12 opening end
pic: 1 state: 3 wait: 10 next: 12 centerx: 39 centery: 73
<frame_end>
<frame> 20 key-health
pic: 0 state: 3 wait: 0 next: 999 centerx: 39 centery: 73
hit_a: 1 hit_d: 100
<frame_end>
<frame> 100 waiting for opening
pic: 0 state: 3000 wait: 5 next: 100 centerx: 39 centery: 73
itr:
kind: 0 x: 34 y: 2073 w: 10 h: 10
itr_end:
<frame_end>
Here you can download a study example. Because the system is quite complicated, I pasted the relevant frames into a PDF and marked the connections with colours.
|
Key-System |
Inspired by Windmill