You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This problem occurs in the Unity demos with code unchanged. I don't know if it is due to a mistake in the scripts or in the plugin. As far as I know, it seems to be fine in the scripts. So each time a player leaves and joins back, it gets a new id. It's like if when the player left it didn't remove its id from the list. It doesn't feel like it is doing what it is supposed, especially compared to the networking solution made in the tutorial series. Also if the id of the player is about to reach over the maximum of connections allowed, it finally gets the id it is supposed to have. Now, even if it really looks like an error, like something that needs to be fixed, I am not fully sure that it is truly an issue and not just some new way that the code works. But here's the reason why it bothers me: if you try to join on the client while the server is not started and then you start the server, it will show an error and the server will stop working. Here's the error: ArgumentException: An item with the same key has already been added. Key: 1. It seems like it happens because of the id that doesn't get removed when the player leaves or fails to join. Of course, I might be totally wrong. After all, I don't know much about networking. But I thought it was better to report it even if I have doubts. I hope this helps.
The text was updated successfully, but these errors were encountered:
The IDs not "resetting" is just the way Riptide works. When someone disconnects, their ID gets added to the end of the list of available IDs, so until the other IDs get used, you won't see that ID again.
As for that error you get when you connect successfully after a previously failed connection attempt, that's definitely a bug and I've been able to reproduce it, so I'll look into getting it fixed. Thanks for reporting it 👍
Thanks for the quick reply. I am making my first multiplayer game and after following your C# networking tutorials and finding Riptide, I decided to use it. I am definitely going to keep using it as long as it fits my needs and I will do my best to give feedback and report problems. Keep up the good work, maybe will it turn out to be hidden gems ;). I am eager to see features such as client side prediction and lan matchmaking. Also, little question: is there any documentation yet? It would be really helpful. Ps.: I'm new with using Github, I don't know how to use it properly so I'm sorry if it's a post instead of a reply or if I'm using the wrong sections to write on.
This problem occurs in the Unity demos with code unchanged. I don't know if it is due to a mistake in the scripts or in the plugin. As far as I know, it seems to be fine in the scripts. So each time a player leaves and joins back, it gets a new id. It's like if when the player left it didn't remove its id from the list. It doesn't feel like it is doing what it is supposed, especially compared to the networking solution made in the tutorial series. Also if the id of the player is about to reach over the maximum of connections allowed, it finally gets the id it is supposed to have. Now, even if it really looks like an error, like something that needs to be fixed, I am not fully sure that it is truly an issue and not just some new way that the code works. But here's the reason why it bothers me: if you try to join on the client while the server is not started and then you start the server, it will show an error and the server will stop working. Here's the error: ArgumentException: An item with the same key has already been added. Key: 1. It seems like it happens because of the id that doesn't get removed when the player leaves or fails to join. Of course, I might be totally wrong. After all, I don't know much about networking. But I thought it was better to report it even if I have doubts. I hope this helps.
The text was updated successfully, but these errors were encountered: