I moved the niagara systems declaration from the main actor into a niagara component.
Now systems are always null when I want to spawn them in a function.
Is this normal? I mean…isn’t it possible to do it this way?
Or should I do it in another way to have non-null instances of the system? Maybe a special specifier or something?
Thank you so much!!
Try filling it in with a spawned system.
I am instantiating it from the Blueprint.
But I get an invalid pointer before spawning it.
It is very strange because It works from the actor projectile in this way without problems.
That’s why I thought maybe I was doing something wrong.
I will read the documentation that you have attached.
Thank you so much 3dRaven!!
actor.zip (1.4 KB)
Here is a file from another thread I was helping out with Niagara. It shows how to spawn the system
I look at it, thank you very much.
If I change the type of a variable and don’t change its name the editor goes crazy, right?
Like this:
UProjectileNiagaraComponent *NiagaraComponente;
UNiagaraComponent *NiagaraComponente;
Because I think that was the problem…
Or it could be that there are three different things to handle a boolean variable and that two of them wreak havoc in the constructor…
bReplicates=true;
SetIsReplicated(true);
SetIsReplicatedByDefault(true);
Ambiguity and extreme confusion.
Is there a way to force the editor to prioritize my C++ code?
It would be great if it didn’t do weird things.
Thank you very much 3dRaven!!
You can’t have the c++ have the same name as a blueprint variable. In the programming world with inheritance this is what would be called shadowing.
You can do this with functions when they are virtual but not with variables, so that’s probably why the c++ variable is fighting with the blueprint one.
You should rename the blueprint var, then go back into c++ make the proper variable and once compiled replace the blueprint var with it’s c++ counterpart.
I know that. That was not the problem.
The problem was that I first had this variable
UNiagaraComponent *NiagaraComponent;
Then create a new class derived from UNiagaraComponent.
class UProjectileNiagaraComponent : public UNiagaraComponent
Then change the type of the variable to that of my new class
UProjectileNiagaraComponent *NiagaraComponent;
Then there is only one name. There is only one variable.
I just changed the type.
And the editor started instantiating my UProjectileNiagaraComponent class members with null pointers.
I only got the editor to work correctly when I changed the variable name.
NiagaraComponent → NiagaraComponente
So I think the editor has retractive memory or something like that… I don’t know… but it’s a problem.
I remember something similar of forech loops in blueprints. If you change the type of the array the foerch loop no longer works. You have to delete it and make a new one. That was one of the reasons why I stopped using bluprints.
Thank you very much 3dRaven!!
If the editor starts behaving erratically then I usually kill of temp folders and rebuild. It usually fixes up errors that are usually stuck in the “Immediate” folder cache.
I will.
Thank you very much for the tip 3dRaven.
Is there somewhere else where the cache is stored?
I deleted these folders:
-Binaries
-Intermediate
-Saved
*Generate Visual Studio Progect Files
*And compile from command line…
However the editor keeps remembering classes that no longer exist
Because I changed those classes yesterday. And I’m not using them right now
UPDATE
I found this in defaultEngine.ini
I think the redirectors are not helping. They are doing the opposite.
I’ll try deleting this from DefaultEngine.ini
UPDATE 2
This didn’t work either…
-But then run “Fix Up Redirectors” in the content folder.
-Then I ran “Resave All” and it fixed the problem. (I think)
What a headache!!
Thanks for your help 3dRaven!!
