Barrier not being detected by sweep

I noticed that my barriers were still not being detected by the SphereCast, so it ends up turning green instead of red. I tracked this down to the fact that in the Unlock Blueprint function for the Barrier actually had this set to “No Collision”, so I suspect that is the issue as to why SweepSingleByChannel isn’t picking it up. So what I tried to do was alter the Collision Settings when the Barrier is unlocked to make it look something like this:

And while this DID work for the SphereCast to detect the Barrier, it created an issue of where when “Locked” the Barrier no longer blocked the Player actor to going back to the previous tile.

So now I am a bit lost as to what I should be doing. Can anyone advise…?

Here is my current repo:

Please note that the Industrial props have not been added to this repo to avoid the use of LFS or just adding large files in general…

@DanM would you be able to confirm if this is expected or actually an error on my end?

Getting the courses version, the barrier uses the Default preset and that blocks everything.

Like I mentioned initially, I did have the barrier static mesh component’s collision to “Default” but that resulted in the sweep not even detecting the barrier. I feel like this is more of an “order” problem where the sphere/sweep is being initiated after the Unlock blueprint function is called…

Could you push your changes so I could test it?

hi @DanM, the repo link i posted is my latest commit minus some of the tinkering done with LineTraceBySingleChannel discussed in the other thread, which should have no bearing on this issue.

Oh I already tested that and it seemed to be fine which is why asked for you to push as I thought there might be a difference there. I’ll take another look at it.

Is it just the starting tile that’s the issue on your end?

I don’t have 4.19 installed and I think there’s a difference in OnBeginOverlap behaviour in my testing. In a later version (4.20?) they made it so that OnBeginOverlap actually needs to be overlapped to trigger so the initial tile isn’t unlocked initially for me.

Hi @DanM Yes my apologies for not mentioning, but I am using 4.19. Would that really be the reason? And from what you are describing are you saying that once you go through the first barrier all of the other spherecast on the next Unlocked barrier is marked red?

If so, what would then be the alternative to replicating this behaviour of later versions? I am really hesitant to upgrading my Unreal further due to there being already enough compatibility issues with this archived course and I have come so far I just want to finish it.

Oh I’m an idiot and thought you meant the other way round. Strangely it works as expected here in BP

but not C++.

Maybe it’ll work if you flip it so the barrier is locked by default? Or vice versa, forgot which way round the lectures have it.

Hi @DanM, I am not sure how it seemed to be working for you even in BP, because it wasn’t really for me, but trying to replicate this in BP has made me realize something.

I believe the reason why this was never working was because when the SphereCast was being generated at BeginPlay() it was actually placed in the area of the BP_Tile where there was nothing there to begin with.

In my C++ Tile class I noticed that as you go through the barriers I realized that the SphereCasts for the NEXT END of the level was being generated, most likely meaning that it was again being placed in the BP_Tile section where there is no “Barrier” mesh component. I was actually able to replicate what my C++ code was doing in the BP as you can see here:

So when I adjusted my C++ like so:

// Called when the game starts or when spawned
void ATile::BeginPlay()
    //CastSphere(GetActorLocation(), 300);
    //CastSphere(GetActorLocation() + FVector(0, 0, 1000), 300);
    CastSphere(GetActorLocation() + FVector(4000, 0, 0), 300);

(4000 in X because thats where I placed the Barrier mesh component inside BP_Tile)

It gave me a more correct looking result for the spherecast with the barriers as you can see here:

And this works while the collision on the Barrier mesh components set to Default!

Now I am not sure why this behaviour is different to what Sam has in his lecture, but seeing the next lecture videos is utilizing this SphereCast is for making sure that each of these prop elements will not overlap upon spawning, I would assume that this would mean the SphereCast sweep setup I currently have will still work for these upcoming lectures.