Hello, after having worked quite a bit with input trigger devices lately, I’ve discovered some settings that, for me, could be highly improved.
I found a post that addressed part of my concern (Issues with the Input Trigger Device), but I have a few things to add.
While I totally agree with what has been said by @im_a_lama, I think the easiest solution would be to merge the “standard actions” and the “creative input action” settings and then remove the “input type” selection in the input trigger device
This way, we would be able to directly track the player’s inputs without hoping that they’ve properly assigned their keybinds in their Fortnite settings.
Any creator thoughts is welcome and if you have any question, feel free to ask!
Thank you for your feedback. While I cannot guarantee a response, I can confirm that this has been forwarded to the appropriate team.
Also since the devices do handle input separately, (which isn’t a problem, kind of nice actually) it would be great to get an enum output with the input indicating what the device is set to. I end up wrapping my input triggers in input_type:=enum:'s every single time I use them.
Also, may as well throw it out there but I find the Device level Activate/Deactivate Register/Unregister timing delays to be unusable (way too much latency). It would be great if the API functions for the device could be extended to have a Show/Hide HUD Element as well as a Set HUD Element Text.
The main issue I find is that the UI shows up before the input trigger will accept input, and this is exacerbated by multiple/frequent activations/deactivations. By giving us the ability to manage the HUD Elements independently it reduces the burden of support and implementation for you on the device overall (presuming its easier to do than optimize timings).
1 Like
