Ashley's Forum Posts

  • I noticed that you can't bundle the browser with the game

    You can actually, with the "fixed" distribution mode. It's documented here.

    Will my game still work the same way consistently, even if they change the way the browser/Edge works in later years? And what if future Windows versions change the way they do the browser? Will my game be safe?

    Even with the default "evergreen" (auto-updating) mode I wouldn't expect there to be any problems. Web exports from over a decade ago generally still work fine, and it's basically the same situation with WebView2 exports. Our Android export option has always used auto-updating web views, it's one of the most-used export options in Construct, and I can't recall the browser engine auto-updating ever causing a problem. So I think while the browser engine updating and breaking the game is a theoretical concern, in practice I don't think it is. Of course if anything did break backwards-compatibility, we'd release a patch immediately. There's also other system updates that could break your game, like a broken graphics driver roll-out. Part of supporting software just means keeping an eye on it.

    I've also heard that it's not good because it doesn't work with Steam overlay or something?

    The Steam in-game overlay isn't supported - we've gone to great lengths to try to get it working, but the way Valve have implemented it means there's just no way to even work around it no matter what we do. However Steam falls back to showing the actual Steam UI when the in-game overlay is not supported, so it's not something we consider a blocker for moving to WebView2; if you care about having the in-game overlay you'll need to contact Valve as unfortunately it seems to be one of the things that is outside our control. The rest of the Steam features work fine and the Steamworks plugin for WebView2 actually has more other features now.

  • Would it be possible to provide a reliable way to tell if the game is running on a steamdeck ?

    The Steamworks plugin has an 'Is running on Steam Deck' condition. It actually also has a script interface and you can use the isRunningOnSteamDeck property from JavaScript too. However I realise that script interface is currently undocumented - I'll see if we can get that written up somewhere.

    Additionally, detecting Steam OS might be great too ?

    I don't think there is any way to specifically detect Steam OS - I think it looks to the app like any other Linux system, and there doesn't seem to be a Steamworks API to identify Steam OS specifically (just the Steam Deck). If you only use Linux exports for Steam OS then you can probably just use the Platform Info 'Is Linux export' condition (or equivalent JS API).

  • It looks like you've somehow installed two addons with the same ID, which is not allowed. Try clearing your browser storage, which will erase all installed addons, and then start over re-installing addons.

    • Post link icon

    Update 8th January: please note the work has been rescheduled for Wednesday January 15th. It was originally scheduled for Monday January 13th. All other details remain the same.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There isn't a specialized script interface for 9-patch at the moment - so unfortunately there doesn't seem to be a good way to identify those kinds of instances... maybe we need to add a new script API to cover that.

  • It sounds like one of the Steam library files is missing - is libsteam_api.so there? If not, that's the problem. Maybe try a fresh export and make sure all files are uploaded and fully overwrite the existing files on the device.

  • I received the project and it is indeed that there is an invalid name that starts with a space - it's the animation name " Bombed6" in object "BoardDoor". The easiest way to fix this is probably to open it in r388, rename the animation to not have a space at the start, save the project, and then reopen it in a newer release.

    There is a special error message meant for cases like this (linking to this guide) but it wasn't shown for animations, so I've fixed that for the next release.

  • Due to architectural differences with CEF it doesn't currently support opening dev tools automatically, but you should still be able to access it via chrome://inspect. It's documented here. You can also use that to debug a different device via remote debugging, similar to how it works for Android devices.

  • I just tried a test project that runs throw new Error("test") in an 'On start of layout' event, and running goToLastErrorScript() in the console correctly highlights the script block in the editor for me.

  • If you want to do something like identify if an instance is a Sprite instance, you can use inst instanceof ISpriteInstance. The instance class names are documented in the manual, e.g. here for Sprite.

  • Send the project to ashleyhnq@scirra.com and I'll take a look. We want to make sure Construct can always open older projects, or if some compatibility change has prevented it opening, at least show you a useful error message indicating what that is.

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

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

    • Post link icon

    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.