Ashley's Recent Forum Activity

  • Last I tried using Proton to run a Windows WebView2 export didn't work. Use the Linux CEF exporter instead.

  • As per the Forum & Community guidelines, please only post in English. I used Google Translate on your post. See also this post - it is difficult for anyone to help you without more information.

  • Last I tried the Windows emulation on Steam Deck didn't work very well for Windows WebView2 exports. I'd recommend using a Linux export anyway as it runs directly on the OS rather than using a complex emulation layer which could be a source of bugs, compatibility problems or performance issues.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You could use Steam Cloud to sync save files between devices. See the Steamworks plugin documentation which covers that.

  • It's much easier to help if you provide a project file that other people can open and try out. Your code sample alone isn't enough to try it, so you probably won't get any help with just that.

  • It's probably because if you create a folder named 'images' in the root 'Files' folder, it ends up using the same name as the Construct built-in 'images' folder used in exported projects. Construct should prevent you using these names, but that wasn't implemented. I've added a check for that to prevent it happening again - as we're close to a stable release that check is in for the next release cycle (first beta after the next stable release).

  • If you want to keep using NW.js, you can - it's still there in the r449 LTS release. Our stats show the vast majority of users are on the latest Construct release and also the vast majority of desktop exports are now for Windows WebView2, macOS WKWebView, and Linux CEF instead of NW.js. So I'd say that basically the switch has already happened, which means it's a bit late to be asking to change anything back.

  • For context, this Reddit comment I posted a while back explains some more of the reasons from moving away from NW.js. I know these transitions can be disruptive, but in the long run it's necessary to improve things, and by now the new exporters should support pretty much everything NW.js used to, such as with the File System object for accessing files and folders on disk.

    I'm actually glad we moved away from NW.js, because shortly after the move, this bug broke support for Steam. As the relevant feature is undocumented and unsupported, nobody is obliged to fix it, so it may well be broken permanently now. I always knew it was a risk relying on things like that because of the chance of exactly this scenario, and that was part of the motivation to move away from NW.js. Luckily we avoided that particular nightmare. Presumably if we had stuck with NW.js, that bug would be causing serious problems, and everyone would be demanding a fix or talking about other better technologies we ought to be using instead. Also moving to new technologies has enabled further improvements, such as better support for dual-GPU devices in the latest releases.

    In these cases we have to choose between continuing to suffer the faults of the technologies we've already chosen, or switch to better technologies and do our best to smooth the transition between them. If we have to choose between short term gain with long term pain, or short term pain with long term gain, in the end it's always best to choose the latter.

  • Multiplayer tutorial 1: concepts covers this in the section about connectivity.

  • The signalling server is available in the store, but I do not recommend using it if you are not already familiar with administrating servers and configuring network setups - we do not provide support for those topics.

  • Our feature request guidelines have a section titled "Please do not try to claim your idea is simple or easy to do". Even much simpler features can end up proving surprisingly difficult. There are parts of Construct that look lovely and simple and straightforward, but internally it is dealing with a great deal of complexity. That's really Construct's job - it often does a lot of heavy lifting internally to provide a simple and straightforward interface. Even we struggle to work out what will be easy and what will be hard, and on the outside it is even harder to properly understand what a feature would entail. Claiming something is easy to do is not helpful and will probably just make people get more frustrated.

    We don't know for sure how easy something will be until we do it, customers use the finished version, and decide it is suitable. Before that point we have to rely on our many years experience developing a complex piece of software, using our familiarity with the codebase, to make an educated guess what it would be like to develop. On this I must agree with DiegoM - template layers sounds like a nightmare to implement. The "sort-of-like-a-normal-layer-but-not-quite" approach actually causes no end of difficulty and complications, as it violates long-standing assumptions in thousands of lines of code distributed across the codebase, which is more or less the same reason why global layers proved to be a nightmare. It probably gets even worse if you want things like a template layer to be an override of a global layer - that sounds like the kind of thing that ends up so messy and complicated it ends in development hell and we basically never get it right, then users end up abandoning the feature because it never works properly. So I think there's a real risk your dream of a nice simple template layers feature actually turns in to a nightmare.

    Batch changes to a project sounds a lot easier though. It basically amounts to repeating a manual operation across multiple layouts. It would be much more straightforward to implement and is much more likely to just work in a predictable way. So this is one of the times where our experience developing Construct is leading us to suggest a different feature that should still do the job, but is much easier for us to develop and support, and more likely to actually turn out to be a success.

  • This doesn't make sense - it's like asking for a Construct project without the Construct engine. Construct always uses its engine, it's a key part of the product.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,788,533 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
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    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
  • x43
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs