R0J0hound's Recent Forum Activity

  • —

    The plugin only does 2d physics so using z is not possible with the plugin.

  • Yeah that's what I meant. My ascii art failed. Also if you can make the ground out of slopes it would work better.

    Outside of that you could make your own platform movement with events. The most useful way would be moving the player completely with physics and not using the platform movement at all.

  • mattb

    One idea that may work is use a force on the object toward the base of the rope and just set the length as it gets closer. That may be more true to life where a force would be used to pull the rope in. You could also instead set the velocity of the object parallel to the rope as well, which would make the rope retract at a constant rate. For the latter you'll need this formula to get velocity along an angle:

    velocity at angle = vx*cos(ang) + vy*sin(ang)

    So given:

    ang= angle of rope

    and

    rope_vel

    We can set the velocity so the perpendicular velocity stays the same and the velocity along the rope is whatever value we want.

    perp_vel= vx*cos(ang+90) + vy*sin(ang+90)

    vx=rope_vel*cos(ang) + perp_vel*cos(ang+90)

    vy=rope_vel*sin(ang) + perp_vel*sin(ang+90)

    Then as with the first idea only set the rope length as the object moves closer.

    Edit:

    A third idea would be to set the maximum force of the joint so that the collision isn't as radical.

  • You can check if the xVelocity is between -1 and 1 with two conditions.

    Basically this:

    Sprite.Physics.velocityX > -1

    Sprite.Physics.velocityX < 1

    Now there are a lot of conditions that can be used to do this. A basic one is the system->compare condition. And if you want it to work with more than one instance of sprite add a "for each sprite" condition above the two conditions.

  • The pin behavior is run after the event sheet, so you either would have to wait till the next tick or position B with events before pasting.

  • That's by design. The size of the texture can't be changed as easily as c2's drawing surface. One reason is the texture is cleared whenever it is resized, another is it isn't always desirable to have the paster's resolution match screen pixels.

    Using digitalsoapbox's suggestion to use the "set resolution" action to the window size is the way to go to make resolution the same as screen pixels.

  • In the image editor the frog needs to be facing to the right. From your image it looks like it's facing up.

  • In my experience object sealing hasn't affected my code at all. Not sure if it's because it's not being done or something, but I'd say just go forward with your plugin and if you get to the point of it not working because of sealing then look for workarounds.

  • If you can re-work it so the walls don't move and you just change the scroll position then you won't need to update the obstacle map.

  • With the built-in physics behavior you can approximate the egg shape with an up to a 16 point collision polygon. The Center of mass defaults to the center of the object, but you can use torque with an imagepoint to make it seem like the center is in a different location. Not mathematically correct but it looks good.

  • It's by design. To make group variables like globals make then static.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • One idea is to change the collision polygons to have a bevel to round them out.

    So instead of the corners being this:

    ----*
    |
    |
    |[/code:1pixj20c]
They'd be this:
[code:1pixj20c]---*    *
    |
    |[/code:1pixj20c]

Another idea is to use the "overlapping at offset" condition to see if a wall is just a step and then move the player up.

right key down
player: wall to right
player: [NOT] overlapping SolidTile at offset (32, -1)
--- player: set y to self.y-1

Instead of -1 you could use a lower value to go up larger steps.  The approach will need some tweaking.