Airfix DogFighter Programmer's Manual


<< Page 4  Tutorial   Page 6 >>

3.2.4: The OBJE-block.

As stated earlier, the .level-file contains all info about the world and its objects that the Mission or Dogfight is happening in. As we have seen, upon saving the level in the House Editor a .asf-file is generated from the .level-file, but this .asf-file only contains info about MODL's: things that can move and shoot, and the four types of Arrows. For the info about other objects, static and dynamic, the .level-file is used. See the  "Game Structure" pages for more info on this. 

The Data for the Furniture (Static) and the Breakables and Burnables (Dynamic) are contained in the OBJE-blocks. These are Simplified versions of the MODL-block: as the Static and Dynamic objects don't belong to a team and can't move, they don't need the parameters that are included in the MODL-block like SetTeam, AIActivate or SetPickupType. The General Format for the OBJE-block looks like this:

OBJE 4D 00 00 00 Header and Descriptor Length (RHN)
E2 5F 5F 42    60 E5 78 40    43 22 5E 40 X- Z- and Y parameters (RHN)
00 00 00 00    92 99 C9 BF    00 00 00 80 Pitch, Rotate and Bank parameters (RHN)
dining_room 00 Location + End Byte
Game\Objects\Dynamic\IaFlowerVase.object 00 Object Descriptor Ref. + End Byte

This is all the info needed to place a Static or Dynamic object in the villa: an OBJE-header, the two sets of coordinates, the room it is located in and finally the path to the object-files.


3.2.4.1: The HidePickup-parameter.

There is one remark to be made here: As we saw in the description of the MODL-block when we assigned a puRepairs pickup to the FW190, we can make a model yield a specific pickup when it dies. Not so for the Dynamics and Statics unfortunately: they do yield pickups, but, as you might have found to your detriment getting short on fuel or ammo when playing the game, the process is completely random and some pickups like Keys and all weapons apart from the green General ammo-boxes NEVER spawn. There is one way round this though, even though it is an indirect one. You can't change it in the .level-file, but you can in the .afs-file by means of the HidePickup-statement. Here's an example:

HidePickup( "PuTeslacoil", "upper_hall" );

This will hide the TeslaCoil-pickup in one of the breakables in the upper hall. Notice that you can't specify the Class of the object, so one time it can be a vase, the next time the wallclock or a trophy.


3.2.5: The IAOB-block

So far, we haven’t touched on the IAOB-block. As mentioned earlier, this stands for InterActive Objects. The Sample1.level-file contains 5 of these blocks: 3 for the light-switches in each room and two for the interconnecting doors. You will remember that in the original campaign-missions you can shoot the lightswitch to turn the lights on/off, and once you found the key to a door it would open? The actual automatic opening of the door is programmed in a script-file, not in the level-file, but there are some settings for this in the IAOB-block as we will see…

There is no uniform format for the IAOB-block, so each Object has its own:


3.2.5.1: IALightswitch.

The format for the IAOB-Lightswitch Block:

IAOB 21 00 00 00 Block-header and Block length descriptor (RHN)
IaLightswitch 00 IAOB-type and End Byte
switch_kitchen 00 Switch Identifier plus End Byte
01 00 00 00 On/Off setting

By now we should be pretty familiar with Block-descriptions, so we’ll tackle this one quickly. The second line gives the type of IAOB-item, the third line indicates in which location it is. These values are preset, we can’t place the objects ourselves so it wouldn’t be wise to fiddle with these lines... The only line that we can safely change is the last one: This initially sets the light on or off: a value of 00 in the first position will switch the light off, any other value (but usually 01) will turn it on. Why 4 bytes for a simple boolean operation? For a while I thought one of the other bytes might “lock” the switch, thereby preventing it from being toggled but after trying different values for every single byte I have come to the conclusion that there is no such lock, though a lock CAN be set in the .asf-file. You can only program the initial state by setting the first byte to false or true…


3.2.5.2: IABlind.

This is a bit of an oddity, as it occurs only once in the whole of the Airfix Villa: the Rollcurtain in the Kids Room.
I don’t want to spend too many words on it, but here is the format:

IAOB 1E 00 00 00
IaBlind 00
RollCurtain 01 00
00 00 00 00
00 00 00 00


3.2.5.3: IADoor.


The largest IAOB-block is the one for Doors. Here is the format:
IAOB 3F 00 00 00 Block-header and Block length descriptor (RHN)
IaDoor 00 IAOB-type and End Byte
door_kitchen_diningroom 00 Door-Identifier plus End Byte
01 00 00 00 Open / Close Setting
00 00 00 00 Locked / Unlocked
00 00 00 00 Locked (Blue Key)
00 00 00 00 Locked (Green Key)
00 00 00 00 Locked (Brown Key)
00 00 00 00 Locked (Pink Key)
00 00 00 00 Locked (White Key)
00 00 00 00 Locked (Yellow Key)

Pretty Self-evident I would think. The first four bytes after the Door-Identifier and End Byte determine whether the door will initially open or closed.
Though in the hex-editor you can set all eight to true, of course you really should do so with only one of numbers 2 to 8, i.e. lock it unconditionally, or unlock with one of the keys….

One last remark about the IAOB-block: 
The description of the IAOB-blocks have been given here to complete the description of the .level-file.
It is a bit useless though, indeed unwise to tinker with the settings in the .level-file directly as, unlike with the MODL- and OBJE blocks, all options can be set within the House Editor. The only time it comes is handy is when all flags for a door needs resetting to false…


<< Page 4  Tutorial   Page 6 >>