Zamargo's Recent Forum Activity

  • 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?

  • After downloading update 388 I can't run any project made before 388. all previews of anything made before 388 don't even get to the loading screen, they just stay black.

    UPDATE: After some testing I found that any project trying to use the loading bar on the loading screen fails to load after 388 update.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

  • First under your start of layout actions make sure global setting: set world gravity action caps the gravity at 0 because we are doing top down.

    The regular driving should be apply force at angle for the angle that the car is facing and you should apply torque towards angle and add or subtract from the car's current angle to get your turn but keep an eye on angular velocity and angular dampening setting and change that when needed. Your steering should have to catch up to your facing angle. This is a pain to get right but also experiment with whether just rotating the object instead of using physics to rotate is better for you.

    A lot of these mechanics are going to be trial and error because the physics behavior isn't the easiest thing to suit to what we are doing here. Lots of things may require a constantly updated variable that you use inside your driving mechanics. Try some experimentation and update me on what part doesn't operate like a car.

  • 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

Zamargo's avatar

Zamargo

Member since 3 Jul, 2017

None one is following Zamargo yet!

Trophy Case

  • 7-Year Club
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

10/44
How to earn trophies