Ashley's Forum Posts

  • I think the source of confusion is events aren't really exactly like IF statements. The event "Sprite X < 500" does not work like "IF Sprite X < 500 THEN run actions", because that only tests a single Sprite instance. Conditions filter down instances. So it's more accurate to describe it as working like "FOR EACH Sprite IF Sprite X < 500 THEN run action (on that sprite)". The "for each" iterative aspect of conditions is essential to the way events work, but means it does not act like a normal single IF statement, so it's not always correct to compare it to that.

    In the example I gave, if you want an action to run on Sprite in that event, then you can only choose a Sprite that did not meet the condition. Therefore it makes it possible to run actions on instances that did *not* meet the conditions. I think this is totally counterintuitive and nonsensical, and although the current system may be sometimes confusing, the alternative is even worse.

  • Does this reproduce on Windows 7 or newer? You gave your OS as Vista, but AFAIK Chromium recently dropped support for XP and Vista.

  • I still don't understand why you would want to do that? The main use case for global layers is to avoid the "copy-paste instances in every layout" problem, what are you trying to do that needs that set of features? Also why can't you just create the global objects on a different layout and then have no instances on your global layer?

  • Construct 2 doesn't do anything special regarding context menus though, AFAIK - it attaches to the same events that Windows fires to all apps.

  • Which version of NW.js are you using?

  • Why would you want to copy the properties but not the instances? It sounds like you either want to make the layer not global, or leave it global and make the objects on it not global.

  • It's not a bug that negative acceleration allows particles to start going in reverse - it was intentional from the start - and someone somewhere probably needs it to do that. So we won't change the existing behavior.

  • Ah, yes, there was another case where changing layouts did not correctly take in to account the new layout size. This should be fixed in the next beta.

  • I can't reproduce any issue with the first .capx. It looks like it always works fine here.

    With the second (Kyatric's) .capx, it's just that mirror is a shortcut for negate width, and the sine behavior remembers the original size to oscillate from, which was a positive width. If you use "update initial state" before activating it, it then oscillates based on the negative width. However since it increases the width starting from a negative size, it ends up making it narrower instead of wider! You probably want to invert the magnitude as well there.

    This is all by design, closing as not a bug.

  • We have an iPad Air 2 running iOS 9.3.2, and I tried your demo in the Safari browser as it's the most convenient way to test. I refreshed 10 times and it worked fine every time. I also tried switching tabs and going to the home screen and returning, it always worked fine.

    What version of iOS is your iPad running? This sounds almost exactly like a past sample-rate/audio distortion bug we had with iOS. The bug was actually in iOS and not C2, so we could not directly fix it, but we found a workaround (which should be in place in r227) and reported the underlying issue to Apple. Apple fixed the underlying issue but I don't know if it's actually made it to the release versions of iOS, or if it has, which version it went in to.

    I'd add it's odd you use "is touching" followed by "trigger once" - that's the same as "on touched", and we have special provisions for the first "on touch" event that do things like unblock audio to work around iOS's restrictions. This is applied regardless of which events you have in C2, but I thought I'd mention it in case it does somehow affect it.

  • Thanks, good catch. Should be fixed in the next build.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

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