R0J0hound's Recent Forum Activity

  • tgeorgemihai

    I think the jump is related to how the behavior finds the closest free spot to resolve a collision. It does checks in kind of a spiral at times from what I understand, which is decent for arbitrary object collisions but not so much when hitting a flat wall it would seem.

    I can't think of any solutions offhand to fix the little jumps other than just implementing the movement from scratch to have more control.

    Here's my go at it that works similar to the platform behavior but only works with un-rotated boxes.

    The cyan box is the one done with events and the grey one is the platform behavior for comparison.

    https://dl.dropboxusercontent.com/u/542 ... _plat.capx

    The basic loop is

    1. move with any platforms the player is known to be on

    2. move based on controls and based on what sides of the player is blocked

    3. resolve collisions by moving the player box out the closest direction of the wall boxes.

    4. mark the walls the player has around him and stop velocity in those directions.

    It does have room for improvement, like anything, but it works ok. The cases when the player gets trapped will need to be handled.

    Edit:

    For the sine behavior you can find the distance moved by adding two variables ox and oy to the object and then in "on created" and an every tick at the bottom of the event sheet set ox and oy to the object's x an y. The the x and y distance moved would be x-ox and y-oy respectfully.

  • system: pick random instance of sprite2

    --- sprite: set position to sprite2

  • You can do it with a sprite that has a hotspot at it's left. Then you can position it to (x0,y0), set it's angle toward (x1,y1) and set it's width to distance(x0,y0,x1,y1). The height of the sprite is the thickness of the line.

    An example that does this is here:

    Another idea is to use the canvas plugin which has an action to draw a line.

  • Those things can be done by adding some conditions to check if lives=0 and such.

    Look at this tutorial, it will help you get the concept down.

    https://www.scirra.com/tutorials/37/beg ... onstruct-2

  • Your formula is wrong. You have this:

    Self.iniy-JumpStrengh_green*(time-Self.time)+Gravity_green*(time-Self.time)^2[/code:19hjq2f2]
    
    You forgot the 0.5*.
    [code:19hjq2f2]Self.iniy-JumpStrengh_green*(time-Self.time)+0.5*Gravity_green*(time-Self.time)^2[/code:19hjq2f2]
    
    [code:19hjq2f2]y = y_initial + y_velocity_initial*time + 0.5*acceleration*time^2[/code:19hjq2f2]
    
    After that it will still differ in height with the platform behavior, a little.  Yours will give the same jump height regardless of the framerate, but the platform behavior will vary a little.
    
    This is basically how the platform behavior does the y motion:
    every tick:
    --- add gravity*dt to vy
    --- set y to self.y + vy*dt
    
    In order for it to be truly framerate independent it would need an extra term:
    every tick:
    --- add gravity*dt to vy
    --- set y to self.y + vy*dt + 0.5*gravity*dt^2
    
    It's not as simple a change as that when I looked in the platform behavior's source, but that's the general idea.
  • It probably can, since it just corrects the object's positions when they do overlap.

  • This topic has a few ideas

  • At any given moment a object has a position (x,y) and a velocity (vx,vy). Using a formula like rate*time=distance, you can guess what an object's position in the future will be: (x+vx*t, y+vy*t), where t is the number of seconds in the future. If the object's velocity does not change then the guess will be 100% correct.

    So checking in the future just means to move the objects to where they will be, check for overlaps, and then move them back.

    For formations each object has it's own goal, which is pretty straightforward.

    Collision response is what will allow units to not walk over each other or not walk over the walls.

    For units this is done by finding the distance between each pair of units and just move each away from each other if they are two close.

    For units against walls you find the distance to each side of the wall and use the closest side to push away from. This distance calculation is the distance from a line to a point, which is different from the distance from a point to a point.

    /examples26/simple_pathfind2.capx

    https://www.dropbox.com/s/lxzh1lizunezw ... .capx?dl=1

  • leandronw

    Webgl speed is not so good with this, since it has to copy the texture to vram every time it changes (internal issue).

    Different size circles is trivial, but for different color circles you mainly have these options:

    1. Use this plugin to draw the circles using any color. You'd be only drawing to this so if you clear it to transparent you can have anything underneath show just fine.

    2. A second option could be to use the paster object which is similar to the canvas object, but was made with webgl in mind. It doesn't draw circles but it does allow making any color. So you could do some clever things with blend modes, a circle sprite, and the paste action.

    3. You could use a white circle sprite with the tint effect. This by far would be the simplest.

    4. As a last resort you could just use a lot of animation frames with different colors.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • There are two plugins for that here:

    One pay for, one free. look in their topics for use.

  • I've done this before by using a large sprite with the dragDrop behavior to move it, as well as the pin behavior for the other sprites to attach them.

    Then also one or two events to limit how far you can drag the sprite. Something like

    Sprite x < 0

    --- set sprite x to 0

    Sprite x > 640

    --- set sprite x to 640

  • Probably not exactly what you want but you can make multi-line comments by using shift-enter.