Mark Abent (MA): Hey everyone, welcome to Bug Smashes, I got nothing witty. Like I said, I got nothing witty. You’re gonna use that aren’t you?
Tom Hennessy (TH): Let’s start.
Hey everyone, we have a fun little bug here. I have a test Hornet which I use and abuse to put all sorts of items on. As you can see, I threw an airlock on the wing because why not. This is mostly so I can test the interaction system and we’ve got a bug in that when items get removed off ships like this airlock, it has no physics and as you can see here, this airlock is attached to my lovely Hornet and it has physics on the door; However there’s no physics anywhere on this airlock when it’s plopped down and same thing with pretty much any of this other items. If I go in here there’s physics for the seats, physics for the weapon, but not when it gets plopped down.
So what happens? Well let’s snap into the code. So let me open up the fun… Eh I’ll open up the item… Where are you item, somewhere hiding. Visual assist does not, ah, there you are.
Alright, so our legacy item which is this guy and our new items, they have a physics controller. Where are you, there you are. We have a physics controller which is a separate component that handles the physics for this item. Both the legacy item which is this guy right here and our new item just both go and use this guy, and we have a call back for physicalizing. We were just there, let’s go find you. We want the physicalization mode.
Going through the fun mess, Aha! Physicalized. Out and about.
Alright here’s our fun physicalization function. So to get this item working with our physicalized component we have to do basically a callback to do special methods. So, when we physicalize we’ll tell our physics controller to basically physicalize our entity and then it will do a callback to come back to the item because the item has to do some special love, and whenever we physicalize we have to define a slot.
Basically we have an entity and it can have multiple slots and each slot could have a character or it could have some geometry. We could have a wallet geometry and a phone and they both belong to this entity, and each one would be into a slot. You could have multiple slots for the entity active at one time or you could have one at a time.
For example the legacy items, if it’s… we could switch between an auxiliary or third person geometry, we mostly stick with third person, but auxiliary is for like attachments. You could do things like you’re if in first person you have switched to this geometry, if you’re in first person you switched to this geometry, but either way we have to define a slot to physicalize and the item and old items, they have one slot which they physicalize on, but they also have another physicalization slot for the interaction system which is these fun little proxies right there and unfortunately we have to physicalize a bunch of slots. So rather than sending in a specific number, we can send in a negative one.
If we go to the physics controller. This is what we use for the new items and as you can see if it’s a rigid body, we pass a negative one saying, “Physicalize every single slot you have” and unfortunately our physics controllers is the top level and the physics proxies are bottom level and then we have super, super low physics. So our entity, physics controller, physics proxy and physics. Our entity tells physics controller, “I want to physicalize”, it does a call back and then it eventually goes the physics proxy to set up a whole bunch of crazy parameters and then finally gets the physics and our guy has physics, it’s cray cray. Basically our item gets here, goes to the physics controller, we say slot negative one, it gets to the physics proxy and we land here.
When we have negative one, we have to go through all these physics slots and add it to physics and say, “Hey, make this thing have physics”, but unfortunately in this param, we when pass since slot negative one, we also pass in this param in here and when we add the slot geometry it gets the param if it’s a character or physics, it checks to see if the slots negative one, but we set in there negative one because we want everything to go.
So we have to do a little trick where we say, when equal to the current slot and then we’ll reset it. So since everything, unfortunately this is the params, we’ll just say, “Hey, just use, we’ll assign the correct slot so everything below the physics proxy gets passed in correctly and then when we go the next slot we do the same thing over and over again”.
And we build this guy. So now my super duper wallet and my super duper phone both have physics instead of going, “Oh my gosh we’re slot negative one, abort”. Woo because this guy doesn’t want to do physics.
Alright as this compiles, we are going to see the awesome result. Best sellody. Alright we’re back into the editor, let’s draw our physics. Haha! We now have physics when we plop down this door. So if I were to hop in this game, weee, my ship goes crazy, but since I have physics I can now open it.
We I can at least shoot it, I guess the animations broke, all fun. Heh It had to open up that door, oh that’s great. Ha ha.
That’s another bug for another time, [Epic thumbs up]
As you saw we had a fun little physics issue where if we had an item and we attached to [Holds an apple] yes this is a ship, pretend it’s an airlock, it has physics! Awesome, but as soon as we detach it we don’t have physics anymore. Problem was with the good old low level component when we try to physicalize all the slots, we send the negative one, but it was aborting out because negative one’s invalid so we just had to make sure that when it goes through each slot we set the appropriate value for the slot, everything physicalized and now our apple is a real boy. Hope you guys enjoyed, see you guys next time, cheers!