Ashley's Forum Posts

  • The browser controls frame scheduling, rather than Construct - so if you have issues with jank the best thing to do is report them directly to the browser maker (Google for Android, and Apple for iOS).

  • I largely agree with that point of view, but as stated in my other forum post, the fact that C3 does not do any kind of live reloading means it's actually extremely complicated to build any kind of external tool that has a decent UX.

    What about the 'Reload all from folder' option for folder projects? You can have an external tool that changes files in the project folder, and then use that option to update the files in Construct.

    You can build a browser extension if you want, but it runs the risk that some time in future it permanently breaks with no workaround, and we won't help you as that's not the kind of thing we support - all I'd say is that I tried to warn you. If that happens then your work is largely wasted and customers may be unable to proceed with their projects. Usually experienced developers faced with a risk like that will do anything but that.

  • My proposal, then, and what I've conceptualized and worked toward since, is a Chrome plugin that simply injects a 3D Editor into Construct.

    Browser extensions are already a big source of compatibility problems and support requests in Construct, because they can easily break things. My advice would be to, wherever possible and to the greatest extent possible, develop a separate external tool and have some way of importing that tool's output to Construct.

    The big problem with browser extensions is they have no encapsulation. They can reach in to the internals of web pages and do whatever they like, even if the web page was not expecting that; and then the web content may change over time, and then break the browser extension, or the browser extension breaks the web content. Unfortunately this encapsulation-breaking approach is fundamental to the way browser extensions work. It is a constant headache for us dealing with support for customers who have some browser extension that does something unexpected to the page and then crashes Construct. People just see Construct crash and then think it's our fault. This is the same story as the Addon SDK v1 all over again, and regardless of what you may think of the Addon SDK v2, if you consider the lengths we are going to in order to prevent this happening, it should indicate to you the magnitude of the problem it is for us. If the option was available to us, I'd have probably already disabled the ability to use any browser extensions with Construct, in order to stop the endless compatibility problems. That is not something browsers let web pages do though.

    Obviously we can't stop you and you can build a browser extension if you want to, but that approach risks falling in to all the pitfalls of the Addon SDK v1. It could end up causing serious compatibility problems and support burden for us, and if it does, we may end up deciding to take action to stop the compatibility problems, which may then impact your browser extension.

    If you build a separate tool which does something like produce a file you then import to Construct, you avoid all these problems and it will probably work fine indefinitely. So I'd strongly recommend you do that instead of trying to use a browser extension to hack unsupported things in to a large, complex and continually changing codebase that is not expecting that.

  • It does the overhead because you asked it to. By adding a 'for each' you are telling Construct 'repeat all the sub-events, conditions and actions for each instance'. So it does that for you. If you don't want it to do that for you, then don't use 'for each'.

    In general, computers can't guess what your intent is. You have to tell it what to do, and it will do what you tell it. This is true of all programming languages: if you write inefficient code, it probably won't guess that you could have used a more efficient algorithm and replace it for you, it will just do the best it can with the code you gave it. If you want it to do something more efficient, you have to write the code to tell the computer to do that instead.

  • The 'Physics catapult' example uses an impulse to catapult the player-controlled character. It looks like it works for me the same at 60 FPS and ~6000 FPS (100x faster). So it looks to me like impulses are working correctly even at substantially different framerates.

  • Running events has a small performance overhead for every event block, condition and action encountered. If you use 'For each' as in example 1, then it means the overhead for all the sub-events, conditions and actions is repeated for every instance. If you don't use 'For each' as in example 2, then the overhead is only done once.

    Sometimes however do you need 'For each' for correct results, such as if you increment a global variable in an action inside it, but my advice is not to use 'For each' unnecessarily. And as ever, if you want to know the real performance impact, measure it yourself.

  • It should just work. The default physics stepping mode is 'Framerate independent' which uses delta-time time steps. You don't need to change any physics forces or settings, the physics engine just uses time steps to match the framerate. I tried the 'Physics catapult' example and it works pretty much identically to me at both 60 FPS and in unlimited framerate mode running at something like 6000 FPS.

    You can set the physics stepping mode to 'Fixed', but then you get framerate dependence issues, i.e. it will go faster with a higher display refresh rate.

    The main downside with framerate independent physics is it's not a deterministic simulation. As delta-time is based on clock readings which have tiny amounts of variance, the simulation is not guaranteed to go exactly the same way every time. Different display refresh rates will also use a different time step and that can also introduce another source of non-determinism. You may have to design levels and such with some tolerance to allow for variance in the simulation.

  • Well now I'm curious, do the filenames need to be url-friendly?

    I'm not sure what you mean. Any filename you choose should load, within reason. If it works in preview mode, then the browser can load it.

  • The way subfolders works changed a while back. Check the 'Export file structure' property under 'Compatibility settings' in project properties. The new default is 'Folders', which means you must specify subfolder paths as well. For example if you have a sound in the path click/click1.webm, you must now use the string "click/click1.webm" when playing from a string. The old way ("flat" mode) allowed you to play from a string "click1.webm" even if it was in a subfolder.

  • Thanks for the feedback! I always thought there's a lot of software out there that's unnecessarily complicated, and we try to make Construct straightforward to use but flexible enough to be powerful.

    If you want to get back in to coding, perhaps try out JavaScript or TypeScript coding - I still think that's an underrated part of Construct, as you can use industry-standard languages and tooling and it integrates with event sheets too.

  • Will SDK V2 be a superset of SDK V1 (all SDK V1 functions + additional V2)

    Yes, the goal is for SDK v2 to be a superset of SDK v1 in terms of the officially documented and supported capabilities. We promise to ensure any addon using only the documented and supported features in the SDK v1 can be ported to SDK v2. In some cases we may change how the API works, so code is written differently rather than porting exactly the same set of methods, but in this case it will still be capable of the same feature the addon was previously using.

    Undocumented unsupported internal details of the engine are not supported, never were, and may be fully removed and become permanently inaccessible in SDK v2 as we always warned they might. This does not mean SDK v2 is not fully compatible with SDK v1 or that it is a subset: as is standard in the software industry the only concern is what happens with supported and documented APIs, and in that regard, SDK v2 will be a superset.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Construct will keep working offline so long as the browser keeps its data saved. It's not in Construct's control. Perhaps check your browser settings - if you have privacy settings or browser extensions that do something like clear storage (possibly referred to as "cookies", a term I think is a bit misleading) periodically, then that will possibly also clear the saved data for Construct to work offline.

  • I realise this thread is about 3 weeks old now, but I note that the methods of the YandexSDK class do not return anything, so they cannot be awaited. Async methods need to either return a Promise, or use the async keyword. Otherwise what happens is awaiting them will complete immediately, but the work is really still continuing in the background.

  • If you think you've run in to a problem with Construct please file an issue following all the guidelines, as otherwise it's generally impossible to help.

  • I will take a look at the integration points raised in skymen's thread. Perhaps we can do some work towards that over the next year.

    However making Construct in to a capable 3D engine is a huge amount of work - and likely endless work, regardless of whatever anyone claims about "we just need this one last thing". Providing APIs to integrate a 3D engine is also a lot of work, but probably not endless work, so while it seems a more feasible path, it's a lot of work either way. This will all take a lot of time and work no matter which path we choose, and that will require patience. Meanwhile there are other tools on the market that are already capable 3D engines, and if people really need a capable 3D engine to develop their game, then it may be wise to choose a different tool anyway, as it's not currently a goal of ours to develop Construct in to a fully capable 3D engine ourselves.

    Accessing the engine internals against our advice is not a sustainable or responsible way to develop software, no matter what results it can achieve. Our SDK documentation clearly stated that undocumented features may be removed at any time. Presumably you had a plan for what to do if the features you were using were removed, as the warning stated may happen. If the addon SDK v2 removes those features, then you should implement your plan for what to do in that case. If you didn't have a plan, or assumed it wouldn't happen, then what can I say? We tried to warn you about this very situation happening. In the other thread the gist of what I was saying is that we will make a best effort to try to make sure addons can be ported where feasible, but that is not a guarantee, and we reserve the right to say "sorry, we warned you". In this case it looks like there's a lot of work whichever way we go, we do not currently intend to make Construct in to a capable 3D engine ourselves, and integrating a separate 3D engine looks like it might be a better way forwards in the long term, and that will inform our priorities when considering what to add to the SDK v2.