I’ve the same big ol’ switch statement for setting the attributes as well. This feels like an absolute mess to deal with. This struct has 68 properties.
The only thing I can think of is completely ditching the struct in favor of a Map<GameplayTag,Float>, but that’s a massive overhaul throughout my entire game. So I’d rather find a more elegant solution here.
Accessing Struct properties by name would be ideal, but then that requires FindPropertyByName, which has performance overhead as I understand it.
this i think although to save you future refactoring a Map cant be replicated so maybe an array/fastarray (with a map lookup) and use a struct instead of float incase you decide later to add say modifers etc
even a property iterator by name has the issue typos/renames etc
another option if your game isnt too complex is make each attribute a UObject
It’s a SP game so I don’t have to worry about replication. I’ve already got the colossal switch statements implemented so I can just leave them as is, but feels wrong in a way lol. It works though so there’s that.
I’ll probably just leave it as is since I can’t find a way to improve the current struct access logic without throwing GetPropertyByName into it and I’d rather not as that has to do a string lookup and comparison on every call.
Decided to just leave the giant switch statement. I couldn’t find a more performant way to deal with this and while ugly would more or less be no different had I done it in C++. So just going to let things be.
