Mar 2

BugSmashers: Episode 20

This post is a transcript of BugSmashers: Episode 20, material that is the intellectual property of Cloud Imperium Games (CIG) and it’s subsidiaries. INN is a Star Citizen fansite and is not officially affiliated with CIG, but we reprint their materials with permission as a service to the community. INN edits our transcripts for the purpose of making the various show participants easier to understand in writing. Enjoy!

BugSmashers: Episode 20 – Full Transcript

Mark Abent (MA): Hey everyone, welcome to BugSmashers and I got a joke for you. So what did the bug say to the code? It didn’t, it died … Let’s get started!


Hey everyone, we’re here in fancy dancy dying star. We’re looking at a fun little multiplayer bug where I have a client on the left and a client on the right. Now on the left guy, where I’m look at dictates where I’m shooting, but as you can see on the right, my projectiles are always in the front. So the client sees one thing and the other client sees another thing and what is happening here? Shenanigans with multiplayer.

As you can see, nothing is getting synced and it’s a little bit of a problem. All of our weapons, they all zero in on basically where this origin is on the reticule unless it’s fixed, then it goes to the other guy. However, none of them are actually aiming towards it on the remote client and well they can’t because they don’t know where that player is looking. However we have in the … where is my code, here’s my code. We have something called a weapon controller and instead of sending network locations for every single one of those guns because we could have 10 to who knows, maybe 15 in the future? So instead of just sending networks to each little guy, we just send where the players looking and then that will make all the guns look at that location. Only problem is, it wasn’t sending the information.

So in our weapon controller we have a function right here which the visor code or where you’re looking at, tells the weapons controller “Hey look at here” because this is what the players looking at, the local player. This will call update weapons and this will basically go through all the weapons, cool! Only problem is, it’s not sending the information to the clients. Now the good news is we have a client aspect. Client aspect means we have some information for the network that’s going to be sent out by ‘client owner’, the server dictates who that client is and if that client gets the delegation he’ll send his information to everyone, if the client doesn’t get the delegation then it will be server controlled.

It is client controlled and we have, where is it, let’s check delegation … We should have delegation, yup! We have delegation and if we go into our weapon controller, it is requesting delegation. So the guy who uses this thing will get delegation by the server. However, it’s not. So if we go down here, any time we change our information we’re gonna have to update our network aspect. This is saying “hey, yes we have new information to send everyone because well, we’re dirty’. So we’ll mark the aspect dirty and it will flush all the information to the other clients.

Now if I were to compile and test this, it would be broken because there was another issue with this other thing that we have called the network controller. This is a brand new thing that we’re bringing to our components, our items. This is going to be a future thing where it takes control of all of our aspects, you just say: ‘hey,  I have some float, or some int, worry about the sinking for me, don’t worry about setting up aspects or anything crazy, this will do it’. It’s kind of our replacement for later things when we get rid of aspects.

For now, the only thing you have to worry about is since the item can only be controlled by one client at the moment because of its limitation of aspects, which in the future we want to get rid of… if someone else has requested it, that means this client will never ever update and unfortunately the energy pipes are using that network controller to request authority only problem is this function gets called on multiple clients so if you’re the lucky client over here who gets the information before me.

You’ll actually get the authority over the weapon control which we don’t want right now so that goes goodbye. In the future, you’ll be able to have more than one but for now we have to stick with our current networking scheme so we get rid of that and make sure this is changed. So now we have recoded and unfortunately we have to kind of reset the state because it gave the delegation to another client so we’re going to hop out of our seat and then hop back in.

This will call basically reset all of the states of the items so when the player actually sits down he’ll get the authority, bam. Let me hold down my magic ALT key, so if I fire on the bottom you see on the bottom, if I fire on the top, you see it on the top, if I fire on the right, you see it on the right. Everything has network synced, oh my gosh. I hope you guys liked that little tid bit, weee. Just blow him up, die!

That’s how you win. Alright everyone, as you saw here we had a little fun networking issue. We have a thing called delegation with our networking which allows a client to take control of an item and say, “Server, here’s some information” or maybe send information to other clients, cool. Only problem is you can only have one of those per item and it’s just not scalable and we’re working on stuff to allow you to have more delegations.

So, maybe we have a power plant some guy is able to fiddle with these settings while another guy is able to turn it on or change some other stuff. For right now, only one client can take control of it and because of that we were using the new scheme on the old system and it just got wonky so we had to make sure only one guy can take control and then we had to make sure the final thing is if we do have a change we flush the network and tell everyone about it. Hope you guys enjoyed and until next time.

About the Author:

Leave a Reply