R0J0hound's Recent Forum Activity

  • Looked in your file briefly. I don’t have a whole lot of feedback other than it’s very different than what I did in my capx.

    I tried to move all the logic in the click function. Yours has it multiple places.

    In mine it doesn’t refer to the mouse or touch at all in the click function. The idea is that function is called for every click xy. Can be modified for touch xy as stated in my previous reply.

    Sounds like you may just want to record the keys instead. Just the time a key changes to pressed from not pressed and vise versa. You wouldn’t have to worry about recording input then and you’d have more freedom with using any input events you like.

    Anyways, just some thoughts.

  • You can set the velocity in a specific direction with a bit of trig:

    Vx=100*cos(a)

    Vy=100*sin(a)

    You can also combine two velocities by adding them.

    Vx=100*cos(a)+100*cos(b)

    Vy=100*sin(a)+100*sin(b)

    Then to limit the max speed you can do this 

    Speed=distance(0,0,vx,vy)
If speed>maxSpeed then
— vx = vx/speed*maxSpeed
— vy = vy/speed*maxSpeed

  • You can set the velocity in a direction with

    a = angle(sprite.x, sprite.y, mouse.x, mouse.y)

    Set velocity to 100*cos(a), 100*sin(a)

    Impulse is more like adding to the velocity so that could be done with:

    Set velocity to sprite.platform.velocityX+100*cos(a), sprite.platform.velocityY+100*sin(a)

    Or something like that. I may have the names wrong.

    For either 100 is the strength of the impulse.

  • I mean you can fiddle with the collision more. It may work better if the ball has a box collision and isn't rotated at all. You can use the "set angle of motion" to let you shoot where you aim.

    If the bullet behavior's bounce still isn't acceptable you can use the physics behavior instead to move the ball. Give the tilemap and the ball the physics behavior, make the tilemap immovable, and when you launch the ball you'd set it's velocity with: 

    set velocity to (speed*cos(angle), speed*sin(angle))

    You may need to fiddle with some of the ball's physics properties to tune it. Stuff like collision shape and elasticity. You may need to disable collisions between balls or change the gravity with events.

    If that still isn't satisfactory you can calculate the surface normal of a collision and do the bounce with math. Here it bounces a perfect ball with a tilemap. This gives more control but isn't as simple to drop in.

    dropbox.com/s/r7ptcicrw0k753w/bounce_sdf.capx

  • I don't understand what you mean by multiple sprites. The capx records and plays back clicks.

    I guess touch would be slightly different but if you chnage it to touch it will work for multiple touches.

    Event 6

    Just use "on tap gesture" instead of "on click", and use "touch.x/y" instead of "mouse.x/y"

  • You could also change the bullet behavior property to not set the angle of the object when it’s moving. It would make the collisions more consistent.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There are the layertocanvas and canvasToLayer system expressions that may help there. At least when the object on the 3d layer has a zelevation of 0.

  • Changing the sprite size or changing the animation frame makes the physics object's shape get destroyed then recreated and that gets delayed till the end of the frame which makes it lose forces/velocity. It's either intentional or an oversight of not transferring the forces to the new object. It's been like that since the physics behavior was made so maybe a bug report could get that corrected.

    The mass property in construct's editor should be labeled as density. The area of the shape changes what the mass is.

  • You probably have to reach out to the developer of that addon since if it doesn't work when exporting it's something they have to correct:

    construct.net/en/construct-2/addons/410/simplethree/documentation

  • Here's one idea:

    dropbox.com/s/5qdydncdpj1c1jl/clickRecordPlayback.capx

    Basically have your touch/click events call a function and do all your click logic there. That way you can also just call that function when you want to simulate a click.

    The second part is recording and playing the clicks back. You'll need the time the click happened and where it happened (x,y). You'd then store that in an array.

    Anyways, you can look at the capx to see if that's something you can work with.

  • I think the default is mouse.x just grabs the bottom layer. I think it would be complicated for construct to automatically guess what layer to grab the position from or it may just be impossible most of the time to make a good guess.

  • You can use the enable/disable collisions action of the physics behavior to do that, at least somewhat.