Check out this week’s episode of Bugsmashers below!
Citizens! Welcome to Bugsmashers, Episode 1.
Bugsmashers, and its tame, slightly insane, host Mark Abent, have been a part of Around the ‘Verse for a while now.
This week though, CIG have decided that his particular brand of insanity is not able to be contained by the walls of Around the ‘Verse, and have spun him off into his own show!
Or his own quiet corner.
We kid. Bugsmashers is amazing.
See today’s transcript below!
Bugsmashers Episode 1 – with mark Abent
Hey everyone, welcome to the all-new Bugsmashers, I’m finally going solo. Got my own spinoff, in tradition of great spinoffs like Joey, Caprica, and Lone Gunman, this is going to be good, and I’m ready to smash some bugs.
Hey everyone, we have here a fun little multiplayer bug. On my left I’ve got my dedicated server, on my right, I have three clients connected, and you can see the status of each one, and they’re all set to in game.
This bug that I’ve gotten is if one of the players decides to eject and disconnect right away, the other two players will be unable to respond. So, lets see what happens.
Lets tell this guy to eject, then we shall disconnect, and lets see what the server is saying.
Everyone is in-game, look at that. Our guy is sticking around, and is in the disconnect state. That’s actually pretty bad, cause now if I tell this guy to eject and I’ll wait for the respawn window, respawn, and he’s not doing anything. Why? Well, unfortunately the server is still trying to disconnect the other guy, and he’s actually blocking the initial guy. Player four is disconnected, player 2 is trying to respawn, but poor old player 4 is still trying to process his disconnect and blocks completely the respawn of Player 2. Yaaaay threaded systems.
What’s happening. Well, lets find out.
lets close down our dedicated server and shut down all of our fun little SC instances. Wooo.
Alright, so everything’s shut down. So, what is happening. Lets go to a fun area of the code. Doo doo doo, doo doo, doo doo.
When they client decides hey, 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 delete the player, and then it will remove the task. So, in our little data store, we’ll come here, and when we first run through, it will go through here, it will, data store is running, we have a player cause we have his information and the state is not disconnecting, it’s in-game.
So we won’t go here, we’ll go into this section of the code. We’ll be set to disconnecting, we’ll spawn a thread, 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?
I’m never going to be a TV star.
DiscoLando (? I’m guessing again.) – You got your own show
After a million takes.
What happens is another one of these tasks gets set, so we go through the same logic, we get to here, and uho, our ‘state’ is already ‘disconnecting’, now we’re going to do the function call, we’re going to delete the player, but he’s still processing the thread, so we just leave the player, because we spawned another task, but now the client disconnect is like, oh my god, because it’s trying to process everything, cause the players no longer here, and I’m stuck, and things just go crazy.
Now, this task could happen for different reason. One, we get the disconnect, two we’ve shut down the player and it wants to clean up, so this task may get spun off a few different times, but we want to make sure we’re not deleting the player until we’re ready.
So what we’re going to do is say hey, as long as we have player information, so the persistent database will say when I’m done, the player will no longer be in this list. If he’s in the list, then we want to make sure if he’s in the disconnecting thread, that we don’t spawn another thread, but we also don’t want to spawn another player.
So we’re going to give an error code…wait. So if someone decided 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 decides to run another task to delete the player, it should 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 can call this remove task as many times as you want, and it won’t delete the player prematurely.
So lets give that guy a little spin. Alright, so I have all three clients back up, and my dedicated server, and everyone’s connected, so lets try ejecting and disconnecting.
Now, if we have fixed this problem, there it went, he went from in-game to disconnecting to gone. So he was able to get picked up and safely removed, so no deleting while he was in process, so we should be good to go.
And, lets eject, and this guy should be able to respawn, doo doo doo doo, wait for the press X and…
he is respawning, wooo-hoo.
Took a little bit cause I have a debugger running that slows down the process, but it was pretty quick.
So there we have it. A fun little bug, solved. Multi-threading. Those are always fun ones. Multi-threading WITH multiplayer.
So, as you guys saw, we had a fun little multi-threading bug there that was deleting the player before our database was able to clean itself up. We just told everyone to hold up, wait a minute, until we cleaned up the player, and then we delete him as we really mean to do.
Anyway, hope you guys enjoyed our new little formatting, our brand-new Bugsmashers.
If you have any comments, questions, insults, or the like, please let us know, we do read your posts, sometimes we have to re-read ‘em, and then re-read ‘em, but we do read ‘em.