Ashley's Forum Posts

  • Sorry, there's not much we can do about this: when you change the size of the object the engine has to destroy the physics body and create a new one in its place at the new size, and since the impulse was applied to the old object it gets lost. You don't need the physics behavior for the specific example in the .capx, but if you really do, try to use an object which stays the same size (or at least changes in single step jumps), and then have an object on top of it that gradually changes, so it has the same appearance.

  • This comes up regularly. I think even though it makes sense from the perspective of the engine, everyone actually expects that 'On destroyed' should not fire when changing layout, which also solves the problem of what to do when creating objects when ending a layout. So the next beta experimentally does not trigger "On destroyed" when changing layout. We'll see how it goes!

  • Thanks, fixed for the next beta.

  • The original .capx is now a 404 so closing as I cannot investigate it. However note that picking families does not also pick container instances (which is what I think newt was saying) for architectural and performance reasons. You can work around this by adding a condition to pick an instance with the same IID.

  • I can only reproduce on the current Chrome stable (43), but not Canary (45). Still I found a workaround so it should be fixed in the next build.

  • It seems to be working correctly, just that the player's position is one tick behind the platform. Is that the only issue you're seeing here?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You could still make it easier to deal with this type of bug report: it unnecessarily refers to paths that don't exist on my computer. This means I can't just open the .capx and press run to see the issue - I am forced to make changes, and that increases the chance I do something differently to you and don't reproduce the issue. I could not reproduce the problem with the file deleting, it deleted just fine after I made the changes for anything useful to happen. The audio-keeps-playing issue actually reproduces with a project file in Chrome so you didn't need NW.js, hard-coded paths or file deletion. Please take this seriously as I deal with a very large number of bug reports and it can really slow things down if bug reports take extra work to deal with. Anyway, the issue should be fixed for the next build.

  • Changed for the next build.

  • Windows 10 isn't out yet - the release date is set for July 29th.

    C2 should run just fine on Windows 10.

  • Should be fixed in the next beta.

  • Closing, please follow the bug report requirements when posting in the bugs forum.

  • Closing, a .capx is required, please read the bug report requirements.

  • Sorry, there's nothing we can do about this. We don't control the audio encoders, and if they hang then that needs to be fixed in the encoder. The AAC encoder has been a little problematic in the past but that one is built-in to Windows, so Microsoft need to fix it The workaround is just to pad some silence in to the audio file...

  • Can anyone still reproduce this in r206?

  • So there's a bug which makes v-sync choppy, but it's temporary and will be fixed. It's already fixed on Chrome 45 on desktop as far as I can tell - it solidly hits within 0.1ms of v-sync every frame. Hopefully the fix will make its way down to Crosswalk soon. I don't know why people seem to think that this kind of thing will be permanent.

    When users complain about performance and send us a .capx, about 80% of the time they are exceeding the hardware capabilities of the device. You probably have no idea of all the exotic sorts of tricks developers pull off to get weak mobile devices to perform well. Construct 2 makes it a lot easier to design games, but also easy to throw in tons of content that hit hardware limits.

    If you're worried about the file size overhead, note that is temporary too: Android 5+ has an auto-updating Chromium based webview for default Cordova apps which supports things like WebGL and Web Audio too. So if you target Android 5+ with Cordova you get no filesize overhead and as good a result as Crosswalk. Android versions update pretty slowly, but it's already about ~12% and will increase to a majority over the next year or so. Newer Android versions also correlate to newer more powerful hardware, so if you have a particularly demanding game it might actually be suitable to target Android 5+.

    Crosswalk is our wrapper for Android 4.x compatibility, and it really does provide by far the best results on those platforms.