It’s time for Bugsmashers with Mark Abent! Check it out.
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 player tried to use the interaction system during flight, the cockpit options we’re not appearing.
- What was happening is the game and the physics weren’t synced probably on the wear about’s of the player, so the player was in the cockpit, but the physics said otherwise.
- A simple way to make sure this doesn’t happen is by using the zone system, however because legacy ships are still in the game such as most one seat ships and haven’t been revamped yet, they have to support both systems.
- What Mark does is find a point in time that both the game and physics can intersect at in order to synchronise with each other to make sure the game and physics knows the player is in the seat when he looks around the ship to interact with it.
Full Transcript
Hey everyone, welcome to Bugsmashers. I guess I finally have to smash a bug, I’ve been busy catching Pokemon in the good ole asteroid belt of Yela but that’s all done. Time to play some Pokemon…or fine we’ll do bugs after this, just one more. Ok, two more, hold one I got to go get one. I got to try it.
Hey everyone, we’re here in fancy dancy test level with all my debug textures…oh no, up and I fell off. So, what we have here is with our lovely programming art for the interaction system, yes, this is totally programming art. So if I get back into my ship with all the fun inner thought systems, we have a situation where if normally in the cockpit, we could use a bunch of these interactions, which is pretty cool. However, when I put this ship in flight ready and I begin to fly around and you can see the shadows move so that indicates that I’m flying around. Working on getting the HUD fixed in, you’ll notice that when I look at any of the interaction points, they’re not working. I can’t actually use anything and this is a fun little frame behind bug. What’s happening is every frame we’re shooting out a ray and we’re trying to capture what we’re hitting in the vehicle, our interaction system uses actual physical locations so you shoot a ray, hits the physics and goes “is there an interaction point on this”, yes… “display all the interactions you can do”. Open, close, restart, you name it.
So, unfortunately our physics and our game code kind of run independent of each other in a way that physics is doing it’s own thing, the game code does it’s own thing and once in awhile they get to sync. However, when we do this ray trace we are actually queuing it up on the game side and then dispatching it at a later time. Fortunately the time that we dispatch the ray is when physics and the entity system are kind of in sync, but unfortunately because the game side caches all the information, you may get that ray a frame or ten later. Our positions that we sent, so if we go over to here, might be wrong. So say I’m in the game and I’m doing something and it’s time to fire a ray. All right, I get the player position, get everything where he’s at, set up some ray properties right here and I basically queue the ray. Which is cool except this position is behind as soon as the queue decides to go, ‘hey, I’m going to fire this off’. So, I can do an array, wait five minutes, it’ll do it however the position is here and my ship is way back there now.
So, what we’re going to do is basically move all this code, undo all things, we’re going to put it into a new function and what this does is when our deferred ray caster is about to submit our ray tracing information to the physics system, that’s when we get our actual information and we can abort out in case thing’s gone wrong. So, I want to do a ray, I tell the… what do you call it… the ray caster, ‘hey, whenever you’re free let me know’. When it goes, ‘hey, it’s your time to shine, give me all your information’ and it sends it off. Now in theory, this would be fine.
Then we have to deal with another problem where again, with the physics system, we have the player and the vehicle and they’re two independent things. So what that means is when the game code snaps the player onto the seat of the ship, at this point in time they’re one, we can think of them being basically in the same area. However, when physics starts simulating, the player actually has no velocity or anything because his position’s getting set to the seat but physics doesn’t know that so he stays behind but the ship has velocity and acceleration so it continues on.
So, our poor player is stuck here until the game code comes along and says, ‘you should be here’. Kind of crappy but we have a solution for this called the zones or the grid system, ideally the ship would have a grid and we stick the player in there and when the ship moves the player moves. Cool, however not all our ships have a grid like our Legacy ships like the Hornet or basically the one seater ships. Do they need a grid, do they not need a grid, debates going back and forth. Maybe we need a grid because we want particles to fall down relative to where you are at but at the same time is it worth the cost benefit.
So, as the debate goes on between whether or not we install a grid we have to support both systems. So, this bit of code works nicely if you’re in the zone relative to the ship. So what we have to do now is kind of similar to the projectile fix a long time ago, where the actor and the vehicle are not on the same grid, basically this snazzy thing and the player is attached to a seat. Basically this snazzy thing… we want to basically start rebuilding all the information. So, we know that the positions are off, the world positions are off, or the zone positions, but we know the local transformations are correct.
So, we know the player’s going to snap to a seat and the seat’s going to snap to the vehicle. So what we could do is build all of our local transformations. So this first part is basically the distance between the seat and the player, and then the rest of this is basically the seat to the vehicle or if it’s the seats on another item within an item, we can build the hierarchy. Once we have the local position, basically where the player is relative to the ship, we can ask physics what the vehicle’s current position and this will be the actual player position if we multiply it by the local offset. So we rebuild everything, get the real vehicle position where physics thinks it’s at, rebuild it, and now we know the players here, and from that we know that the players eyes relative to him so we can use that same matrix to basically rebuild our position so that we’re in the actual location.
With that setup, I can hit recode, and wait… Alright recode’s done. So now I’m flying around. Let’s get our shadows going so you can see the movement, there we go, and when I look around, if I let go of the mouse, I’m still able to look at the interaction point for the engines off, same thing for the power on and the open exterior. So there you have it, fixing all the fun things you have to deal with when you have multithreaded systems, independant ordering, and all this chaos. Hope you guys enjoyed, until next time.
We always have these fun little things when writing games where you have multiple systems and they work different which ways. You have physics doing one thing, the game code doing another thing, they’re working independently and then you have to find ways to, you know find the areas where they intersect so that you can do the right calculation at the right time, and you also have updating, when can you update in the game code: Pre, Post, Now, Later. So you just have to find the right set of sequences so that if you’re trying to do an interaction in a ship, you’re making sure that the player in the position is exactly where the physics thinks it is and where the game thinks it is so that you could pop up a little text box saying, “hey, open your canopy”. Hope you guys enjoyed, till next time!
The post Bugsmashers: Episode 29 appeared first on INN.