Never even thought of that! Was originally suspicious I was missing certain features because I checkboxed a "simplified" editor thing in settings once during trial and error. Good to know this is not the case, thanks for your reply.

Anyone have any idea why conditions like "Supports multiplayer" have to be copied and pasted from another project and don't show up in my list of conditions from my editor?

you should create a debug text:

Create a layer on top for GUI with a parallax of 0% x 0%, place a text object there and at the end of your events put

system>every 0.1 second condition

and action

of set text with the text object

Set the text to something like "VelocityX: " & ball.physics.xvelocity & newline & "VelocityY: " ball.physics.yvelocity

This will allow you to see exactly what cutoff point you want to force the object to sleep because you only want to take away a settling bounce, which should have a different velocity level of any kind of bump from moving along regularly.

Eliminate anti-settle when torque:

Since you are moving using torque you might want to add that to your debug info list because you won't be trying to force a settle if the ball is still rotating.

Slow motion for debug if needed:

do a start of layout events set time scale if needed to put the project into slow motion. Then with our anti-settling events disabled (D in editor while highlighted) try letting the ball settle in slow motion and picking the degree at which you want to cut it off at to still allow regular bumps from movement.

Isolate Y Velocity:

A suggestion is that you are really fighting gravity here so no point in really taking into consideration X Velocity so you might want to single out Y velocity for this one.

Remember that both the ball and the bricks have a friction and mass, you can raise the friction to the point where there is no bounce so there should be a middle ground. Try raising the friction to a higher amount for an easy fix.

OR

When the ball and the bricks collide try an event that says "If velocityX + velocityy is less than 40" then ball velocity X = ball velocity X / 2 (halved) and the same for Y in another event. That will severely drain the ball of it's velocity when you approach the settling that you are trying to get rid of. Raise the number higher than 2 if this isn't enough.

Also if you want when the screen is touched you can position a sprite to the touch with a scrollto behavior and just turn scrollto behavior on when the touch is active and off when the touch is released.

Well the basic idea is when a touch begins you mark the coordinates on a variable(StartTouchX,StartTouchY) and the starting screen position(ScrollStartX,ScrollStartY) on another variable, then you take the current coordinates that the touch is at and the difference between the two are used in a system scrollto action to place the camera at a different position.

If you already have a scrollto behavior on an object or anything else conflicting with this camera position they will be battling each other.

The ball should settle into place naturally by using the physics object and you can set the friction and mass inside the properties of the physics behavior. I think the problem must lie in the movement logic somewhere that is competing with the physics behaviors ability to settle. May I ask how this ball gets into motion and if you modify the motion after that point?

In the conditions for an event put all these conditions:

Disposable is overlapping trashcan

Icon Is Overlapping Trashcan

And for the action to that event put:

Icon set visibility to false

(Because you referred to the icon overlapping the trash can in the condition it should pick the proper icon for that trashcan.)

Then to make sure this is only when we are over the can the next condition is:

(X) Disposable is overlapping trashcan (press I to inverse condition to have red X)

Icon Is Overlapping Trashcan

Then the action is:

Icon set visibility to true

Hope this helps!

The issue is that using the default car behavior comes with it's own collision with a solid object. So even if you did temporarily turn off car and on physics and then transfer the calculated velocity and turn off physics and back on with the car the rotation would still take you manually applying it using variable to keep track of rotational torque. You can't have two collision deciding behaviors on at the same time.

The fix I chose for this was to ditch the car behavior entirely and use physics behavior only and manually create the car movement. The only thing different than basic movement will be the car movement angle has to catch up to the direction your pointing, which is no big deal, in fact this is the only way to pull a 180 and drive backwards kind of technique as well because the max drift is like 90 degrees with default car behavior meaning it doesn't have a smooth in-motion method of transitioning between forward and backwards movement.

Here is an example of what you are talking about that was posted in the tutorial section.

https://construct-static.com/tutorials/downloads/24500/touchscroll.capx