Firs some advice: don’t overdo with structs in arrays of structs. Or do not push unreal to the limits, make al data structures as simple as possible. Unreal is stable with structs in arrays, but something more nested may cause weird stuff. Epic fixed a lot of it since 4.4 but it is still there, just deeper. So do not dig that deep in.
So best is “flat” struct that keeps all you data for module. Or if you plan to have different modules (same magazine for 2 different guns that have slightly different model) that have same stats, split all data into 2 structs, one for visuals one for gameplay data.
I think visual struct should have something like this:
- name of module (so you can use this later in GUI), for eg “drum magazine MK I”
- some unique ID, that is if you ever want to search modules array for something, or compare 2 modules, this can be enumerator. Also having this as ENUM could make life easier if you code some function that fills rest of values after you set this enum. But that would work only with C++ when you read rest of values from database or some json file.
- socket name of gun this thing needs to snap
- transformation relative to gun that you should apply. Scaling and moving should be done in 3d app when modelling parts, but just in case you need to tweak a abi its handy to have this.
- material that should be applied to mesh
- and last mesh reference
Then you need gameplay struct
here you should keep all modifiers this module will apply to gun.
- you can add second part of name. for this part (so you can have identical models of part but with different name variation)
- if you want same mesh model for modules that may have different stats you may want modify material, so add material override field
- and add all your gameplay modfiers below.
Child actor components also limit some stuff, problems are similar to structs i described above, just in different places.
For eg, with structs if you want to modify how material override is applied, you change single place in blueprints.
With child actor you will have this (override material) logic in every module blueprint. Now to change it you need to fix every single blueprint.
Yes this can be avoided with inherited blueprints, but child actors with inherited blueprints messes everything even more than plain structs.
Ps. Soon I will do similar system for myself, that is why i thought about this all so much. I already tried to do this for spaceship weapons and turrets, and i tried child actor method.
About storing (and more about importing and setting up default values) this is something that probably requires some C++.
Yes you can make array of those structs, fill it all up in editor. But few times i got all that data wiped (yes it was 4.4), this may happen again.
So safest way that i think of is writting some json (or any text file format you want) parser in C++, writting all that in text file and importing as data into unreal.
Then you need C++ for reading it and filling structs. But this introduces quite big problem: acessing blueprint structs from C++, i read that this is quite messed.
So instead you coud create function in C++ that reads single struct from text data, and returns it to blueprint. Then you apply values in blueprint.