Ashley's Forum Posts

  • Lancifer - your tone is too harsh - even if you disagree with the addon developer it us up to them how they advertise or license it. Please review the forum & community guidelines to avoid further moderation action.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Preventing cheating is essentially impossible, but I find it strange that these commands are globally accessible. Is there a specific reason for this?

    Basically there's no difference between writing JavaScript code in your project, and running commands in dev tools. So there's no good way to block one off but not another.

    Another concern is the possibility of players bypassing paywalls.

    Welcome to the DRM arms race. All you can do is invest increasing amounts of time to make it increasingly difficult for anyone to bypass protections. It is not generally possible to make it completely bulletproof for the reasons I mentioned. The best protection is an account system with server-side validation.

    FWIW, blocking off various JavaScript APIs is only minimal protection. If your "no ads" option permanently disables ads by saving something in storage, then someone can run a command in dev tools to write the same thing directly to storage - then there's no need to go via your project's logic and no amount of blocking off code features will help. In principle on the client side nothing is trusted and everything can be manipulated. The only way to put things beyond reach is to move it to the server side, and even that has ways around it - clients can intercept and change responses from the server too!

    My advice: as long as it's fairly difficult to do, 99% of people won't do it. I'd count accessing dev tools and running some specific command as fairly difficult for most people.

    Please note that some routine server maintenance will be carried out on Wednesday 15th January 2025 between 10:00 and 16:00 GMT. There will be some disruption to cloud services during that time, including the mobile app build service, multiplayer, Remote Preview, and minifying exports. All being well there should be minimal disruption, but we are giving advanced notice of possible disruption during this time period to ensure there is time to complete the necessary upgrades and also warn users in case servers are inaccessible during that time. Thank you for your patience.

  • If you're willing to use dev tools, then in principle users can probably do pretty much anything to your project. You can try to hide things, but then you can use the debugger to break inside engine code and run more commands. You can even use dev tools or browser extensions to rewrite the JavaScript code and remove protections. You can even go lower-level and use advanced tools to identify values in RAM like for the score or lives and overwrite them.

    In general normal players just don't do that, so I don't think it's ever been a major concern. Trying to remove various interfaces could also break your project, so it's risky to do that. If you're concerned about cheating, yes, people can cheat in single-player games, and have always been able to do so pretty much regardless of the technology, unless you run on a totally secured and locked down console platform. If you're concerned about cheating in multiplayer games, in a well-designed system with an authoritative server, peers cannot cheat regardless of what the client does. That's about how it is and how it's always been for the industry.

  • See the manual section on Exporting with Advanced minification, which includes advice on debugging issues. It's difficult to provide any further help unless you provide more information, such as a sample project.

  • The Online multiplayer in Construct tutorial series covers a lot of what you'll need to know.

  • My best guess is a browser extension is breaking Construct. Try disabling any browser extensions you have installed.

  • JavaScript doesn't contain enough information for accurate autocomplete - if you want that, make sure you're using TypeScript.

  • I'll take a look at setting that up. Feature requests are regularly reviewed, but as I mentioned before, we get so many it is a very large amount of work even just to respond to them all in any useful way. If any suggestion you care about for any reason is closed due to expiring, and you still care about it, you can just resubmit it - you will only have to do that once a year.

  • It's normal that some cross-domain requests send a "preflight" request before the actual request, for security reasons. If the server is correctly configured then this shouldn't affect how it works. There's more information in the MDN guide on CORS.

  • See the guide in the manual on using an external editor.

  • The code in your initial post appears to be correct. Maybe you didn't set the right script purpose properties. The easiest way to get help is to share a project file, so others can see exactly what you've done - otherwise all we can do is guess.

  • As writing JavaScript code for a multiplayer game is a very advanced use case, the script API just gives you access to sending and receiving messages, and then you can write your own synchronization code on top of that. That's the approach used in Command & Construct.

  • Performance will most likely be absolutely fine and you don't need to worry about it. See Performance Tips in the manual for more advice.

  • Construct moved from UIWebView to WKWebView several years ago already. If you're seeing that message for an old app, exporting it with the latest version will move it to WKWebView. However if it's an old app, updating it may have some compatibility issues, so you might just want to leave it as-is - the warning only says they don't accept it for new apps, and existing apps can continue to use UIWebView.