Button Devices Not Respecting Interaction Radius

Summary

button_device Interaction Radius not enforced. Players can interact beyond configured radius (including through barriers).

Please select what you are reporting on:

Unreal Editor for Fortnite

What Type of Bug are you experiencing?

Devices

Steps to Reproduce

  1. Place a button_device and set its Interaction Radius to a small value (e.g., 0.4 m).
  2. Surround the button_device with a barrier_device configured as a hollow box, sized larger than the interaction radius.
  3. Ensure the player is NOT on the barrier’s ignore list so the barrier blocks physical access to the button.
  4. Enter the game and approach the barrier from outside.
  5. Attempt to interact with the button_device from outside the barrier.

Expected Result

The player should only be able to interact with the button_device when they are within the configured Interaction Radius. Since the barrier prevents the player from getting close enough, the button should not be interactable.

Observed Result

The player can interact with the button_device from well beyond the configured Interaction Radius, effectively bypassing the barrier. The button appears to be interactable at or near the maximum possible distance regardless of the Interaction Radius setting.

Platform(s)

PC (Windows), Xbox, Playstation

Island Code

9881-8842-2718

Additional Notes

This issue appears to be a recent regression. The Interaction Radius was functioning correctly in prior updates. This affects any design pattern that uses barriers to gate access to button_devices, since players can now interact with buttons they are not intended to reach. Our map uses this pattern extensively for pet purchase and equip stations. We have implemented ownership checks on button interactions as a workaround, but players are presented with the option to interact anyway, which is confusing. The Interaction Radius property on button_device should be enforced by the engine as configured.

Hi Iantram, Interesting bug.

I tried setting this up and was able to see what you’re describing, but just ā€œApproaching the barrier from the outsideā€ was not sufficient.

I needed to angle myself diagonally, and hunt around with the camera to find an angle that triggers interaction prompt.

I used the interaction distance of .4 as mentioned in the bug report. Barrier Depth/Width is set at .4 in the screenshots. When barrier Depth/Width is set at .5 I’m unable to reproduce.

I’m assuming physics is disabled in your island - when physics is enabled a different FortCharacter is used, so I wonder if that would make a difference as to what is triggering the interact prompt. (Invisible collision boxes attached to character used for overlapping buttons?)

FWIW I was able to reproduce this with a Scene Graph Interactable component as well. (No interaction radius setting there, I’m guessing it’s just based on mesh size)

I think in the long-run a system that changes what the button looks like when it’s enabled/disabled would be preferable.

I took a look at how you had things set up in your island, it’s a lot easier to reproduce there. (no standing diagonally and hunting with camera needed.)

1 Like

Thanks for taking the time to reproduce this and share the screenshots. I appreciate it.

On my island, physics is currently disabled, so I cannot easily test whether enabling it changes the behavior without risking other systems that depend on the current setup.

I also can’t quickly try increasing the barrier depth and width to 0.5 in my production layout. In my case it would push the barrier outside the station footprint and would require reworking the scene. That said, your finding that 0.5 does not reproduce it is interesting. I will try playing around with that to see if I can see the same thing.

On the flip side, I have also seen cases where an interaction prompt appears but the button event sometimes will not fire.

I like your suggestion about a clearer enabled or disabled visual state on buttons. That would be a nice quality of life improvement.

Thanks again for digging into it!

1 Like

FORT-1054159 has been ā€˜Backlogged’. This is an issue we’d like to address in the future.

Thanks for the update.

Just to confirm: Interaction Radius (which worked fine for us for over a year in a live published island) now behaves as if it’s ignored, including allowing interaction through barriers, and that regression is getting parked in ā€œBackloggedā€??

We can block the action with ownership checks, but players still get the interact prompt anyway, which is a great way to teach them ā€œthe UI is lying.ā€ So I guess there’s that.

If this can be re-triaged as a regression impacting live islands (9881-8842-2718), that would be ideal. If not, should I assume this is effectively ā€œfiled awayā€ with no realistic expectation of being addressed? :thinking:

The truth is, seeing a bug get marked as ā€˜backlogged’ is not a good sign, but in this case it’s probably the right decision. Gating buttons behind barriers like this is not good design. (But I do acknowledge that there should be expectations for not having your island broken with updates)

If there were several creators raising this issue that might help with traction, but so-far this is the only report I’ve seen.

Your repro steps are good, but in the future something more scientific might be useful. (ā€œPlace barrier at this location with this scale, place button at this specific location inside of barrierā€) It’s better to be able to demonstrate a bug outside of the context of your island where many other factors could be involved.

It’s not really ā€œinteracting through a barrierā€ that’s the issue. I probably shouldn’t have even mentioned that, since it distracted from what I was trying to say.

It’s the fact that there’s this setting in the button_device:

image

Interaction Radius. Which has always worked as advertised. And recently, it stopped.

A player can now be like a mondo distance away from a button and be incidentally prompted to interact with it. Interaction Radius now provides no help.

Anyway, I’m over it. I’ll just avoid creating anything that relies upon that setting in the future.