oosyrag's Recent Forum Activity

  • Use a variable to keep track of the dashing state, then use that variable as a condition when colliding with an enemy.

  • Are you using it in an "On movement" triggered event, as specified in the manual?

  • I'm not very experienced with mesh deformation myself, but I imagine you could use some invisible helper objects with image points in place of bones to use as reference points for mesh deformation. It would probably still be significant work and math heavy since you don't have any built in inverse kinematic systems to assist in keeping everything connected and in place. I think we currently do have the tools to set up the necessary constraints, it would just be difficult.

    Either way from a visual design perspective splitting up a sprite into multiple individually deforming pieces is always going to give you a significantly superior result than trying to deform one large sprite.

  • I've done something similar before. The solution I settled with was to set imagepoints at every corner of a los blocker, the cast rays immediately before and after every corner in range. Then see if any rays collide with the object in question. The key is that you're casting rays at the obstacle corners, not the target object directly.

    Depending on the sizes (and distance) of the origin and target objects, you can further cull the rays cast by only checking the corners in a certain direction, within a set range of angles from the angle between origin and target.

    It ended up much more accurate and higher resolution with less rays cast than trying to cast rays every x degrees in all directions, and more reliable than casting rays at the object.

    An alternate solution could be to cast a fan of rays towards the target object, wide enough to envelop the object. If the target is a fairly square or round shape you could set the bounds of the fan based on the distance and width/height of the target, then cast x amount of rays based on the desired resolution (or by distance, since you probably want higher resolution the farther away the target is).

    Edit 3: For further (significant) optimization, first check to see if the target origin is in los directly before casting any additional rays at all.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Built in physics catapult example - editor.construct.net

  • First off, don't use waits in repeats.

    Repeats all happen in a single frame. Wait's don't delay events, only the actions following it.

    You can try using the fade behavior or tween behavior instead.

  • Divide n by 10^(l-s), where n is your original number, l is the length of your original number, and s is the number of significant figures you want your result to be.

    Round or floor the result, then divide again by 10^(d) where d is the number of digits you want after the decimal.

    You can use an expression to get l, which would be len(n), as long as n is a whole number.

  • No, a larger cell sizes requires less processing, but less resolution. For example if you make the cell size too large pathfinding might not be able to find a path through a small gap.

  • It's less about your viewport size and more about how much space you have between obstacles.

  • By default, an undefined cell contains a value of 0. Values outside of the array dimensions also result in 0.

    You can enter your own string or value that you don't plan on using otherwise to define an undefined cell, and compare values to look for your specified value/string.

    For example, in my game I wanted to differentiate between empty or out of bounds in my array. Since I did not plan to use negative values, I filled the array with -1 on start of layout. Then I could compare to see that -1 was empty, 0 was out of bounds, and anything else was a valid data value.

  • So it was just taking them a while to find a path? Consider doing something to ease the burden of the pathfinding algorithm. The A* algorithm should be very fast to the point it is unnoticeable on modern devices.

    Things like increasing your cell sizes or limiting the area and distance of pathfinding can do a lot for performance.

  • Is the delay happening when finding the path before the pathfinding path found triggers?

    You can visually fudge it by spawning them invisible, and enabling visibility on pathfinding path found.

    If they're still getting stuck after pathfinding path found and not moving, you might have some other events interfering with their movement or state.

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 39 followers

Trophy Case

  • 11-Year Club
  • 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
  • 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
  • Email Verified

Progress

21/44
How to earn trophies