Citizens! Check out this week’s episode of Bugsmashers!
Transcript by Erris
Super Short Form
There’s some physics bugs and large words and items don’t attach right. Mark fixes it. Bug Smashed.
Alright, so, that little bug was a fun one. We’re doing a lot of major changes in the engine and unfortunately when we start taking off the branches for the next release, we have some broken stuff we have to clean up. The whole physics issue thing when we detach from a port was due to a huge overhaul with the item port system, and since we needed a fix for the next release we put in this little thing just as a way to say hey, we need to get this working, we are working on a proper fix but of course that stuff takes time. And with that out of the way, let’s get on to some questions.
Ardent Hammer – Nice video, keep it up. I’ve always wondered, with large projects such as SC, how do you manage to keep track of such a large codebase?
So, that is actually a really challenging thing that we have to do day to day. We do it a couple ways. We have a lot of tools in Visual Studio such as Visual Assist, which allows us to search the codebase for things we really need. The other one is our structure of how we keep things together. Core engine things go in core engine, animation things go in the animation folder, rendering goes in rendering, gameplay goes into the gameplay section. That helps us narrow things down. And then we also have mandatory code reviews anytime we want to submit stuff, and we have ownership where, some people own a particular section of the game so if you have questions you go to that person. We also have a wiki. There’s all sorts of things, even skype emails just to find anything or fix things. It’s a huge huge undertaking, and we use all sorts of fun little gadgets.
Frazziboy – He wants to know, basically, it’s a nice little worded thing, I will summarize it, he wants to know why you would use event handling rather than checking if the player was dead or… blah, let me restart that. So I’ve got another question here from Frazziboy, it’s a little bit wordy, so I’ll try to narrow it down. He basically wants to know why you would use event handling over say checking a value every frame.
Well, checking a value every frame could be expensive. Also, you may have to have a store or a pointer of the value of the thing you want to check. It’s, it could be cost worthy, could not be, depends on what you’re doing. The benefit of an event handling system is when that event happens, you know immediately, and you can handle that state, rather than checking every time to see if that state has changed. Storing what the old state was, what the new state was, it can get a bit messy, but it always depends on what you’re trying to do. Sometimes event handling might be better than just checking updates, or vica versa. Again, depends on what you’re trying to do to solve the problem.
Again, Event handling is great for a large system such as this, because for example, when a radar has updated a signature, I can send an update to all the systems, rather than them constantly checking checking checking and checking which could use to expensive frametimes because they’re all doing their own update functions, rather than just a push and a pull.
So, hope you had some fun little answers there, and if you guys have any more questions, I’ll answer them next time.
I had no idea how to end that.
Hey everyone, Bug whisperer here, Mark Abent, here to bring you Bugsmashers 2, the lost world.
Hey everyone, we have a little fun bug today. I’ll start off with a little fun changelist here that will set us up. So, little bit ago, actually last week, we had an issue with our items not getting physicalized when they detached from our item ports. Items are basically anything that will attach to the ship or a rack, a missile rack attaching to a ship. There was a lot of major code change in this build, which basically destroyed all that physicalization stuff, and this was just a basic quick attempt to get it up and running by good old Paul. It worked for the most part, except it had some knock-off consequences in Multiplayer. The problem is, we have an attachment system code and a physics entity proxy code, which both of them handle the physical entity of our missile or item, and in singleplayer it’s pretty easy to tell who gets ownership, but in Multiplayer due to packets coming out at any time and ordering issues, the ownership of the physics could be on the attachment system instead of the item port system, or the proxy, and that will cause problems when the item expects it to be here. And the ordering of those things is very delicate.
So what good old Paul has done, we look at the difference, he basically, lets skip all this, and here we go. Anytime we get an item port, we will disable physics, and anytime we leave an item port, we will enable physics. The problem with that is we may get serialized, the item will serialize and tell it to physicalize prior to the item being on the item port, or vice-versa. And it causes some fun physics crashes.
So what I have done, if I undo all my fun little code, doo doo doo, so I have introduced something called a desire physics. So it still goes through the same way, it’ll be like, hey, I want to sync this and physicalize this, we’re going to now do a frame delay so we won’t have these issues where if I get attached and detached on the same frame and it serializes all these physics weird states go funky, so now it’s going to wait till the next frame to see if that should happen. And for all intents and purposes, that worked out, except in voila, multiplayer. The reason why is, let’s compile this, and i can do a live demonstration.
So, I took off the first point because I forget this is a valid state, but this is where the problem lies. So we put in that frame delay, the problem is the physics proxy doesn’t exist yet, so when it tries to serialize this information, it can’t because we have a null pointer, so it says hey abort, and this causes the player to disconnect. Can’t have this happen so what we need to do is make sure that luckily in our physics proxy we have another parameter which will allow us to create the proxy. This is only because we have a frame delay. Before whenever we serialized this information it would immediately create the physics. BUt now, since we have that slight delay, we have to create the physics in the serialize just so that we can serialize the type.
And there is a chance the physics has not been created yet, that’s what this snapshot, which also the proxy takes care of, it’ll basically dump that information in till it’s ready to take it when it physicalizes, so lets try this again.
As this loads up, one thing to note is since the attachment manager and the entity physics proxy both handle physics, it always becomes a weird thing to try to make sure that both of them don’t mess each other up. We do have something in the pipeline to basically make sure that both the physics and that is handled by the physics proxy and not the attachment manager, however that’s a huge big change that’s still ongoing and will eventually come out, but in the meantime we have to do this little bit of shenanigans to make sure that we have the proper gameplay, ‘cause we want our missiles to actually move in multiplayer, so we’re able to get that other huge change out of the way.
So as you can see, I was able to join, and if I had another character, I’d be able to shoot missiles at him. So, we’re going to fly a little bit, weeee.
But there you have it. Fun physics woes.