oosyrag's Forum Posts

  • Does idle left work? 0 degrees is usually to the right and 180 is left. Try disabling the angle conditions and see if it works.

  • Use a solid image instead of pieces? Looks like a pixel rounding issue.

  • I'm not absolutely sure about this one though - try it out with the built in sprite font and see if it makes a difference.

  • Have you tried with a sprite font instead of text? It may work better. From what I recall, the text object is particularly inefficient, such as when updating large amounts of text every tick. I assume transformations are the same.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You can use an instance variable, that contains the "type" or "state" of each instance of the sprite, which you can use to pick and apply specific events to. Then you would only need one sprite object.

  • If there are only fixed snap locations without other shapes or sizes, I would try using invisible helper sprites to snap to. You'll need two sets, one for triangles and one for squares, since the distance to the center of each is different. Set the helper sprite angle to the angle between itself and the object that created it (rounded).

    So placing a square would create 8 helper sprites, one for each square and triangle at each snap location. 6 helpers would be created for triangles. When placing a new shape, check only the correct helper type to snap to, and if it's close enough to snap then set the angle of the new shape based on the angle of the helper sprite it snapped to.

    Destroy any helpers that are already overlapping a shape.

    Edit: make sure your "connecting" flat edge is facing towards the right (0 degrees) for the triangle sprite

  • Are you trying to draw a line?

    Save the coordinates of touch in a variable at the end of each tick, and draw a line from those coordinates to the current coordinates. Draw the dots as well, to keep it smooth when changing directions.

  • You're probably using the wait action wrong.

    Do you have an "On signalling connected" trigger event to catch the successful connection?

    It would be useful if you showed your actual events.

  • If framerate independent mode isn't working for you (have you confirmed it is set properly?), you might consider using an alternative behavior. Many games don't need physics that can't be simulated with other behaviors, and if precision and consistency are priorities, it may be best to implement your own pseudo-physics.

  • Use the tween behavior.

  • You asked for an example equation. The equation is different depending on how you want to draw the arc at different distances.

  • It's more physics than math. You still need to describe in more detail the desired behavior. If the input value is the destination coordinates (instead of origin angle and velocity), would you want the resulting arc of travel have a static angle, velocity, or vertical height?

  • Aiming arcs are generally described from the origin to destination, one step at a time, rather than from a center point.

    The functions for the x and y components are x = horizontal velocity * time, and y = vertical velocity * gravity * time.

    The initial velocities can be found per angle by using sin and cos on the angle multiplied by a power value.

    Edit: sorry looks like your going for an isometric arc based on your screenshot. In that case, your x and y are both constant and you'll need to add a z component, which is affected by gravity. In effect, the z value is added to the y value to display "height". When z is equal to or less than 0 is when your projectile hits the "ground".

  • Objects can be added to multiple families. You shouldn't need to get rid of the old ones or consolidate variables.

  • Just wanted to chime in that it's usually a good idea to design your code so that order does not matter in json.