[4.7.5] Multi linetrace by channel always reports false

anonymous_user_c0687f281 · April 13, 2015, 1:24pm

For some reason the “Return Value” of a Multi linetrace is always FALSE, even when there was clearly a (non-blocking but overlapping) hit:

If I check length of result array instead, if works:

Should this workaround not give exact same result as return value of trace itself?

anonymous_user_33800a51 · April 13, 2015, 5:07pm

Hi ,

I wasn’t able to reproduce this in 4.7.5. Do you see this same behavior in a new project, or does it only occur in your current project? I see your Trace Channel is set to “Selectable”, can you show me what those settings are? You’re also using Trace Complex, are you hitting only Actors with Complex collision or a mixture of both? If you’re able to set up a small test project with which this occurs, please feel free to upload it somewhere and send along a link so I can investigate it here. Thanks!

anonymous_user_c0687f281 · April 13, 2015, 5:56pm

Hi, thanks for your answer.

“Selectable” is configured to throw overlap events. In screenshot you can see, that this is working as expected.

realy strange thing here is, that “Return value” is not true although length of result array is greater than zero.

I will try to reproduce this in a new project tomorrow.

anonymous_user_33800a51 · April 13, 2015, 6:55pm

Hi ,

No need to create a new project, I see it happening now. If you set Selectable object to Ignore or Block, you’d get same result from length of Out Hits > 0 and Return Value, and difference only occurs with Overlap. This does not occur with Single Line Trace by Channel. I was able to reproduce this in 4.7.5 as well as our main internal build, and I’ve entered a bug report in our system for issue (UE-13738). I’ll let you know as soon as I see an update on it. Thanks for pointing this out to us!

anonymous_user_33800a51 · April 13, 2015, 7:26pm

There are plans, but I have no idea when they plan to implement them. ability to up-vote them is part of what is being considered. For now, when we get alerts to Bug Reports we’ve entered or watched when they’re fixed and verified, and we do our best to alert you all when we can.

anonymous_user_c0687f281 · April 13, 2015, 7:22pm

Thanks .

BTW: Are they any plans for a public bugtracker to check status of bugs, get an automatic report on status changes or being able to vote them up etc.?

I wonder if it’s really possible to give everyone an individual, manuel feedback for each fixed bug?

anonymous_user_c0687f281 · April 13, 2015, 7:30pm

Ok, thanks.

Dig_Squid · April 16, 2015, 11:13am

I think this might actually be working correctly - ‘MultiLineTraceByChannel’ only returns TRUE if there is a blocking hit. I’ll update comment to make that more clear (it was correct on C++ function, but not clear on BP one).

anonymous_user_c0687f281 · April 16, 2015, 11:19am

Sorry, but that sounds really unnecessarily confusing. A hit is a hit. That’s what you are searching with a line trace. Isn’t there a special result node already to determine if hit was blocking?

This wouldn’t make sense otherwise.

Instead, how about adding a boolean result node to MultiLineTraceByChannel and set it to true if there was a single, blocking hit?

Dig_Squid · April 16, 2015, 11:38am

One important use for trace/sweep functions is for sweeping objects around (e.g. projectile movement), and in that use case a blocking hit affects motion of object, whereas an overlap does not, so that is why it’s an important difference. Returning bool is as convenience to let you know if you need to process some movement-affecting logic.

anonymous_user_c0687f281 · April 16, 2015, 2:35pm

Sorry, I just don’t get it. Why does ‘blocking hit’ then even exist?

Wouldn’t it be better to set

‘return value’ to TRUE if there was a hit and ’
setting ‘blocking hit’ to TRUE if it this hit was a blocking one…?

Dig_Squid · April 20, 2015, 4:23pm

In case of a ‘single’ query that returns a single result, you can do either. I should mention though that the ‘expand struct pin’ feature that you show in your screenshot came along quite a while after initial API, which was designed to avoid need for a ‘break struct’ node just to check if you hit something. Removing it now would break things!

anonymous_user_c0687f281 · April 20, 2015, 6:10pm

I really appreciate this functionality as it greatly reduced spaghetti factor in almost every blueprint.

Would be great if input parameters inside of functions would create local variables with same names, too. Way fewer lines across screen (I do that now manually for each function).

Dig_Squid · April 21, 2015, 8:16am

I’m pretty sure we have that feature now (function inputs are available as local), as I saw a post here that you can now set defaults for them as well.

anonymous_user_c0687f281 · April 21, 2015, 9:22am

Hi James,

I wish, you were right:

My workaround for this is currently, to manually create local variables like _testBool and run a setter for each input variable. Otherwise all my blueprints are crossed by many colorful long wires back to function input node.

Dig_Squid · April 21, 2015, 9:27am

Ah maybe that is a feature for 4.8 then!

anonymous_user_c0687f281 · April 21, 2015, 11:36am

That would be A-W-E-S-O-M-E.

anonymous_user_c0687f281 · August 21, 2015, 4:56pm

… but isn’t there.

anonymous_user_33800a51 · August 24, 2015, 9:33pm

,

Sorry, I’m not seeing this in our internal builds either. I’ll follow up with James to see what he might have been referring to, but it might need to be a new feature request. I’ll let you know either way.

anonymous_user_33800a51 · August 24, 2015, 9:39pm

Ah, I apologize, I found an existing feature request, but there hasn’t been any actual implementation that I’ve seen. For reference, request number is UE-6936. I’ll update it with a link to this post.