Ashley's Forum Posts

  • Browsers don't have permission to use raw network connections like sending UDP packets. You can only use the browser networking APIs like WebRTC, AJAX or WebSockets.

  • You will stay on the free edition unless you purchase a plan. If you have made a purchase and have an issue with that, please contact supportnmo@construct.net.

  • Chrome has a flag for mDNS in chrome://flags too. I'm not sure if it's on or off by default, but switching that to "On" might help too.

  • I had got the impression this problem occurred on all mobile devices, not just iOS, since the thread didn't specify it only happened on iOS (or did I miss that?)

    If it only happened on iOS, and that fixes it, then that's great! I guess mDNS helps establish local connections. Generally those experimental options eventually graduate to enabled-by-default, so hopefully that will just work out of the box in future.

  • I think a "minor suggestions" category might help, so I created it.

    I do think there could still be some problems though:

    - not everyone can estimate how easy their idea really is, e.g. "just add a checkbox that says 'Enable 3D'. It's just a checkbox!"

    - some people may firmly believe their idea is really easy and get offended if a developer disagrees

    - it can actually be quite a lot of code review work to identify if something really can be done easily

    - sometimes it's not until you actually develop something that you realise it's tougher than you thought - you might end up having to restructure things to do it, and the restructuring might end up breaking or affecting something else, causing the job to rapidly escalate. So even our own estimations can be off.

    Still, let's see how it works out. Hopefully people are generally OK with ideas they thought were minor being moved to another category if it's discovered they are in fact more complicated.

  • The ICE candidates are generated by and read by the browser, and the browser is what attempts the connection based on the information. As I mentioned Construct has no part in this particular process - its only job is to swap them between each device, which is what the signalling server does.

    However if you inspect the ICE candidate information that the browser generates, it may identify some leads.

  • It's a peer-to-peer connection done with WebRTC DataChannels, much like the multiplayer feature. However all the connection details are handled by the browser and it's not an area I know a huge amount about the internals of, so it's difficult to comment further. Our role is largely just the signalling server. Both sides generate some connection info about how they can be reached, our signalling server merely swaps those so each side gets the other's connection info, and then it tries to establish a connection.

    This is different to the HTTP server model used by Construct 2, which is more of a client-server model so in that sense is probably simpler. But you can't run a HTTP server in the browser - which is why Construct 3 does it differently. Also the HTTP server model had its own issues - sometimes you had to configure the firewall; sometimes you had to try a different port; sometimes you needed admin permission (which in some cases you can't get); some people had an altered system "hosts" file which broke it; sometimes Windows would just return a mysterious error code and refuse to work, for reasons we never figured out. So that was never a perfect option either. As with most things in technology, any particular solution has a series of tradeoffs, and other solutions have different tradeoffs and aren't always clearly all better or all worse. I like Remote Preview because it's convenient with the QR code, doesn't need any specific configuration, and works over both local networks and the open Internet. But I guess the connection speed is not always perfect.

    One potential workaround is if a HTTP server really is much faster, you can host your own local HTTP server using tools like nginx, caddy, python or node. It requires a bit of technical set up, but then you have a folder you can do a HTML5 export to which you can load on your phone from your PC's local HTTP server. (Edit: I realise that the original post pretty much does exactly this! So you're ahead of me on that one.) Then to make that work more smoothly we could explore a feature like "quick export" which just does a default settings HTML5 export to a local folder (which we can directly write to with the new native file system API in Chrome). This is the kind of thing which despite not being ideal and still taking some work to put together, is still far less work than coming up with an entire "Remote Preview 2" type feature.

  • Global variables have no association with specific layers or layouts, so the question doesn't seem to make sense. Global variables are available across the entire project.

  • There's a big difference between Remote Preview to someone else over the Internet, and remote preview over your local area network (LAN). Over the Internet may well be slow, since it will be limited by your upload speed. Over a LAN, it should be super fast, since the devices can communicate locally at a very high bandwidth.

    I have no idea why a LAN would be slow as some people describe though. As I said I have what is probably a typical home wifi setup and it's really fast. Maybe it's routing everything over the Internet for some reason, even though the devices are local. I don't know why that would happen though.

    Time is by far our most limited resource and these features are difficult to implement and hard work to maintain. I really don't want to have to do loads of work to implement a sort of "Remote Preview 2" feature just because we don't understand why some LANs seem to be slow. I would much rather figure out precisely what the problem is, and what else can be done about it. For example perhaps there is some network setting that can be changed and makes everything super fast again. If that's the case it provides a workaround in case Remote Preview is slow, and we can document that and point anyone having trouble to a guide. Also the results people state with C2's preview-over-wifi suggests that fast speeds over LAN is possible, so there may be something that can be done to reach that speed in C3 too.

    Another risk of not understanding the problem is we could end up doing loads of work for "Remote Preview 2", and then it's still slow! How do we know that won't happen if we don't know what the problem is in the first place? That's why it's essential to start by working out what the actual problem is for some people.

  • If you have a physical device, you can connect the USB cable and test on that.

  • That's right, I'm afraid. If Apple fix the problem with the iOS simulator, it will start working there too.

  • Construct currently just fits the SVG to a 500x500 box. If that's not the right size you can resize them in the Layout View.

  • As I've said before, remote preview should be very fast so long as it can establish a LAN connection. I just tried Space Blaster over remote preview and it loaded in 3 seconds for me.

  • The iOS simulator is not supported due to a Apple bug. It should tell you this if you try to run your app in the simulator.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • See delta-time and framerate independence. Currently physics defaults to framerate dependent, and you have to opt-in to making it framerate independent.

    This stems from what was a poor choice years ago, and it's difficult to change, but I think we will have to change it, since it's not the first time I've seen this...