Peer "ghost" in multiplayer when changing/resetting layouts

Hi all !

I've been encountering a small glitch in multiplayer when changing/resetting layouts ; basically, peers positions' still seem to interpolate between the old position and the new one (before/after changing layout), and peers also leave a "ghost" (multiple instances of the peer's player object bound to the same peerID)

Surely it's got something to do with the way I use Multiplayer.Associate(peerID), or some assumptions about the layout transitioning logic I don't fully understand (my guess is that all objects should be wiped clean and re-create, but are they...?)

Bottomline question : what happens to synced objects during layout transitions ? What are the best practices in terms of object creation/destruction and peer association to deal with layout transitions ?

I have re-created a "small" .capx example demonstrating the problem (nothing is really "small" with multiplayer, even if C2 makes it easy, but it's as minimal as I could make it) : 2+ players (blue squares) need to collect all the collectables (yellow squares), upon completion the layout is restarted (hosts restarts and broadcasts a "restarts" message to peers)

.capx : https://db.tt/4X0NpqRh

video : https://db.tt/5qaa0ktJ

4 layouts to deal with the front-end and 4 stages of multiplayer setup : menu (checks for multiplayer support), login (player id), matchmaking (room id), and lobby (multiplayer set up, waiting for all players to be "ready")

1 dummy layout containing prototypes of all entities

1 actual "game" layout where the collection / restart logic is

WASD to move

Any suggestion would be greatly appreciated <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":D" title="Very Happy"> Thanks !

How about making the peer objects global ?, and destroy them when a player leaves/disconnects, and hide the peer in menu screens. (if needed)

Solves a lot of creation issues

Interesting ! That would make peer objects persist across layouts, giving me full control of their life cycle (created by the host, destroyed when players disconnect as you said). That should remove the destroy/re-create question altogether. Thanks

I'll investigate that ! Though I'm still curious about what actually happens to synced objects when changing layout

There is a moment of layout transition on 2 parties, happening at different moments. (host side/peer side)

You could have solved the issued performing a check if the object you are about to create already exists.

pick all peer

pick peer by evaluate peerid = peeridat(loopindex)

else

create peer

Ahaaah ! Great, thank you very much, I will be experimenting with all this !