R0J0hound's Forum Posts

  • Set some text to Canvas.RgbaAt(350,120) and see what the color is at that spot.

  • Looking here:

    https://www.scirra.com/manual/29/object-type

    Couldn't you save a copy of sol.instances and sol.select_all to variables and then set the sol later?

  • If the comparison doesn't work, what is the value of rgbaAt()? What are the x and y values you're using? They do need to be integers as I recall.

  • While lerp() can be used for easing out, there's no way to do easing that way.

    The main way to use easing like that is this:

    about-the-new-interpolations_p787879?#p787879

    Although that's not really suitable for a moving target like yours.

    You could treat it a bit different by using angular speed. Basically just accelerate toward the target and decelerate to stop at the angle exactly.

    For that you could use this older example:

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

  • The two equations you need to calculate collision impulse are:

    Total momentum before = total momentum after

    m1*v1i + m2*v2i = m1*v1f + m2*v2f

    "i" means initial and "f" means final.

    We also need another equation so we can solve for the two unknowns (v1f and v2f). Since we want perfectly elastic collisions we can use:

    total kinetic energy before = total kinetic energy after

    0.5*m1*v1i^2 + 0.5*m2*v2i^2 = 0.5*m1*v1f^2 + 0.5*m2*v2f^2

    So with some algebra I was able to calculate it as:

    v1f = (v1i*(m1-m2) + 2*v2i*m2)/(m1+m2)

    v2f = (-v2i*(m1-m2) + 2*v1i*m1)/(m1+m2)

    Now those velocities are in only one dimension. For 2d collisions if we only need to consider the speeds along the normal between the two objects, which is still is one dimensional.

    So the steps would be:

    1. calculate the normal between the two objects.

    --- normalx=cos(angle from object1 to object2)

    --- normaly=sin(angle from object1 to object2)

    2. calculate v1i and v2i only in direction of the normal.

    --- v1i = normalx*object1.velocityx+normaly*object1.velocityy

    3. use the equations above to calculate v1f and v2f.

    4. apply v1f and v2f back onto the object's velocties.

    --- add normalx*(v1f-v1i) to object1 velocityx

    --- add normaly*(v1f-v1i) to object1 velocityy

    Working example:

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

    You can also incorporate a coefficient of restitution into the impulse equation so you can anything from a "perfectly elastic collision" to an "inelastic collision".

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • gogobotz

    When physics is concerned (this or the official physics behavior) it doesn't mix well with other movement behaviors. So to to have 8 direction with physics you'd need to do it all with physics.

  • Here's a simplified version. The units go around the wall when they collide with it. "Overlaps at offset" could be used to get the units to start avoiding prior to overlap. In the capx above i was checking for an overlap in the range from where the unit is to where it will be later.

    Sprites:

    "Wall"

    "Unit" with variables i, targety

    Events:

    Global number starty=240

    Start of layout

    --- unit: destroy

    Start of layout

    Repeat 10 times

    --- create unit at (0, starty)

    --- unit: set i to loopindex

    Every tick

    --- unit: set x to self.x + 100*dt

    --- unit: set targety to starty+(self.i-5)*16

    Wall: is overlapping unit

    Pick all unit

    ===unit: targety<wall.y

    --------unit: add -wall.height/2 to targety

    ===unit: targety>=wall.y

    --------unit: add wall.height/2 to targety

    Unit: y < self.targety

    --- unit: set y to self.y+100*dt

    Unit: y > self.targety

    --- unit: set y to self.y-100*dt

  • Try the bullet behavior with gravity instead. It would look the same only without collisions.

  • Here's one possible idea. When you create the objects calculate their spread out position, that will be the target position. Next see if the path from the current position to the target hits any walls. If it does shift all the targets up or down depending on if they're above or below the line. Finally move toward that target and repeat next frame.

    Here's a basic example that spreads units up and down around walls.

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

    Another idea would be to looking into boids or flocking behaviors.

  • I don't think you can, but I'm curious, why you need it? If it doesn't have the solid behavior and if you aren't checking for collisions with it in events then no collisions are checked with it.

  • This example here is applicable, although I forget if varying costs is implemented in it.

  • AllanR

    TELLES0808

    I'm glad it was useful and amusing to tinker with. I had fun making it.

    Concave terrain like that would cause the algorithm to run longer, but it's only an issue if pathfinding for all your ships ends up being too slow. A simple thing you could do is avoid concave terrain in your levels.

    Or if you're feeling ambitious you could reference this fun site for other pathfinding ideas.

    http://theory.stanford.edu/~amitp/GameProgramming/

    One thing I've done in the past is calculate the path over multiple frames instead of all at once. It helped spread out the pause when a large amount of nodes were used.

  • Any reason for using a corner of the hexagons instead of their centers?

    If done manually with events you'll use this for finding the path:

    https://en.wikipedia.org/wiki/A*_search_algorithm

    The difference between a hex grid and a rectangular grid is just how the neighboring grids are found. For simplicity collision detection can be used.

    Here's an example:

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

    /examples29/astar_hex.capx

    In it it defines a function "astar", which you call with two iids: a start and and end node. After the function the start node's node.next will be the uid of the next node in the path. This can then be repeatedly followed to the end node. For smooth motion you'll have to use the moveto behavior or devise your own method.

    Event #9 is where you control the cost to move to a node. Right now it uses the distance times the average of the node costs, but there's no reason you couldn't tweak it to be based on other factors.

  • tunepunk

    There is also redat, blueat, greenat and alphaat expressions to get individual components of color. That said, it only reads the color from the canvas object itself so you need to paste stuff first to read it's pixels.

  • Look here for a list with links: