Ashley's Recent Forum Activity

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

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

    "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".

    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.

  • Why would you want this? It seems sensible that you're doing one of either typing in a text input, or controlling a game, but not both at the same time, that seems chaotic.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,428,037 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x108
    Coach One of your tutorials has over 1,000 readers
  • x62
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x36
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs