Bugsmashers on a Tuesday!? That’s right, get your bugsmashing one day early with Mark Abent.
As is with any information on our transcripts and summaries, everything posted is subject to change by CIG and in some cases may not always be 100% accurate at the time. While we strive for accuracy, mistakes do happen so please let us know if you find something amiss that we didn’t catch. Enjoy the show!
Transcript by CanadianSyrup & Stormy Winters
TLDR (Too Long; Didn’t Read)
- The bug: When a character attempts to get into a ship, he sits down off centre slightly and then suddenly snaps in at the correct position end.
- At first they thought it was an animation issue, but the animation team sent it off to engineering after figuring out there was more going on.
- On the engineering side, when a player starts the enter animation, there’s a position that the player attaches to inside the ship and moves relative to that point giving the illusion that he sits.
- Within the code, there’s a section that uses prediction/waypoints in a way to line up the character movement by movement till its in the seat. The problem is that this prediction is being used at the wrong time or when it isn’t needed and causing an offset.
- After setting up a parameter to only use the above system when needed, Mark tests the code and everything works as it should!
Full Transcript
Mark Abent: Hey everyone, it’s early in the morning, we’re here to crack some bugs down on good ole Citizen Con. Going to do some bug fix fixed, all for your fixing needs, going to fix all those bugs. Let’s go.
Hey everyone, we’re here in our super secret test level with the Gladius and invisible ship. So, we got a bug here about all the enter animations being offset, this happened after all the animators switched the enter animations to this new fast enter animation. So, you can quickly get into your ship and it doesn’t take forever. So let’s turn on our AI physics and I have my little pilot guy here, our ship’s going to dance around and we’re going to tell him to enter and I’m going to actually scale down and you can see, oh kinda missed it there. Let’s try it again, weee, you’ll be able to see as this plops down he’s supposed to grab onto the bars and propel himself into the ship. He doesn’t quite do that, so as you can see he kinda missed the bar there, it’s kind of penetrating and as he gets in the seat he has a little offset and he snaps. This is happening across all the ships, there’s a slight little offset so let’s watch that again.
He just decided to float into the air. So real time, he’ll grab on and oh that time he fully missed on the right hand. So he grabbed right before and he propelled himself up. Then when he gets in he like has a small little gap between his thigh and his seat, so there’s a global issue that affects all of the enters and it’s just a slight offset and it’s not inside the actual animation. So, all the animators were going nuts going, they set up everything, they synced everything, they even placed these things called animobjects that lined up correctly and they’re like, ‘all right, we got to send this off to an engineer cause there’s obviously some weird offset’ and fortunately there was.
So, what our set up, let’s go back into here. What I’m doing actually is when a player gets into this enter animation, what we do is on the ship there is a position roughly where our character is and what we do is, is we attach our player to that position and then we have the player move relative to that attachment point and that gives the illusion that you’re still in… he’s actually in that little enter position but we’re moving him and when he sits down we teleport the attachment to where he’s sitting. So give the illusion that you’re sitting when you move and all that fun stuff and you just move relative to the attachment which… it works out pretty nice but when you have this weird offset issue, you get this bad snapping so when you finally sit down and when it teleports to the actual sit thing you get this teleport and it just looks unnatural.
So, what’s happening, well here is our animated character or what our player does to figure out where he’s going to move next. This desired animation movement block of code, what it does is it looks at the… basically the skeleton to see roughly what movement we’re going to do. So, as we’re here every frame we have a little bit of movement. Movement, movement, movement, movement until we get to our seat and that’s what basically this calculate relative movement does and this block of code ideally you just want to do a current frame to get to a current movement so you can work your way up.
Unfortunately this block of code actually get used for the usual standard player movement and they have to use this prediction block where it samples the current frame and the next frame, the reason why is if you’re not on the seat attachment, you’re just generally moving around it actually figures out where you need to go and it sends this information to physics and physics runs here and the main thread where this animation runs here. They run parallel and between each other so they’re not quite in sync so we have to get some future information so we can send to it so it can run even if it runs ahead or behind the main thread.
So, we need an extra sample and unfortunately that breaks one attachment cause we’re not actually going through the physics side, we’re going through the attachment side to figure out where we need to move the player. So we don’t need this extra bit of prediction and that’s actually where our offset is happening because we’re not sampling here, we’re sampling ahead double so we’re going places we shouldn’t be going.
So, what we have to do is do something sniffy like, should use movement prediction and by default we want to use it if we have our Cvar, but we also don’t want to use it if we have the first step to an attachment. So, if the movement Cvar for prediction is enabled and we do not have an attachment then we do this movement prediction. Otherwise we just sample the timeframe. So, do some recode, all right recode is done and let’s see how it looks when we only sample the current frame instead of the future frame.
Up… recode broke. So unfortunately recode sometimes breaks the game so I have to restart the editor. All right, so recode had some issues so I had to restart the editor, let’s try this again. Let me turn on the Cvar, wham. All right, got into position, let’s have the pilot enter and see what happens. Slow motion…bam, oh he grabbed the ladder, yeah. He hops in, he grabs the side correctly, sits in the seat on the correct position, wooo. Everything works better, a lot better. There is still kind of a snap between the end of the enter and the idle that’s something that the animators have to work at but the whole offset between the entering and getting inside is there Cvar is gone, done. Just slight little programming and bam, we got good results.
All right, hope you guys enjoyed this little, small fun bug. There was a global issue with seats entering, they switched over to the new combat animations and things were just not lining up/ The animators were going bonkers and then they decided to shift the bug over to engineering, they took a quick look at it. Some slight issues with the movement prediction, turns out we don’t even need that prediction when attached, so disabled it when we’re attached, the problem went away you’re able to get in, grab onto the ladder, animations all lined up good to go. Animators can take a sigh of relief and all the animations look great. Hope you guys enjoyed, till next time, bugsmashing.
The post Bugsmashers: Episode 33 appeared first on INN.