R0J0hound's Forum Posts

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 22 Sep, 2015
  • Quote

  delgado

  The behavior only does sorting when the game is run. For it to sort correctly the isometric size and z of the blocks need to be set correctly. If the blocks overlap in isometric space the sorting won't work right.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 22 Sep, 2015
  • Quote

  It looks like you need an action to set the audio volume from the variable. Volume is in decibels so you could convert a value 0-100 to decibels with this:

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 22 Sep, 2015
  • Quote

  Try this topic:

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 22 Sep, 2015
  • Quote

  This could help:

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 21 Sep, 2015
  • Quote

  Do a forum search for it. There have been a few discussions about it, a plugin to help with that type of game, and even a few examples here and there.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 21 Sep, 2015
  • Quote

  If you're using the wrapping behavior, then you'll want to do it with events for better accuracy.

  Maybe these will help:

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 21 Sep, 2015
  • Quote

  I was searching around and didn't you ask this before in a way?

  Anyway can't this problem be simplified further?

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

  Use a family to be able to pick two different instances and then just compare the distances between the two and then move them apart with the "move at angle" action if they're too close?

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 21 Sep, 2015
  • Quote

  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.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 21 Sep, 2015
  • Quote

  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.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 2

  • 21 Sep, 2015
  • Quote

  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.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 21 Sep, 2015
  • Quote

  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.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 21 Sep, 2015
  • Quote

  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.

• Try Construct 3

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

  Try Now Construct 3 users don't see these ads
• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 20 Sep, 2015
  • Quote

  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.

• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 19 Sep, 2015
  • Quote

  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.
• • R0J0hound
  • 
  • • Joined 15 Jun, 2009
    • 
    • 90 topics • 7,333 posts
  • 1

  • 17 Sep, 2015
  • Quote

  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.