Ashley's Forum Posts

  • If you export with minification enabled, it's combined in to the runtime code.

  • You do not have permission to view this post

  • For the record, this is documented in Keyboard shortcuts, including Alt+Preview, Alt+4, Alt+5.

  • Here is a test project I made that loads a local project file with AJAX: https://www.dropbox.com/s/tuthzoi8maxca8a/ajax-file.c3p?dl=0

    I tried reloading the preview 10 times - it works fine for me every time in r229.

    • Post link icon

    For the record, in this comment on the filed issue I've tried to explain the complexity of the problem, how we sometimes have to make changes over time, and the difficulty in getting it to work in all cases. Hopefully it will work better in the next release.

  • Construct 2 is no longer available for sale and will be fully retired in July, as per the schedule in Sunsetting Construct 2 that we announced in February.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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.