Citizens! Check out this week’s episode of Bugsmashers!
Helmets were all wonky, because the game thought players were dead and weren’t breathing, because they weren’t making any sound. Fixed with code. BUG SMASHED.
Alright, so today you saw a fun little issue with our helmets where they were jittering all about, which affected boht our ships and our FPS module, because well, when you have a helmet on, it’s going to be controlling your HUD, and that’s used for both your ships and your, when you’re walking around as a player.
This bug was introduced when we enabled the breathing manager, but then code was disabled for sounds because we’re doing WWISE integration, and it was the natural conditions for a bug where you enable something that’s been enabled for a long time, and you disable some code here and here, they get together, and hey! Here’s a brand new bug.
It took a while to track this one down, cause we’re also integrating our large world stuff, and it was like, is this a 64 bit problem, is this something else, and luckily one of the illfonic guys was like, Hey, this might be the breathing manager, and… holy crap it is. And we looked at it, and BAM, there it was.
WopWop 0482 – I wonder what is the average length of time that a guy can perform work like this before burnout?
THat is an interesting little question. It depends on a lot of factors. Are we on crunch, how much sleep have we had, is there bad traffic today, was there… I Don’t know, something personal that affected you, was there a long overhaul. THere’s a lot of factors. I’ve seen, not only myself but other developers you could go, holy crap, it’s been 16 hours already, I haven’t eaten, but I got a lot done, to okay, I got here at 6, it’s 6:10, I need a break. It just depends what you’re working on, what the workload is, if you want to work on the thing or if you have to work on the thing. It just really depends. But from what I’ve seen here most of the time, everyone just zones in, and they’re, holy crap, 8 hours have passed, I need to go on lunch, I need to take a break, and then they go back right in. But another factor that ties into this too is, when you’re here early in the morning or late at night, you can really zone in on something and then time passes by and you don’t really get bruned out. But if you get here in the middle of the day and someone comes up to you, or you have a call, or you have a meeting, then you get… disorganized cause you can’t work on that one thing, and then everytime you try to work on it you get bugged, so you can burn out that way, so… THere’s all sorts of reasons why and how you can get burned out. THe best thing to do is jhust take a quick little break, go PHOOO AHHH, get a soda or something, and get right back to it.
RyanMatthewlick – What pathway did you follow to get yourself a spot working for CIG?
So, prior to working here I worked for a company called New World INteractive, and they were a small little indie group in Colerado working on Insurgency. At the time, I wanted to move back to California, but I still wanted to work on Insurgency, so I was.. looking around, job searching to see what’s available, and I saw Star Citizen, and I was like, ooh, this is Chris Roberts, he made Freelancer, I loved that! I didn’t play Wing Commander at the time, I was small, please don’t kill me. I did play it later on, I do like it, but Freelancer was my game, and I was like, that sounds fun, I’ll apply. I don’t have as much industrial experience, but I do have a lot of indie work, so the worst they could say is no. And a couple months later, they brought me on for an on-site, they liked me on, and here I am.
PD12 PD12 – What kind of design diagrams do you use, or does CIG use? Which EML ones, what kind of standard does CIG have?
What he’s referring to is, before you design or code something, you want to have some kind of framework of what is going to be the overall scope. How it’s going to work, how it’s going to interact with things, and we use a combination of tools. The two biggest that i use is Visio and, there’s a plugin through visual studio, Design Patterns UML Toolbox. But, we use Visio to create little code blocks that say this section of code’s going to call this section of code, this section so you can see the flow, and we’ll use confluence so we can post these pictures, and state ‘code interfaces’, and how it’s going to work with descriptions. Designers will do the same, they’ll have code blocks with the flow saying here’s how it’s going to work, and they’ll have diagrams and pictures along with words describing how and where things are supposed to happen. This will be basically the prototype or design phase where, once this gets approved, then it gets moved on to the design implementation, which usually gets tasked out by all the lovely producers and leads. Then from there it gets integrated in as a feature, bug-tested by QA, and then eventually given out to you lovely folks.
Hope you had some fun with those questions. If you have any more, can’t wait to answer them next week.
Hope you enjoyed this weeks episode of Bugsmashers, see you next time!
Hey everyone, welcome to bugsmashers episode 5, I’ve got my man here, Shia La Beof, lets DO IT, lets DO IT, lets DO IT.
Hey everyone, we’re here in our fancy dancy oh, good old multiplayer server, and if you see here we have the HUD shaking like crazy. Funnily enough, a little issue with our recording process where, when we recorded this, as you see now, it stopped bouncing, and then when we stopped recording, it started bouncing again. We found a trick where if we don’t have the mouse inside the game, it will actually do the shaking, so somehow oh, it stopped, but, what happens, regardless if we’re unable to capture it, our helmet from the FPS module is for some reason shaking very rapidly and, because it’s shaking, it’s causing our HUD to go crazy cause our HUD’s attached to our helmet, so the helmet shakes like crazy the HUD will shake like crazy.
This is a fun little thing that was introduced I believe on the WWISE integration. So, we’re switching over our sound system from FMOD, and because of that we had to disable a whole bunch of sounds so that we could slowly convert them over. We have a full audio team that’s working on that, and in the progress, this particular bug has to do with the good old breathing manager.
How you ask? Well, breathing manager actually looks up, as you can see here there’s some sound stuff disabled, until we get to the WWISE integration. But the breathing manager will actually get its duration, here we go, will actually get its duration from either some parameters in the XML or from the sounds themselves, and since the sounds were disabled, the breathing duration was obviously set to zero. Unfortunately, in our little code, this controls what the players sees, or in this case it’s going to control the player helmet so that when he breathes he’s like this, actually I think it controls some bones down below that end up going up, but either way this messes with the helmet so when you breathe it goes like this, in, out, in, out, and unfortunately if we put a little break point here, our transition is going to be zero our duration is also zero but because of coding optimizations this duration is not actually used here, but it is zero and every frame, we’re just getting 0 0 0 0 0. So, what we want to do, let’s get back in the game, is we want to make sure that, for one, we don’t want to do any of this stuff unless… Why isn’t… of course everything breaks at the last second.
So what I’m going to do, is copy this bad boy, and what this does is it makes sure our floating point value is above the minimum value that would be recognized by floating point. I could also use zero, but this is pretty much a standard to use across multiple platforms, just to make sure that, basically if it’s greater than zero, then we have a duration. And if we don’t, we want to make sure that we reset this lovely value, which controls your view. ANd if you look in here, it goes HEY! we’re going to apply an offset so that you breathe in and out based on a couple of different parameters, and it’s always set to zero, so it’s trying to go to the next one, next one, next one, and it constantly resets.
So we’re going to be like hey, no, stop, we have NO breathing duration cause apparently our player is dead cause our breathing is related to sound, so hold up, don’t do any of this unless we have a valid duration, otherwise set everything to 0 so it doesn’t modify any of our offsets.
Give that a good old recompile through recode, and as you can see, the helmet is no longer jittering, so our HUD stays pretty much static, and we go out, and about, see, the player’s kind of moving, but that’s from a different issue, but his helmet, for all intents and purposes, is sticking with is head. SO if his head moves his helmet moves, so you should see the HUD in the same exact place, which is good.
Now if we were to actually do the reverse logic to break it, we should see his helmet freak out, and it’s kind of hard to hell, but his head is moving independent of the helmet and that’s causing that weird offset. So if we go back in here, you can see that kind of jerking a little bit. And because of the recording it slows it down, but if I were to… yeah, you get the drift.
So there’s your little fun fix. And the other thing I did was, inside this breathing manager, it’s checking to see if this float is 0 by doing naught. So if we’re zero, then we’re going to return zero. Problem is, you may not ever get just 0. You may get very very tiny values, so I did a little code tweak here that gets the duration. If it’s less than floating point Epsilon, then we return, otherwise we divide by the duration.
That was a quick optimization. With that and our fix here, our camera no longer shakes. This also affected FPS , when you’re running around in the map the FPS HUD is also attached to your camera, so that would shake here and there. So this affected both FPS module and Arena Commander module. Now that that’s fixed, hopefully the WWISE integration will go much smoother.