R0J0hound's Forum Posts

  • Prominent

    I've been trying to think of a good solution to that. What's happening is this is the order things are run:

    1 update physics positions from c2

    2 run sim step. This is where pre and post collide are run.

    3 update c2 positions from physics.

    So the issue is the c2 positions aren't updated at that point.

    The quickest fix I may add is an action to update a object manually. But that's not ideal as intuitively it should be automatic.

    The ideal solution would be to only update when retrieving the object angle or position. The issue is there isn't a way to do this with c2.

    A third idea would be to update the c2 object every time the physics object moves. The issue with that is it may happen a lot per object so it will have an impact on performance.

    I'll have to give it some thought I think. In the meantime I may just do the first idea so performance won't needlessly suffer.

  • balsh

    That hack is what's refereed to as absolute isometric sorting, which as noted works if most of the blocks are on the same level and if they're mostly the same size.

    For the general case you'd need relative isometric sorting, which is done with a topological sort.

    I just posted a behavior that does that, or if you're interested in the logic behind it done with events, look at the iso_test2.capx in that topic.

  • Here's something that's been growing dust on my pc for over a year.

    Isometric Behavior

    https://www.dropbox.com/s/nmm5g3xlg0s0a ... 7.zip?dl=0

    It is a behavior that assists in z-sorting and motion of isometric objects.

    At a glance you can:

    * have the isometric positions calculated automatically from their positions in the editor.

    * set the isometric position

    * move in isometric by an offset

    * check for overlaps in isometric

    My main motivation was make the sorting faster.

    Without behavior:

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

    With behavior:

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

    But it also adds some nifty features like:

    * pushing out of other objects in isometric

    * positioning a shadow sprite below another

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

    To use:

    To be clear this only handles a 2:1 isometric view, so you'd need to make graphics accordingly.

    You need to specify the sizes of you sprite in isometric. For instance a 64x64 cube sprite would have an isometric size of 32x32x32. This is important otherwise things may not sort right.

    Also sorting will fail (not look right) if they overlap in isometric. So when making the levels or moving with events, you need to keep that in mind.

    There is also cases where it can't sort. Like noted here:

    http://bannalia.blogspot.de/2008/02/filmation-math.html

  • Something like this could work:

    global number prevX = 0

+-----------------------------------+
| for each enemy ordered by enemy.x |
+-----------------------------------+
    |-------------------------------+
    | system compare: loopindex > 0 | enemy: set x to prevX
    | enemy x < prevX + 32          |
    +-------------------------------+
    |-------------------------------+
    |                               | set prevX to enemy.X
    +-------------------------------+[/code:liwu97d1]

That takes the enemies left to right and keeps them at least 32 pixels apart.
For a game like yours you could handle the enemies left and right of the player separately so you'd push from the player.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • "Is there a way to make physics object don't fall through solid objects."

    Yes, you need to make them physics objects as well.

  • Update 2.3:

    +Added "on pre collide" trigger. This is triggered before a collision response occurs. [see note 1]

    +Added "ignore collision" action. This only does something under a pre collide trigger.

    mattb

    This allows for making a jumpthru behavior.

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

    note 1:

    From both "pre collide" and "post collide" you can access all the collision expressions, although the impact and KE ones aren't calculated till a post collide.

    Also both are subject to a limit in the chipmunk library where nothing can be added or removed form the simulation in them. This behavior works around that by delaying creation and deletion which works most of the time but is the cause of some of the latest bugs.

  • You may attempt to make the astar algorithm directly with events. I have made a few you can find. If you use connected nodes instead of a rectangular grid you can reduce the number of positions needed to compute through thus making it faster.

    You could also look at this:

    Basically you put down a bunch of sprites that you setup before hand with the directions to the next cell to get to any other cell. So all the paths are manually inputted before hand so the pathfinding takes no time at all. The only drawback is you'll want to keep the number of cells as low as possible to keep the amount of setup time down.

  • mattb

    I don't think so, at least I can't think of a way off hand.

  • If their hot spot is to the left you could do this:

    global number num=0

    sprite is on

    --- set num to sprite.pickedcount

    sprite is on

    for each sprite

    --- set x to 640/num*loopindex

  • How are you doing the ragdoll, as in how is it setup? Any answer depends on that.

  • Variables that are common to all types in a family don't become family variables. To make it a family variable you'd have to create another family variable with a different name, then go through your events and change them to ref the family var instead of the old one. Finally you can delete the old vars and rename the family one to what you want.

    Construct Classic kind of used the common variable idea instead, but it had issues.

    Not being able to add or remove stuff from objects or families with events is a design choice as it simplifies the number of bad situations to work around. Both for C2 itself and for the user.

    If you could, switching factions is one thing you could use it for, but even though it doesn't you can still do switching factions in a different way.

  • You could try this plugin:

    It probably can be used to do what you want.

    Or you could implement pathfinding in just events. Here's my latest attempt using a hex grid. It actually should work if you change the hexagons to squares and position them on a grid. You just need to tweak the collision polygon into a square with beveled corners so diagonal cells won't be used.

  • Aher0

    Here's the capx:

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

    The motion is jarring at times but the players run back and forth trying to kick the ball to their goal.

  • The idea should work. You can calculate the angle from the ball to the goal with the angle() expression and then calculate a position behind the ball to hit it to the goal with this:

    X+radius*cos(ang)

    Y+radius*sin(ang)

    This is basically all the trig you need for games. For x and y use the ball's position in this case.

    So with this you'd move to that position then to the ball. The next issue to address is the car can hit the ball accidentally when moving to that position. To fix it you'd need to move left or right of the ball first.

    At this point it becomes a bit tedious to describe but a picture would help a lot.

    Basically

    Angle2ball is from the player to the ball

    Angle2goal is from the ball to the goal

    If both angles are Within 90 degrees of each other then move to the point behind the ball

    Otherwise

    If clockwise go to left point

    If counterclockwise go to the right.

    I got it working in a capx but I can't post it for a day or so.

    Here are the points:

    Behind ball

    Ball.X+radius*cos(angle2goal+180)

    Ball.y+radius*sin(angle2goal+180)

    Left point. Right can be found by making 90 positive

    Ball.X+radius*cos(angle2ball-90)

    Ball.Y+radius*sin(angle2ball-90)

    The radius can be whatever looks good. Also I was able to get a more pleasing result by using 135 instead of 90 for the left and right points. I apologize this doesn't cover exactly how to make it work but it should be good enough to get the idea across.

  • Ah, true. I missed that forward momentum bit.