Ashley's Forum Posts

  • You must have done something wrong. If you choose the Linux (CEF) export option, it has no dependency on Microsoft Edge WebView2 at all.

  • The link you pointed out is intended to go to construct.net. That's the site for Construct 3 and Construct Animate!

    It's usually impossible to help from just a picture of a crash - especially because the screenshot only includes a small amount of the crash report information, and nothing relating to the actual crash that happened. It's best to file an issue following all the guidelines to ensure we can properly investigate - or at least copy-paste the full crash report, otherwise there's nothing we can tell beyond "it crashed".

  • The situation you described shouldn't normally result in a conflict. Suppose Layout1 has instances of ObjectA and ObjectB. User A modifies the position of some ObjectA instances on Layout 1. Meanwhile you change some properties of ObjectB which change how they are saved to the layout file. These should result in non-overlapping changes (i.e. they affect different lines in the layout JSON file) which all get merged fine.

    Conflicts only occur when two users both modify the same lines with conflicting changes - such as if you both modify the position of ObjectA instance 1. Now the line in the layout JSON file with the position of that instance has two conflicting changes, so the source control tool will ask you to resolve the conflict.

    I'd suggest having some policies about how your team work to reduce the chance of conflicts - for example making regular small incremental commits is better than waiting a month and making a huge commit with tons of changes which has a much higher risk of conflicts. And of course avoid directly working on the same thing at the same time.

  • WKWebView has basically the entire Safari browser engine. The main difference for Construct with video playback is to get the video to render inside the canvas it has to do texture upload of the video to WebGL/WebGPU every frame. That can work efficiently and be fully GPU-accelerated, but it seems to be a bit problematic on some platforms. You can bypass it by just using a video tag in a HTML element object, and HTML layers if you need more layering - that will just play the video normally, but with limited features in other ways (e.g. because it's not rendered inside the canvas, it won't respond to layer opacity, effects etc.)

    FWIW I think the AI is wrong - Construct mobile exports do not run on the file:// protocol, it uses a custom scheme handler and works much the same as a HTTP server, and I don't think that GPU acceleration is affected by how anything in the networking stack works (I've never heard of such a thing before nor is there any obvious technical rationale to do that). I think it's still the case that AI doesn't say "I don't know", it just makes up plausible sounding guesses.

  • IIRC .mov is an older variant of .mp4. I didn't think there would be any significant difference in support for them and everything on the modern web would use MP4 instead of MOV. Are you sure you've encoded the video correctly?

    AFAIK alpha support for video is pretty inconsistent in browsers at the moment - you might have better luck encoding the alpha channel as a separate greyscale video, and then using it like a mask.

  • Controller support should work, but for Steam you need to install the GameInput redistributable. See the instructions under "Gamepad support" in the Steamworks plugin documentation. If it still doesn't work, please file an issue following the guidelines so we can properly investigate.

  • Whenever we've seen reports of "getModifierState" in the crash message, it's usually been a browser extension interfering with Construct and breaking it. Try disabling any browser extensions you have enabled. It would be useful to know which extension was causing this if you can find that out.

  • Whenever I test Steam support, it works fine for me - both on PC running with Steam or on the Steam Deck. That indicates everything on Construct's side is working OK - if it wasn't, then it wouldn't work when run in a test or development environment. If there's a problem with publishing, then that is all happening on Valve's side, and it's beyond our control - for example if there is some bug or issue with Valve's upload or publishing process, we can't fix it for them, nor is it reasonable to expect us to do so. So I'm afraid it is one of the times you have to go to another company for support with that, as it's not something we are involved with.

    We don't have titles that we publish ourselves, so it's a difficult thing for us to test. However it's one of these things where even if we did try to publish something ourselves, and it is broken because of something on Valve's side, it doesn't change much - we would still need Valve to fix it. So I don't think that makes too much of a difference here.

    AFAIK there are Construct users who are publishing titles to Steam, and the process isn't significantly different between NW.js and our newer export options, so I would assume this is working for at least some people. I'd guess that there is some configuration issue, mistake, or bug that only some people are running in to; if we can figure out what that is then hopefully it would be all sorted. But I would encourage you to go to Valve first, as I don't think there is much we can do about this.

  • I think this is something of a non-obvious consequence of changing the default Z axis scale from 'Normalized' to 'Regular'. It usually makes the Z axis work on a larger scale, e.g. for 100% zoom the camera Z would be ~600 instead of 100. However since the project near and far distance haven't changed, changing the Z axis scale effectively makes the zoom range smaller.

    I'll update the default near/far distances to allow a wider zoom range for the next release - but for existing projects you'll need to modify those values yourself. I'd recommend a near distance of 10 and far distance of 100000 (i.e. 10x the previous values) to allow a wider zoom range without significantly impacting depth buffer precision.

  • I don't think it's fair to blame Construct if Valve's upload process rejects a regular zip file.

  • Check the 'Far distance' in the advanced section of Project Properties, and try increasing it. The 2D editor zoom level is locked between the near/far distance, because if you move the camera outside that range, everything would vanish as it's no longer in the renderable range.

  • Are you sure you're using the latest release? If I open a project and switch the Z axis scale back to 'normalized', the option appears for me:

    You might also want to review the near and far distances in the 'Advanced' section - if you had previously changed those, you may need to increase them for Z axis scale 'Regular'. Those also affect the maximum zoom range in the Layout View.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • When I upload the zip without changing it, I always get "Error: Failure."

    You should contact Valve if there's a problem with the upload process. Construct is just generating a regular zip file - I don't know what could be wrong with it or what we could change.

  • Yes - have a browse through the reference in the documentation and you'll find the ILayer method cssPxToLayer() as well as lots of other useful things.

  • Most input events like keyboard, mouse and pointer input are fired on IRuntime so you don't need to forward them yourself. For example you can write runtime.addEventListener("pointerdown", e => OnPointerDown(e)), just like you would with document or window in the DOM.