# Trace for Objects - BlockingHit is always true

**URL:** <https://forums.unrealengine.com/t/trace-for-objects-blockinghit-is-always-true/405013>\
**Category:** World Creation\
**Tags:** Trace, blocking, unreal-engine, question\
**Created:** [September 20, 2017, 1:30am UTC](https://forums.unrealengine.com/t/trace-for-objects-blockinghit-is-always-true/405013 "2017-09-20T01:30:54Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Spoondog](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@Spoondog](https://forums.unrealengine.com/u/Spoondog)\
**Post date:** [September 20, 2017, 1:30am UTC](https://forums.unrealengine.com/t/trace-for-objects-blockinghit-is-always-true/405013/1 "2017-09-20T01:30:54Z")

</div>

If you perform a trace for objects and a hit is received, BlockingHit is True even if the actor that was hit blocks nothing.

For example, if you do a “Sphere Trace For Objects” inside a TriggerVolume, and you include WorldDynamic in Object Types, it will return a hit on the TriggerVolume actor as expected, but BlockingHit will be True, even though TriggerVolume doesn’t block anything in it’s collision properties:

 ![214027-blockingtracetest.png](https://d3kjluh73b9h9o.cloudfront.net/original/4X/8/8/4/884e7b0b952d61c2656251e0302f1c52c8225241.png)

[Here’s a test map][2] in 4.17 for reproducing that.

You can use TraceForChannel against the “Visibility” channel for most things, but sometimes you need to Trace For Objects so it would be great if this flag worked (unless I’m misunderstanding what BlockingHit means).

---

<div class="post-metadata">

**Author:** ![Drkephrim](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@Drkephrim](https://forums.unrealengine.com/u/Drkephrim)\
**Post date:** [September 20, 2017, 1:39am UTC](https://forums.unrealengine.com/t/trace-for-objects-blockinghit-is-always-true/405013/2 "2017-09-20T01:39:19Z")

</div>

Hi there,

It’s possible that the trace is hitting a component on the object it is originating from. Are there any meshes attached to the trigger volume? Try checking the “Ignore Self” flag on the trace and see if that does it. Alternatively, you can make an array and plug in any actors you want to ignore in the Actors to Ignore pin.

Another thing to try is to pull the hit actor pin from the hit result, get the name and print it. That should at least tell you what it is hitting.

I hope this helps!

---

<div class="post-metadata">

**Author:** ![Spoondog](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@Spoondog](https://forums.unrealengine.com/u/Spoondog)\
**Post date:** [September 20, 2017, 1:58am UTC](https://forums.unrealengine.com/t/trace-for-objects-blockinghit-is-always-true/405013/3 "2017-09-20T01:58:04Z")

</div>

Thanks for the time, but it only returns one hit and that is the TriggerVolume (besides, the above example map is tracing from a level blueprint, there is no Self to hit).

I’m fairly certain it’s either a bug, a misunderstanding of the BlockingHit flag, or possibly that return flag was intentionally disabled as an optimisation

---

<div class="post-metadata">

**Author:** ![Drkephrim](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@Drkephrim](https://forums.unrealengine.com/u/Drkephrim)\
**Post date:** [September 20, 2017, 2:17am UTC](https://forums.unrealengine.com/t/trace-for-objects-blockinghit-is-always-true/405013/4 "2017-09-20T02:17:05Z")

</div>

Gotcha. I opened up your map in 4.17 and here’s what i did to get it working. The volume is in fact triggering the trace because it’s tracing for WorldDynamic, which is the default collision preset for trigger, and the Trace is not originating a from the volume itself, so i plugged the pin for the trigger volume in the level blueprint into Actors to Ignore, and now I’m getting false for bBlockingHit

 ![214053-ue4editor-2017-09-19-22-14-20.png](https://d3kjluh73b9h9o.cloudfront.net/original/4X/9/a/7/9a72db7a4d6a2812acbc1bdf9e63f457c91e6f88.png)

Alternatively, changing the object type in the trigger volume’s collision settings to anything other than world static or world dynamic seems to do the trick.

---

<div class="post-metadata">

**Author:** ![Spoondog](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@Spoondog](https://forums.unrealengine.com/u/Spoondog)\
**Post date:** [September 20, 2017, 5:04am UTC](https://forums.unrealengine.com/t/trace-for-objects-blockinghit-is-always-true/405013/5 "2017-09-20T05:04:55Z")

</div>

Thanks for your time again, but I think I should clarify the bug a bit more.

The reason you get BlockingHit returning false with your modifications is because the trace doesn’t hit anything _at all_.

The trace _is meant to_ return a hit with the TriggerVolume (because it’s a WorldDynamic object, and we’re tracing for WorldDynamic objects), but BlockingHit should be false, because it’s not a _Blocking_ Hit… (but it’s still a hit). The volume doesn’t _block_ anything, but it overlaps and can still be queried with a trace.

Say you want to do a multi-trace against a bunch of WorldDynamic objects, but you want to do different things depending on whether they’re blocking hits or not. You might be able to get around it for each case by using TraceForChannel, and/or adding a custom collision channel for your project, but that is more complex, time consuming and error prone. I’ve run into this a couple of times on different projects now so figured it’s worth bringing up, because if all hits on a particular TraceForObjects call are going to be blocking, or all hits are non-blocking, then the flag seems pointless.

---

<div class="post-metadata">

**Author:** ![Lewbonskee](https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/8/5/28502927f1d97ba1051b3b47ccfe17233bf41ef0.png) [@Lewbonskee](https://forums.unrealengine.com/u/Lewbonskee)\
**Post date:** [June 5, 2023, 5:39pm UTC](https://forums.unrealengine.com/t/trace-for-objects-blockinghit-is-always-true/405013/6 "2023-06-05T17:39:14Z")

</div>

Ran into this myself and haven’t found anyone answering this. Object traces don’t have a notion of overlap vs blocking. It kinda makes sense, what would it check? It seems like it would be object response, but remember that’s how other objects respond to it. So it’s not the same as trace channels. Here’s the relevant code in CollisionQueryFilterCallback.cpp

```auto
const uint32 ShapeBit = ECC_TO_BITFIELD(ShapeChannel);
	if (QueryType == ECollisionQuery::ObjectQuery)
	{
		const int32 MultiTrace = (int32)QuerierChannel;
		// do I belong to one of objects of interest?
		if (ShapeBit & QueryFilter.Word1)
		{
			if (bPreFilter)	//In the case of an object query we actually want to return all object types (or first in single case). So in PreFilter we have to trick physx by not blocking in the multi case, and blocking in the single case.
			{

				return MultiTrace ? ECollisionQueryHitType::Touch: ECollisionQueryHitType::Block;
			}
			else
			{
				return ECollisionQueryHitType::Block;	//In the case where an object query is being resolved for the user we just return a block because object query doesn't have the concept of overlap at all and block seems more natural
			}
		}
	}

```

In other words, object traces will always return hitresults with IsBlocking set to true.

---

<div class="post-metadata">

**Author:** ![MostHost\_LA](https://d1ap1mz92jnks1.cloudfront.net/user_avatar/forums.unrealengine.com/mosthost_la/32/907035_2.png) [@MostHost\_LA](https://forums.unrealengine.com/u/MostHost_LA)\
**Post date:** [June 5, 2023, 9:05pm UTC](https://forums.unrealengine.com/t/trace-for-objects-blockinghit-is-always-true/405013/7 "2023-06-05T21:05:09Z")

</div>

Not that the behaviour is exclusive, but the blocking/non blocking is a purview of the trace by channel system.

Thats because in theory the object trace will return any object in its path.

The channel system will not flag a hit on an object who’s settings are such as not to flag the hit.

Open the trace object blueprint node in visual studio or any c++ editor to read how the code handles things.  
Potentially, you could copy over the function to your own plugin and make modifications to add a working block result that matches the collision settings (by just testing the settings before assinging the bool).

Note:  
The hit result is a standard steucture, so it contains parameters which may not necessarily be set in the code that gets you that return value.  
That is likely what is going on here.

I’d suggest just merging your own custom version of the 2 traces to use in BP as you need…