I had not heard of data channels in Niagara systems before now. It's experimental yes, but still cool. Hmm.
25.02.2026 13:40 โ ๐ 1 ๐ 0 ๐ฌ 0 ๐ 0@cpioli.bsky.social
Gameplay Engineer and Game Designer. Loves Nintendo, Square-Enix, Sony, Jedi, Muppets, and cooking! Opinions are my own and do not represent my employers!
I had not heard of data channels in Niagara systems before now. It's experimental yes, but still cool. Hmm.
25.02.2026 13:40 โ ๐ 1 ๐ 0 ๐ฌ 0 ๐ 0If I can successfully get looping effects to work, that's a huge challenge over and done with.
At some point I need to write functionality so effects can be triggered in code by collisions, too. And ones that are emitted by default, like on a weapon...
God this is getting so complex. Y.Y
Otherwise, I would have done it already!
So what's the solution?
๐ก
Delegates!
When an Actor is going to be destroyed, pass a function that destroys its Registry inside the subsystem's "Looping Effects" directory.
So back to the original problem... use UStructs.
#RubberDuckCoding
To maintain encapsulation, I can't just write an AActor subclass and expect all projects to rearrange their architecture. The plugin's component could keep track of looping effects... if that didn't create a circular dependency. The Subsystem would have to send looping effects back to the Component!
25.02.2026 13:14 โ ๐ 0 ๐ 0 ๐ฌ 1 ๐ 0I just realized something...
If an Actor - that owns components emitting looping effects spawned by my plugin - is removed from the level, I'd have to update the Subsystem to remove that Actor from the Directory, and all its references. Seems inelegant?
The alternative is...
I'm frustrated that template errors and incompatible argument lists are causing this problem. That's such a junior-level problem! The only thing that's changed is I am not using ustructs or uclasses, just normal structs. I do not understand why that would be the problem, but whatever man...
25.02.2026 13:14 โ ๐ 0 ๐ 0 ๐ฌ 1 ๐ 0However, the *other issue* remains. I created a bunch of structs like in my original post, but every time I implement them, some template error stopped the compilation.
I was hoping I could just use plain structs, but the more I think about it the less it makes sense, especially in Unreal C++
#UnrealEngine All I had to do for the first problem was get the AssetManager to front load. It refused to load into the class's member, though. *That* caused a crash for some reason. Had to use a pointer in-scope. Maybe I should grab the Asset Manager and Stream Manager in the constructor?
25.02.2026 13:14 โ ๐ 0 ๐ 0 ๐ฌ 1 ๐ 1"YO DAWG, I HEARD YOU LIKE TEACHING YOUR AI WITH DATA!
SO I TAUGHT MY AI
WITH THE DATA THAT CAME FROM
THE AI YOU TAUGHT WITH DATA!"
...there's a way to make this work, I swear to God! That Is the 5th draft. I can do this.
Oh, riiiiiiight!
The object referenced could also be an AActor, so I will probably need to use a different pointer type. Urgh...
Maybe I can make an ActorManagementComponent to hold reference to all these Actors the system might be generating? Wait that sounds ridiculous...
And LoopingEffectsReference would house the essential data: the pointer to the thing, maybe the owning Actor, the time that has passed since the object was fired, etc.
Honestly? This might be overdoing it, but if it works for the AnimNotifyEventReference, it can work for me!
TMap<AActor*, FLoopingEffectsOwnedByActor> LoopingEffectsDirectory;
struct FLoopingEffectsOwnedByActor
{
TMap<FName, FLoopingEffectsContext> LoopingEffectsIndex;
}
struct FLoopingEffectsContext
{
TArray<FLoopingEffectReference*> LoopingEffectsList;
}
struct FLoopingEffectsReference
{
}
The Key is the Actor's address and the Event Name, but I turn them into an FString. The intent is to make these looping effects accessible to any part of code that knows the owning actor and the event that was fired.
The best idea is probably using structs.
#UnrealEngine I did not realize that in AnimPreview my WorldSubsystem does not call OnWorldBeginPlay(UWorld&)...
Because that's what's happening. And it is one of two suspects into why my code crashes.
The other being a poorly implemented Data Structure that crashes when I lookup a key.
If you're used to using Facetime but it's a voice-only call, that can definitely happen and it's just force of habit. Not your fault.
If you still do it, it's still not your fault but just make sure nobody noticed you... ๐
2. Front-loading all effects in an AnimMontage before AnimNotifies fire, begin, tick, or end. I thought the Subsystem would handle this, but *boy was I wrong*
Why not just make the Async code into Synchronous Load Code? It'll stop this from happening...
Returning to the looping effects now. There are 2 huge problens
1. Creating a data structure that meets the criteria I have written (accessible through Subsystem, generated by owner Actor and Event Name, etc.) and DOES NOT CAUSE ANY FATAL ERRORS
(Cont'd)
Ask the OP/Author to give you a copy, directly through E-mail.
They'll probably give you a copy, free-of-charge. They want people to read it, those resources want people to pay for it.
๐ตGasp! ...shiny... ๐ซ alpha...
Baxcalibur... ๐ฉ
I caught it... ๐ฎโ๐จ
Someday he will be old, and he will be cast in a trailer
He will walk down wooden halls of hand carved mahogany; adorned in gray linens and prayer beads on his wrist. Hanging metal braziers glowing with green tongues of fire
He will enter an arena, raise his knotted finger, and shout the words...!
I added config vars so the user can define which classes and what directories to search for asset references. An Interface is also provided so any class written can return them in list form.
AnimMontage doesn't let me make subclasses easily, tho, so it's hard to get the assets in all their Notifies
Asset loading works correctly now. Create Object libraries, cycle through all Blueprint Classes, find and upload all the assets. #UnrealEngine
I've isolated the redundant code into lambdas, and I created an Interface so any future classes that use this system can pass the assets their unique way.
Let me tell you what happens when they canโt manufacture enough parts for critical medical equipment: the companies will exit making that equipment and your insurance company will say โtoo bad, do your best to keep it workingโ.
Phillips did this with pediatric ventilators.
I really dread this one because a certain help forum was pretty unsupportive. Gatekeeping bullshit, "oh this looks like something written by an entry level programmer."
Give me a break! Oh well, better suck it up. If I let their remarks get in my head, I'll never get this work done.
Once I'm done with asset loading, I must return to making my STUPID LOOPING EFFECTS WORK!
Maybe front-loading the effects will fix my looping effects bug, or make it easier to deal with.
I don't think this is absolutely necessary to implement right this moment, but it is a really cool programming challenge I'd like to get into.
16.02.2026 00:52 โ ๐ 0 ๐ 0 ๐ฌ 0 ๐ 0I suppose the best way to do this is to make an Interface and attach it to each class that houses this data, containing a function to return the List.
Fine for my classes. But engine classes like AnimMontage will need a child class. Sucks, but it'll simplify the ObjectLibrary part of the code.
that "list of effects to fire" is going to be stored in several different class types. Some will be Blueprint objects, some will be assets. Each require a unique lambda to loop, cast, and dereference complex data structures to find these lists. I've decoupled the code as best as I can. But...
16.02.2026 00:52 โ ๐ 0 ๐ 0 ๐ฌ 1 ๐ 0I was able to synchronously load all the effects during level load. Used ObjectLibraries, gathered FAssetData, and find the particles, sounds, and actors.
It's hard-coded into the subsystem, tho. Not very flexible, especially for more complex projects. They'd want to load assets "their way." Also
I am so sorry, Saleem. It must be unbearable. ๐ซ
14.02.2026 04:43 โ ๐ 1 ๐ 0 ๐ฌ 0 ๐ 0