Very Personal Conclusion on all this:

The "on bounce" condition is (i think) only recently added. patryk used it to solve this problem.

And after all, its probably the right solution today.

Although the "on bounce" condition is meant to over come the limitations with a ball behavior that only will bounce on solids.

Now you can choose witch object its bouncing from. And you can have 2 balls in the layout, each bouncing from different objects. Witch is very nice.

Do not understand me wrong, its a very useful condition.

But after all it is not solving the general problem.

Maybe, we need 2 Big Brother Loops. To solve this completely.

?

1 thats V-synced, and acting as it does now.

another 1 thats NOT v-synced, and keeps running trough the events to set flags for collision detections and triggers.

This will also make triggers finally really work as triggers.

Now i just hope that there is anyone understanding what i mean. Or anyone willing to ask questions and this way triggers me to explain till it is totally understandable, or accept that i am wrong.

You might think:

All this V-sync mummble and mamble is not influencing my .caps.

You might think again.

Allow me to show you something, starting out with this .cap.

Orginal it comes from this topic:

You can download it from both places. Fire it up and watch.

It will give a error about a sound not found, just click "ok" and it will run fine.

When i ran this .cap for the first time. I noticed the Ball is bouncing a little weird. And in a closer look, you can see that the ball is intruding the blocks and paddle with a few pixels. Also, sometimes the ball is jumping out the layout in closed areas, mostly in corners.

So i dived in the .cap. And i saw that patryk is using his own bouncing mechanism. And an event to bring the ball back in the layout when it escapes.

So asked him (assuming he's male): Why you do that for ?

And he answered me: If i dont do it this way, the sounds are not working.

And i slammed my own forehead, leaving a M mark. My question was rather dumb.

His solution to the problem is in fact elegant. Solution ? Ah yes, he worked around a problem.

Allow me to step back on his steps, and reproduce the problem.

download this.

unzip, and fire it up. Leaving the folder structure intact.

I modified his .cap this way.

1/ i made all the objects that are supposed to collide with the ball "Solid" in the groups/attributes properties. I deleted all actions/events from the .cap used to bounce the ball. Now all bounces are made due the build in bounce of the ball behavior.

2/ i added 2 sounds, since i dont have his original sound.

Run all, and notice that the events do not pick up any collision detection.

Not the collision detection to destroy the blocks.

Not the collision detections that should trigger the direct sound into playing a sound.

This is what he worked around.

But.

What is happening here ?

On my laptop it only runs 60 ticks / second. It runs all the events in 1/900 of a second, and in the remaining time its waiting for a V-sync.

Imagine the following situation.

You are babysitting 2 kids. You sit in the couch. And both kids sit at the other side of the table. Playing monopoly. You are supposed to monitor the kids behavior. Meaning. When one hits another (collides) you are supposed to yell "STOP IT" and punish the kid who started.

Now lets limit your eyes.

Imagine there is only one light bulb in the room. And its kinda working bad. Meaning: it burns 1 second to not work for the next 5 seconds. Light 1 second, dark for 5 seconds.

Thats is close to what happens with The Big brother Loop. While waiting for the V-pulse to happen, its blind to what happens in the events. BUT, the behaviors keep running and running, unattended.

Just like the kids behavior. After all they are kids, they tempt to fight. But, when they start fighting in a moment that the light is out, you have not seen it, you missed one hitting the other, you missed a collision.

To prove this,

download this .cap .. and fire it up

It is exactly the same .cap Only, in the application properties i disabled the V-sync.

Do NOT Be Attempted To Do this For Your Games. It brings Other Bigger Problems.

I dont know exactly what happens now. I do know that The Big Brother Loop now runs more times a second. But there is still some kind of V-sync, else i would have 10 balls on my screen, considering the speed this ball moves.

But yes i do know that it runs at more ticks / second. And at my computer now like 2/3 th of the collision detections actual get detected. That can be more or less on your computer, depending on the speed of your gpu and screen.

And i think i proved the connection between v-sync and the amount of ticks/second, and the connection between ticks/second and the cap working as expected or not working as expected.

So keep this in mind, its important.

:::

Guess this story is a never ending story. Yup i have to add something to this topic.

The follow .cap i stole from this topic. (i always misspell threat, so allow me to use 'topic' in stead )

You can download it from there, or pick it from this link.

Fire it up, and take a look at it.

I am only interested in the event numbers 2, 3 and 4.

Back then i saw the error in this. But i had no 'general' solution. With 'general' pointing to something that will work in all situations. I do now.

Lets first analyze the problem.

There are 3 objects in this project. Sprite, Sprite2 and Sprite3. Personal i do not like unnamed objects. But anywayz.

All 3 objects are member of the group 'blue".

So in events 2 .. 4. You see an attempt to set the gravity in the platform behavior for a certain object to zero, when the vectorY in its platform behavior is also zero.

This looks ok j0h! Whats your problem now again !???

Um, well, the syntax is right. And it does exactly what it is programmed to do.

Namely, when the object sprite's VectorY = zero, it will set the gravity in ALL objects that are member of the family Blue to zero.

And it does this in event 2 and 3 and 4, resulting in .. well i guess you can see that.

Do not laughs ! I have done those kinda things myself. I am dead serious ! ( lol well ).

Now lets upgrade this isolated little error to something 'general' to learn from.

The condition in event number 2 is a (what i call) Flow Condition. It runs its Sub Events and Actions when the condition is true.

But what we need here is a Pick Condition. In this case we need to take all the Blue objects, filter out those who's VectorY is not zero, and feed the left overs to the Sub Events and Actions.

Yep, its a Picking Objects situation, why its on its place in this topic.

We do have a small problem here though. The expression as used in the events in this .cap, can not be accessed using a Family.

Thats is not a bug or so, thats rather a very normal thing. Imagine an object having 2 platform behaviors. And at same time being member of a family with 10 other objects, who have only 1 platform behavior attached. Now when accessing the expressions trough the family name, witch VectorY shall the system take ? The one of the first behavior or the one of the second behavior ?

Anyway !

We need a good Pick Condition to make this work.

So lets convert *Flow* to *Pick*.

Let me show you in steps "how to".

Step 1.

Make a private variable in the objects.

Step2.

Use the "for each object" system loop to walk trough the objects and set the private variable to the Expression. (in this case that would be to the VectorY in the platform behavior)

It does not matter in what order the "for each" walks trough the objects, so do not worry about that.

Step3.

Now you can use the Pick Condition "Compare Private variable" to pick objects based on the stored expression.

Problem solved ! : )

