that makes me want to help further 
thanks
good. that’s something worth thinking about. it’s something important. not to be depressed, but to make the best use of what you have. also how i’ve seen life works.
like the meme
but sometimes it’s just “■■■■happens” and well. you have to rearrange your life.
for example, last night i saw this video, of a guy working 10 years on a game, and suddenly it had to rush to make a demo in early access because he lost funding. and had to cut a ton of content (many years of work). he was lucky to pull it off. but most people aren’t and it’s a lost opportunity. from my outsider pov he could have been more efficient/effective and saved a lot of headaches.
i’ve been through enough shhtuff to know that’s pretty common. and i’ve worked on a few companies that had the same issue.
Macros (not to be confused with Macross 
) aren’t “bad” (i don’t think in terms of good/bad). you have to know when to use them and how. the way you were using them would bring you issues. most people using macros are overusing them in my experience.
don’t worry i’m not dogmatic, nor i expect people to know things. i just like to help and share my views. goto’s are a very old element in programming which allows you to jump to random places of the code. when used properly they are good, and the cpu works in terms of gotos. so if you disasemble a program, or write assembly, you’ll end up doing gotos. but they are hard to maintain and requires proper thinking. and end up causing issues when missuses. so most people decided that “goto” was a bad word. to avoid even having to think about them. not bad per se, but requires discipline and careful thought. and they aren’t really necessary. pretty much like macros. you can get away with not using them without much pain. (for general programming i mean). the fact you don’t know about them, it’s a pretty much a result of that i think.
gotos in particular lead to spaghetti code, and unpredictability, since you can’t really follow the flow of the code as easily.
macros have specific side-effects, when you’re starting you might not be aware of them (dejavu). i won’t explain now, but beware they exist and require time to learn.
i used function too loosely. i meant “block of code”.
this macro returns 5 different variables. and will force you to branch always you call it (mostly).
i would put the branches inside the same block of code and return that enum. so only one variable. since my experience tells me you’ll rarely need to know exactly that one of those bools is true. and if you do, it’s easier to do with a select or switch node, using the enum instead of 5 bools.
rule of thumb, if your values are mutually exclusive, and boolean (on/off), an enum will be fine. (but make sure tehy are mutually exclusive,
a single function that returns the enum.
this is a stub
you can either return the value or set it on the variable you use. that depends on how you will use the function.
at the same time. multiple output variables. it’s leads to issues. usually you’ll return only one variable. if you need complex data you usually use a struct or a reference. since bps has issues passing things by reference, sometimes you use more than one variable.
for example map::find returns the value and another boolean to know if it found it or not.
this is legal and i’ve used it multiple times, specially when interfacing with bps. but it’s not ideal imho. nobody will kill you, and shouldnt. but i prefer to minimize that to make it easier. now, returning 5 bools is just too much.
most of the times yes. if the values are “correlated” you’d probably want to use a struct. correlated are values that together make up a concept. e.g. you have a car piece. every car piece has a mesh, a position, a scale, a rotation, etc. those should go together most of the time. so make a struct. then in the future it makes it easier to define other things, like data tables. and it’s easier to pass parameters from one function to other. since you only connect one cable.
sometimes if you have a function with lots of params, you just make a struct to clean it up. but that’s preference. i’ve done that for a cpu 3d renderer in cpp that had to pass like 10 parameters, and it was getting annoying to maintain. later on it saved me since i used it for other things.
ultimately is your call. you’ll get the hang of “how many are too many”. but it’s good to be aware that multiple return values usually are a sign that something could be improved.
i personally would still recommend a function even if you use it only once. i have ton of those. since they are more closer to programming paradigm than collapsed nodes. you don’t have that in cpp. also having data going into the collapsed nodes and data out makes it harder to handle.
a function still provides some usefulness, it can be reused, bound to events, renamed, found in searches, they also can use return nodes which breaks the flow, exposed to other objects, etc.
the reason is good, but the reasoning might miss a bit. you don’t know if you are going to need it or not. using a function is not THAT much more effort than collapsing the nodes. in fact you can just select > right click > collapse to function (i think). yet not using a function prevents you to reuse it in the future. so you end up with what could be called “technical debt”. or plainly get shot in the foot for refactors.
the biggest issue i see with bps is that it has many new utility elements like macros and collapsed nodes and events, multiple execution paths, the ability to goto, that lets people use ways of doing things that are not the usual ones, then they get confused. i don’t say they should remove it, it has its place, but it confuses people. and most of the bps users are not hardcore programmers, they’re mostly people starting, designers, artists and other non-programmers. so it’s too much power to shoot yourself in the foot. kinda funny, since that’s the argument some programmers use to force others to not use goto. lol.
i usually would prefer a sequence for that code. that way makes it much easier to maintain.
i don’t have much more time. but what i meant is to remove that switch. and have only one function for “Weight value print on screen”. that receives both, the “random weight to display” and the enum that you use on the switch.
in fact i wonder if you really need to pass the enum at all, or you should call the function that converts a weight to an enum inside WeightPrintOnScreen. which is what i would do. it depends on whether you are going to use the enum elsewhere.
in cpp itd be something like this.
(this is pseudo code fast, it wont compile) also if you want to translate your game you would need to use ftexts.
EWeightType GetWeightType(float Weight){
if (weight <1000) return EWeightType::Grams;
if (weight < 10000) return EWeightType::KG;
return the last one;
}
FString WeightValuePrintOnScreen(float WeightToDisplay) {
EWeightType Type = GetWeightType(WeightToDisplay);
FString result = “Whatever text “ + FString::FromFloatIDontRemember(WeighttoDisplay);
switch(Type){ // you can use an array instead
case ::Grams: result+= “gr”; break;
case ::KG: result += “kg”;break;
}
return result;
}
yeah. it’s helpful to be clean when you can to avoid having to pay for it later. but beware. you can be “too clean” to the point of being wasteful (ocd/paranoic/dogmatic/etc). if you end up arguing with your colleagues, it’s a red flag. also it’s important to move forward and break stuff sometimes. perfectionism leads to paralisis, and there are too many things that you only learn by experiencing them (that’s why i try not to tell people what they “should”™ do and why i don’t like gpt that much (since it’s very strict on what it “knows” (it’s too eager to give you an “answer” and doesn’t care to ask what you want.)).
for example in my project that i’ve been working for 2 years, i started doing some things in a way, and a year later realized, actually, not optimal, let’s refactor it. and it was ok. i didn’t held the whole project to decide one thing. for example i’ve removed a big mechanic, and i’m happy i did it this way.
i was trying the technique for “do only good enough work, but only what you need, refactor later”. and i’m happy that it worked well. it’s a balance, doing good enough work. not too trash, not future proof/perfect.
one issue that i ran into, is, after 1 year of working in a project, i started to forget what i’ve done before and why. the codebase and content is quite large. so it’s easier to remember my pattern for how i work, than the specifics of the code. (like, oh i usually check for null pointers inside a function, not before calling it. so it’s relatively safe to call here, or this potential bug is not going to crash).
and maybe if you’re lucky you find someone to help you.
those are my opinions.
pd my english is not the best either, don’t worry.
