In case, the problem is that normal projection / deprojection functions aren’t exposed at all. There’s an interface in the player controller but a lot of that revolves around the mouse cursor (GetHitResultUnderCursor / DeprojectMousePositionToWorld). is obviously way too specific to meet the needs of anything except clicking on objects. There’s one function in the PlayerController called GetHitResultAtScreenPosition that is actually more versatile and is the only function that needed to be exposed, but somewhat perversely it’s the one that isn’t exposed to blueprints. There’s also a function in the HUD called Project, but it suffers from nasty UE3 hangovers and relies on the HUD (if there even is one) for a given player controller, and relies on the canvas being valid when you want to do the projection (the canvas is often not valid). Maybe I want to get screen space coordinates for objects, but don’t want to do gameplay stuff and not perform drawing operations?
In short, it’s not very well implemented and all of these functions are completely reliant on having a player controller. Some are reliant on having a HUD and being called at a time when the canvas is valid. The functions that are exposed to blueprint do not need to exist, and the function that should replace them is the one that isn’t.
In the player controller, GetHitResultAtScreenPosition should be exposed to blueprint and the under cursor / under finger functions can be removed. Functions to get the mouse coordinates and finger coordinates (with indices) already exist and can be just plugged directly into GetHitResultAtScreenPosition. By having the under cursor / under finger functions, you’ve made an assumption about what I intend to implement, and there’s a pretty good that assumption is wrong. Maybe I want to find what is on the screen at an arbitrary set of coordinates that are not the mouse or a finger? What if my game is split screen and I have one HUD, but two cameras? There are probably loads of other valid use cases where these functions aren’t useable.
What you should implement are standard projection / deprojection functions for any given camera via something like the scene manager. removes the reliance on player controllers, HUDs and the canvas - and at the end of the day these are the functions you’re using anyway, just via a chain of other actors that aren’t actually relevant.
TL;DR - The current philosophy for building game framework and other parts of the blueprint API are causing people issues because assumptions are being made that are resulting in highly specialised and completely inflexible nodes that do not meet the needs of a wide variety of use cases. Instead, blueprint should really mirror the C++ API for each actor / object / component class as much as possible and provide a static function library for certain gameplay specifics - it doesn’t matter if it takes three nodes to achieve something instead of one highly specialised node - what matters is that the user can actually achieve what they need to do.
Also, try and avoid hangups caused by Eldercode and awkward conventions from previous engine iterations. A lot of them did some real bad voodoo.
Thanks!