Is Multiplayer Broken?

Can someone tell me what I'm doing wrong?

Multiplayer appears to work perfectly fine, right up until it doesn't. When it crashes, it's impossible to reconnect without completely restarting the program.

I thought it was something I had done wrong with my game, so I decided to simply make a program that purely connected to a multiplayer room, then restarted.

I tried adding in all kinds of leaving the room, etc, just to see if there was something I was missing.

It works if I have the player leave the room, but what if the signalling server goes down?

https://1drv.ms/u/s!Am3CPIM7woZ9i-gVN45be9UWV5ulgA?e=2JGq39

I think you misunderstand.

It only works if you leave the room first. If, for some reason, you disconnect from the server, you cannot reconnect.

That's not right, surely.

Yo DO have to wait to be disconnected from a room before you disconnect from the server, that is just how things go. I guess, if you are like me, you'll understand why you will rather stop/park a car before moving out of it ? Kind of the same thing here.

This is a common mistake. Leaving a room is an asynchronous process and takes a moment to complete, triggering "On left room" when it's done. However if you disconnect from the signalling server at the same time, the connection drops and so the leaving room process cannot be completed. This leaves the game in an inconsistent state: the signalling server still thinks you're in the room because you never finished leaving, but the game doesn't think you're in the room, and so if you try to rejoin you're effectively joining twice and so the signalling server returns an error.

It's one of many reasons multiplayer logic is difficult. You have to have both the remote and local systems in sync, and if your logic gets them out of sync, things go wrong.

This is all very interesting... but let's go back to my initial question.

"but what if the signalling server goes down?"

I understand that at present you should leave the room BEFORE leaving the signalling server... but why doesn't Construct have measures in place to sort this out?

Why is there even an action in Construct that will completely break a feature?

If someone chooses to leave the signalling server before leaving a room, why doesn't Construct leave the room first automatically? In my tests, it takes 0.4 seconds to do that. Any less, and things break again. If it detects that we're in a room when we lose access to the signalling server, why isn't there some kind of safety in place to stop the multiplayer plugin from breaking entirely.

You all keep talking to me as though I'm not understanding what you're saying, while steering around my actual question. I mean, the solutions you're offering me is exactly what is already in my code!

For example, while testing this out, I unplugged my ethernet cable. How do you code for that? What if your ISP goes down? What if you have a power cut? Hell, what if you switch from wifi to 4g?

At present the only result is "Entirely break the multiplayer plugin, requiring your app to be reset!"

How is that an acceptable answer?

I was playing Apex the other day, and lost connection. When it recovered, I was able to join the game again immediately. They didn't expect me to quit Apex and reload it.

If you get forcibly disconnected, e.g. by pulling out your network cable, the signalling server will timeout the previous login after a while. That'll still happen if you use the wrong events, too - after a while it should timeout the previous user and start working again. In the meantime you should still be able to log in to a different room with a different name, because that counts as a different user, not two cases of the same user. Although off the top of my head I think there are some different flows at work here so it may depend on exactly what you're trying to do. If you think something is broken despite the fact your events are correct, as ever please file an issue following all the guidelines.

In my experience any time you try to write software that second-guesses what you're trying to do - such as silently and automatically waiting for prior operations to complete before disconnecting when you told it to disconnect immediately - you create as many problems as you solve. For example someone else will be using that action intentionally to disconnect and cancel any existing operations. Perhaps it's a way to bail out if something is taking too long and you want to timeout and return to the main screen. If disconnecting is changed to wait for existing operations to complete, you break that process, and whoever was relying on that will complain and file a bug and ask for it to be changed back. In short Construct provides the tools and it will do what you tell it, and it's up to you to make sure you tell it to do reasonable things.

In the meantime you should still be able to log in to a different room with a different name, because that counts as a different user, not two cases of the same user.

Unfortunately, this doesn't work for me. My program generates a room based on a Twitch username, and for an external user to access the room, all they need to know is the user's username. If I suddenly change the name or room there's no way to pass that information on to the peers.

I suppose mine is a unique problem, and not worth fixing.

You mention that it will eventually timeout the previous login. Is there any way to force that, or perhaps any way to find out how long that will take?

You mention that it will eventually timeout the previous login. Is there any way to force that, or perhaps any way to find out how long that will take?

You can set the timeout time in the signalling server available for purchase in the store : https://www.construct.net/fr/game-assets/tools/multiplayer-signalling-server-2

And as you would be hosting it, you would have the hand on making sure the signalling server does not go down.