You can see this work in this .cap

Hope this was a help.

all gone, do not worry no more

patryk ?

Can i use your .cap to illustrate a point that i would like to make in one of my other topics ?

plz ?

I have a error on the sound anyway.

Warning: failed to open resource file:

E:\Scirra\Construct\Projects\fongeso3\NextGen\odbicie.wav

This resource will not be exported!

But yes, i understand about the sound.

This is because collisions done by the behaviors often escape the little moment that the event is measuring.

Its like when, you try to take a picture of a bullet leaving a gun. There is more chance that the bullet is out of picture when u push the button, then in picture.

Ashley ? is there a way to not V-sync collision detections ? Would you plz consider this ?

Question ...

Why do you use the "bounce off" actions ?

The paddle by instance..

You have the ball behavior set to "bounce of solids"

if you set the paddle to solid in its groups/attributes properties ...

the ball will "auto bounce" from the paddle ...

and it will do this with a more natural angle ..

The last cap in this topic is this one.

But i did't manage to make all my targets.

[quote:3upt614e]including seizing there shapes a bit

At the moment i am a little frustrated, because, it looks like ....

Change the seize of an object in physics, will mess up its physics system.

Still hope i helped some one with writing all this.

...

ty so much

Conclusions:

When the Y velocity component = positive, then the object is falling.

When the Y velocity component = negative, then the object is climbing.

When the Y velocity is big, then it has more speed.

Smaller numbers indicate a lower speed.

When the Y Velocity is zero, then the object is in rest.

Well zero ? I rounded the numbers. Meaning, zero in this readings mean, a number between 0.5 and -0.5, since i rounded the numbers.

Take the round out the actions, and you will see that even when the object is in rest there is a small Y velocity component left. Will it ever be zero ? i dont know.

So lets test if an object with a 0.5 Y velocity still moves, can we tolerate that error ?

So set up a new direct X game. Add any object to the layout. Give it a Physics behavior. Dont switch the gravity on. Add an always in the events. Add an action to that, setting the Y velocity component to 0.5. And ? yes it moves. 0.5 is a to big an error. We will have to get around that.

And we will.

But lets start with what we learned already.

Positive numbers means to object goes up. Negative means it goes down.

Translated to events and actions that address this to the animations, go like this.

I left the events that make it all run over and over. Ignore the every 7 seconds event.

And i should have deleted the text boxes, sorry ? anyway.

The heart of it are event 3, 4 and 5.

In event 3, i make the For each loop. To store the Y velocity component in a private variable.

This done, i can pick the objects based on that private variable.

So in event 4, i pick every instance who's private variable 'Y_component' is negative. And in the action, that only acts on the objects picked, i bring up the right animation (in this case just a 1 frame animation).

And in event 5, i pick the instances who's 'Y_component' is positive. And those i let play the other animation in the action.

3 lines, to do something in fact very very complicated.

Run all.

Yes this works perfect. But i do notice also that i will have to think about the rest moments. Because the Y component comes close to zero in rest, but seems to have always a little number left, positive or negative. Based on how i see those animations change at the rest points.

Still we have like 1/3th of the mission accomplished. And that makes me happy enough for this moment.