Grabber Component Crashes Unreal!

Unreal Courses Ask
,
#1

Hi I’m having some trouble with progressing since my project seems to be massively ****ed somehow.

So I’m finishing off the grabber (85. Using Physics Handles) and whenever I press Play to test the grabber, it crashes Unreal.

  • If I delete the Grabber component from the Default_Pawn_BP then it plays fine, so I assume that it’s my grabber.cpp & grabber.h that are causing the problem?
  • Following this, I have replaced the contents of these files with Ben’s github versions, but it makes no difference, it still crashes Unreal upon pressng Play.
  • I have also reverted to a previous version via sourcetree and rebuilt the derived files, but it has not helped.
  • I wondered if it was to do with deprecated GrabComponent (as I am on 4.15) but changing this to the GrabComponentAtLocationWithRotation made no difference either.

I’m at a loss! Any ideas would be appreciated.

#2

OK so FYI, I could not get grabber back to working. I reverted the files to an earlier build and it still fell apart.

I have deleted the grabber component and I made a new one called GrabIt, which I have used the previous version of Ben’s github .cpp and .h files for his grabber, and it works.

HOWEVER, when I try to take the latest code, it crashes again. Thankfully at this point I can still roll back the code for GrabIt and make changes, but I’ve yet to figure out what the solution is.

I presume this must be some incompatibility in the code between 4.10 and 4.15 ?

#3

OK, so updating the code and testing gradually through Lecture 85.

I can add the Actual ability to grab the component:

image.png887×422 17 KB

It lets me “Play” but Unreal will crash after “grabbing” onto the chair. This might be typical though as we haven’t finished the grabber.

#4

Adding this lot crashes it outright:

image.png1103×517 25.6 KB

#5

OK DanM has managed to come up with a solution to part of the problem that I have noticed after googling it.

To do with Physicshandle being set to nullptr in the .h file I think. This change prevents the crash, though I could do with a further explanation of the logic (But I guess the && means, if PhysicsHandle is true (givng no chance to be nullptr …? [Deeper explanation would be great!]):

image.png982×451 21 KB

I still have the problem of the crash when actually picking up the object. I’ll try changing to the newer GrabComponentAtLocationWithRotation now to see what happens.

#6

Bad news, GrabComponentAtLocation and GrabComponentAtLocationWithRotation do not help the crash.

But good news in that I guess I know that’s not the problem now. But it must definitely be something in that code block!

#7

You most likely aren’t setting your PhysicsHandle

Conditional statements are short circuit, meaning for && if the left is false it won’t bother checking the rest. So

if(PhysicsHandle && PhysicsHandle->GrabbedComponent)

Is effectively the same as

if(PhysicsHandle)
{
    if(PhysicsHandle->GrabbedComponent)
    {
        //code
    }
}
#8

Hi Dan,

Thanks for responding!

So you are saying that I should remove the logical operand && since it’s simply preventing code running (if PhysicsHandle is false) and not fixing it? (So it’s not crashing because offending code is not being run?)

(PhysicsHandle is set to nullptr in the .h file)

If I remove that, then it crashed on pressing “Play” in UE again.

From what I can tell this doesn’t get me any closer to fixing the problem. I’m at a loss! Where do I go from here. Currently I’m back to square one (identical code to Ben’s that crashes UE)

Many thanks :slight_smile:

#9

(Ah you are onto something about PhysicsHandle) I’ve just reliased I get the log error:

UE_LOG(LogTemp, Error, TEXT("%s missing physics handle component"), *GetOwner()->GetName())

How do I set PhysicsHandle?

#10

No, that code will prevent crashes. You want to keep that.
On your BP_Pawn, add a PhysicsHandle component

2 Likes
#11

Omg… that’s it… all sorted. I can’t believe that held me up for 3.5 hours!

Thanks DanM, you are a lifesaver!

1 Like
#12

One of the pitfalls of a system that requires you to code in one program and develop your environment in another. The bad news that you spent 3.5 hours searching your code for a problem that was actually in the Pawn Blueprint.
The good news is that you learned something valuable first hand and that knowledge later on down the line with more complex problems will save that time the next time something weird like that happens.

3 Likes

Privacy & Terms