I have a blueprint class that I’m going to be creating a lot of instances of. I’d like to create a const variable instead of leaving a magic number in my code and just adding comments everywhere I use it. I’m not sure how UE5 handles read-only non-Instance Editable variables memory wise though. So does UE5 assign memory for the variable once for the class, or for each instance of the class I create?
afaik it will create a variable per instance, unless it’s “static.” not sure if bps allows you to have static variables.
i think it’s not the best way to worry about it. instead of you should centralize the place of that data, for example on data tables or material parameter collections.
if you think that’s troublesome, then probably your data is too small to be important to be optimized away. if it’s important then it’s worth organizing it like that.
It’s definitely not something important enough to deal with making a data table and reading from it or doing other stuff like that. I only really want it as a const variable so if someone (future me) reads it they can tell at a glance that index 0 is for horizontal objects, and index 1 is for vertical objects.
I’m probably just going to leave it as is, but I’m going to leave this question open in case someone knows for certain how UE handles the memory for those types of variables. I’d still like to know the answer ffr.
what’s “frr”?
as much as i’d want to get my post marked as answer, i’m also interested in knowing if someone has a better answer.
btw, i’m not sure if this fits, but sometimes what one needs is to see the problem in a different light.
what you describe to me sounds exactly like an “enum”.
also there are string tables, but those are used for translation mostly.
and for names there are … “game tags” ? (it slips my mind) though i rather use fnames.
1 Like
you can also have blueprintfunctionlibraries that returns constants. or subsystems that do that. either a constant or a variable. but it’s on one place.
if you’re worried about memory, you have to think if you’re having a ref to a bp. in the bpfl and subsystem. i’d say it’s better to use a bit more memory to have less references, as those cause issues.
1 Like
frr is “for future reference“.
Enum should work well, I will try that. Thanks for the suggestion.
1 Like
thanks 
oh that’s pretty neat. i always come back to the forums to search for info or benefit from old threads. so it’s good. good luck !
here’s an example of a subsystem centralizing a value. as you can see performance and memory savings is not the goal in this case. Making sure you're not a bot!
1 Like