Dear Friends at Epic,
Is it possible to add a static array variable to a blueprint?
Thanks!
Rama
PS: I know how to add dynamic arrays to blueprints
PSS: To me this is more of a bug / essential missing feature than a question, I dont really consider it a feature request because it is a very low-level thing 
Hey Rama -
Nope, unfortunately you cannot add static arrays to blueprints. We intentionally decided not to add them because of the complexity it added to the end user. Are you trying to interface with an array that you declared natively? Or would you like to declare a new static array in a blueprint?
Lovely to hear from you as always Nick!
âWe intentionally decided not to add them because of the complexity it added to the end userâ
What exactly is this complexity?
I am not a user of Rocket that is worried much about complexity, if the option can be made available I would much prefer it.
I wanted to be to create a static array as part of blueprint, as opposed to a dynamic array, simply as a lookup table
Thatâs something that is super easy with static arrays and iffy with dynamic arrays / clunky at best.
But again, what exactly is the complexity to the end user?
I dont like the idea of Epic limiting the power of the engine to the perceived limitations of the end user.
The end user should be forced to grow to meet the power of the Engine
That way the potential for growth of the individual is there, rather than that potential being stifled from the beginning.
And if the individual does not grow, well people like me will, so we will benefit from the fact that you made this option accessible to us.
You could lump it together with other features that need to be made visible to advanced users,
but please do not average me out with people who are a perceived audience of casual users!
Rama
PS: In truth I think even casual users would ultimately grow to wanting the more advanced / complex features made available, when theyâve learned the basics
To clarify, do you mean a statically accessible array or a statically sized array? Iâm guessing the former, but your comparison to dynamic arrays makes it sound like the later.
Assuming you mean statically accessible arrays, I believe the complexity Nick is talking about is related to newer users. Iâve had students come to me, completely lost and in over their heads, code riddled with unnecessary static variables and functions, with no idea why modifying X is changing Y. Static member access is, unfortunately, a crutch that many inexperienced programmers tend to use to âmake their code work.â It rarely has a legitimate use case, like the one you have. ( EDIT: To clarify, I mean that you are using static access properly, unlike a lot of other programmers.)
Blueprints, in my mind, are the âbeginnerâ programming form in UE4. For this reason, I think adding static data access would do more harm than good. It would not provide any tangible benefit, as any functionality required by experienced programmers can be replicated a number of other, better, ways:
#I Await Your Response Nick
All of this would be clarified if I know the answer to this:
âBut again, what exactly is the complexity to the end user?â
Rama
The complexity is that there would be more than one way to do something, and the ambiguity wouldnât be immediately obvious to non-programmers, which is why we chose to allow dynamic structs only in blueprints. Since dynamic arrays offer a super-set of static array functionality, we chose to limit users to dynamic arrays only.
In imagining the interface for static and dynamic blueprints, the two would be basically mirror images of each other, but to a user who didnât know the difference, they would potentially be confused by why one array can be resized and grow, while another could not.
I can certainly sympathize with not wanting to limit the power or the expressiveness of the language, but one of the primary design goals was accessibility for non-technical users.
One thing we are exploring is adding support for other helpful things, like TMaps. That would help in the case where you wanted a mapping like you would get from a static array used with enums, but would also have allow for a non-overlapping set of functionality from arrays. To me, adding a wider variety of useful types would be the ideal answer here.
Hope that helps clarify things!
âI can certainly sympathize with not wanting to limit the power or the expressiveness of the language, but one of the primary design goals was accessibility for non-technical users.â
Ahhh okay, well then I really just want to say this Nick
#Thank You for UE4 C++!
I just finished making my in-game undo-redo system for my in-game editor using a lot of low level memory allocation, struct inheritance, and all sorts of pointers everywhere
and it works perfecty!
Something I could not have done in unrealscript
So
please tell everyone for me
Oh thank you thank you for UE4 C++ Access!
#
Rama
Glad you were able to fill the gap with C++, thatâs our hope that people will be able to extend bits themselves now to support their preferred workflows Thanks as always!
âthatâs our hope that people will be able to extend bits themselves now to support their preferred workflowsâ
I absolutely have been doing that!
I posted a tutorial for people on how you can make your own UE4 C++ Operators to work with FString conversion functions more quickly!
tutoriol on making UE4 C++ operators
#C++ Code
//Str float
FORCEINLINE FString& operator<<(FString &Str, const float& Value )
{
if(Str.Len() > 0) Str += " ";
Str += FString::SanitizeFloat(Value);
return Str;
}
FORCEINLINE FString& operator<<=(FString &Str, const float& Value )
{
Str = FString::SanitizeFloat(Value);
return Str;
}
#Result
Str = FString::SanitizeFloat(TheFoat);
becomes
Str <<= TheFloat;
#FString Stream
The above C++ also enables me to make an UE4 FString Stream
Str = "";
Str << Float1 << Float2 << Float3;
#Thanks Nick!
Thanks Nick!
Iâm am loving UE4 C++ !
#
Rama
This is a great bit of info, Im wondering if it might be useful to compile some of these responses and put them into a Q/A so that people arnt repeating themselves.
I am curious why it was decided to keep the name as Array and not use the name List, it just seems to mean something similar in lay terms especially in regards to the dynamic arrays.
It just seems odd to me is all, on one hand I understand the reasoning behind making things less tech savvy but on the other we kind of work in the business of being tech savvy lol so I see all kinds of complex vector math in blueprint that even a skilled python programmer would cringe at then we call those people creating that less technical. It just kind of escapes me for words, that I guess in comparison a person can still create a work of art by using their fingers alone without the need for brushes.
To get alittle bit philosophical as I like to do, sometimes we need to go backwards to go forwards. That in the dawn of 3d games (wow sounds like centuries ago) 2d games still had the palettes to beat em in pure fidelity, that changed. I think we are now getting to that point with tools, sculpting tools were only the start, texturing tools followed and now I really think we are seeing the divergence of math from the old (well we arnt exactly using ancient greek all the time) methods into something new with building expressions up in blocks.
In terms of a teaching tool I think Blueprint could actually be a gateway into more complex programming, Ive certainly considered more educational games now because of the amount of control the tools bring. Unfortunately while education is something I find intriguing my current project is my focus but I would just like to put it out there, that UE4 could be used to make higher level math and english games. Learning on a whole has evolved so far thanks to mainstream conventions like TED, its really less about pen and paper and more about productive learning outcomes.
We decided to keep the name âarraysâ because of the legacy of UnrealScript, and consistency with our own code base (since the native templated container type in code is the TArray). There could be an argument made for changing it to be named âlist,â which would be more familiar to Pythonists, but we felt in this case, it would be better to maintain consistency within the engine, since blueprints and native code touch more frequently. The hope is that by keeping the naming consistent between the two, itâll make it easier for people to go from blueprints into native code eventually.
And as for BPs being a gateway to more complex programming, I certainly hope that they become this! Learning to break down a problem into a series of tractable, logical steps is to me the heart of programming. Syntax and whatnot varies from language to language, but they all share the commonality of being about the proper deconstruction of a problem. Blueprints help to remove the mental block of âwall of text,â and the need to learn a written syntax from the get go, and allow focus on the problem solving material. My hope is that people will learn in a friendlier, visual, and contextual style, and then be able to move that knowledge into traditional programming.
#Thanks for sharing Nick!
âAnd as for BPs being a gateway to more complex programming, I certainly hope that they become this!â
I have an idea for you in this regard:
#âSee the C++ For This Nodeâ
Obviously many nodes have complex or private C++ behind them,
but there could be some nodes that could have a little icon âsee the C++ for this nodeâ
And this could be like training wheels for people to get more into the C++ side of things.
FORCEINLINE functions would be great for this since a lot of them have all required logic visible in the.h file itself.
Just an idea for you
Rama
#Gift for You Nick
By the way Nick, I created this thread for awesome Devs like you to enjoy
Feedback for Epic, Things We Like
http://forums.epicgames.com/threads/983001-For-Epic-Things-We-Like-Positive-Feedback-to-Epic
and the most common thing I heard about in the thread other than everyone loving the c++ access:
#Everyone Loves Blueprints!
!
#
Rama
Thanks for the reply! That makes alot of sense to me coming from a UScript background, I was just curious because arrays are quite a complex topic and to a non-programmer I know terms like replication and array can seem so overwhelming. Ive witnessed many morale defeats before any work is even underway and I believe alot of them are down to nothing but the fact people wernt working with a GUI, that text based programming (regardless of its complexity) has a stigma attached.
I do think that is Blueprints greatest strength is that its independent from underlying syntax allowing a user to explore their potential more thoroughly without being railroaded into a line of thinking. I find it great that I dont have to write as much pseudo because I can draw a flow graph on paper and just take that to Blueprint when Im ready instead of having to convert back and forth. I do think that is an overlooked step, that even when Im writing text based code I still find flowgraphs important on a number of different levels, especially for gameflow and events so its possible that Blueprint can teach skills you cant learn from math and syntax.
Daniel: Yes! The stigma of text based programming is exactly the sort of thing we want to remove as a barrier. Itâs understandable, other than an IDE, you have nothing to help you when youâre poking around. Hopefully with Blueprints, we can remove that barrier and get people straight down to the hard part. Learning a text language is much easier if youâve already managed the logical and problem solving concepts!
Rama: Thanks for the link! Thread made my day
âRama: Thanks for the link! Thread made my day :)â
Yaaay!
That was my goal!
To make your day a happy one!
Rama