UEFN 42.10: PointerSelect receives native Settings clicks — expected behavior?

[RedeatI]

Summary

In a private UEFN/Fortnite 42.10 Windows session, native Settings clicks reached a Verse PointerSelect.BeginDetectEvent callback while Settings remained visible. This can change underlying island selection. A counter-only diagnostic reproduced it without initializing board logic, custom UI, cameras or gameplay controls. Could Epic clarify whether this detection event is expected to receive native menu clicks, or identify the supported way to suppress them? No published-island reproduction or engine root cause is claimed.

Please select what you are reporting on:

Unreal Editor for Fortnite

What Type of Bug are you experiencing?

Verse

Steps to Reproduce

1. In an existing single-player project, replace gameplay controller startup with a counter-only diagnostic. Leave existing native scene actors, but do not initialize board logic, custom UI, cameras or gameplay controls.
2. Add TouchMapping and TraversalMapping once to the active player. Retain one PointerSelect.BeginDetectEvent and one Jump.BeginDetectEvent subscription. Callbacks only increment counters; no deprojection or board mutation.
3. In normal gameplay, click once and press Space once: pointer=1, jump=1.
4. Open the native Esc menu and click the gear, then click the Display category in Settings.
5. Observe pointer increments to 2 at 14:08:19 UTC and to 3 at 14:08:49 UTC, September 6, 2026, while Settings is visible.
6. Space alone in that Settings state did not increment Jump. Clicking Back incremented pointer to 4; after returning, a deliberate click and Space advanced counters to 5/2.
7. End the game and unsubscribe. One subscription instance and generation were retained throughout the observations.

Expected Result

Native menu interaction should not reach island pointer-selection logic. The Virtual Pointer tutorial says it does not work when Fortnite game menus are open, and its screen-coordinate example subscribes to PointerSelect.BeginDetectEvent. Please clarify whether this promise includes detection callbacks.

Virtual Pointer in Fortnite | Fortnite Documentation | Epic Developer Community

Observed Result

The same raw PointerSelect subscription received the native gear, Settings Display-category, and Back clicks. The Display-category click incremented the counter while Settings remained visible. The tested Space press in Settings did not increment Jump; this does not establish isolation for all controls or menus.

Platform(s)

Windows PC; UEFN / Fortnite 42.10; private editor-launched session. Observed September 6, 2026 UTC. Not tested on a published island, console or mobile.

Additional Notes

Scope: this is business-logic isolation in an existing scene, not a blank-project reproduction or proof of engine root cause. Native scene actors and both mappings remained. The diagnostic compiled and ran privately, then was removed and ordinary gameplay restored.

Documentation clarification: the input_events(t) reference describes BeginDetectEvent as low-level detection that fires even if activation is canceled, and recommends TriggerActivationEvent for most bindings. But the Virtual Pointer tutorial itself uses PointerSelect.BeginDetectEvent while stating that the pointer does not work in Fortnite game menus. Does native menu suppression include detection callbacks, or only a different part of the pointer system? The public player_input API does not list a native-menu-open query/event.

Verse API reference page for the input_events(t) class | Fortnite...

Verse API reference page for the player_input class | Fortnite Documentation...

Separately, switching PointerSelect to TriggerActivationEvent in the gameplay project still delivered menu clicks and was reverted. A normal UI button isolated the tested menu input, but focused Space activated that button and conflicted with independent Space confirmation; this is not being reported as a separate engine defect. No unsupported focus-property workaround is requested.

Filtered counter evidence (UTC, September 6, 2026; pointer/jump):
14:07:28 subscribed, instance 1, generation 3: 0/0
14:07:51 normal click: 1/0
14:07:59 normal Space: 1/1
14:08:19 native gear click: 2/1
14:08:49 Settings Display click: 3/1
14:09:40 Back click: 4/1
14:09:56 recovery click: 5/1
14:10:07 recovery Space: 5/2
14:15:09 OnEnd unsubscribed: final 5/2 (cleanup generation 4).
No account IDs, session endpoints, authentication data, screenshots or full client logs are included.

Please advise the supported mapping/event or native-menu gate, or whether a separate clean-project reproduction is required.

[RedeatI]

Separate follow-up observation, UEFN/Fortnite 42.10 on Windows, September 8, 2026:

We tested an isolated ordinary two-button canvas with InputMode.None. The sole controller added TouchMapping and TraversalMapping and subscribed only to Target.OnClick and ConfirmSink.OnClick, without raw PointerSelect/Jump subscriptions or gameplay initialization. Both buttons were visible. The Target handler toggled selection and then called PlayerUI.SetFocus(ConfirmSink).

The first click produced no observed callback. A second click while the cursor was already over Target produced target_count=1, sink_count=0, selected=true and a sink focus request. Approximately 19 seconds later, one Space key press produced another Target callback: target_count=2, sink_count=0, selected=false. The runtime module and diagnostic markers were verified. Production code was restored afterward.

This establishes that the tested post-click focus request did not route the subsequent Space activation to ConfirmSink. We cannot observe internal focus and do not claim whether focus never changed, was overwritten, or differed from activation routing. The first-click miss may be a separate issue.

Could Epic clarify whether SetFocus is supported in this InputMode.None callback scenario and whether this should be tracked separately? This does not expand the original Virtual Pointer report to all menus or platforms. The original reproduction retained native scene actors; the tested Settings Space did not increment Jump. A Custom Button IsFocusable=false override was rejected by Valkyrie and restored; no validation bypass is requested.

[RedeatI]

One additional isolated check on Fortnite 42.10: I subscribed to MenuNavigationMapping/Back.BeginDetectEvent and TouchMapping/PointerSelect.BeginDetectEvent, without game rules, custom widgets, Jump handling, or pointer projection. After one successful registration, I opened the native menu with Escape, opened Settings, clicked the Audio tab, exited using the on-screen Back button, and clicked once in gameplay. The trace recorded three PointerSelect events and zero Back events. Thus Back did not provide an observable native-menu entry boundary in this check. The diagnostic was removed and production restored.

Is there a supported way for Verse to suspend PointerSelect handling while a native menu owns input, or to distinguish a native-menu click from a gameplay pointer click, while retaining mouse click and Space as separate actions? If this is a known issue, could you identify the tracking reference or intended API contract?

[Sprintermax]

Looks like this report was AI generated. It is valid, but the wording and details that the AI wrote are wrong or confusing to understand…

But quick TLDR is: Yes, this is a bug, not expected behavior. Fortnite “native” interfaces being active such as Social Sidebar and Settings Screen should prevent the PointerSelect from receiving inputs. (Should behave exactly like the values reported by the “jump” action or the other actions mentioned)

The behavior also does not differ from having UIs added with or without InputMode.All/None. PointerSelect forces and automatically adds the “InputMode.All” while being active. Plus, UI related actions (Back, NextTab, Drop, etc) only works when UI related mappings are active + InputMode is set to All (by an added UI or by the TouchMapping)