R0J0hound's Forum Posts

  • [quote:1nb3nvgu]Well that's too bad because it seems like the OnCollision Trigger "knows" there was a collision and must know where it is on the screen. Too bad it doesn't return or populate a system variable like: Sprite.OnActiveCollisionX and Sprite.OnActiveCollisionY

    It doesn't know where the collision occurred, it would have to be calculated in js in the same way as listed here.

    sqiddster

    A plugin could access the collision polygon. The physics, polygon and chipmunk already do internally. In just events you could place imagepoints in the places of the collision polygon points for a brute force way. Then you can do line intersections with:

    http://paulbourke.net/geometry/pointlineplane/

    I can find a capx where i've implemented it if needed. A plugin could be made to hide the complexity, but I don't enjoy the process of updating and fixing plugins currently.

  • Prominent

    Yeah, it looks like it's from the previous position. You can try adding these two lines to line#6528 :

    binstA.updateC2(binstA.body);

    binstB.updateC2(binstB.body);

    That should update the c2 object from it's physics body. I haven't tested it, so I don't know if it has any other side effects, because usually it's only done at the end of the tick. Looking at the function it may but I don't have the time to really analyze and debug it.

  • The fact the laser is growing fast or that the objects are moving is not really a problem. The same idea can be used. If the laser at any point overlaps the object, then in with a loop make the laser a little shorter until it's not overlapping the object. At that point the end of the laser is the collision point.

    Another way would be to do a raycast with math, which basically amounts to calculating the intersection points of the laser line and the edges of the object and keeping the closest intersection.

    You could also utilize the chipmunk behavior as it has some stuff built-in to get the collision point. Vanilla C2 collision detection only finds if two objects intersect, at no point is a collision point calculated so you'll have to use one of the above approaches.

  • Prominent

    I forget exactly where. Search for "poly" in the runtime.js for how I accessed it. It was basically mirroring what the built in physics behavior does. They both use some helper functions that are defined in commonjs.js. (I think that's the file, it's in the exporters/html5 folder).

    The functions allow you to get a list of the points that make up the collision polygon, but transformed to match layout coordinants. The sprite behavior may be another place to find the list of points.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Prominent

    The best way I can think of would be to create an object at each corner and use the "pick nearest" condition. You'll probably need to define the corners with imagepoints to do that.

  • In the simple case set a variable to the current time "on touch". Then you can get the duration of the touch from "is touching" with time-start_time.

  • One approach is to move the laser backwards until it's not overlapping the other object, then the end of the laser would be the collision point.

  • 1

    You can use random if you set it with events.

    2

    You can set the angle to the angle of motion by adding the action:

    Bullet: set angle to angle(0,0,self.vx,self.vy)

  • If you're setting the x every tick you're just overriding where the behavior moved the object. Behaviors are run before events.

  • For the first one you can do it with the bullet behavior and a negative gravity I think.

    The second one you'd have to use the custom movement behavior with a negative horizontal acceleration.

    Or you can do it with just events with and object "bullet" with instance variables vx and vy

    on space pressed

    --- player spawn bullet

    --- bullet: set vx to 100

    --- bullet: set vy to random(-20,20)

    every tick

    --- bullet: add -100*dt to vx

    --- bullet: set position to (self.x+self.vx*dt, self.y+self.vy*dt)

    ^-that's to do the second picture. Fiddle with it and you can make the bullets accelerate in the other directions.

  • This should do it I think.

    "energy" is the amount of energy to add

    "slot" is the selected weapon

    "num_full" is the number of weapons with full energy, so the loop knows when to stop. To make it work when you don't have some weapons just keep the weapons you don't have with full energy.

    variable slot=0
variable energy=10
variable num_full=0

Array.At(slot) + energy <= 100
---> set array at slot to Array.At(slot) + energy
---> set energy to 0
else
---> array: set at slot to 100
---> set energy to Array.At(slot) + energy -100
---> set num_full to 1

while
num_full<9
energy>0
------> set num_full to 0
--- array: for each x
------ array.curValue < 100
------ energy > 0
---------> set array at array.curX to Array.At(array.curX) + 1
---------> subtract 1 from energy
------ array.curValue = 100
---------> add 1 to num_full[/code:2dhud75g]

  • ghost As you probably have found the replace function in the event editor doesn't let you do that. The objects need to be the same type to do for it to work.

  • Sorry, I don't know what's amiss. Assuming my example is correct then yours should work if there is no typos.

  • pcfernandesjr

    Doesn't the original example do that too? Like alextro said it just positions the eggs where the player was a certain time in the past, so if the player stops they will all stack on him.

    I don't have a solution to keeping the eggs from stacking. I've tried stopping time advancement when the player doesn't move, but then the eggs are just frozen in space.

    One idea could be to think of the eggs as a chain attached to the player. So maybe leveraging the pin behavior to link them together and drop them with gravity and bounce them a bit.

  • I meant how the behavior actually moves the object. The two ways I can think of off hand would be either it calculates a distance and angle an repeatedly moves and decreases the distance, or it continuously moves toward a point at a constant speed. It doesn't matter either way since it just moves to a stationary point. It can't handle a moving point.

    One way you possibly could use the behavior would be to use the move to behavior to advance to the next node and then every tick manually rotate the square and use that equation to rotate the object with the square.