It should keep working - if any breaking changes happen that aren't clearly noted please file an issue for them as they are probably accidental.
It just means a new field has been added when inspecting the Multiplayer object in the debugger.
I'm not sure. I'll try removing it from the next beta and see how it works out.
It sets --disable-features=HardwareMediaKeyHandling on the command line.
Huh, I didn't know the black bars needed redrawing too. Has anyone ever reported these problems to Valve? In my view they really should be fixed by Steam, since adding weird compatibility hacks can cause their own problems, especially with these command line switches (Google could remove them at some point, there isn't any support guarantee for those).
Remember the 41 suggestions excludes loads of work done elsewhere. For example you recently requested some improvements to the Project Bar - that was done but counted as bug fixes. It also includes features that were difficult and time-consuming to implement, but still count as just 1 suggestion. Further, it's always easy to write, "you should have done more". If we did 100 suggestions, someone could write, "you should have done 200". If we did 200, someone could write, "you should have done 400". It's easy to write such things. It's much harder to do it.
If you run in to any problems please file an issue following all the guidelines, otherwise it's impossible for us to help.
We aren't aware of any issues with copying and pasting. If you run in to a problem please file an issue following all the guidelines so we can properly investigate.
It doesn't work in Firefox because Firefox doesn't support using modules in workers yet. They're currently working on adding support for that though.
Yes, it was deprecated a few years ago IIRC. The addon wasn't marked deprecated here though, so I just updated it.
If you send positions with deltas, then do you send deltas when the position changes? If so it's near enough reinventing full updates, which use too much bandwidth for this project. If not then there's probably still going to be drift away from the true position, so you'd need something like full updates to occasionally correct it.
The bandwidth requirements for this project are pretty serious too - sending any data that is not strictly necessary could push the bandwidth over the 100 KiB/s goal.
I think the big problem is delta updates don't send a position, so over time errors would accumulate and everything would drift too far from where it's meant to be. Sending the full updates over 2 seconds uses a tiny amount of bandwidth and means errors only accumulate for up to 2 seconds.
If you have any backups you've made, or if you set up Construct to make backups for you, there may be a file you can restore in the backup location. However if you did not make any backups, I'm afraid there is not any way to restore a lost local file save - unfortunately this may be a hard lesson on the importance of keeping backups.
This issue has not affected any stable release. It only affected r319, which is a beta release that requires people to opt-in to use it - the default version is a stable release.
It's essential to keep backups of any important digital work you do. If you have made backups then you need to find one of your backups and restore it. If you have not made any backups or set up Construct to make backups for you, then I'm afraid there isn't any way to recover a lost local file save - unfortunately this may be a hard lesson in the importance of keeping backups.
Member since 21 May, 2007
The official blog for all things Construct and Scirra run by our employees!
Wider technology issues from Ashley's perspective.