Ashley's Forum Posts

  • I can't reproduce this on a Nexus 9 (Android). Are you sure the iPhone 6S hardware supports multiple force touches? I've not seen any references indicating multitouch works with force touch simultaneously, especially since it's awkward to force-touch with one finger and then use another finger to do a separate touch somewhere else. So it might just be that this is not a feature of the device!

  • Should be fixed in the next build.

  • This is tricky to work around - if you type on the comment box on this page, you can still select its text sometimes by dragging from outside the textbox. It even seems to focus the control sometimes, even though the click started outside the control. This kind of browser-default behavior is tricky to correctly disable: if you just say "disable mouse moves", then you can't select text at all inside the control, but trying to define how to say "disable when the click did not originate from this control" requires app-wide pointer tracking with support for mouse, touch and pointer events for cross-browser support, and co-operation between different plugins that need this kind of feature. So it's actually pretty complicated.

    I think it's a fairly minor issue that is easy to workaround with that event, but I'll leave the report open in case future refactoring of the runtime can resolve this.

  • This appears to be a bug in Chrome. Star this report to follow updates: https://code.google.com/p/chromium/issues/detail?id=518863

    I think I found a workaround which I've integrated in to the next build: it will play a silent sound every 25 seconds, to avoid the 30 seconds of silence detection which seems to shut down Web Audio. It seems to work here, but I'm not sure if it covers every possible case. Anyway, star the issue and hopefully Google will fix the real problem soon.

  • Thanks, 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

  • This is a variant of "Expecting math calculations to be exact" in common mis-used events and gotchas. R0J0hound is right that you are running in to the precision limits of floating point numbers on computers, so closing as won't fix.

    You only need to hold down W for a short while to get 100,000,000 pixels away. Internally the engine stores positions as double-precision floats, which have integer precision up to 2^53 (= 9007199254740992). However for performance reasons the renderer uses single-precision floats, since this uses half the memory bandwidth, is faster to process, and is still perfectly suitable for virtually all realistic uses. This means when it comes to draw the object it only has integer precision up to 2^23, which is 8,388,608. Basically beyond that point there will be rounding due to the limited precision, and the further you go the more severe the rounding is, which appears as the object shaking as it goes further.

    Making the renderer use full double-precision floats would cause all games to take a performance hit. This is a really extreme example which it should be easy to work around: you don't really need to move the object that far, you can do a lot with just faking it (e.g. not actually scrolling but showing stars in the background shooting past really fast, or something similar). As far as I can tell from a quick glance at the source, CC also used single-precision floats in its renderer, so ought to be subject to the same problem, but maybe I forgot some aspect of the renderer that uses better precision. CC is officially retired and hasn't been updated for years though, so I would say don't even consider it!

  • Closing, review the bug report guidelines on how to provide a useful .capx that you can share.

  • Gah, more Firefox ridiculousness. It should be fixed in the next build to not throw an error, but it still won't be able to store or load savegames.

  • Closing as does not reproduce in r219 with NW.js 0.13.0-beta2. Alt+Enter does nothing there, so presumably this was a NW.js issue that was fixed.

  • This is currently by design. I will leave this report open as a feature request.

  • Can't reproduce in the latest NW.js 0.13.0-beta2. Can you confirm if it still happens there for you?

  • Closing as not a bug. You are missing an "Else" condition in event 3. As it stands, event 4 (else, meaning "slider value is not < 2") will always run when the slider value is >= 2, overriding the "Slider value > 5" event. You probably intended to have an else-if chain, as in:

    Slider value > 5

    -> "greater than 5"

    Else [ <-- this was missing in your .capx]

    Slider value < 2

    -> "less than 2"

    Else

    -> "in between"

    This works correctly.

  • Should be fixed for the next build. Please always make an effort to fill out as much of the bug guidelines as possible.

  • I actually managed to reproduce this in the end on alpha7: if you choose the "reload app" option it permanently breaks the app! It appears to corrupt the app data, which you can fix by going to AppData\Local and deleting the folder with the name of the project, or renaming the project (so it uses a different folder). I just released beta2 though and I can't reproduce there, so I guess it was an NW.js issue that was fixed. Can you confirm it does not happen again in beta2?

  • Do you mean an instance of an object from the C2 engine? Passing around UIDs is the typical way to do that.