Upcoming Events! Community Event Calendar
Social Media Follow us, or not!

Bugsmashers: Episode 41 - Caterpillar Doors Written Wednesday 18th of January 2017 at 01:06pm by CanadianSyrup

Mark Abent brings us another episode of Bugsmashers featuring an elusive door that has a mind of its own.

As per usual, anything said during the show is subject to change by CIG and may not always be accurate at the time of posting. Also any mistakes you see that I may have missed, please let me know so I can correct them. Enjoy the show!

TL;DR (Too Long; Didn't Read)

  • Today's Bugsmashers featured the Caterpillar and a bug that would only occur when the player did not look at the cargo bay door during its animation.
  • The issue was that when any of the cargo bay doors were opened and the player looked away while it opened, it would only open the exterior and not the interior door. This is partially due to LOD where a door animating in the distance does not need to be rendered, but the interior door was not synced properly
    • The Caterpillar cargo bay doors are made of two meshes that work in sync, but unfortunately the interior isn't being forced to open and close when the exterior does
  • Mark applied a code that forces the interior door to update at the same time the exterior door does in order to have them open at the same time perfectly.
  • A simple bug, but one that had to be fixed none the less.

Full Transcript

Mark Abent (MA): Hey everyone, welcome to Bugsmashers. I’m your host Mark Abent, I’m a Gameplay Programmer at CIG Los Angeles and I'm here to show you behind the scenes of bugs and how I smash them. Let’s take a look.

Hey everyone. We’re here inside of the Caterpillar and we have a bug where these fun cargo doors sometimes don’t open or they open incorrectly, and these doors are a little special because there’s an interior and exterior part. So you can think of the interior here and the exterior here, and when you open it, they’re supposed to be coincide. When you close it, they’re supposed to go to together, however when you look away from the door the exterior opens, but the interior remains where it was until you look at it and then it may start animating or just get stuck.

So if we open it up, we can see it, everything looks fun. If I close it and look away, it’ll take a bit… BAM! Oh we can see the exterior door close, but the interior which it should show this metal stuff with Drake on it and all that panels is not closed.

So the interior, we can actually fly out. The exterior closed, the interior has not. So if I run over here and hit close, you can see it snapped to the close position and now it works correctly.

So what’s going on? Well there’s a bit of code that says, “Hey if this thing is visible, we can fire off on the animations”. The idea is it’s some kind of optimisation so if there’s a ship wayyy out there, I don’t have to animate it because why take up all those CPU cycles, but unfortunately when we’re inside the ship, the exterior knows that we’re potentially visible so it animates, but the interior when we switch this way, that CGA in the back is not owned by any entity it’s just there, and because of that it doesn’t animate correctly. Even though it's attached to the animation of the ship, it’s just called out because it’s like, “well it’s not visible so I shouldn’t have to worry about it”.

So I have this bit of code in Manikin, if I enable it, what this will do is it checks to see if this entity has a parent which is going to be the ship and if this door, the interior is enslaved to the exterior and the exterior is visible, then we allow it to animate even though you can’t see it. The idea is if you can see the exterior, then you should potentially see the interior when the door opens and closes.

So what we do is if the owner entity which is going to be the vehicle which is going to be the exterior door is active, but the interior door is not, we’re going to force it to be active. Same thing down here, so we’re forcing the entity active and we’re forcing the skeleton to be active. What that will do is this will allow the entity to do an update call to tell the animation system, “Hey I’m active, so go process my animations”, and this will allow the skeleton to actually function.

So two updates we have to do. Entity system wanted to say, “hey, animation, I’m ready”, and the animation system will go, “yup, I’m ready too”. So in theory this should allow if the outer door is ready, the inner door will be forced to be ready so they can open and close together.

So let's hit the recode button and take a look at what happens. Okay recode is done, let’s start back up the game, alright!

So we’re back in the level and let's close the door. Magic door close. We won’t look at it. Wham! It’s closed as you would expect. Alright let's open it again. Let’s not look at it, not look at it, and it’s open!

So now we’re getting the interior update when the exterior is updating. So if I close this, going into another room, open that door, go to the other room it’s closed correctly and this room should be open correctly.

So if the interior is not updating, but the exterior is, we say, “Hey you should be because we’re updating both” and then they both play the animation, everything works well and you could open and close your doors just by not looking at it. Well hope you guys enjoyed, till next time!

So as you guys saw we had the Caterpillar and its just a gigantic long ship and it has all these bay doors in it and you’re supposed to be able to hit one or open one up and brings down the bay door and it's a little bit of complicated geometry in this setup because we have an exterior mesh for the door and an interior mesh. So there’s two doors that open and close and what was happening is when you’re looking at one of the doors it opened correctly, however if you looked that way when the doors open, one of the doors would open, but the other would stay intact and it would usually be the exterior door that opened and the interior door when you’re inside wouldn’t open until you looked at it and then it would start animating, but by then it would be too late, it would be stuck open or stuck closed. You could go around and hitting all the buttons and it wouldn’t move until you looked at it.

It was a simple fix, we just made sure that if the exterior animates, then we force the interior to animate at the same time. So the doors would open close even if you looked the opposite way. Hope you guys enjoyed, until next time.

CanadianSyrup

Director of Transcripts

A polite Canadian who takes pride in making other peoples day brighter. He enjoys waffles with Maplesyrup, making delicious puns and striving for perfection in screaming at the T.V. during hockey games.