Lets Give the way of using a sensor in my last post a name.

And lets call it The Zombie Sensor.

It works, but it is not really aware, and the AI is brought by the player hitting the arrow keys.

Its a zombie sensor.

The next sensor i bring to you i call The Ghost Sensor.

(Nope Ashley, you can not upload in a reply, and i seem to annoy people when starting new posts)

The base for the Ghost Sensor is no more then just a copy of how the behaviors keep objects from intruding solids. So basically we just code our own behavior. But since we will have more control, we are not limited to only "solids".

Behaviors do this:

They memorize the objects position,

then they move the object,

then they check if the moved object is overlapping a solid,

if thats not true, they keep the new position of the object,

If there is indeed an overlapping with a solid, they will move the object back to the memorized position.

And this way, whatever shape the sprite has, the object will never be able to intrude a solid sprite.

This we can do ourself in Events. And even very simple.

So take up the starting layout, available in download on top of this post.

Since we not gonna use a "8 directions", we will need the mouse&keyboard object to code our own key related movements.

Add a new object to the layout, choose the mouse&keyboard object to add.

Go to the Events Editor.

There is already a "Start layout" event, let it just be there.

Add a new event.

step1: object = mousekeyboard

step2: condition = on key is down

step3: parameters = Up Arrow

finish

Add an action to this

step1: self = Sensor

step2: action = Set value

step3: parameters: add a new private variable "sX" / set the value to 0 (zero)

finish

Add a second action

step1: self = Sensor

step2: action = Set value

step3: parameters: add a new private variable "sY" / set the value to -2 (negative one)

Copy the this whole event tree 3 times.

Change the key's to right arrow, down arrow and left arrow. Change the values in the actions to.

for right arrow

sX = 2

sY= 0

for down arrow

sX = 0

sY = 2

for left arrow

sX= -2

sY= 0

When done with that, add a new event from the system flow "always"

add a sub event to this from the system flow "always"

add 2 actions to this,

where u set the object Sensor to "its self position" + "the private variables sX and sY"

You should know how to do this by now.

You can run it at this moment, to check up.

Temporal "invert the condition" that hides the Sensor in the "start layout" event.

add a second sub event to the top "always" of this event tree.

Make a collision that detects overlapping between the object Wall and the object Sensor.

Add an action to this that positions the Sensor to the DVD

(oh i forgot to rename the wall object to Wall, well then you do that)

Copy that event. And invert the condition.

Change the action in the copy to position the DVD to the Sensor.

Run all.

Thats all for the Ghost Sensor.

Its difficult to move the DVD into the middle maze ? Ah yes to do that it needs little adjustments.

But this type of Sensor, we will mostly use for objects moved by the computer.

So yes, this is the base for the Ghost Sensor.

The Events sheet should look like this.

<img src="http://usera.imagecave.com/j0h/tick/99_result.jpg">

note for Ashley: as you can see in my uploads i had to start this .cap over.

Is there a bug in saving a .cap under another name ? Making them corrupt ?

xx

...

Yup Ashley,

There is a Norm variable, and if one of conditions is met, there will be a new Norm.

Thats is correct.

Nope, lol, this is not gonna be a game. I am just diving and diving into "how to capture

behaviors by events", without missing even one collision.

Here is was looking for the optimal speed where the most of collisions made by a ball behavior get captured.

I expected the speed to go straight up. Then i would alter the ticks to find the optimal speed, expecting the speed would stabilize when changing the time window the event is checking in.

But i did not expect the speed to "wiggle" like this. Guess there is a Big Random part in what i try to measure.

And i do start to realize now that there is no optimal speed where the events make the most collision detections done by a ball behavior.

Sorry if u think i dont make sense, lol. Guess i start to write my beginners post about Ghost Sensors.

j0h

Why is the balls speed not gooing straight up ?

..

i am not "arty" but i am a video editor.

http://video.google.nl/videoplay?docid= ... 5267468424

This one won this years (2008) company video competition, although its low budget.

http://video.google.nl/videoplay?docid= ... 0&q=&hl=nl

this one was the official video for 175 year Belgium, done in 24 languages

http://video.google.nl/videoplay?docid= ... 4&q=&hl=nl

this i just made at home in my free time on my laptop

http://video.google.nl/videoplay?docid= ... 6&q=&hl=nl

done in 4 languages and low budget.

Yes i am one of the few editors left doing everything in a production,

video, grafics, and sound.

at the moment i have

1 cars TV program in Dutch every week

1 cars TV program in French every week

2 cars programs special for Fleet in dutch and french / month

1 program about Trucks every 3 months

1 item from the cars program

http://video.google.nl/videoplay?docid= ... 7733993997

and still do company movies during summer.

There is also a General Lesson to learn out of this.

Collision detection or overlap detection by events is limited to the moment in time they "tick".

And, on top, they are limited to Pixel coordinates.

To refresh.

The game runs 1 tick if it completed the whole events sheet 1 time. The time it takes to run 1 tick is of course depending on the speed of your computer and graphics card. But it will never be zero.

Lets assume an event sheet that runs 3 times a minute on your computer. (the slowest computer ever made) Lets assume the events sheet has 5 events.

Then one event runs every 20 seconds. (it ticks every 20 seconds) And lets assume the actions take 2 seconds to do there thing.

If this event is made out of an Collision detection condition, then the detection will be done Every 20 seconds during 2 seconds.

In other words, there will be no detection for 18 seconds, the remaining time the other events are ticking.

<img src="http://usera.imagecave.com/j0h/tick/timeFrame.jpg">

Thats 1 grid the events run in. Yes it is a time grid. Detections only get made when the event "ticks".

