Online Multiplayer Object Sync Problem

Problem Description

Sync'd objects, on the peer side, pop in and out randomly, and may not all be created or destroyed when they are on the host side, but some will. This only happens with latency, simulated or not, and doesn't seem to be cause by either simulated PDV or packet loss, only latency, simulated or otherwise.

Attach a Capx

https://drive.google.com/file/d/0B8SU_2 ... sp=sharing

Description of Capx

The capx is as stripped down as I think it can be while still making the bug easily reproducible. I believe it might have something to do with bandwidth or just client inputs in general, so I set three client input values to constantly update, and that seems to be the main source of the bug.

Steps to Reproduce Bug

• Start up two copies, one host and one peer, in debug mode
• Look at the object counts for Peer and Test and watch how they deviate
• If nothing happens at first, wait a little longer, or refresh/restart the peer copy.

Observed Result

Object counts go down or even zero, then back up but sometimes not all the way. i.e. The test count which should be 5 will drop down to 0, then come back up to 3, then maybe go up to 5 or go back down to 0 again.

Expected Result

I expect objects not to randomly be destroyed on the peer side.

Affected Browsers

• Chrome: YES
• FireFox: n/a
• Internet Explorer: n/a

Operating System and Service Pack

Windows 10 Home 64-bit

Construct 2 Version ID

Release 244 (64-bit)

Did a quick check:

There appears be an issue when there is no position syncing happening. At least from what I can tell.

Without position syncing for the test objects and peer objects (as in the given example above) one of the peer objects vanishes here on my system for the peer. (object count for peer)

When I enable position syncing for both objects, the object counts are as they are supposed to be.

This issue arises also arises when I just have the peer object with position synced and the test object without position synced.

PS

In the past I ran into this issue a couple times too without narrowing down where it originated from;

it happened when I tried to make my own position syncing system where I wanted to have the objects automatically created (synced) based on the peers created and maintained on the host side. (just the object amounts)

This did not work nicely in the past so I made creation and destroy events on peer/host for peers connecting/disconnecting on the host end.

This manual approach worked well, but required a lot testing and quite some extra events.

Without position syncing for the test objects and peer objects (as in the given example above) one of the peer objects vanishes here on my system for the peer. (object count for peer)

When I enable position syncing for both objects, the object counts are as they are supposed to be.

This issue arises also arises when I just have the peer object with position synced and the test object without position synced.

So then Multiplayer Sync Object (none) pretty much totally breaks multiplayer whenever there's any significant amount of latency. That sounds like a bit of an issue.

> Without position syncing for the test objects and peer objects (as in the given example above) one of the peer objects vanishes here on my system for the peer. (object count for peer)

>

> When I enable position syncing for both objects, the object counts are as they are supposed to be.

>

> This issue arises also arises when I just have the peer object with position synced and the test object without position synced.

>

>

So then Multiplayer Sync Object (none) pretty much totally breaks multiplayer whenever there's any significant amount of latency. That sounds like a bit of an issue.

Not sure its due to the latency, with position syncing more information is passed along, potentially causing more lag/latency.

But seeing as the this scenario appears reversed here (more syncing works better) I am guessing there is a glitch somewhere in peer creation/count when no position syncing is used.

It looks like that might not be the only problem. I tried setting every sync'd object to position sync and that did work with the capx I provided, but not with my project. Going to try to strip down my project to find another contributing factor to the bug, when position sync is enabled on all sync'd objects.

Not sure its due to the latency, with position syncing more information is passed along, potentially causing more lag/latency.

But seeing as the this scenario appears reversed here (more syncing works better) I am guessing there is a glitch somewhere in peer creation/count when no position syncing is used.

When I set latency to zero in Simulate latency, or turn simulate latency off entirely, there seems to be no problem; the bug stops happening.

update:

Irrelevant now

So I haven't narrowed it down totally yet, and I won't get the chance to until a bit later, but I think if you have positions synced on everything, the bug still persists if the peer object is constantly moving on the host side through the custom movement behaviour

https://drive.google.com/open?id=0B8SU_ ... HQwVWJiNkU

Another capx, this time showing object sync failing even when all objects sync'd all have position sync on. Either the test objects don't load in at all on start on the peer side, or they do load in, then disappear some seconds later. Setting latency to 0 in Simulate Latency fixes this, while setting PDV or packet loss to 0 seem to have little or no effect on it.

bump

This is incredibly difficult to debug since it seems non-deterministic and latency-sensitive. In particular latency issues are very thorny since simply setting a breakpoint in the debugger changes the latency and can cause issues to change :-

If you look in the browser console you can see it logging some errors about being unable to read data. I think it's failing to read data for some message, which causes it to fall back to an error path which means for some objects it considers it to have received no messages. In the multiplayer engine if an object does not receive data for ~3 seconds, it destroys it as presumably having timed out. So I think disappearing objects is caused by the timeout, and the real problem is being unable to read data. I've not been able to isolate it much further than that though. As ever producing an even smaller, simpler reproduction would help.

In the multiplayer engine if an object does not receive data for ~3 seconds, it destroys it as presumably having timed out. So I think disappearing objects is caused by the timeout, and the real problem is being unable to read data.

So couldn't you disable the part that destroys objects when timed out? Or maybe add some sort of option for it? It seems that the timeout-destroy creates more issues than it solves, at least in this instance. The problem of reading data only ever seems to be momentary, anyway.

> In the multiplayer engine if an object does not receive data for ~3 seconds, it destroys it as presumably having timed out. So I think disappearing objects is caused by the timeout, and the real problem is being unable to read data.

>

So couldn't you disable the part that destroys objects when timed out? Or maybe add some sort of option for it? It seems that the timeout-destroy creates more issues than it solves, at least in this instance. The problem of reading data only ever seems to be momentary, anyway.

I second that. I think a simple action to manually override the destroying timeout would be really useful for specific cases like this one.

Ashley It would be amazing if you could add this to your todo list for the next C2/C3 beta update.

No, that's just papering over the cracks rather than fixing the actual underlying issue. There is data being received but it's not resetting the kill timer for some reason. And the kill timer is important in case the destroy notification was lost in transit, ensuring it reaches an eventually-correct state rather than piling up zombie objects when packet loss occurs.

No, that's just papering over the cracks rather than fixing the actual underlying issue. There is data being received but it's not resetting the kill timer for some reason. And the kill timer is important in case the destroy notification was lost in transit, ensuring it reaches an eventually-correct state rather than piling up zombie objects when packet loss occurs.

Well then I guess it's all up to you Ashley.

Is there any possible way to help you out with this? Is there something wrong with the samples that bjayfont provided you?

(Sample 1 | Sample 2)