Download

[Request] Blueprint Variable Readibility

General Feedback for Unreal Engine team
#1

Hello,

After working a bit with blueprints, there are some things that kinda bother me quite a bit. They are namely:

1. Visual Cues For Local and Public Variables
In the visual scripts, it would be nice if we can see if the variable is local or global. Sometimes I have to review BP scripts that are not checked in because it may break the game so they send in the stuff via SnagIt/ScreenPresso/<insert screen capture tool here> of the visual script. The trouble is sometimes I don’t know off the bat if the thing is a local or global variable so it makes for some interesting correspondence where I need to ask questions that could have been avoided if I had that visual cue. I know there if the left panel but at times there are so many local variables it is not feasible to screen capture every scroll of the variables pane on the left.

In terms of C++, what we usually do is this->bPublicOrGlobalVariable to show that it is public and when there is no “this” prefix, it is a local variable for the sake of consistency. At least in my world, it makes things a whole lot more readable. What would be nice would be some sort of prefix in the variable either in the get or set nodes like say:

Global/Public:
Same as now

Local:
Has something like [Local] as a prefix in the nodes or in the title of the node, have an italic text that says Local variable for MyFunction.

2. Visual Script Export to JPG/BMP
Sometimes when we wanna brainstorm, it would have been nice if we could have exported the visual script as a JPG file and share it to the team so we can be on the same page. It is really awkward when we have to either huddle in front of one screen or at times screen share over team viewer/Google Hangouts.

3. Expanded tooltip on variable type dropdown
Currently, the mouse tooltip over the variable type does not show what type is the variable. No biggie if you haven’t used it but if you have, it is greyed out and it tells you a message, albeit a helpful one that it can’t be changed. This is problematic especially if you have prefixes for certain actor types such as “cover_type_destructable_full”, “cover_type_destructable_partial” and the like because the drop down will only show “cover_type_destr”. Which one is it? This is especially annoying when the guy who did it (at times myself) forgets.

4. Blueprint export to C++
Items 1 to 3 are would what I consider as MUST HAVE, this is more like a nice to have and also I understand this is probably going to be a pain in the ****.

What at least I do would be that a lot of the stuff is done in blueprints to prove out the code in blueprints as it compiles faster and all that good stuff. After that, it will be ported over to C++ for the sake of performance and also it takes up lesser space in my Git repo plus we get to do diffs in Git. It would be really cool if you guys can have the ability to export this as C++ so we can optimize it ourselves as when it is done in BluePrints, the logic/algorithm is already in place and we just need to trim the fat.

This is something like what Dreamweaver and Visual Studio does with the HTML writer, would be even cooler if you can have a split view between blueprints and C++ like they do as well.

This is more for convenience and would also be good for people to learn up Unreal Engine and transition better to C++.

Thanks for reading this and I would also like to give a big thumbs up to you folks as Unreal Engine enabled me to live the dream of making a video game and pulling me away from the dreary world of business app development.

#2

In 4.5 (and previous versions), if you add “CompileDisplaysTextBackend=true” to the Engine.ini (under the [Kismet] section) . Then when you compile a blueprint it will display c++ code in the log. There are still some things that don’t get converted properly.

In the master branch, they have been doing some more work on this recently. Including the ability to save the c++ to files. At the moment it seems that they still see this as a debug feature, but it seems they are slowly moving towards where we could set some blueprints to compile to c++ and then that c++ is compiled and loaded in by the hot reload feature. One problem with this at the moment, is even if the c++ code is saved, the blueprint is still compiled into a blueprint generated class. So if you compiled the c++ code unedited, there could be name conflicts.

Although I’m not sure the generated C++ code would be good for people to read to try to learn c++. As it uses a switch based statemachine for the functions. So one or more related blueprint nodes are a state in the statemachine. So it would be quite easy to optimize it for someone who knows c++, but not very friendly to someone new to c++.

BTW: You can also get the vm bytecode, that the blueprint generates, displayed in the log by adding “CompileDisplaysBinaryBackend=true” to the engine.ini file. This is what actually is used by a compiled blueprint. At the moment the c++ code is just used for debugging.

#3

Thanks for the feedback!

  1. Seems like a good suggestion, I’ll make a task for adding some visual distinction in there to help clarify things.
  2. This is actually coming soon! One of our programmers on his Free Friday made a great tool where you can select nodes, hit a button, and it both captures a screenshot and uploads it to a website where you can share with others. That site also has a button to copy the blueprint nodes directly from the webpage, so you can paste the nodes in the screenshot directly into your graph.
  3. Easy enough, will make a task for this.
  4. As MattW pointed out, you can already do this. We’re working on improving the backend, and investigating how much trouble it would be to make C++ as an optimization step. However, we’re unlikely to ever allow a pure C++ representation only…you’d want to keep the BP around as the source file for the code generated by the backend.