[SUGGESTION] Expression: multiplayer.listroomlatency(index)

Hello!

Multiplayer Plugin is really powerful and easy to use but I think there is an expression that would be extremely useful. Something like multiplayer.listroomlatency(index) which would return the average latency of each room (by index) after On Room List.

This would be extremely useful to create a quick match finder that picks the lowest latency or even a server list (using the form object List) ordering rooms by latency.

I know there is a workaround to implement this by joining every available room, storing latency inside an array, leaving the room and then manipulate the array but this approach can cause problems with the Sync Object since it automatically creates objects for each peer that joins the room.

\o/

heh ... with associated objects, when you leave .. your objects get destroyed in those rooms.

but euhm, This latency ... isn't this rather the host latency ? and the signalling server would never be able to predict this seeing as its location is not yours ?

Your method of workaround actually sounds decent, seeing as you would get the latency between you and the host of each room.

Downside is that during this action you would effect each games host and peers their performance for a few seconds as your stuff gets created and destroyed.

heh ... with associated objects, when you leave .. your objects get destroyed in those rooms.

but euhm, This latency ... isn't this rather the host latency ? and the signalling server would never be able to predict this seeing as its location is not yours ?

Your method of workaround actually sounds decent, seeing as you would get the latency between you and the host of each room.

Downside is that during this action you would effect each games host and peers their performance for a few seconds as your stuff gets created and destroyed.

The main problem of the Sync Object while using this method of workaround is that the peer may not be in the same layout as the actual game layout, this usualy cause unexpected bugs when the multiplayer engine tries to sync objects for players in different layouts. (e.g. host is playing a match in the layout "game" and the peer is checking the latency in the layout "lobby", the engine will try to sync objects and associate objects in the wrong layout). Also this method can't check latency of full rooms and locked rooms because you can't join those rooms.

This expression should return the latency between the host (of each room) and the peer that calls the expression and not the latency between host and signaling server.

• Player calls request room list
• On room list triggers
• A For loop feeds an array with listroomname, listroompeercount, listroommaxpeercount, listroomstatus and listroomlatency (For each loopindex)
• When this multiplayer.listroomlatency(loopindex) is called a generic message should be sent to the signaling server,
• signaling server should send it to the target host (current index),
• target host send it back to the signaling server
• signaling server send it back to the caller of the expression containing the average time (in ms) that the message took to reach the host and return.

> heh ... with associated objects, when you leave .. your objects get destroyed in those rooms.

>

> but euhm, This latency ... isn't this rather the host latency ? and the signalling server would never be able to predict this seeing as its location is not yours ?

>

> Your method of workaround actually sounds decent, seeing as you would get the latency between you and the host of each room.

>

> Downside is that during this action you would effect each games host and peers their performance for a few seconds as your stuff gets created and destroyed.

>

The main problem of the Sync Object while using this method of workaround is that the peer may not be in the same layout as the actual game layout, this usualy cause unexpected bugs when the multiplayer engine tries to sync objects for players in different layouts. (e.g. host is playing a match in the layout "game" and the peer is checking the latency in the layout "lobby", the engine will try to sync objects and associate objects in the wrong layout). Also this method can't check latency of full rooms and locked rooms because you can't join those rooms.

This expression should return the latency between the host (of each room) and the peer that calls the expression and not the latency between host and signaling server.

- Player calls request room list

- On room list triggers

- A For loop feeds an array with listroomname, listroompeercount, listroommaxpeercount, listroomstatus and listroomlatency (For each loopindex)

- When this multiplayer.listroomlatency(loopindex) is called a generic message should be sent to the signaling server,

- signaling server should send it to the target host (current index),

- target host send it back to the signaling server

- signaling server send it back to the caller of the expression containing the average time (in ms) that the message took to reach the host and return.

I meant the connection between the host and the peer wanting to know the latency.

To get the latency, you would actually have to transmit some data back and forth resembling the game data in order to get a decent estimate about latency between the peer wanting to know the latency and the host hosting the game.

