Ashley's Forum Posts

  • I believe it's a bug in Chrome on Android.

  • Support for apps in the Chrome Web Store is being retired, so it's not really worth publishing to any more.

  • It's not supported in Construct 2. The feature is new in Construct 3. You posted in the Construct 3 forum so I assumed that was the context.

  • Please only post in English on the forum. I used Google Translate on your post.

    See the Text formatting example.

  • Please only post in English on the forum. I used Google Translate on your post.

    Try ticking 'Play in background' in the Audio object.

  • Do not use "every" with small times. As I noted, it will actually be framerate-dependent and break in some circumstances.

    A display that runs at 240 Hz will usually have a powerful gaming-grade computer to drive it - after all there's no point having a 240 Hz display if your CPU can't keep up. So usually such devices are specced to be able to handle the extra workload. Even if not, you should guide your optimisations based on profiling measurements, not wild guesses about what the problem might be.

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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 `.

  • 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).

    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.

    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!

    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.