The other grid events run in are the Pixels. They are always Round. Events dont know a X position of 200,457. Place an object at 200,457 in an event and it will be placed at 200.

And the dimensions of 1 pixel is not zero. There dimensions depend on how big your screen is.

If the resolution of your screen is 1440 by 900, and your screen is 40 cm, then one pixel is 40 cm / 1440 = 0,3 mm / or 0.0118110236 inch. And that is not zero.

So events are limited by a time grid and by a position grid.

Behaviors do not have this limits at all.

In other words, an object moved by a behaviour ...

Who's position has to be tracked by an event, ..

Will a lot of time not be on the time grid that the event is checking on ..

and also not on the pixel grid the event is checking on.

Behaviors and Events RUN OUT OF SYNC.

There is a speed where the events always will pick the object moved by a behaviour.

How faster OR slower then this speed the object moves, how less chance the events have to pick it up.

To see this in action.

Scale the h1 ... h4 objects to 1 or even 2 pixels.

Place them on the grid in the corners

and run all.

there, thats all for this second.

Starting .cap is here.

The duck has a "8 direction" behaviour already.

Run all

Move the Duck with the Arrow Keys.

But, oh man, thats a totally drunk Duck.

Suppose we want its movement aligned with the grid for this maze ?

Huh ?

Lets move the paper roll aligned to the maze's grid in a quick event, to show you.

Give the Paper object a Bullet Behavior.

Be care full to not move the Paper,

if you accidental did, then move it back by giving it x = 480 and y = 400 in its common properties.

Notice the Green Box objects, named h1... h4.

They are placed strategical on points where the Paper will change direction.

There angles are according the direction the Paper will change to.

And look under the Group properties, and deeper the Families properties.

They have been given a family name Yellow.

You can give a group of objects a Family name, to call them by there family in the events.

Go to the Events Editor.

Add a system flow event "always"

Add a sub event to this ..

step1: object = Paper

step2: condition = Is overlapping another object

step3: parameters: Choose Yellow as object.

finish

Yellow is the family name we call all the h1 ...h4 objects with.

Add an action to this.

step1: self = Paper

Step2: action = set angle

Step3: parameters: Yellow.angle

finish

Run All

That paper has a nice move.

And our duck is still drunk.

This is then the limit of the "8 directions" ?

Ahhhhh, not yet. But yes almost.

Go back to the layout Editor.

Edit its grid to 80 by 80.

Click Toggle grid to make objects snap to the grid.

Select the most Bottom layer.

Add a box object. Name it Sensor

Give it height and a width of 80

place it somewhere on the grid, but not on a wall, and not in the middle.

The grid will snap it to a good place.

You can change its color and looks, but the initial values are ok for me

Delete the "8 directions" behavior on the Duck

Give Sensor an "8 directions" behavior.

Go to the Events Editor

Add a system "Always" flow condition.

Add a sub event with a system "always" condition.

Ad an action to this sub event.

Step1: self = duck

step2: action = set position to another object

step3: parameters : choose the object Sensor

finish

Run all.

Nice !

Although, The Duck is still drunk by 1 pixel.

And Because you see the Sensor, it is easy to move the duck, because your eye is using it as a guide.

Go to the layout editor.

Select the Sensor,

Try to find its "set invisible" properties.

Uhh, i dont know myself where it is. But

Go to the Events editor.

Make a new Event from the System "Start of layout" condition

Add a sub event "always"

Add a action to this sub event.

Step1: self = Sensor

Step2: Action = Set visible

Step3: parameter = Invisible

finish

Move the "Start of layout" events on top of the events sheet.

Run all

Move the duck Around a while, and notice that its a little more difficult to push it around the corners.

Also, and this is the end of the "8 directions" behavior.

What if i want the duck to move in the maze but only in one direction ? With no Returns?

What if i want the duck keep moving and let the player only alter its direction?

Its the limit of the "8 directions".

BUT it is the Born of the sensor principle. You just made your first Sensor.

And believe me, once its born, it sticks on you.

;;;

..

Here is the starting .cap

Lets forget the Square and bring in a real animated Sprite.

Adding animation is not the subject of this post, so i already added the animations.

You can see this when u select the Car thingy, and bring up "Animator" in the right Organizer Pane.

There Is One animation. With 4 sub animations, for each 90� angle of the object 1 sub animation.

When the object rotates, it will automatically play the right animation corresponding with its angle.

So add a "8 direction" behavior to the car thingy.

The walls are set "solid" already.

Run all.

Looks nice, but there are some culprits.

The car will go stuck in the bottom corners, and sometimes stick to the top edge.

From the last post we know that the behavior goes very well with Box shaped sprites.

Even when they are not square like our little car is.

Must have to do with the the way our car is sensing the walls.

Select the car, and change its collision method properties from "per pixel" to "Bounding Box"

Per pixel = every outer pixel will sense if it collides with a solid.

Setting this Method on "Bounding box", will use the the pixels that make up the bounding box of the sprite to sense collision with solids.

The bounding box has also the simple straight forward shape of the Box we used in previous post.

To see the bounding box, select the car in the layout, and there will be drawn a square around the sprite. Thats the bounding box.

Now its works perfect again.

Although, the way the car moves when bounded by the upper wall is silly. The head of the beast should move a few pixels over the wall. To have at least a little 3d feeling.

To do this, we need to make the bounding box smaller then the Sprite. But at the moment that is impossible in Construct.

There is no option to add "collision masks" to a sprite yet also. (version .95.3)

What now ? Stop using construct and wait till those things will be added ?

Nopes, no way.

The solutions is quite simple, and you will use it a LOT. Personal, for me there is no need to add "collision masks" to the program.

Lets get it going.