Ashley's Forum Posts

  • See the note in the manual:

    The "is online" detection of the Browser plugin is more or less a guess. It is actually difficult to categorically determine if an Internet connection is available. For example the user may have intermittent signal, and online features sometimes work and sometimes fail unpredictably. In this case the "Is online" detection is probably wrong, as it can't actually tell whether a connection will work. Rather than using this condition to check if online features will work, usually it's better to just go ahead and use online features anyway as if the user is online, and handle any errors that occur as a result.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • "This app requires the Microsoft Edge WebView2 runtime. It will be downloaded and installed for you now."

    Use the Linux exporter for the Steam Deck. Don't use the Windows WebView2 exporter - despite the Windows compatibility on Steam Deck, it's not good enough to run WebView2, but the Linux exporter runs natively. See Exporting to Linux and the Steam Deck.

  • In the NW.js object, there is a ReadFile expression (not an action) that synchronously reads the content of a file and returns the content as a string.

    However I would advise using the File System object with one of the newer export options. NW.js is deprecated so will be removed in future, and the File System object can read files asynchronously which is usually better for performance and avoiding jank.

  • It looks like GetAccessToken() wasn't available in SDK v2 due to an oversight - I've added an equivalent getAccessToken() method for the next beta (which would be called via runtime.objects.Facebook.getAccessToken().

    The existing IPlugin static method getByConstructor() and methods getSingleGlobalObjectType() and getSingleGlobalInstance() allow for retrieving an object type or instance for a given plugin constructor, but you won't need those for calling getAccessToken().

  • You do not have permission to view this post

  • You do not have permission to view this post

  • It should already be possible. Set the drawing blend to 'Destination out' and any opaque drawing will erase.

  • If you're doing something like stepped collision checks, then you can just use any fixed time step. The only difference it makes is how many checks/collision accuracy. For example you could just use a fixed time step of (1/60) and it will have about the same accuracy as frames when running at 60 FPS but with no variation at all because you used a fixed step.

  • Don't use 'Execute Javascript', you can just insert a script action directly in the event sheet which is much easier to work with.

    You probably need to turn off 'Use worker' in project properties, as by default the runtime runs in a web worker without direct access to DOM properties like 'window' and 'document'. The manual guide on JavaScript in Construct explains that more. And if you use a script action in the event sheet, Construct defaults worker mode to off so all those APIs will just work like you expect.

  • Yeah, if you are calculating something like where an object will end up after 1 second, you definitely should not be using delta-time. The only input to that calculation should be 1 second, because that's how far ahead you're calculating the movement. If that's the case the problem is not that there are small random variations in delta-time, it's that you're fundamentally doing the wrong calculation.

  • Delta time has small random variations because neither the refresh rate of your display nor the timer measuring the time between the display refreshes are perfectly accurate. However this should not normally matter.

    It's also actually correct that it varies, if your display refresh rate varies too. For example suppose a display had an irregular refresh rate: one frame was displayed for 50ms, then the next frame was displayed for 100ms. In this case the delta-time measurement should be 0.005 then 0.01, so that the motion of the game is lined up to the actual display refreshes. If you smooth delta-time or otherwise don't use the actual value, then it can actually add jank and inconsistency, as in this case the game might do something like advance motion by 75ms when the image is shown for either 50ms or 100ms, either undershooting or overshooting. Given the prevalence of variable refresh rate displays, this may be a more likely scenario than it seems.

    I think the problem in this thread may be that you've jumped to conclusions. The object you showed wobbling is not actually moving. So why is it using delta-time? This appears to be a logic problem with your events. I don't think you should be using delta-time at all there.

  • Messaging between frames on the same page can be done with the postMessage() JavaScript API. Some services also provide a JavaScript API you can use.

    If neither is applicable and you want to communicate with an entirely separate application which does not provide any JavaScript API, it is tricky. Your best options are probably a WebSocket or a browser extension - but you'll still need to know how the external application works and how to message it.

  • That sounds like a regular cross-domain request issue, and that's also covered in the manual.

  • The current plan is to include it in the next LTS release - due out in the middle of this year (June/July) - and remove it after that. Then you can keep using the LTS release with NW.js included for another 18 months beyond that.

  • You can use the Timeline Controller object's 'Set instance' action to set a different instance to play a timeline with. See the Timeline instances example. If you want to play for all instances, you could try something like 'For each Sprite - set instance Sprite, play timeline'.