Ashley's Recent Forum Activity

  • The preview window needs to communicate with the editor window to load.

    Browsers throttle hidden/invisible windows to stop them slowing down your PC. So if the editor window is minimized/invisible and is throttled, it will work much more slowly, and then the preview will be slower to load.

  • We fixed this ages ago. Are you using an old version of Construct or something?

  • I just tried it and it works fine here.

    As ever if you run in to any problems please file an issue following all the guidelines, since usually it's impossible to help you without that information.

  • dop2000 is basically correct, but there are really 10 "Wait 0.5s" at the start - but they all run in parallel. So it's the same as if there was one "Wait 0.5s" at the start.

    Internally, you are creating ten "Wait 0.5s then add 1 to variable" operations, which all run in parallel so all the waits happen at the same time. This has the same effect as "Wait 0.5s then add 10 to variable".

    If you do something like "Wait loopindex * 0.5 seconds", then you create a sequence like this:

    Wait 0.5s then add 1 to variable

    Wait 1.0s then add 1 to variable

    Wait 1.5s then add 1 to variable ...

    These also run in parallel, but they finish at different times, resulting in adding 1 to the variable every 0.5s.

  • That won't do exactly the same thing: it will schedule the following two actions to all run at the same time after the same delay, instead of before.

  • Ah, OK. That looks about right, and is a similar pattern we use in Construct itself. It's true there is some documentation missing for this. I've updated the docs to cover SDKInstanceBase AddDOMMessageHandlers and a new page for the DOMHandler base class which has the runtime messaging features. As per our support policy, now these are documented we promise to support them.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This is a common misunderstanding of "Wait": it doesn't pause all event execution. (It wouldn't be much use if it did, since it would just hang your game.)

    It really means "schedule the remaining actions and subevents to run after a delay, then carry on". So the loop still completes immediately, and the wait schedules a bunch of actions/subevents to run afterwards.

    However in this case, there are no actions or subevents after the wait, so it schedules to do nothing after a delay.

  • What do you need this for? If it's related to this thread, as per my reply, you may be able to entirely avoid having to use a DOM-side script. If you can, that is definitely preferable, both for you and for us as we don't have more runtime code that risks breaking third-party addons whenever we change it.

  • By far the easiest solution is to load the SDK on the runtime side (i.e. in the web worker). If all the SDK does is use fetch/XHR/WebSockets etc., there's no reason it can't run in a worker: all those features are available in workers too. It may be that the SDK only needs a few minor changes, such as replacing window with self or globalThis, and then it may just work. You should ask the Photon developers about it.

    The issue is that I don't know a way for the domSide.js and instance.js to communicate synchronously.

    It's currently impossible, because when the runtime is hosted in a Web Worker, it has to communicate through postMessage which is fundamentally async. You have to design around it. For example instead of directly accessing the "Is connected" state, post messages when the state changes to update a boolean on the runtime side, which can be accessed synchronously. This can end up being very complicated for more advanced state, and especially so when there is a real-time aspect. In Construct that was the case for both Audio and Multiplayer, and both were extremely challenging to implement in worker mode due to the complexity of async message passing and state management. In comparison, the WebSocket plugin was easy to implement since it just uses the same APIs directly in the worker. So it will be far easier to adjust the SDK to support workers, which from a glance, looks like it may be easy, so I'd suggest trying that first.

    • Post link icon

    Please don't repeatedly bump old threads - closing this thread. The suggestion platform is the official place to post feature requests.

  • I tried doing exactly what you did in the video and it worked fine for me.

    Maybe it's something to do with your network configuration, or maybe one of your browser extensions is interfering somehow (I see you have several).

  • The server is returning 404 Not Found for the file box2d.wasm. Check it is uploaded. If it is, check the server MIME types are set up correctly, since some servers return 404 Not Found if they don't have a MIME type set up.

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,442,428 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x109
    Coach One of your tutorials has over 1,000 readers
  • x63
    Educator One of your tutorials has over 10,000 readers
  • x3
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x36
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs