Ashley's Recent Forum Activity

  • AI often generates stuff that looks plausible but is wrong. In this case, with your code, textBox appears to be a Text object instance, and so is an ITextInstance class. The documentation does not list that there is an elem property so it's not valid to use it. The object is not even a HTML element (as it's rendered directly in to the canvas) so CSS styling is simply not applicable to that kind of object.

    If it was a HTML element object, like "Text Input", you could call getElement() and then use the standard DOM APIs to alter its style.

  • Google Closure Compiler doesn't support public class fields by default at the moment. Finding well-maintained up-to-date minifiers has always proven difficult. I looked at UglifyJS 3, but it hasn't been updated for a year, so it doesn't seem to be actively maintained. You can export unminified and try minifying with some other build tools (or Closure Compiler if you get the right flags to make it happy).

  • It's not possible to tell what might be wrong from just that. In general if you run in to a problem please file an issue following all the guidelines, as we need all that information to be able to help.

    It seems reasonably busy as ever to me. Early January is often a quieter time of year though.

    People usually come to the forums when they have a problem. So to some extent, well-designed and easy-to-use software should have a quieter forum, whereas complicated and problematic software would have a lot of people posting!

  • Note that the compression format of images (e.g. PNG vs JPEG) or the degree to which they are compressed has no effect on memory usage. See memory usage in the manual for more details.

    Construct's image memory measurement includes the main render surface which can depend on the viewport size, but this is not a useful way to reduce memory usage, as the vast majority of a large game's image memory will be from object images, and changing the viewport size has no effect on that.

  • You'd need to contact Google and ask them to allow the .wasm file type. Construct's physics engine is built using WebAssembly (hence the .wasm file) and so if you use physics, you will have a .wasm file exported.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I don't think GitHub has any feature that allows for limiting submissions per user, so we couldn't enforce that easily - but I don't think we should do that anyway. The process is basically a collaboration between users saying what they want and us reviewing what we think is important and feasible. When things are positive on both sides of the equation it is much more likely to get done (subject to available resources). Limiting submissions means it's less likely to get a positive result on both sides of that equation, and also tends to make people upset as they have ideas that they want to submit but can't. The downside though is the huge volume. If people go ahead and submit roughly 2 years worth of work in the space of 3 days - which is what I think has just happened - I don't think there's much we can do about that, other than encouraging people to only file a small number of their most important requests. But I don't think anyone pays much attention to that!

    I also don't think it's feasible for us to respond to every suggestion. The feature request guidelines say we don't promise a response because I don't think we reasonably can. Even minor features can become unexpectedly complicated, and so I don't want to give a "this looks easy!" response even if I think that, because regularly it descends in to weeks of complicated work anyway, and in the worst case could end up having to be removed again, and so such responses would be misleading. Often responses end up in extended discussions where people dissect what I've written (which was usually only a vague impression anyway), try to advocate their case more strongly, or end up talking in detail about various aspects of the suggestion; I just can't afford the time to do that for hundreds of feature requests, nor does the discussion even always come to any particular conclusion. The only feedback I'm comfortable giving is "this looks particularly difficult and would likely be a major project", which unfortunately has the side-effect of making me look really pessimistic and only ever saying negative things about suggestions. I don't really want to give that impression as it's a useful and positive thing to have lots of cool ideas being submitted and discussed by members of the community who care about making Construct better. But I'm not sure there's anything better to do - when there are such a huge number of suggestions, way way beyond what we could possibly do, I think it's sensible to manage expectations and push back where I can to help identify what really matters.

  • Perhaps the library does not support modules. Some older libraries need adjusting to work with modules. The Construct for JavaScript developers quick start guide has some advice on how to update older JavaScript libraries to work with modules.

  • No idea if construct does its own buffering on top of that.

    Construct does not do any buffering (and so should not add any latency) itself. Any delay comes from the browser or the rest of the system.

  • For me exFrames=2 clearly shows the future sprite ahead of the mouse and exFrames=1 is behind. It only seems approximately aligned with exFrames=1.25, which is weird, as it's not even a whole number.

    I'd guess there's both mouse smoothing and different system-specific latencies on both hardware mouse input, system cursor rendering, and presenting frames from apps.

  • You do not have permission to view this post

  • the parallel feature sounds like a good idea

    Part of the problem of doing this is for backwards compatibility the old feature can never really be removed. Deprecating and removing a feature widely used for many years is infeasible. This means we have two separate code paths for the same feature, both of which are complex and must be maintained long-term, and any significant code changes/upgrades/optimisations have to be re-tested with the old feature to ensure it isn't broken, and sometimes can even preclude making the improvement. A completely redesigned feature sometimes doesn't always cover exactly 100% of what the old one did, and so then you get people who ask for the old feature to still be available to do the things the old feature did; if you do that, now you have two duplicate features which both need active maintenance. You can do something like hide the old feature, but you will still get years of confusion as people who keep running in to old tutorials, documentations, lesson plans, printed books, or people who used it a few years ago and then came back after a long gap, repeatedly getting confused by the fact things look and work differently now.

    It's a really painful process to go through that substantially increases our workload, adds a lot of complexity to the codebase, and ends up confusing people for years afterwards. In general I would say that we are going to avoid that at all costs, and suggestions should take that in to account. It has to be really, really worth it. We went through all that with the new functions feature, as I think the improvement was worth it, but it was still far more difficult and long-running transition than I imagined.

    I care about C3 and my ideas, but I think copy-pasting 40 ideas is too much!

    That's about a year's work on your suggestions alone. I think there was about 9 years worth of work in suggestions posted in 2023 alone. Part of the problem we have is there is just far, far, far more suggestions posted than we could possibly have any chance of doing. I would say only submit a few of your most important suggestions, as making as many suggestions as that just means you're submitting so much work there is no chance most of it will be done in that year. If you submit a smaller number of suggestions it's more likely one of the things you care about will be done.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,383,453 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
  • x107
    Coach One of your tutorials has over 1,000 readers
  • x61
    Educator One of your tutorials has over 10,000 readers
  • x2
    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
  • x35
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs