The SetAngularOrientationTarget blueprint node takes a Quaternion as the
position target but there seems to be no user friendly way to create such
data. It would be great if there were conversion nodes from a rotator or
Euler angles.
If you know c++ you can do it yourself
Here is a RotatorToQuat blueprint macro for those of us who do not know c++:
http://zspline.net/files/RotatorToQuat.uasset
That is just an oversight, we have tried to hide quaternions from Blueprints to try and reduce complexity, and they are not much fun to work with element-by-element. Iâll deprecate the version of that function that takes a quat and add a new one that takes a rotator. Thanks for bringing it up!
Iâd appreciate it if you guys stopped doing kind of thing - Iâm finding blueprints increasingly difficult to work with since the earlier UE4 versions, because you guys are abstracting away and removing core functionality under the guise of âreducing complexityâ. Blueprint should mirror itâs C++ API counterpart as much as possible, not have everything hidden away in âhelperâ functions whose functionality renders them pointless outside of very specific use cases. Quaternion math exists to solve specific problems, and people have historically used them for various ends in Unreal gameplay scripting, the classical example being objects that require the full three degrees of rotational freedom and the issues that would otherwise occur with Euler angles.
Just doing things like projecting from camera space, or working with actors based on their screen space coordinates has become a complete and utter nightmare, whereas it was trivial before. It would also help if functions stopped getting âfriendlyâ names - I get that youâre trying to cater for the non-programming crowd, but is isnât helping anyone when functionality stops using naming conventions that have been widely used since the 1970s, since if youâre following any kind of documentation external to Unreal, it becomes a pain in the **** to translate. As a person used to said conventions, I frequently have a really hard time even finding the functions Iâm looking for without going into the source code to find what theyâre now called.
4 Likes
I have to say I agree with on one.
Before I begin I want to please note I am not directly at JamesG, but all of Epic who is involved in policy of weakening the power of what Blueprints were, even in the Beta!
Itâs a strange day when you have to admit that Blueprints are weaker now then they were in the Beta!
Someone as experienced in the Unreal Engine as should not have to be quoted as saying this:
If even one of your core community members says that, something is very wrong.
message should not be ignored!
**Blueprints should be growing! Itâs such a young language with so much potential!
**
I urge you all to consider deeply!
People dont need weaker tools, just organize the tools and maintain their power!
learns and grows, and as they learn and grow, I dont think itâs a logical progression that advanced BP -> now I will learn C++ !
Beginner BP should lead to powerful advanced BP user, who has the tools they need!
If you think my comments are coming out of nowhere, then consider me as responding to the very IDEA that blueprints should be less powerful just to cater to a wider audience. You dont have to think of specific things that you might have done (or not done yet), just please make sure that does not happen!
I am responding to the general software trend of lowering the power of a tool just so it is more accessible, when you do not need to!
Blueprints are a young language that can grow to be very powerful if you are not thinking of blueprints as simply a way to cater to those who dont want to use C++
Why not see what Blueprints can become on their own if you allow them to be powerful?!
At least leave the functionality in there that people who only have Blueprints as a programming language will need!
FRotator is not enough, even for my project which does not involve a 6DOF flying space shooter.
Iâve had to transition most of my custom game mechanics to Quaternion to get proper results 
**Organizing the Complexity**
Blueprints should not have reduced complexity,
**Blueprints have so many tools to organize the complexity**, that you can simply organize everything appropriately and leave it in!
Why are you limiting what blueprints can become before they've had a to blossom into a truly powerful programming language?
People want and need the Power to be in Blueprints as a standalone programming language!
PS: again I am not needing you to think of specific cases as the focus of my response, I just want you to deeply consider this:
Blueprints can become a very powerful visual programming language, **why not work on maximizing the power of blueprints**, instead of thinking of how they can be made to cater to beginners?
No one stays a beginner, we all learn and grow, but advanced BP users will not necessarily then jump to c++, they should have advanced BP Power that you allow and encourage to be there!
I can appreciate where you are coming from but I think you are worried too much about public opinion rather than the people who will actually use your system daily. If the occasional user says "wow is a lot of options, too much for me" that's not you're fault. They are just the occasional user anyway.
The people who use blueprints **daily** need the power to stay in blueprints and even grow!
**It's a young language, don't stifle it for the sake of "beginners"**
3 Likes
I think as designers we can all see the need to reduce complexity.
Of course we also want the most powerful tools possible.
The challenge Epic has is to introduce us to as much power as possible without making the engine into something un-intuitive like Cryengine. And of course they have a finite amount of man hours available.
I am sure they would love to give us quaternions in blueprint wrapped in a nice, polished package, but maybe it wasnât high enough on the priority list so they removed what they felt was an unfinished, un-intuitive system?
Maybe the devs can put quaternions on the roadmap to properly flesh out?
Come on EpicâŠWhy are you making moves like this? While BETA testing we all said how much we loved Blueprint system and how easy it is to do things. One of the reason why other engine users shifted to UE4 was Blueprints. Now you are reducing their complexity for beginners? When we first got UE4 Beta we were beginners too in UE4 and we showed how easy it was to pick things up get everything running. If you are reducing the complexity for beginners they aint gonna say âOh look, Epic reduced complexity for us. Its way easy now.â. Instead theyâll say âOh look, its just another node editor that does nothing. We still have to do things in C++.â
Please Epic PleaseâŠDont ruin Engine for beginners.
I would like to quote what Hourences once said.
Me tooâŠ
Yeah, what they said.
I havenât been around for very long, so I donât know how the current state of Blueprints compares to the beta, but as a general observation thereâs a limit to the degree of simplification and âfriendlyficationâ that any given system can take before it starts to lose its power and flexibility.
Blueprints are awesome, and the very best parts of the system are the bits that closely mirror the underlying C++ structure and classes. The more tightly entangled they are, the better, in my humble opinion. Please keep them in close parity going forward.
What, what do you put there that has 4 letters that makes sense?
Here to 2nd the comments in thread. Not looking to bring any flames on, just want to provide some end user feedback.
I think thereâs quite a few new to UE4 drawn into the system not only for the price but for blueprints in particular. When they realize that they may need to get into C++, I think there will be much more frustration and support tickets to deal with. So instead of speculating any further, let me give you the rundown of our situation and how blueprint limiting affects us.
So picture a small two person team looking to put together a modest mobile game. My partner is the artist and sees the blueprint system as a great way for him to tweak and modify the system when needed. Iâm doing the coding. From time to time, our roles will merge and flip as needed. Iâm coming from Unity and have not toyed with C++ since the mid 90âs. So, much relearning to do. Except while learning is taking place, we prototype in blueprint and convert to C++ when able or when it just makes better sense for speed. Problem is when what we need isnât in blueprint, or when the conversion from blueprint to C++ doesnât work for reasons we canât yet identify. So what we end up doing is spending a lot more time on trying to ascertain how the C++ functions work and how things tie together, instead of game development.
So in our case, what would help us out greatly (and many others I suspect) is a lot more documentation. I know is planned and we need to be patient right So, weâre being patient. Just that between now and then (when documentation really rocks), I suspect there will be much complaining with end users. Hey, maybe thatâs what prompts to limit blueprintsâŠwhich I think if so will just increase the # of support tickets. Anyway, while we all know that there is much still in the works and that there is only so much that can be accomplished on any given day, samples and copious amount of documentation for C++ functions would do wonders for those finding themselves diving into code when blueprints donât cut it. I think would be a wise foundation to develop until one day in the distant future blueprints perform and have all the capability that code provides.
Hope I donât come off too negative, as my dev partner and I are quite thrilled with UE4 and very much look forward to the future with platform. Just a bit of friendly feedback Thanks!
b u t t? [adding more text to exceed minimum 10 char limit]
I think that Blueprints can have complex features without necessarily becoming user
unfriendly. The whole engine is supported by tutorials and the community and thats
a huge advantage. Staying with the quaternion example, a designer might create a
whole game without hearing about them, just by following tutorials. However if that
designer runs into a problem where rotators canât do the task then he/she will end
up learning about quats. And that knowledge will help that designer down the line.
@Zeblote: That would be â****â.
Heh, didnât think of what way to write it.
@Zeblote, ZoltanE and : Please stop trying to circumvent the word filter. 
Seriously, itâs kind of obviously against the rules. is your warning, Iâm going to edit your posts as well.
As far as Quaternion rotation issues, we will make sure gets addressed as soon as we can.
Thanks for the feedback, all! I can definitely understand the frustrations voiced in the thread. Balance between accessibility and power is always something weâre very cognizant of when making design decisions for the blueprint system.
To give some insight into our thought process, we never make conscious decisions to limit our users, and we always want to give people the ability to open up as much as they need. To end, youâve seen stuff like Blueprint communications, interfaces, user-defined enums, expanded delegate (event dispatcher) support, support for passing of interface parameters around in Blueprints, etc. All these are an attempt to make the Blueprint system more powerful, and let you do even more things without needing to touch code at all. Compared to where we were a year ago, our internal teams have been able to make many more Blueprint-only games now without touching code. My favorite example is the Couch Knights demo we did for Oculus at GDC. That was a multiplayer, VR-enabled standalone experience, and we didnât touch a line of programming to do it. That wouldnât be possible in the beta!
Some that i see from above:
- Quat support
- âprojecting from camera space, or working with actors based on their screen space coordinates has become a complete and utter nightmareâ (are the Project / Deproject functions that are BP exposed insuffiient for your case?)
What else can we take a look at?
That being said, I know the API changes can sometimes be frustrating. The quat thing is understandable! Those that understand quats should be able to use them. Thankfully, nothing prevents us from adding quats in as blueprint types (one keyword is all it takes!) and we can expose the same quat math and helper functions we have in native code. Or, if you donât want to wait for us, you can do it yourselves for your own project.
So, we hear your feedback! What would be really useful now is to get some details of things that have changed that you perceive as limiting the usefulness of blueprints. I see a lot of mentioning of things being less powerful than in the beta, and thatâs totally valid feedback, but it would be really helpful to us if you guys could give us some specifics that we can take a look at to better understand where youâre coming from! Quats are a great start, but what else causes you to think that BPs are being nerfed?
I checked our bad words filter and saw a few words that needed to be removed. I think âbutt of my gunâ and âcigarette buttâ would be normal enough terms. I also found âbunnyâ as one funnily enough.
Thank you and rest of Epic for hearing us out!
I was responding to my perception of the trend / thought process, rather than specifics, my only really tanigible contribution is to offer you a compliment:
Blueprints have amazing organizational tools!
I was shocked when I found out I could do a filter search for anything using the search results tool!
Blueprints have way more tools to organize complexity than c++ does!
So one thing I really dont think you awesome folks need to worry about is complexity!
My only real tangible helpful suggest is just use your already amazing tools to organize the complexity, and focus on organzing complexity wherever you previously might have felt the social pressure to actually reduce the complexity.
Organization is all it takes, and you have such amazingly already well developed tools to do it!
Great to hear from you !
Hahah really?! the word bunny?
Thank you, !
Maybe it would help to clarify: we arenât trying to hide complexity for complexityâs sakeâŠweâre trying to hide unnecessary complexity! For instance, take something like the Math Expression node: makes it much easier to hide the complexity of doing long chains of math, but a) it doesnât limit you, and b) you should still be able to do it the âoldâ way if you choose! Hiding complexity isnât about removing options, itâs about adding shortcuts to use if you need it, and providing a versatile API if you need fine grained control. Hopefully thatâs in line with what you all want to do
Dear ,
I sent you a PM but I guess I will say publically as well:
I hope my feedback has not hurt any feelings over at Epic, I really care about all of your future, the future of the engine, Blueprints, and I appreciate all of you!
Iâve shared my thoughts/feelings only because I want you and UE4 to be as massively successful as possible!
I also have a feeling:
I really think blueprints will become far more powerful than unrealscript ever was!
I dont know why, but whenever I use Blueprints, I just have sense that that they have so much power that is still yet to fully be revealed!
So please really pursue idea:
How absolutely powerful can Blueprints become, way beyond anything thatâs been seen before in the realm of visual scripting nodes and even Unrealscript?
I just feel like UE4 Blueprints have the community and devoted development team of people like you to really become something way beyond what anyone thought a visual scripting system could be!
Letâs all face it, Blueprints are the scripting language for UE4 users, and always will be!
That fact needs to always be kept in view, and beginners will have their tutorials, while Blueprints becomes a scripting engine!
So that is my ultimate point
**Happy Feedback**
And yes math expressions is a perfect example of organizing complexity, not removing any functionality, great example! I really enjoy the math expressions system (many additional thanks to for one)!
I also loooove that you can right click to merge any nodes you want into a function or a subgraph!
I get a kick of merging groups of nodes just for fun, to satisfy my wishes for ultra-organization :)
Great to hear from you !
[FONT=Comic Sans MS]â„