Ashley's Recent Forum Activity

  • The touch plugin and drag&drop behaviors rely entirely on touch start/end events provided by the browser. In the past we've had a bunch of bugs with double touches which turn out to be bugs in the OS or browser layer. IIRC both Chrome on Android and Windows Phone have had issues with this, which were not C2 bugs, but bugs in the OS/browser incorrectly firing touch events. Another case was touches being "cancelled" but the event not firing for it. We can't fix any issues in the OS or browser, and if C2 gets the wrong touch events, after a while it can end up confused since it thinks there's a stack of touches piled up that never went away, or something like that. The C2 code already has mitigations to ignore duplicate touchstart events (e.g. if the browser fires "touchstart" twice in a row with the same touch ID), but it's impossible to mitigate bugs like duplicate touchstart events with different IDs, or missing touchend events.

    In short, the fact it works on almost all platforms is strong evidence C2's code is actually correct, and you're facing OS/browser/driver issues. I suspect the OS or driver, since Chrome has a pretty well-tested touch input engine, and presumably Chrome works fine on other devices.

    Your best bet would probably be to report Android bugs. Alternatively you could try to make a more minimal repro that demonstrates a problem immediately and I could see if we can work around it, but I suspect we cannot reproduce it without having the exact model of device in the office, and even if we had, the bug may not be possible to work around.

  • Sorry, it's not currently supported by the settings the Particles behavior provide. We could provide even more options, and there have been a bunch of other suggestions for similar tweaks, but I want to avoid making the Particles object look like the cockpit of a passenger jet. If you want customised behavior a good place to start is just creating lots of sprites with the Bullet behavior, which you can control however you like with events.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Closing as won't fix: while one way or the other may be technically correct according to English grammar, in programming some "inaccuracies" are actually quite common in order to refer more to the technical state rather than English prose. For example in programming it's common to have a function name like "SetIsVisible" (as in "set the 'is visible' flag"), even though "set is visible" is wrong or could mean something else. In C2 the action is meant in the context of "set visible [flag]" or "set [is] visible". I agree the contractions can look weird, but I won't rule out such style from C2, especially when action/condition names work best when they're as short as possible.

  • Closing as won't fix: see the manual entry's advice -

    [quote:2aozn49i]When using a light radius, avoid placing the light very close to or directly over a shadow caster. Shadows can fail to render correctly in these circumstances.

    The maths and algorithms behind shadow casting with a radius are pretty complex and radius-based lights very close to a caster is an extreme case requiring almost-infinite projection. The projection isn't actually infinite which can cause artefacts like this.

  • Closing as a feature request, not a bug.

  • Closing, please attach a .capx as per the bug report requirements.

  • Closing, please always attach a .capx as per the bug report requirements, which describe why we enforce this.

  • Families maintain different picked instances, by design. If you pick from one family and have actions for a different family, the actions will still apply to all instances.

  • I can't reproduce this without the TMX file you are using. Can you attach that?

  • Closing, please see the bug report guidelines, which also describe what to do if you don't want to share your .capx.

  • Closing, please see the bug report guidelines.

  • The pathfinding behavior cannot find paths outside the layout area, because that would imply an infinite sized pathfinding grid. So the whole area outside the layout is treated as obstacle. Are you sure it's not that?

    Otherwise the .capx has enough events it could just be an event mistake - if the pathfinding behavior really can't find a path to a certain area, surely you can reproduce that with a single "find path" action? Can you simplify the .capx at all to isolate the exact problem? It's also easier to understand the problem if you don't include any disabled events at all.

Ashley's avatar

Ashley

Online Now
Early Adopter

Member since 21 May, 2007
Last online 27 Oct, 2026

Twitter
Ashley has 1,832,431 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • 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
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x6
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x44
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs