Ashley's Forum Posts

  • What issues are you talking about exactly? Has an issue been filed either with Safari or us? That is the best way forward.

  • It works fine for me. It's hard to say more without all the information requested for a bug report.

    • Post link icon

    As per the Forum & Community guidelines, please only post in English on this forum. Closing the thread.

  • Please contact Valve about the gamepad input issue - it appears to be the case that it works fine so long as you don't initialize the Steam SDK with Steam Input enabled, so it looks like it's Steam Input that is breaking it, and that's all Valve's software. I'd guess they can fix it, so long as you get in touch and report the problem to them.

  • 1. go to editor.construct.net 2. Log in to account 3. Opening via cloud (dropbox) 4. Logging into dropbox. Sometimes it just opens as normal, sometimes it says "Not a valid file, please check if it is a .c3p file"

    I tried these steps and could open a project OK. I'm afraid it's probably impossible to help further unless you can either find a way to reliably reproduce the problem, or access the developer tools - perhaps you could try a different system, or talk to the system administrator.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • The built-in particle rendering is fairly limited, because it uses a specialized rendering mode that is more optimized. It currently only draws squares, but you can always draw a non-square shape inside a square image. If you need additional features such as truly rectangular images, or other features like rotation or animation, you can set a Sprite object to be spawned as particles instead, and change those sprites however you like.

  • OK, well glad to hear you've thought about it in detail and tried to design the system appropriately!

  • I think it would be best to leave it be for the time being, because there are some details to be sorted that would probably require thinking over, such as where the content for the popup window is loaded from and what its origin should be. (I don't think such content should run on editor.construct.net.)

  • if you read through ANY issue people usually encounter with Construct performance or otherwise it's always at the point where any sort of desktop or mobile deployment happens

    Often when I see this, it's people hitting the GPU hardware limits. If you did the same thing in a different tool you'd hit the same limits because the hardware has only so much capacity. That's why our performance tips say to regularly test on target devices. If you never test on mobile, develop your entire project, and then find it's too slow, the problem probably really was your lack of testing during development. You should do that with any tool, and it's quite unfortunate if people think Construct is to blame for this kind of thing.

  • We were talking specifically about JavaScript performance. It doesn't sound like you were talking specifically about that, so that's bringing in a whole other set of discussion topics.

    I'm happy to benchmark performance issues, and usually the engine does have very good performance. If you're referring to performance problems, I'm not sure exactly what you're referring to - there could be all sorts of different things going on, ranging from GPU selection for dual-GPU systems (something I'm hoping to address in the next release cycle), graphics driver issues that are (surprisingly common) system problems rather than anything to do with Construct or browser engines, or actual issues with the Construct engine. It's helpful if you can be more specific, and file issues following the guidelines so we can properly investigate.

    No software is perfect, and all software has its bugs and issues. The number of open issues isn't necessarily a perfect measurement, but given that we currently have 53 open issues, GameMaker have nearly 5000, and Godot has over 12000, then I wouldn't say it's necessarily the case that everything is going so much smoother for everyone else.

    This is really going quite off-topic for this thread though, which is something we address in our Forum & Community guidelines - it's probably best to start new threads to branch off new discussion topics, rather than chucking everything in to one thread that was originally about the addon system, which tends to get pretty confusing and aimless.

  • As a show of good faith I have privated and removed all 3 addons and their repositories.

    Thank you - I appreciate that. I will put a warning in the addon documentation to make it clearer the editor DOM is considered internal details. So long as nobody is doing anything like that, then there isn't much need for SDKv3 or similar measures in the interim. Much like SDKv2, if the necessary encapsulation features were available from the start we'd have definitely used them from the start, but adding them in afterwards can be a lot trickier, both just to implement it and for backwards compatibility reasons. We will probably weigh up what to do next when ShadowRealms become available consistently across browsers, which may be some time away - I'm not sure there is any public schedule for it.

    Does encapsulation cause performance degradation?

    FWIW, in the first releases with SDKv2 we used WeakMap for encapsulation, which did have some performance overhead as many APIs required a map lookup. Now private fields are widely supported we have mostly switched over to using that instead, which should have minimal performance overhead.

    I don't regard this as a factor in the decision about using encapsulation though. Slower but working code is better than fast but broken code. If there is a compatibility disaster and thousands of customers have broken projects, the fact the code was well optimized doesn't matter much. That's not to say we don't take performance seriously though, and Construct's performance is already outstanding and JavaScript performance is far better than the competition.

  • I'm afraid it's not possible to help from just this information. Generally we need issues to be reported to the issue tracker following all the guidelines and providing the requested information in order to be able to help. If you press F12 and look in the browser console for a more detailed error message, that information is often very useful as well.

  • So you made a public server that executes untrusted code from anonymous users? Oof. Good luck...

  • I can reproduce no gamepad input when using both "allow-host-input-processing": false and the Steamworks plugin. However using app ID 480 (Spacewar) with the test, if I then go in to Steam, right-click Spacewar and go Properties > Controller > Disable Steam Input and try again, it works. So it seems Steam Input is preventing gamepad input from working in this case. You'll need to contact Valve about that as Steam Input is their software.

  • For what it's worth, is editor extensibility not part of what was advertised in the Construct 3 promo page before its release almost a decade ago now?

    I don't believe we ever advertised such a feature - this blog from 2017 mentions we were "planning to allow editor plugins", but unfortunately we ended up giving up up on those plans mainly because the scope of the feature is so large and potentially has very difficult maintenance concerns, as I mentioned in this post. Sorry, sometimes things don't work out as planned!

    When people try to use undocumented internals to hack features in from the outside, it ends up causing disaster. Those disasters can be so bad that they outweigh any benefit that the feature ever brought, so it would have been better to never have had it at all, rather than a hacked together version that eventually caused disaster.