R0J0hound's Recent Forum Activity

  • Not a bug, and actually your expected result is working correctly since +y is down, not up. Even that isn't a bug as that's a perfectly acceptable and is a very common convention used with computers.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • megatronx

    I guess it doesn't then. The solution would be to move it with physics instead of letting the pathfinder movement do it. You'll have to use the Sprite.pathfinding.nodexAt and nodeyat expressions to get the points along the path and come up with a way to move along it with physics. That way physics will be in full control of the object's motion and can keep the objects from overlapping.

    That's the idea at least. I don't have any working example.

  • Ok cool.

    The simplest idea would be to save the initial angles and positions of each part of the ragdoll and rotate and move each piece toward those initials when you want it to reset. You may even be able to get away with only using the initial angle. Here's the idea. You can replace the "every tick" with a condition to reset the ragdoll.

    Start of layout:

    --- sprite: set initialAngle to self.angle

    Every tick:

    --- sprite: rotate 100*dt degrees toward self.initialAngle

    A slightly more deluxe idea would be to save the initial angle difference between each body part and the other part it's connected to. It would probably give a more natural motion I imagine.

  • megatronx

    Probably the same way as with the physics behavior. All physics objects will push out of each other. I haven't tried it so I don't know if there is any fighting between the behaviors that might make the objects jitter.

  • kmsravindra

    Those two expressions were for use when adding joints. They aren't needed now since I since came up with a better solution.

    Basically what they do is this.

    "World" is just your standard xy coordinates on the layout.

    "Local" is just a position relative to an object's location and rotation. If you're familiar with 3d programs the idea is similar. For example a local position of (100, 0) will always be 100 pixels in front of wherever the sprite is facing.

  • kmsravindra

    You should be able to do it by scrolling to the object and settig the layout or layer angle to be the same as that object.

  • Prominent

    You're right that's what they do. I'll still want an action to update the object's c2 position or physics position for each other, but I need to do some refactoring, which is taking time, and i haven't been productive.

    Here's a slight breakdown of the limits of those triggers. Some of it can be fixed, but not all.

    pre step

    • can set forces here
    • setting position and angle is ignored here

    pre/post collide

    • setting forces is ignored here
    • setting position and angle is ignored here
    • position of objects aren't updated to correct locations at this point. The fix you linked only fixes this partially.

  • I'll be sure to reference that bit. However as I recall that's an incomplete fix that only updates the two objects connected to a joint. I'll try to come up with a list of the situations you'll need to update positions manually. Hopefully it's not too though.

  • 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.