Ashley's Forum Posts

    • Post link icon

    If some network requests are failing, it sounds like a problem with your Internet connection, or the server.

  • Only WebM files are guaranteed to work everywhere. The solution is to update the server. WebM has been around for over 10 years now, it's a well-established format.

  • The problem in your original post is using double quotes in strings is syntax specific to Construct expressions, and it is invalid in JavaScript. In JS you need to use \" for a quote inside a string, or use a single-quote string so double-quotes are allowed unescaped, or use a template string with `.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You probably need to set up the right MIME types on the server, and then it will work.

  • This has been suggested from time to time over the years but I don't believe it's feasible. Event sheets are so high level that they would generate huge amounts of code with a lot of boilerplate. I doubt it would be useful to anyone.

  • Using an additional texture input to a shader is not currently supported. The only workaround is to use the foreground and background as two separate inputs, which is what the built-in normal mapping shader does (instead of providing the normal map as an additional input).

    • Post link icon

    it could interfere with double-jump, and then you'd end up with a bug report with a specific case for this, which leads to editing double jump, which could lead to many unexpected issues that DO affect other projects.

    Yeah, this is exactly the kind of thing that happens.

    I had a look and this is probably a good example of a "sounds simple but is actually complicated" feature request. Just off the top of my head and glancing at the code, some questions that come up are:

    • Does forcing a jump in mid-air count as a double jump? Some people will assume it should, others it shouldn't; whichever answer we choose someone will want something different
    • Should landing while forcing a jump beyond the jump sustain time allow bunnyhopping? Perhaps yes because you're forcing the jump, perhaps no because it should follow the normal jump rules
    • Should it trigger "On jump"? Perhaps yes because it's a jump, perhaps no because that should only happen in response to the user input controls (real or simulated)
    • The code contains a check that there is no obstacle 1px above when jumping, and blocks the jump if it's not clear. Should forcing a jump bypass that rule? Someone will probably want that on the basis they're forcing a jump so it should be attempted anyway; we've dealt with even more subtle things than that in the Platform behavior.
    • Should the ceiling collision mode affect forced jumps? I don't know. I would fully expect someone out there to want forced jumps in the ceiling to slide past, and someone else to bounce off, and someone else to want a dynamic response based on gameplay circumstances.

    "Just do it" glosses over all these complications which we inevitably will have to deal with if we do it. I know that implementing these things means signing ourselves up to dealing with all the fallout, and I don't take it lightly. Meanwhile you can answer all these questions yourself via event logic and "Set vector Y".

    The rule of thumb is changing existing complicated code is a very complicated thing to do, and the Platform behavior sure is complicated.

    • Post link icon

    I've lost count how many times I've thought something would take 10 minutes, and then spent the next 3-6 months in a mix of subsequent refactoring, fixing obscure edge cases, working out why regressions happened, talking to users who said actually it doesn't work exactly like they thought it would so actually it needs to be changed, and then the change causes a regression, and then there's more refactoring, more obscure edge cases, someone else finds it's not exactly what they need for their project so please just add another quick setting because how hard can it be, etc. etc...

    Meanwhile this is already possible with "Set vector Y" and some of your own events, and you can definitely customise that to work with your specific project's requirements.

    Software development isn't just "how long does it take to do it in the first place", it's "what are the long term maintenance implication of this". That's the point of that blog post I wrote, which summarises: in software, everything is always more complicated than you think!

    • Post link icon

    We also get more "just do XYZ how hard can it be" requests than we can possibly deal with, and seemingly simple things routinely turn out to be unexpectedly complicated. (The Platform behavior is also extremely complicated and a source of nightmarish bugs even after about a decade of development, to the extent I dread making even small changes to it.) The feature request system is there to try and deal with all this, so post suggestions there and vote on the ones you want to see implemented.

  • There's nothing iOS-specific about savegames, it's running identical code on all platforms.

    I'm afraid it's impossible to help without more detailed information - see the bug report guidelines as we need all that information to be able to investigate.

  • Including objects that don't support rotation in hierarchies where the parent can rotate introduces some complications, which is why it's not supported at the moment. Using form controls in a hierarchy seems like a weird use case though - what would you need that for?

  • Try the latest beta release - maybe it's a problem we already fixed.

    • Post link icon

    "Jump sustain" just sets the vector Y to the jump strength every tick while the jump button is held, up to a time limit. That shouldn't be too hard to reimplement with events as well.

    The aim of Construct is to cover the basics and then give you an "escape hatch" to customise things in more advanced ways. The Platform behavior is a great example of that: it can do a lot for you, but it also gives you control over the vector X/Y so you can do virtually anything else imaginable providing you can come up with the event logic for it.

    Further, we already get far, far more feature requests than we could possibly act on, so each request needs to be strongly justified, and this appears to be already possible via the existing customisation feature. And then even if we did everything everyone asked for, there's a risk Construct could end up crammed with loads of settings to configure the minutiae of every last micro-feature and quirk, and then it's no longer easy-to-use software accessible to beginners. So I do think there needs to be a point where we draw a line and say "use the existing advanced customisation for that".

    • Post link icon

    The whole reason there are 'Set vector X/Y' actions is advanced customisation like this. Why not use that?

  • this proprietary software receives the data and pastes it into what ever has focus.

    That sounds like a weird and extremely specific situation. Doesn't it have an API or some other way to get the data without needing to have a focusable text field to automatically paste in to?

    It's such a specific situation I doubt we would change Construct to support it even if we were making software dedicated to application development.