Ashley's Forum Posts

  • The parameter description tells you to leave it empty to use the app ID from project properties.

    In other words this should be what you enter for "ID" in project properties, which is the ID of your app. If you leave the parameter empty, it just uses that. You only need to fill it in if you want to request the rating for a different app.

    The parameter description also tells you it's for Android only, so it won't be used on iOS.

  • The fact you can have multiple functions with the same name is basically a design mistake. AFAIK, no other programming languages support this, and it's simply an error to declare the same function twice. So if you were writing code, you could not do this and would be forced to find another way to do it. You should do the same in Construct too, so you don't have to rely on an deprecated, slow and badly designed feature!

    I would suggest using function maps instead. You could have a function that does some basic work and then calls a mapped function at the end using a string variable to continue doing any extra layout-dependent work. Then you change the string variable as you change layout, and the work that the function does will also change accordingly.

  • Just make sure you're waiting for the "ready to use offline" notification - I think sometimes people don't wait for that then go offline, but that means you're going offline before it's fully downloaded everything it needs to work offline.

    Construct 3 is architected so that everything works in full while offline, except for features that connect over the Internet, like cloud save, remote preview, and the build service.

    It's also worth mentioning as always that regular backups are essential for all digital work, in case of software or hardware failure, power cuts, fire, floods, theft, etc.

  • The restrictions of the new functions are intended to both enforce better organisation on your project, and improve performance. For example if you are allowed a function with the same name in two places, you can no longer look at a function and know what it does - you have to be aware of the entire rest of the project and see if there are any other functions with the same name. Besides, there's no reason to do it: you could just use one function with a series of sub-events to do everything in one function. And if for some reason that is difficult or awkward, you probably actually just want two separate functions. Now with the new functions you can look at one function and be confident that is the full logic of the function right there since other functions with the same name are not allowed. This improves your ability to reason about your events. It's also faster since the engine doesn't have to handle iterating over multiple functions with the same name, it just goes to the one function directly and runs that.

    There are also major usability improvements, like being able to properly name and describe parameters, and renaming functions and parameters automatically updates the entire project for you.

    I would strongly discourage you from using the old functions since they have poorer usability and much slower performance. Also in general deprecated features should not be used in new projects, since one day eventually they will probably be removed.

    There's more info in the blog post Construct 3's new redesigned functions and More about Construct's new functions.

  • Construct should work offline and be able to save offline (e.g. as a download, but obviously not cloud save while offline). If it does not please file an issue. As far as I'm aware it should all be working fine offline.

  • Preview works locally and so normally doesn't have to wait for the server. So not only are we not currently aware of server issues, even if there were it should not affect preview.

  • The scripting section of the manual links to some resources.

  • I haven't looked in detail at the documentation I linked to, but it appears you aren't doing it the way the documentation advised. For example it looks like you shouldn't be changing any code inside the iframe, that seems to be all managed by YouTube. I'd suggest following the documentation and doing it the way they recommend.

  • I also think the principle of running on ranges of instances at different ticks is not a good way to solve the problem. It potentially raises more tricky problems:

    - it's a subtle way to introduce framerate-dependent logic. It's essentially like saying "every N ticks", which is framerate dependent. On a high refresh rate screen the "every N ticks", or "for-each across N ticks" will run faster, and this can produce a different and potentially unwanted result, with parts of your logic running faster than they ought to. Using dt to avoid this is also extra-tricky, because you really want a time step across multiple frames. So you can end up introducing hard-to-find and hard-to-fix bugs in your project that won't show up until later.

    - it's very difficult to schedule efficiently. On a high-end machine you might want to go through 1000 instances per tick. However on a low-end machine that might still kill performance. If you reduce the number though, the high-end machine has wasted capacity - it could easily be processing many more instances but you had to put in an arbitrary limit for low-end machines. So now high-end machines have to pretend to be a low-end machine, cancelling out their performance benefit. Determining the right number depending on the hardware is a notoriously tricky problem. This is compounded when you consider: should it go through N instances per tick? e.g. if you process 100 instances per tick regardless of the total count, then you end up with increasingly long latency to process all instances (at 60 FPS, it takes 33ms with 200 instances, or 1000ms with 6000 instances). Or do you go through all instances per N ticks? Now you have an unbounded processing limit again, so it can still end up slow, defeating the purpose of doing this.

    I think there are several different existing approaches you could use that avoid these problems completely. For example you could use a boolean instance variable to opt-in instances to processing with a certain event. Or you could only process objects on-screen or nearby. Or you could find a different way to approach the problem that doesn't involve heavyweight for-each loops. It depends on exactly what you're doing.

  • Why not just use the browser WebSocket API directly?

  • It's a problem with Safari - its tracking protection incorrectly identifies Construct's login as a tracker and deletes its storage. The only way to get it to work is to turn off tracking protection. You could also report it to Apple.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I just tried creating and destroying iframes by events and it worked fine.

  • You can't - the iframe content defines its styles, the parent page can't control it.

  • Use the 'Set CSS style' action to set "font-family" to the name of the web font.

  • I think creating variants of the same condition is actually more confusing for beginners. Now you have to explain what the differences are between the two, why you need both, and when you'd pick one over the other, instead of just explaining one condition.