Ashley's Forum Posts

  • We don't publish any usage limits other than stating it's a free service that works on a best effort basis for reasonable usage, with the interpretation of those terms at our discretion. If you are not comfortable with that, you should set up your own TURN server.

    It's hard for anyone to tell what the usage would be anyway, as it is only used when direct connections fail, and it's difficult to guess what proportion of devices will be resorting to TURN for any particular game audience.

  • The only major difference between SDK v1 and SDK v2 is how you write the runtime scripts. Therefore the Runtime scripts part of the Addon SDK documentation is split in to two sections for each SDK version. There's also a porting guide.

    Am I able to simply use the same calls from the scripting reference for use inside construct 3?

    example:

    runtime.collisions.testoverlap(...)?

    Yep, exactly. One of the major design improvements with SDK v2 is it unifies all the scripting APIs so you can use the same calls as you would in Construct itself.

    I'd also recommend getting TypeScript support set up for addon development - it gives you precise autocomplete for all the available APIs, and is another new feature of SDK v2.

  • I've updated the addon SDK on GitHub to configure all addons to use modules. Then I can successfully test a module import by:

    1. Add mymodule.js in c3runtime folder, and add references (this._info.AddC3RuntimeScript("c3runtime/mymodule.js"); in plugin.js, add "c3runtime/mymodule.js" to file list in addon.json

    2. Write content of mymodule.js: 

    export function GetMessage()
{
	return "Hello world!";
}

    3. Import mymodule.js somewhere - I tried adding this to the top of instance.js: 

    import * as MyModule from "./mymodule.js";

console.log(MyModule.GetMessage());

    That successfully logs "Hello world!" to the console on startup for me.

    These points have all already been discussed at length in this thread. In short:

    The issue is this: If you can't make the built in behaviors with sdkv2, then the sdk isn't robust enough

    I believe you could make all the built-in behaviors with the SDK v2. Sufficient APIs should already be implemented. If they are not, you can submit a feature request.

    I feel like shutting off sdk1 in December

    It's not December: the plan is support will be dropped next summer, after an LTS release which will be supported for another 18 months - so there's over 2 years of support still to go with the Addon SDK v1.

    I've spent the last half year making behaviors using only the official api, and now I am being told that even though my addons were permitted and done the official way, I still have to go back and re-work everything!?!?!?!?

    If you are referring to v1, then I'm afraid the great extent to which other developers have ignored the warnings in the SDK documentation have forced us to act on this to prevent disaster in future, and I can only apologise that addon developers who have always abided by our advice are impacted by this. For what it's worth, there are a range of new features in the Addon SDK v2 such as TypeScript support which may help with future addon development, as well as a wider official documented API surface that will be improved more quickly in future too, as it's the same APIs as the JavaScript coding feature in Construct uses.

    You promised that if we used the official sdk, you would support it forever.

    Again, the intent is that everything officially supported in the Addon SDK v1 is still supported in the Addon SDK v2. If something is missing, please file an issue. These features all remain supported indefinitely, but will need to move to the Addon SDK v2 to continue using them in future releases.

  • The latest beta release is still r404. Click the link where it says r404 and it will open it.

  • As I mentioned in this recent forum post, of commercial tools, having a subscription model actually makes it more likely we can keep going indefinitely - not less. I would say other commercial tools are actually a riskier long-term proposition if they don't have a sustainable business model.

    FWIW we've been going since 2011, Construct 3 came out in 2017, and we're still going strong. We're not going anywhere!

    Sometimes this happens and it is my least favorite part of software development, but: sorry folks, this is not our fault. The problem is with AMD's software. You can ignore that and insist it's our fault anyway, or that we do something about it anyway, and nothing will happen, because it's not our fault and it is impossible for us to fix the root cause.

    Ordering in a bunch of expensive equipment in what is normally a hopeless effort is not something we're willing to do. Like I say I would fully expect that to cost us money and result in a dead end - because it's not our software that's broken.

    So there's apparently a workaround with an old setting. I guess you can keep using those old Construct releases then. It is a total mystery to me how the old setting could possibly have anything to do with this whatsoever: that setting just sets a flag in the browser engine asking it to reduce the latency of display. What that does I don't know, and why it works around the problem I have no idea, but it also caused a whole bunch of other bugs and problems, so if we bring that back we get all those problems back, which I don't want to do either. As ever, the only way to really solve problems is to fix the root cause, which is in AMD's software.

    Your choices are: continue to insist we act on it anyway, which will be fruitless, or actually get in touch with AMD (don't ask me how, we're not AMD) or the browser vendors, either of whom may be actually able to do something about it. Those of you who actually want to see the problem fixed, please choose accordingly.

    For those of you who think "just make a 3D engine, how hard can it be?" - food for thought.

  • Most such recent cases are due to the issue described here. You can also try opening the projects in the latest beta release where we've done some further work to mitigate this, including trying to automatically resolve problems, or at least show a better error message.

  • Construct Animate's export-to-video is faster than real time, whereas the Video Recorder plugin only records in real time. Each has their uses: if you want to export a 5 minute video without having to wait 5 minutes, faster than real time encoding is useful; if you want to be able to record a video which includes you interacting with the project, then you'll need to record that in real time.

    Construct Animate's free edition allows exporting videos up to 5 seconds - other than that limit everything else works so you can try it out yourself.

  • My best guess is a browser extension is interfering with Construct and causing a problem. Try disabling any browser extensions you have installed.

  • Addon SDK v2 runtime scripts can now import modules as of r398+, but note currently those are currently only beta releases, and so if an addon does that it won't work in the latest stable release. Therefore I've held off from documenting it as it just means people making addons that won't work for most people. However if you want to experiment with it in an addon and hold off on publishing it until the next stable release, then the way to do it is:

    1. Add two extra runtime scripts: main.js and myModule.js (see existing docs on adding extra runtime scripts)
    2. In the editor plugin, call this._info.SetRuntimeModuleMainScript("c3runtime/main.js")
    3. As the content of main.js, use:
    import "./plugin.js";
import "./type.js";
import "./instance.js";
import "./conditions.js";
import "./actions.js";
import "./expressions.js";

    Now you can write whatever you want in myModule.js, and import it in any other runtime script like normal, e.g.: 

    import { Thing } from "./myModule.js"

    Basically if your addon does not call SetRuntimeModuleMainScript(), it creates a default one that imports all runtime scripts - in this case including myModule.js, which isn't how you want imports to work. When you call SetRuntimeModuleMainScript(), then Construct only imports main.js, and then all other scripts are loaded by imports - which allows you to choose not to import every runtime script, and instead set up a tree of imports.

    When the next stable update is out I'll update all the SDK samples to use SetRuntimeModuleMainScript() so you can use those as templates.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

    I don't have much more to add, other than: yep, that sounds like a graphics driver bug. I've seen such issues plaguing software and game development ever since I started coding around 20 years ago. They're a total nightmare.

    Your best bet is still to try to get in touch with AMD - or perhaps report it to the browser vendors who may be able to figure out a workaround. For our part, even if we wanted to try to help, we'd have to start by ordering in affected hardware and building a system that reproduces the issue, which may then not reproduce the issue because it actually depends on something we haven't figured out yet; even if we reproduce it, it may be impossible to work around in our engine anyway, in which case we're back to square one. I've attempted such things in the past and generally it's hopeless, so it's best to follow up with browser vendors or the GPU vendor who are generally better prepared to deal with such issues.

    If using WebGPU works around it but there are other issues, you can report those to us, or list them here if they are already reported, and I will try to prioritize them. The architecture of WebGPU allows for much simpler drivers, which should hopefully make cases like this much rarer. In the long term our goal is to move to WebGPU by default and ultimately (probably very far in future) retire support for WebGL.

  • That shouldn't happen. Perhaps your addon is including a library that overwrites it? Or some accidental code that assigns over it?

  • That feature request appears to reference supporting looping conditions, which is now supported with the createLoopingConditionContext() API. All the old APIs around the event sheet manager, current event etc. where previously only there in order to support looping conditions, which is now more conveniently handled with the new API.

    I'd rather not expose the internals of the event system, as it is a very large and complex API, exposing such details to addons can severely limit our ability to make future improvements, and I'd rather addons did not tinker with the event system anyway, as sometimes addon developers do things that contradict the intended design of the event system. We could consider small, specific features, if they have a clear and important use case that cannot be feasibly achieved any other way.

  • Other storage APIs like IndexedDB should work fine in preview - in fact that's what Construct's own storage does. It doesn't do anything to prevent other code using them. So they should be working fine. Perhaps you made some other mistake.

    You could also use IStorage to access the runtime's own storage system, backed by localforage.