Lets analyze your GenerateItems() function.
At first, there is a loop for fetching locations from Data Tables and spawning AItemGroup actors.
At line 108 you call ItemGroupRef->GetAllTransforms(...). From where? This object is just spawned few lines before, so? You paste GetAllTransforms(...) definition in another thread and this function grab transform from meshes… but who set it? If AItemGroup just holds some meshes, why you ever set location for AItemGroup?
Line 32 & 34. FTransform have a proper constructor for this. Using Kismet function for this is bloat.
Line 39: Functions have return type for some reason. And C++ uses RVO/NRVO (return value optimization). Don’t avoid it, use it.
Line 39: I dont get it. You have fixed number of item types, but your loop have random number of iterations. And only unique item types are added. This is illogical. If the AItemGroup can have various number of item, then your other functions dont take it into account (like GetAllTransforms which always get transform from all five meshes).
Line 54: Unneccessary loop. You can do it in previous loop
line 74: Another unneccessary loop. You know which item is a E_Weapon when you randomize item type. You can assign ammo to weapon there
Line 88: Yyy… what? Completly dont understand. Besides that you modify container inside for-each loops, which is dangerously.
Line 103: This code have no effect, and can be cutted completly. Why? Because you dont store results anywhere. Everything are a local variables, destroyed after function returns.
Same situation is with RandomItemID(...) function. A lot of duplicated code, hard to read and maintain. Handling probability is really inefficient.
No offense, but this code is bad. I won’t be surprised if its performance is worse than the blueprint version. Because of this, you will only wander into more problems.