Basically what jwatte said: storing the class rather than an instance.
Consider the fact that an instance of a thing is a single, solitary one – a specific medpack, not the concept of “medpack” as an item. Realistically, you’d want to store the concept, so that when you were dropping something, you’d say “I want to drop a thing of this type”, rather than “I want to drop this one specific medpack, out of all medpacks anywhere in the world.”
Admittedly, I personally might go a little further than jwatte here. (But I’ve never met a system I wouldn’t overthink and try to genericize, so…)
That said, I’d probably define a data table that could hold weighted lists of possible loot. Each row in the table would hold a TSubclassOf<AItem> – a reference to the class, rather than an instance – and an integer value for the “weight”, with bigger numbers making it more likely that the item drops.
(If you’ve got quality levels or quantities, I’d probably add a minimum quality/max quality or minimum quantity/max quantity, too.)
Then I could build multiple “loot tables”; if I had a “general trash mob” table, I could use it on a bunch of different types of trash mobs, versus, say, a “miniboss” table that had better drops. And when something died, I’d take the loot table for that character, use the weights to pick an item from the list, and get a resulting subclass of your AItem class. Then, in code, I could easily just use that class with SpawnActor to spawn in a specific instance of that type of thing at the appropriate location.
Which is functionally handling this as “create a medpack and drop it here”, versus “take this one specific medpack from wherever it might be in all of existence, and move it to this spot.”