Ashley's Forum Posts

  • If we made these changes it would basically regress the built-in functions to the old design, which people asked us to change for good reasons.

    For example people got annoyed that renaming a function was difficult because you had to update a bunch of strings everywhere. The new functions system fixes this, and function mapping is specifically designed to de-couple the string from the function, so that you can always rename functions without having to update a bunch of strings too. You call it redundancy, but actually it's to improve refactoring, which was a major user request. If we go back to referring functions by name, we regress back to renaming functions sometimes breaking your project, which re-creates the whole problem we were trying to fix in the first place.

    As for accessing parameter counts and parameters by index, adding this would also regress the usability of functions in various ways. For example with built-in functions you can refer to parameters by their name - another top request. If we add indexed parameters we regress back to unnamed parameters, which is what we were trying to fix in the first place. It could also cause refactoring problems as well - for example with built-in functions you can just drag and drop parameters and the entire project updates automatically (something that was also previously involved a lot of manual work to update); if you can refer to parameters by their index, this re-creates the original problem that reordering parameters can break your project unless you do a bunch of manual work.

    If there are still shortcomings I'd really want to fix them without recreating the original problems! For example with variable numbers of parameters, some languages do not allow this at all. Instead you can do things like pass arrays. In Construct you could already use an Array object to set a variable amount of data in which then gets used by the function. So I think there are already ways to handle this, you just need a different set of techniques. If that still doesn't cut it for whatever reason, then I would want to think about a better design that isn't going to bring up the same problems and cause the same feature requests of "please fix this problem" that we already dealt with.

  • You can already change the spritefont color without needing to use other spritefonts. Use a white spritefont and use BBcode to change the color.

  • Please keep things on the feature suggestion platform, ideas in the forum will get lost. Sometimes ideas get caught by the spam filter so they don't immediately appear; if you let us know they can be approved.

  • It's complicated to make it work for user scripts. Getting it working again is on the todo list.

  • Very frequently the problem people have is they have misconfigured something, and then blame the plugin or Construct. We regularly help people get it working again by making sure they've done things like use the right IDs in the right places.

    There have been some bugs which really were in Construct. We do work hard to make sure these are resolved. However some issues are particularly difficult - the issue you linked to is tagged "difficult", but it also looks like it only happens in a specific set of circumstances, so it should not block other uses of the feature. We are a tiny team dealing with thousands of bug reports; please be patient, sometimes we need a bit more time to sort the thornier issues out.

  • NW.js only supports open media codecs like WebM VP8/VP9 or Ogg Theora. You will need to transcode your video in to one of these formats. This is not a bug and is actually explained in the manual.

  • See the note on the latest stable release which recommends the following three options:

    1. Use C3's mobile app build service to build C2 exports.
    2. Use an actively supported third-party build service like PhoneGap Build.
    3. Use the Cordova CLI. This is a free manual build tool that works offline. (This option is more appropriate for advanced users.)

  • See the note on the latest stable release which recommends the following three options:

    1. Use C3's mobile app build service to build C2 exports.
    2. Use an actively supported third-party build service like PhoneGap Build.
    3. Use the Cordova CLI. This is a free manual build tool that works offline. (This option is more appropriate for advanced users.)

  • We don't have the resources to integrate all possible third-party services. The other companies they mentioned are bigger and it's probably much easier for them to justify the developer time, but we're a tiny company and just can't afford to do that. To work around this problem, we have created a third-party addon SDK for other developers to intergate their services themselves. The Spine developers should use this. What they said about performance isn't right and looks like a way for them to try to get us to do their work for them - unfortunately we just cannot do that. Meanwhile Spriter have used our SDK to write their own integration and we got positive feedback from the developer, so I think we have everything set up well and with the full performance capabilities of the engine. We worked with Spriter to fill in any gaps in the SDK to ensure everything works well (although there are still some nice-to-have requests we have on our todo list); I am prepared to do the same with the Spine developers to fill any gaps and ensure they can implement a fully capable integration, but we cannot do it all for them. So long as there is no Spine integration I would recommend to use Spriter instead.

  • I can't comment without an example project to look at. Otherwise all I can say is: I guess that shouldn't happen.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Why not just try it and compare?

    It means you only need to do an export over local files instead of having to upload to Facebook and publish, which should be quicker. Note you should still use the Instant Games export, not the HTML5 export.

  • Fengist - I think you missed the bit where I wrote this:

    ...I'm just trying to find a way of doing it that doesn't oblige us to do a lot of wrapping around low-level JavaScript APIs. Construct is generally much more high-level than that, for example giving you Sprite objects, not just an OpenGL vertex buffer to fill out.

  • BTW let me know if you do file an issue - I'd be happy to follow it and explain any Construct-specific details that come up (if any).

  • I think this idea in general is fairly close to something workable, but I'm just trying to find a way of doing it that doesn't oblige us to do a lot of wrapping around low-level JavaScript APIs. Construct is generally much more high-level than that, for example giving you Sprite objects, not just an OpenGL vertex buffer to fill out.

  • Couldn't you do this mapping in events? Kinda of how you map strings to function you can map dom element events to c3 functions. You would just need a bit more information such as the element ID and the event you want to map?

    How would you access event parameters like the button or key that was clicked/pressed? I wouldn't want to have to try to cover every kind of possible event and event parameter that exists in JS, that's a lot of work just reimplementing what JavaScript already does.