I was starting to write a function library to make things a little easier, and I had one function in particular (which is called Ignite() ) that I wrote, but I’m unsure how to reference assets required for it. This function “Ignite”, for example, should take in a mesh component and spawn a niagara emitter and sound emitter attached to the provided component.
How would I specify what Niagara emitter spawns or what sound plays without a blueprint child where I could normally change what is used via a blueprint-editable UPROPERTY?
A function Library can be a limiting factor because it must be static, and generally lacks UWorld context (you can get UWorld context through an Actor)
but what you are describing sounds more like a manager rather then a Function Library, which are still static, but if say this manager was a UWorldSubsystem you can ensure that they exist any time the system, they are a subsystem of exists, and where it would be a subsystem of UWorld it would already have context, and be persistent.
for how to reference game assets (I am going to presume that these are not just member variables for the given object) there are a few options but for C++ none of them are pretty (technically one of the things Blueprints does better)
in like the subsystem mentioned before you can give a Runtime-Resolved-Hard-Reference to the assets in the constructor (if you go this approach you should include some kind of Warning or Error messages if the Asset is not found because these Runtime-Resolved-Hard-References can silently fail and that is “OK”) you can get these references by in the Content-Browser right click the Asset and select “Copy Reference” which will give you the path the Asset Manager would use to get to it. (Runtime-Resolved-Hard-References have the issue of if that Asset is moved or renamed that reference breaks, and things stop working)
you can create an AActor that inherits a specific class whose sole purpose is to exist at level load and hold the needed data Assets, and then use those to populate the Subsystems member variables, then at BeginPlay attempt to grab the AActor in the level to do work with it, harvest the variables, then destroy it (this can have the issue of forgetting to put it into a level and then not being able to find it.
for this method if you don’t want to put this actor in every level, or think the level designers will forget then you can have this be a GameInstance Subsystem and have this find actor to harvest happen in the background of your Title screen or something ??
you could put these references to Data Assets into well a Data Asset, treated like a glorified struct, but you run into needing to get the reference/pointer to it somehow.
the last one that comes to mind is putting these reference paths into an ini but I dislike this the most where it combines the Runtime-Resolved-Hard-Reference with an external file that could be edited by the user who has access to the file system.