Ashley's Forum Posts

  • I am also not a lawyer, but I believe part of the problem is that AI is still new enough that copyright law hasn't caught up yet, so there are lots of unknowns. Perhaps it's fine, or perhaps you'll be infringing copyright. You might need to wait until the situation becomes clearer.

    I've also seen cases where AI image generators are able to create obviously copyrighted or trademarked images. It's obvious enough to see if it generated Mario, which is a Nintendo copyright, but how do you know if it generated something else obviously copyrighted that you're not already familiar with? It's a difficult question and it's not clear to me how AI image generators can completely solve that problem.

    But yeah, I don't think anyone you'll talk to on this forum is able to offer proper legal advice, so this is probably all just speculation.

  • It's probably a question better asked to itch.io themselves - but as far as I know, Android devices deliberately make it difficult to install apps from anywhere other than its own app store for security reasons, so it'll probably be difficult whatever you do. It might be a lot easier just to do a web export.

  • Generally browsers are designed so it's impossible for merely visiting a website to harm your computer in any way. This is definitely not true of running a desktop app, so in this sense browsing the web is fundamentally more secure than running apps locally.

    For an iframe in a game to show a malicious website, the game would probably have to have chosen to do that, which means the game itself is a malicious website. However merely loading or showing it cannot generally harm your computer in any way. If you start interacting with the page it may then try to harm your computer - probably by getting you to download a desktop app, because those are more useful for malicious purposes and it's difficult to do any lasting harm from a website, as browser security is generally very tough and hard to bypass.

    A malicious website might try to do something like trick you in to entering your personal details, or pretend to be your bank and try to steal your login details. This isn't anything to do with Construct or HTML5 games though - these are just general risks of browsing the web, and these risks can be mitigated by some general rules of thumb, like don't download desktop apps unless you know for certain they are trustworthy, check the address bar is the website you're expecting, etc. But the bottom line is: websites are pretty much the safest way to run software - they're generally safer than mobile apps, and certainly safer than desktop apps. No other platform has such strict protections for privacy and security.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • editor.construct.net/r407-2/components/bars/propertiesBar/https://editor.construct.net/yGo-WcBiKFxRwjDdQbSKot_YC5B1XbMpl55bpxqk7N2ZPmR2A-LUNmK6GYGvmAn9xUis7zbseYotB6BtbpMaYA==

    Unfortunately it's completely mangled that URL - it seems to have duplicated the full URL after part of the path. I don't think there's any way around this on our side. It looks a lot like a bug in NordVPN incorrectly processing URLs, so it would be great if you could report it to them.

  • Ah, there you go. Can you post one of the full modified URLs anyway? Just in case it's easy for us to work around on the server side.

    It would also be good if you could report this to NordVPN so they can make sure nobody else has the problem.

    You can find a full list of domains that Construct uses here if you can set up per-domain exceptions.

  • Probably the best way to figure out what's going on is look in dev tools at the failing network requests. Find the first one that fails with status 400 and see what the full URL is and share it here. It looks like something is adding a lot of nonsense to the URLs Construct requests, which makes them invalid and so the server returns 400 Bad Request. Then the question is: what is changing the URLs to do that? It might be obvious from the full URL if there's something like "contosoantivirus-xyzabc123..." in there, but it might not be obvious either.

    Whenever I've seen this before it's been a browser extension messing up URLs, and turning off the browser extension fixed it.

  • Thanks for the feedback! We think JavaScript (and TypeScript too) are great features and hugely powerful, so it's nice to see people happy with using them!

  • You do not have permission to view this post

  • It's a difficult problem - if you run at v-sync rate, you can't use a fixed time step, otherwise the speed of the game changes depending on the display refresh rate. I suppose you could use a fixed framerate based on timers, but it would probably look janky, as it's no longer aligned with the display refreshing. I suppose also physics could be run with separate fixed timesteps and v-sync independently of that, but it's quite a complex thing to implement, and it also multiplies the CPU usage.

    I think it's still possible to design reliable physics games with a variable time-step - it does add some nondeterminism, but you can change the steppings to increase precision (at the cost of more CPU), and then your game design needs to avoid knife-edge balances since those could fall either way with small nondeterministic results - but those won't do something like push a ball over a wall as they're too small, so as long as you have robust designs, it should be OK.

  • It works fine for me, and I've not seen anyone else reporting this problem. It looks like something specific to your system interfering with network requests and breaking them. Usually this is caused by browser extensions, but I guess it might be something else - possibly even some kind of malware, antivirus or proxy that is trying to inject different content in your network requests.

    I don't think Chrome Sync has anything to do with this. It shouldn't affect network requests at all AFAIK.

  • Construct itself doesn't impose any limit. If Dropbox imposes a limit, it's out of our control, and you'd probably have to take it up with them.

  • By far the easiest and quickest way to get help is to share a sample project. Otherwise all anyone can do is guess.

  • We could try moving to Capacitor, but it would probably be months of complicated work; if we dropped support for Cordova it would probably be highly disruptive as there would be a bunch of difficult backwards-compatibility issues; if we kept support for Cordova now we're maintaining two mobile exports which is a permanent drain on resources and focus; and then, as no software is perfect, we'd probably find Capacitor has a bunch of its own quirks and issues. In a worst-case scenario we have to do months of disruptive work, and the end result is no better, or even possibly worse. Often it can seem the grass is greener on the other side. We do occasionally shift between technologies, such as our current effort to move away from NW.js, but that has literally been years in the making (Windows WebView2 came out about 3 years ago) and it's much clearer there are significant gains to be had after completing the transition.

    Meanwhile bugs can be fixed - I expect Google will sort out the frame scheduling in the webview sooner or later, and if anything else comes up, make sure the issue has been filed and reported well (following all the guidelines). Fixing even a whole bunch of difficult bugs still likely works out as less work than moving to a whole new mobile framework. I think you can also try out TWAs already - they're based off web exports - see the TWA documentation here. It would be interesting if people tried that out and reported how it worked. For example if lots of people are already using TWAs and reporting that it works great, then we could more seriously consider improving support for it. But that approach doesn't support Cordova plugins - so what happens to all the advertising plugins for example? If we move to Capacitor, it still uses the Android Webview - so bugs with the webview would still need to be fixed. So it's not clear that any other approach will actually be better - which is why I think it's better to focus on making sure any bugs are fixed.

  • Just to clarify - browser games are completely safe and absolutely cannot do something like run an executable on your computer. Browsers are essentially a strong kind of security "sandbox" and have permission prompts to access anything potentially sensitive like your camera or microphone, and if you don't trust the website you can just deny permission and that's that.

    If you run an executable, that is something much more risky, as it could be some kind of malware, and downloaded desktop apps have far broader permissions by default - such as being able to read and write files, run other programs, access your camera and microphone without asking for permission, and so on.

    A possible source of confusion is Construct can export your project as a desktop app, using options like NW.js. This then does potentially have all the risks of desktop apps noted above, since those are all risks with any desktop software. However if you are only loading a HTML5 game in a browser, then it's basically completely safe and cannot harm your computer in any way.

  • JavaScript in Construct works the same as JavaScript in a web page. You can write the same code you'd use on a web page. There's nothing special about Construct's "JS implementation" - it's not Construct that implements JS, it's the browser.

    You may have difficulty with some APIs when Construct runs in a web worker, but by default when you add JS code it runs in the DOM, so as long as you don't change the 'Use worker' setting then there's nothing different to coding a web page.