Ashley's Forum Posts

  • I could not reproduce this on an iPad Air 2 running iOS 9.2.1, after building the Cordova export with PhoneGap Build. Could somebody else affected try PhoneGap Build as well? Perhaps it's something about the Intel XDK that is causing this.

  • I would, but I looked in to it and it's not a bug: when playing in the reverse part of the ping-pong animation, the animation speed is negative, indicating it is playing in reverse. By setting the speed to a positive value, you are continually forcing it to play forwards.

  • For further reading: Keyboard Ghosting explained

  • Closing as still not a bug, what I posted previously is true. We've had several reports like this in the past, researched it, and it is the keyboard hardware. The key combinations that work with three simultaneous presses are inconsistent: some do, some don't. Again, this is to do with the way common keyboard circuitry is designed. I think you can get some special keyboards that support more key combos, but they are expensive and few people have them. Like everyone else in the industry, you have to design games that only rely on two simultaneous key presses.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • IAP should be working on Android. Follow this guide for the full setup steps.

    I don't think Chrome Web Store or Amazon IAP support was ever more than experimental - when we originally introduced it we asked for testing feedback but never heard anything, so I assumed either nobody cared or it worked. (It's really hard to test these features with all the store configuration and publishing requirements.) I'll review the Chrome Web Store and Amazon IAP support in the coming builds.

  • Good catch - if the server is case-sensitive then the video path can mismatch. Should be fixed in the next build, thanks.

  • This is not a bug: it's actually due to a recent change in Chrome. Due to security concerns, some sensitive features like webcam, microphone and geolocation accesses now require a "secure browsing context". Typically this means HTTPS, but localhost also counts. I assume you are testing with preview-over-wifi with a URL like http://192.168.0.1:50000. The problem is since this is neither localhost nor HTTPS, Chrome treats it as insecure and blocks access to sensitive features. So any requests for sensitive features are immediately declined.

    If you publish your app to a HTTPS server, it should work again. However this makes testing more cumbersome. To raise this issue with the Chrome developers I filed this report suggesting that there be an option to disable these restrictions on private IPs, which would make testing easier.

  • This is a tricky case internally, but I think I've found a way to cover it. Should be working in the next build.

    • Post link icon

    I have to say, any method by which you try to forcibly shut down the leftover processes is an appalling hack, and could just open another can of worms (e.g. do all users have permission to use VBScript? Is it always installed? Are its dependencies the same as NW.js?), not to mention being a classic treat-the-symptoms solution rather than fixing the real problem. It would be far better to put effort in to finding a repro that could be submitted to the NW.js developers as I said in my previous post.

  • Well the fact it returns a blob: URL indicates the file picker is working and has chosen something. I think maybe it's just Android doesn't support loading images from files like that. I'm afraid it just sounds like Android doesn't support this combination of features - I'm not sure there's anything we can change in C2 to work around that.

  • I've changed the next build to return 0 in this case instead. Note the loading progress is not always guaranteed to be available, e.g. if the server does not provide the Content-Length header.

  • Closing as won't fix: it works correctly in Chrome for Android and Safari on iOS, which suggests the code in Construct 2 is correct. (Besides, it just forwards the information that the browser tells it about touches.) The Android stock browser is crap and not worth the trouble of trying to support and is rapidly falling out of use anyway as everyone switches to Chrome. As for Firefox, I can reproduce it there, but since I believe our code is correct since it works in more modern browsers, I think it's a Firefox bug that you should report to Mozilla.

  • Closing as won't fix. This is a known issue, but is impossible to completely resolve: you can use expressions to refer to layer names like "Layer" & index, where 'index' is only known at runtime. Therefore if you renamed Layer1 to SomethingElse1, it's impossible for the editor to know to update the reference to it. We could fix the cases where it updates the layer name if it's constant, but the dynamic names problem remains, so there will still be cases where it's broken.

    I think a better solution would be a new feature to find all references to a layer, so you can review events that use it before renaming.

  • Closing as not a bug. Most keyboard hardware lacks the circuitry to reliably detect more than two simultaneous key presses.

  • .capx link is invalid, closing.