To overcome the obstacle of on which layout is what ... simply add some checks for on which layout it resides. There is an expression LayoutName, which returns the current layout name.

LayoutName <> "lobby" should prevent it from checking while it is in the lobby

I meant the connection between the host and the peer wanting to know the latency.

To get the latency, you would actually have to transmit some data back and forth resembling the game data in order to get a decent estimate about latency between the peer wanting to know the latency and the host hosting the game.

To overcome the obstacle of on which layout is what ... simply add some checks for on which layout it resides. There is an expression LayoutName, which returns the current layout name.

LayoutName <> "lobby" should prevent it from checking while it is in the lobby

I see... but the problem is: Sync Object is a setting that (as far as I know) can't be disabled during runtime. Once it is set it will automatically start to create objects everytime the player joins any room (Sync Object is usualy set before connecting to the signaling server and persists forever while the game runs) . If we had an action like Desync object to disable it when needed it would be possible to use your method.

We could think of executing the Sync Object action only when the layoutName == "game" but (as I said) it will persist during runtime even if the player leaves the room, so if the player tries to check latency after (in layout "lobby") the Sync Object would be previously enabled, causing the unwanted behavior of creating objects.

Do you know any way to disable the Sync Object after it was executed?

Yes .. but you have to 'event' it ... not so much disable it ...

For instance, a peer wanting to join has a global variable: playing default 0

When wanting to know the latency, and joining room for it ... leave the playing at 0.

Peer joins a host

Host:

On peer connected, send message, check playing.

Peer receives messages, and replies: 0

Host sees the 0 ... and does not create the needed objects.

Would the host receive 1, (perhaps set in the lobby when a peer selects to join a game instead of wanting to check latency)

The host would then create the required objects for the peer.

"Host sees the 0 ... and does not create the needed objects."

This can't be done. Sync Object is automatic, it doesn't have an option to create or don't create objects.

The only thing you can do is don't create the object that represents the peer on the host side but all the existent synced objects on the host side will be created on the peer side automatically.

Example:

Synced objects:

• player
• bullet

On peer connected, send message, check playing

Peer receives messages, and replies: 0

Host sees the 0 ... and does not create this peer player object

Every other synced object that already exists on host side (player object associated with the host and bullets) will be automatically created on the peer side regardless of if check playing was 0 or 1. (and this can't be disabled during runtime).

*Bullets spawning on the lobby!*

True true, but you could ofc just have it invisible by default, and that after some ping pong like events, the players gets activated and is brought into play ?

Construct 2 games often have a base object, on which another sprite is pinned with player animations.

If the base gets synced, you could simply not create the extra objects.

True true, but you could ofc just have it invisible by default, and that after some ping pong like events, the players gets activated and is brought into play ?

Construct 2 games often have a base object, on which another sprite is pinned with player animations.

If the base gets synced, you could simply not create the extra objects.

Well this is a good solution (At least for simple games). But I hope that in the future we get an update to make this more practical and safe.

Always good to discuss with people that also understand MP btw

Thanks for taking time to reply to this, lennaert!

You're very welcome

I have made various methods for entering and leaving rooms.

One of the more controlling approaches is to simply loop through the peer list on the host, which determines their states as well, and based on that list create objects.

Another loop runs those object, checking if that peer still exists.

This gives you full control of who is in or not in a room and what to do with their objects.

Sadly this turns listroompeercount, listroommaxpeercount and listroompeerstate useless since we would have to create rooms with no peer limit so anyone can join merely to test ping. We would have to analyze all these information manually (and also implement the room locking system through the event sheet).

This listroomlatency to get average latency before joining rooms would save us from a lot of rework and I think it can be added to the mp plugin. It would be simply a join room which ignores peer limits, locked state, synced objects and does not fires any peer related trigger on the host side. It would be simply a "stealth join room" :'D

Heh, sounds logical enough.

Doable is another thing.

I think it could add to the ease of use when testing connection quality.