Ashley's Forum Posts

  • shinkan - ha, kudos for referencing a 6-year old thread from 2008... I think the forum was only set up shortly before that! "nobody talks about us in 'real life', heh" - lol, hopefully that has changed now (That was way back in the Construct Classic days, nostalgia...)

  • This is very good news! It should bring a substantial performance boost to iOS devices, and should mean we can finally get rid of non-browser "wrappers" like CocoonJS and Ejecta completely, and move to WebGL-accelerated PhoneGap with a real browser engine and no annoying compatibility problems. With Crosswalk covering the Android side things should be looking pretty good by the end of the year...

  • Ldk - it looks like it's working fine here, what's the problem exactly? I noticed you accidentally have the platform behavior on both objects which is wrong and might be confusing you in the debugger.

  • The button appears for me in the Crosswalk player app in preview-over-wifi, but pressing the button navigates to Twitter inside the app itself, replacing the game. That's not very helpful. I've tried hacking it to open a window the same way the Browser object does, but the Twitter API does something different that I can't figure out.

    I think the easiest thing to do is just make your own ordinary button and use the Browser object's 'Open URL' action to open your feed's page on Twitter so the user can do whatever they want from there.

  • I can't reproduce on an iPhone 4S with iOS 7.1. I can actually see it cuts off the bottom slightly on an iPad 2 with iOS 7.1, but it's not a Construct 2 problem, it's just Safari on iOS has a stupid viewport. It's working correctly based on the viewport information iOS gives it, but iOS gives it the wrong viewport size. You can actually scroll your example up a bit and see that the canvas can be positioned to appear slightly underneath the address bar (which is semitransparent), which I guess throws it off. I don't know what we can really do about this, iOS has had a stupid viewport system since iOS 7.0 and they keep tweaking it and breaking it. I think this has to be closed as won't fix, workaround it by not putting anything important very close to the top/bottom, and ask Apple to fix their viewport :-\</p>

  • Can't reproduce, closing as must be a system configuration issue with that particular machine.

  • You do not have permission to view this post

  • Closing, please follow the bug report guidelines.

  • Closing as not a bug. The landing animation has the origin in a different place, which causes it to bump up and down when it lands confusing the movement as to whether it's in the air or on the floor. You should use a single rectangular non-animated object with the platform behavior as described in this tutorial, and place any animating objects on top of it to ensure this problem does not occur.

  • Closing as duplicate of https://www.scirra.com/forum/pixel-art-issues-after-exporting_t106142, verified the next build appears to fix it.

  • Closing as won't fix. I'm afraid the pathfinding behavior only guarantees that the object ends up in the right cell, and not pixel perfectly.

  • Closing as it appears fixed in the next build (direct export of your .capx here: http://www.scirra.com/labs/runnertest/, works in Chrome/Android and Safari/iOS 7.1). I haven't changed anything specifically for this but I think it was related to the spritesheet off-by-one bug in exporting, which probably threw off mobile browsers for some reason.

  • 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: since you use 'move at angle' and the 8 direction behavior, you are causing a conflict. Setting the position effectively teleports the object, and then the 8 direction behavior notices it has been wedged inside a solid without knowing how it got there. This causes it to use a last-ditch "get me out of here" algorithm which happens to use a spiral search for the nearest free space, which in this cause causes it to move both up and right. Workaround: use 'simulate control left' instead and it works correctly, since the 8 direction behavior then controls the movement, knows where it came from, and can handle the collision correctly.

  • Memory management got merged in to the main Ejecta project, so try it from there instead of my fork. It should be working already.

  • Without a .capx and steps to reproduce I feel this is likely caused by either a syntax error in a third party plugin, which causes an error in the minifier, or just the wrong Java version is installed. (You need the 64-bit version if you have the 64-bit version of Construct 2, and the website often guides you to the 32-bit version.) Closing, please make a separate report following all the guidelines (.capx and steps to reproduce + your java version) if you still have a problem.