Hello,
Have a scary bug that makes me thing my project is broken.
This is had to explain, basically I have a function the uses set view target with blend for when the player backs out of a context screen (entering a keypad). I have a function (call it deinteract) that fires when the player uses input action (Back) which is backspace on keyboard and right face button on my gamepad. This works as intended, the player can exit the keypad view using the two button options. I have print string after the set view target with blend as extra confirmation.
However I now made it so if the player enters the correct code and hits input action (Enter) which is Enter on keyboard and bottom face button on my gamepad, the deinteract function is ran. I can confirm this uses the print string. The bug is that if I do this Enter action with the gamepad, the code runs, the print string fires, but the camera blend DOES NOT happen, despite the function running as intended and confirmed via the print string. Then if I do the same thing with the keyboard, the function fires, the print string confirms it, but now the view target with blend works.
This is a worrying bug as I feel like it’s possibly something broken internally with my project and that I’ll have lose a lot of progress and work on an earlier version of.
Any help will be greatly appreciated!
Thanks
Jack
print string firing on both paths means the input side is fine and the function really runs, so your project is almost certainly not broken. this is the set view target with blend call being a no op or getting overwritten on the gamepad route only, and two quick logs will tell you which.
first log: right before the set view target with blend node, print the name of the current view target (get view target on the player controller). do it on both paths. if the gamepad path already prints your player camera there, something earlier on that route snapped the view back without a blend, and blending to the target you are already on does nothing visible. gamepad ui focus handlers are a classic source, a second set view target call hiding in the widget blueprint that only runs on the gamepad exit path.
second log: print get view target again about 0.1 seconds after the blend call, with a short delay node. if it still shows the keypad camera, a competing set view target with a zero blend time is running after yours in the same frame and snapping over it. do a ctrl shift f across the whole project including widget blueprints for set view target and drop a print on every call site, the gamepad one will expose itself.
if both logs show the blend genuinely starting and the camera still not moving, try a hard zero duration set view target on the gamepad path once. if the snap works, your target logic is correct and the problem is purely the blend transition being replaced or cut short, which points back to the competing call rather than the input.