Ashley's Forum Posts

  • Sorry, I don't think there is anything we can do about this. If the browser loses focus then the browser does not fire the key up event. I think some native apps are affected by this too, as well as any other engine/framework running in a browser. It's more to do with how the OS deals out events to different apps.

  • If you have issues with Crosswalk, please report them. Intel have so far been very cooperative and receptive to issues. It's also a much better route to go for mobile exporting since it's based on a real browser engine and is highly compatible with (almost identical to, in fact) Chrome for Android. Its feature support is excellent, whereas non-browser engines like CocoonJS are probably never going to be able to support things like XML parsing, WebRTC multiplayer, form controls, and so on. Android 2.3 is down to about 13% marketshare right now, which I think is low enough to be worth disregarding for the far better compatibility of Crosswalk (as well as likely being available on more powerful devices which will perform better).

    I would re-emphasise that yes, despite PhoneGap being slow right now, it is hardware-accelerated with WebGL support and full JIT capability from Android L and iOS 8 which are both due out before the end of the year. So that is really the ultimate solution: they are real browser engines, and they don't come with the overhead of Crosswalk (particularly the ~17mb filesize overhead). We basically only need to wait for these versions to come out and gain wide marketshare and problem solved. We will likely even deprecate Ejecta at that point. Android does take a while to gain marketshare with the latest versions, but Crosswalk serves nicely to cover the ~85%+ of devices running Android 4.0+ until Android L support is widespread.

    With that on the horizon there's really no point researching other platforms, wrappers, or even native engines - good browser technology has finally reached native apps with iOS 8+ and Android L!

  • Are you sure this is a good idea? The manual updating seems like a good sanity check, since if you accidentally overwrote your assets folder with junk, Construct 2 would go ahead and junk up your project without asking.

    You can also already just use a folder project and have your artist directly overwrite the files in the project folder.

    Maybe a project-wide 'reimport all' button would be a good compromise?

  • Did you try scrolling around taking snapshots like OddConfection suggested?

  • I do not want to ship a built-in plugin for whom there is nobody officially maintaining it. We used to maintain the plugin, but Ludei repeatedly broke it and failed to provide any kind of guidance on how to update it, so we gave up and told them to maintain it. Then they released it on github for "the community to support" which we took to mean they were not interested in maintaining it either. On top of that, the version they released on github has been broken and is now incompatible with the one we ship with Construct 2: they mangled all the plugin IDs so old projects using the old plugin can no longer open with the new plugin - it will either fail to open or corrupt the project. They presumably did not read our documentation that states you cannot change the plugin IDs after release (link, "A number uniquely identifying this... saved to the project XML, so you may change the rest of the parameters after releasing your plugin, but not the id.").

    So updating the plugin means breaking lots of existing projects and having no clear owner for maintenance to address things like new features and bug reports, which there inevitably will be. This does not meet the quality bar that we set for official features.

    On top of that CocoonJS has various bugs and incompatibilities that Ludei have never fixed, despite my repeated attempts to contact them and guide them to solutions so users don't have to keep running in to the same old things (memory management being an excellent example of this). Overall users appear to be having a bad time with CocoonJS, and Ludei have made it almost impossible for us to easily support it, and this repeatedly reflects badly on us as well since it adds to the reputation that "mobile support doesn't work" (where Crosswalk and Ejecta ought to be working better). So at this point to be honest I am thinking more about deprecating support for it than making any motions to keep supporting it. Deprecating means the same thing as happened to the Intel AGI: it's hidden by default so new users are discouraged from going down that route, but for users who need to keep using it for existing projects (or have figured out a way through all the problems) can do so by right-clicking and showing the deprecated options. We'll work hard to get any bugs or missing features sorted out in Ejecta and Crosswalk. And with Android L and iOS 8 on the cusp of coming out in a couple of months, PhoneGap will be a great solution from then on too, which I think is the ultimate solution and allows us to get rid of this minefield of non-browser engines once and for all.

  • Closing, there is nothing we can possibly do in response to a bug report like this, please follow the guidelines.

  • Audio looping with a gap is a bug in Chrome.

  • brandonarmour - as per my previous post, still nothing I can do without a .capx and steps to reproduce!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Oh, so the problem is not actually to do with LastButton at all. It's firing 'On any button pressed' when moving the analog sticks. That is the real difference here, right? Since that's the only reason it's retrieving LastButton at all.

    It's still difficult to fix, because not all gamepads have a clear distinction between an axis and a button. For example the Xbox 360 controller has triggers at the back which are buttons, but return a continuous value from 0-100, like an axis. To support 'On trigger pressed' Construct 2 treats axes as buttons which are pressed by moving the axis past 50. Some browsers/platforms report them as buttons, and others as axes, so it's hard to tell exactly what physical control is being used. The analogs get the same treatment since it's hard to distinguish them from triggers in the code, so moving them down or right past 50 will fire 'On any button pressed' with the LastButton set to the index of the analog stick. I'm not sure we can fix this without breaking the triggers or other gamepad models, so I think this will be left as is.

  • Bug 1: I just cannot figure out what is going on here. I'm sure I remember it used to work, and IE11 has been through some updates recently, and perhaps they broke it... I can see in the debugger it's calling the function to request fullscreen, and IE just ignores it. No errors, no messages, just nothing happens. I could reproduce the same issue on Firefox for Android and Firefox OS so I'm not sure if it's something wrong with C2 or what, since it works correctly on Chrome desktop and Chrome for Android, and Firefox desktop. I submitted bugs to Microsoft and Mozilla to see what they make of it:

    https://connect.microsoft.com/IE/feedbackdetail/view/956312/ie11-silently-ignores-msrequestfullscreen

    https://bugzilla.mozilla.org/show_bug.cgi?id=1058700

    Bug 2: this won't be fixed - fullscreen 'off' is simply not supported in node-webkit, just choose a fullscreen mode (e.g. letterbox) and set the window size, the result is the same.

  • Closing, there is no bug here. The free edition does count groups, variables etc. as events towards the 100 limit, even though the editor only numbers event blocks. Please also follow the bug report guidelines when reporting bugs - the original post includes 70-80 events, which is too many to prove it's a C2 bug and not just a mistake in your own events, which is why we ask for absolutely bare minimum reproduction .capx files only.

  • Closing, please only report bugs with the latest version of Construct 2, and we do not investigate bugs where you combine the Physics behavior with another movement behavior since it is documented that this will not work well.

  • Looks like a node-webkit bug. Reported here: https://github.com/rogerwang/node-webkit/issues/2250

    Closing since the issue will now be dealt with on the node-webkit tracker.

    Please always follow the bug report guidelines without exception. This post would have been closed without investigation if you had not followed up with the .capx that demonstrates the problem.

  • Closing, followed this up by email.

  • Closing, please don't use bug reports for support requests. Please always follow all the bug report guidelines since they help eliminate the possibility the events are wrong (e.g. making a minimal .capx).