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.
You'll need to restore a backup. This is one of the reasons it's essential to keep regular backups for any important digital work!
Do you use cloud save? If so the cloud service should have a version history you can recover it from. Otherwise you'll need to restore a backup...
I was asking where you save your project file. Are you using cloud save, saving to a local file, or something else?
Do you mean you are using Google Drive? It should have a version history for the file so you can restore an older copy.
Audio has long had a positioned sounds feature, but the listener was always pointing at the layout. It now lets you rotate the listener, e.g. to match a 3D camera. As ever, positioned sounds simulate the sound being in a certain position using a mix of panning and audio processing effects.
Measuring it is always the best way, but I'd expect using arrays to be much more efficient than tokenat() in some circumstances.
I haven't really done any real testing on the networking code yet, but I definitely will at some point. Poor network conditions might cause the hit event (and resulting explosion) to not visibly line up with the bullet or the unit it hit. But I think it can mostly be covered up reasonably well by the client. For example given the bullet movement is predictable, if a "projectile fired" message arrives late due to being delayed by the network, the client can advance the bullet to compensate for the lateness, and then it's back in sync. I'll be digging in to all those details in the blogs when I get to beefing up the network code.
Why would you want that? The quality will look poor if you scale it, whereas using a Text object will display with better quality.
I know, unfortunately links to specific lines in a file go stale over time as the file is modified. Perhaps links to text snippets like this would work better... but those will go stale too if things are renamed. I'm not sure there's any good way to consistently link to a snippet of code in a file that changes over time.
Obviously Construct has built-in collision detection and you can use that from both event sheets and JavaScript coding. But if you want to run in a separate thread you need another solution, and that's what I've done for this project. I could've instead chosen to use the built-in collision detection, but then I couldn't use multithreading, which would reduce the overall performance. I went in to detail about this architecture and its various tradeoffs in the architecture blog post.
The fact you can even do custom collision detection in a separate thread to the runtime is actually pretty cool I think! It shows Construct's flexibility: use the built-in collisions if you like, or write your own custom implementation in a separate thread. That could then even be split off in to something like a dedicated server running in node.js. Not all tools provide that kind of range of options.
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.