Compound Objects

The most fundamental differences are that it is made up of parts - and always has at least one part and at most 10 - and has hotspots for activation functions. These are powerful concepts and allow you to animate one part seperate from the whole and have different parts respond in different ways when clicked on.

An example of why you would want different parts is apparent when you think about the learning computers in C2. The computers are relatively large objects, they have rows of flashing lights and a screen which displays concepts. If this were to be implemented as a SimpleObject you would have a series of frames that showed the computer with nothing on screen and the lights flashing in all possible permutations, then the same series of frames but with a picture concept on the screen ... and so on for all concepts. Implemented as a CompoundObject the graphical overhead is reduced because we create it as a collection of parts - we have the base computer shell itself, a strip which makes up the lights flashing, and a seperate section that has the picture concepts on. Now we can piece these parts together to make all the different combinations we had before - the flashing lights are completely independent of which picture concept is showing ... and vice versa. An important aspect of having seperate parts is that each one should be fully contained within the area of part 0. If this isn't the case you can always increase the size of the sprite for part 0 to make sure that all the seperate parts fit into it.

The learning computer is also a good example of how different hotspots can be used to produce different events. Instead of the bhvr values you give to SimpleObjects you actually define an area on the CompoundObject and give it an event - so, for example, one area can produce and Activate1 and another an Activate2 without the need for these to be triggered in a certain order.

That's the theory, now lets try putting some of it into practice.

Start by having a look at the 'tele.s16' file which is the sprite file for the teleporters. For this example we're only concerned with the images starting at number 8 - the first 8 make up the teleporter in the hatchery area. So, starting at image 8 you should see that there is 1 image for the teleporter structure (a metal horseshoe shape with 'handlebars'), 2 images of an orange button, 2 images of a blue button and 8 images of the base. These 4 things will be the 4 seperate parts for this object we'll make.

So to start we need to create the object, give it a classifier and attributes and then set up the parts - the chunk below will do this ... if you are unsure of any command and the numbers given look them up in the CAOS Language Guide.

Some important things to note with this are that you have to specify the creation of the CompoundObject using new: comp and also create parts using new: part. There must always be at least one part defined. The new: comp command is almost the same as new: simp with the notable exception that you do not specify an image plane here - that is specified for each individual part. Other things to note are that the new: part command specifies an image number relative to the first image specified in new: comp, not relative to the sprite file. Also see how the definition of each part gives a co-ordinate for it's placement relative to part 0 ... and this is why part 0 has 0 for both X and Y co-ordinates. If you are unsure of how to work out the co-ordinates for positioning the parts you can use a paint package (such as Paint Shop Pro) and that can tell you the locations of pixels within an image - in this case the main teleport structure.

You should be able to work out from this that we have defined part 0 as being the main teleport structure, part 1 as the platform it sits on and parts 2 and 3 are the orange and blue buttons respectively.

Ok, so that's the parts taken care of but it's not going to do anything even though we've given it an attr value of activateable - this is because CompoundObjects need hotspots defined to specify where you can click and what it does when you click there. There are two commands that set this up, spot and knob. Remove the teleporter from the world and lets create it again but this time with hotspots specified.

Use exactly the same code as before but this time before you insert it into the world with the mvto add these lines:

What we have done here is specify 2 hotspots (numbers 0 and 1) with the first line. The numbers contained within these lines specify the location of the region relative to part 0 - so again you can use a paint package to calculate the boxed area you require for the hotspot. There can be a maximum of 6 hotspots and the last 4 spots are specified as blank - this isn't strictly neccessary but I have included it to show you how to blank a hotspot.

It's probably worth looking up the syntax for the knob command because each line of it has a special meaning - essentially we are saying whether the creature can activate1, activate2 and deactivate (and which spot to use) and then doing the same but for the pointer. In this example there is no difference between the spots used by the hand and a creature but it is possible to create a spot that is only usable by the hand and another only usable by a creature.

You should be able to work out from the above code that we've marked an area around the orange button as performing an activate1 and an area around the blue button as performing an activate2 - if not then re-read it while consulting the CAOS Language Guide!

Ok, we now have an object that you can click on - but only over the 2 buttons. Nothing will happen yet but then we haven't made any event scripts. Try the ones below which show how you can animate the seperate parts of the object.

Click on a button and you should see it flash while the base rotates one way, click on the other button and that one will flash while the base rotates the other way. You can happily click one button and then the other without any problems, but if you try and click the button that is flashing you will notice that it doesn't make the base rotate. You should be in a position to guess why this is so now ...... any clues?

The reason is to do with the actv flag that gets set whenever an object is activated (Remember - actv is set automatically by the engine whenever an event is triggered ... tutorial 2 goes into more detail). For compound objects the actv flag only prevents the same event occuring again, not a different event. If you make a change to each of the event scripts that sets actv back to 0 at the end of the script you will find you don't have this problem anymore.

In the previous tutorial we talked about user defined events - and there exists a mechanism to trigger these events from CompoundObject activation hotspots. The way it works is by redirecting a defined knob function to a new event rather than the standard activate1, activate2 or deactivate. So, you create the knobs as usual - but if you are intending to redirect them then it doesn't matter which knob function you set up - defining which hotspot the knob refers to. Then you use the kmsg command to say that a particular knob actually will trigger a different event and for who it is appropriate to. In this way you can get more functionality out of a CompoundObject. A good example of where this was done was in the chemical mixing machine that exists in Creatures 2. - this used four custom events for altering the levels of fluid in the tubes based on clicking on one of four different hotspots ... each of which were only usable by the hand.