Hello! I would like to provide some feedback.
I tend to avoid blueprints for low-level stuff when possible because they’re bound to break very easily when something changes in a parent C++ class – name, path, parameters, etc. My philosophy for blueprints is simple: the mapmaker right-clicks the C++ class, creates a blueprint based on it, sets any cosmetic values, and uses it as they see fit, modifying the exposed properties if need be etc. So basically, I’m trying to make the project as portable and non-programmer friendly as possible. Unfortunately, the way UCameraShake works right now prevents me from doing that as much as I’d like to.
For some reason, in order to apply shakes on the camera, I am forced to create a blueprint of the UCameraShake class. Why? For instance, in Valve’s Source it’s as easy as calling a static method named UTIL_ScreenShake(). I don’t really see the reason why I’m forced to use blueprints here. Animations, FSM and materials, I can understand, but this? And what if I want my shake to be dynamic? Do I create 500+ camera shake blueprints?
My first attempt was to try and use one blueprint for everything. But it didn’t work. Simply obtaining the blueprint object and modifying it in-code doesn’t work because of the way the responsible engine function is designed. The values are restored to whatever was set inside the blueprint.
Unfortunately, this is hardly doable without modifying the engine source code, and that is something I am not willing to do because that will be the death of any portability and ease of future upgrades that I have in mind. Please, consider making UCameraShake C++ friendly. If not, i will just have to create a custom shaking algorithm, which is of course not a problem, but in a nutshell, I would be reinventing the wheel for no real reason.