BUGSMASHERS! Episode 01

Transcript — every row opens the video at that moment

1. 00:00:07

   Hey everyone, welcome to the all new Bug Smashers. I'm finally going solo. Got my own spin-off, you know, like in tradition of uh you know, all those great spin-offs like Joey, Capria, and Lone Gunman. This is going to be good. And I'm ready to smash some bugs. Bug smashes. Hey everyone. Uh, we have here a fun little multiplayer bug. So, on my left I have my dedicated server. On the right, I have three clients connected. And on the dedicated server, you can see the status of each of the players. And currently, they're all set to be in game. This bug that I've gotten is if um one of the players decides to eject

2. 00:00:57

   and disconnect right away, the other two clients will be unable to respond. So, let's see what happens. So, let's tell this guy to eject and then we shall disconnect and let's see what the server is saying. Everyone is in game. Oh, look at that. Uh, our guy is sticking around and he's in the disconnect state. That's actually pretty bad because now if I tell this guy to eject and I'm going to wait for the respawn window respawn and he's not doing anything. Why? as well. Unfortunately, the

3. 00:01:46

   dedicated server is still trying to dis disconnect um the other guy and he's actually blocking the initial guy from So, player four is disconnected. Player two is trying to respond, but poor old player four is still trying to process his disconnect and blocks completely the respawning of player two. Yay, threaded systems. So, what's happening? Well, let's find out. Let's close down our dedicated server and shut down all of our fun little Star Citizen instances. All right, so everything's shut down. So what is happening?

4. 00:02:36

   Um let's go to a fun area of the code. All right. So when the client decides, hey, you know, I should be removed. It will spawn a little task here and this task will say, hey, data store, I need to be removed and data store has to do its thing and then it will come to this delete the player and then it will remove the task. That's what so in our little data store we'll come here and we will when we first run through um it will go through here it will this data store is running um we have a player because we have his information and the state is not disconnecting it's

5. 00:03:25

   in in game. So, we won't go here. We'll go into this guy section of the code. We'll be set disconnecting. We'll spawn the threads and that thing will basically clean up the player, remove all his vehicles, all his items, anything particularly connected to him. It'll close down some other sections of the code, and then that should be good and gone, right? Well, problem is I'm never going to be a TV star. What are you talking about? You got your own show. Joe after a million takes. What happens if another one of these tasks gets set? So, we go through the same logic. We go to disconnect. We get to here.

6. 00:04:14

   Uh-oh. Our state is already disconnecting. Now, we're going to do that function call. We're going to delete the player, but he's still processing that thread. So, we just deleted the player because we spawn another task. And now the client disconnect is trying to process everything, but it's like, "Oh my god, the player is no longer here, but I'm still stuck." And then things just go crazy. Now, this task could happen for different reasons. One, we get the disconnect. two, we shut down the player and it wants to make sure he's cleaned up. So, this task may get spun off a few different times, but we want to make sure that we're not deleting the player until we're ready. So what we're going to do is

7. 00:05:05

   say, hey, as long as we have player information, so persistent database will basically say when I'm done, the player will no longer be in this um information or this uh list. If he's in the list, then we want to make sure that if he's in the disconnecting state that we we do not spawn another thread, but we also don't want to spawn another player. So, we're going to say, let's see, let's give it error code. Wait. If someone decides, hey, we're going to spawn another task, even though another task was already made, it will delete the task, but not kill the player, but the very first one will. Therefore, we should be safe. If someone

8. 00:05:52

   decides to run another task to delete the player, it's going to wait until this whole thing gets done. Now, once this whole thing is done, it will actually remove the player from this list. So when we get to disconnect, it will no longer be in here and it will allow the code to continue. But even still, when we get done, it will still call it. So you could call this remove task as many times you want and it won't uh delete the player prematurely. So let's give that guy a little spin. All right, so I have all three clients back up and my dedicated there. Everyone's connected. So, let's try ejecting then disconnecting. Now, if we have fixed this problem, the player should go from Yep, there it

9. 00:06:41

   went. He went from in-game to disconnecting to gone. So, he was able to clean himself up, then safely remove and no deleting while he's getting processed. So, we should be good to go. And let's eject. Then this guy should be able to respawn. Wait for the press X to respawn. And he is respawning. Woohoo. Took a little bit because I have a debugger running so it kind of slows down the processes, but it it was pretty quickish. So there we have it. Fun little bug solved. Multi-threading. Those are always fun ones.

10. 00:07:28

    Multi-threading with multiplayer. So, as you guys saw, we had a fun little multi-threading bug there that was, you know, deleting the player before our persistent database was able to clean itself up. Uh, we just told everyone to hold up, wait a minute until we've cleaned up the player and then we delete them as we really need to do. Um, anyway, hope you guys enjoyed our new little formatting of the new brand new Bug Smashers. If you guys have any comments, questions, insults, or a like, please let us know. We do read your u posts. Sometimes we have to reread them and then reread them, but we do read them. Imagine if we included this part.