Why would you want to use this? Well, one example would be if you wanted an object to respond identically to both an activate1 and an activate2 - to save yourself time you could just write one of these events and then in the other one trigger the one you had written. For example, suppose we have an object that changes pose when clicked on - but to make it more usable by a creature you want this to happen with both an activate1 and an activate2. You could write out both the events, using cut and paste to save yourself time or you could use the following:
scrp 2 1 10000 1 anim [01234] over anim [56789] over snde bang anim [9876543210] setv actv 0 endm
scrp 2 1 10000 2 mesg writ ownr 0 endm |
This is a fairly trivial example, but you can imagine that with long complex scripts this can prove beneficial.
Care must be taken when using this method as some event scripts make no sense unless they have been triggered by another object. In the example above, if an activate1 is triggered on the object by a creature then during the execution of the script the from object will be the creature - but if the creature performs an activate2 then the from object during the execution of the activate1 this time will be the same as the ownr ... because that is what actually caused the event.
Ok, lets use a small example to show how you can make things pick up an object or drop it using this command. Make sure you have no objects corresponding to (2 1 10000) or (2 1 10001) or any scripts corresponding to (2 1 10000 4), (2 1 10000 5), (2 1 10001 1) or (2 1 10001 0).
inst new: simp bal2 1 0 9000 0 setv cls2 2 1 10000 setv attr 193 mvto 4856 432 setv grav 1 sys: camt
new: simp bal2 1 0 9000 0 setv cls2 2 1 10001 setv attr 4 bhvr 3 0 edit
scrp 2 1 10001 1 rtar 2 1 10000 mesg writ targ 4 endm
scrp 2 1 10001 0 rtar 2 1 10000 mesg writ targ 5 endm |
This will create a ball that falls to the floor and then another one in your hand - place the one in your hand somewhere above the ground and then click on it. The loose ball will be carried by it. Click on it again and it will drop the ball.
Now, there is a similar mechanism that actually allows you to create your own events - this can be very useful if you want to create a common mechanism for various agents to interact through. One example would be a pollination event on flowering plants, you can create an event for each plant on what happens when it receives a pollination signal - and then each insect or agent that can cause pollination will just trigger an event and leave it up to the plant to decide whether it's actually worked or not.
If you look in the reference section at the event list you will see that there are events numbered from 256 to 65535 that are labelled as 'user defined' - these are the numbers that you can use for these events. Needless to say these events are only ever triggered programmatically and the command for triggering them is mesg wrt+ - which takes various parameters. These can allow you to pass in a parameter to an event - which can used within the triggered event using the _p1_ and _p2_ variables.
A simple example would be a nectar transferal from a plant to an insect - the insect triggers the pollination event in the flower it touches, the flower then can pass a custom event back to the insect which also passes an amount of nectar which the insect keeps track of for it's own use.
Scripts are scheduled within the Creatures 2 executable and will be acted on in discrete slices, this can cause strange operations if you are not aware of the way they are ordered or know which scripts will interupt other scripts. As a basic rule of thumb it is helpful to know that timer scripts can be interupted by any other script, but will not interupt any scripts themselves. This means that you can set up a timer script as a kind of 'lifecycle' script and it will be modified whenever activations, collisions, pickups etc happen to the object concerned. A reason this is important is that if timer scripts were not interupted then response to collision or activations would only happen after a delay if the timer was running.
There exists a mechanism to prevent a script being interupted involving the lock and unlk commands. Care must be taken with these though because events that try to trigger while a locked script is running will be lost - they are not stacked up and executed when the locked script is finished. For example, if you try and lock an activate1 script and the object has a collision script that changes it's appearance as it hits the floor - if the object hits the floor while activating it will lose the collision event and not change appearance.