R0J0hound's Recent Forum Activity

  • As zenox said it mainly depends on the user. C2 makes a lot of things very easy, for things that aren't easy you can still do it with events in most cases. The SDK is nice and all but it isn't really necessary unless you want to interface with something outside of C2 like some js library that isn't covered by existing plugins. So most don't need to use it, as the event system can handle any logic you can devise.

  • Here's a capx for wall sliding with the 8dir behavior.

    https://www.dropbox.com/s/0ll7vaonp0h5w ... .capx?dl=0

    All it is is a superior way to push the player out of solids than what the behavior does by default. Well, actually solid isn't used so that we can handle collision response ourselves instead of letting the behavior do it. The player is treated as a circle (which solves your third image), and the walls are all rectangles. The algorithm just calculates the closest corner or edge on each wall and moves out in the opposite direction. The velocity isn't messed with and it appears to work well enough without doing that.

    It has no dependence on the 8 behavior so it could be used in other ways. All that it needs is a player sprite and box sprites for walls with four image points at the corners.

  • For orbits with physics you can do it using equations of actual orbiting. Some info and capx on it here:

    Basically you can do the gravity force with "newton's law of universal gravitation" and set the orbit by setting the velocity to a calculated "mean orbital speed" and set the direction to be perpendicular to the direction from the moon to the planet.

    Calculating the impulse to change directions may be doable, just your standard algebra problem, but it's probably simpler to just set the velocity directly.

  • I was pretty sure SAT isn't used in C2. Just checked and no it's not. It does the collision detection with either bounding box overlap tests, which are very fast or "line intersection" and "point in polygon" tests for polygons. Collisions are resolved in most (all except physics) behaviors using the runtime's pushout functions which basically are loops that check for an overlap, move a bit and check again until not overlapping. The function used to push out in the nearest direction uses a spiral scan pattern to find a free space.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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

R0J0hound's avatar

R0J0hound

Member since 15 Jun, 2009

Twitter
R0J0hound has 157 followers

Connect with R0J0hound

buymeacoffee.com

Trophy Case

  • 15-Year Club
  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

28/44
How to earn trophies