You can have data-only components now on actors right? Because they don’t all have to tick anymore?
Haven’t paid too much attention, but I’m thinking of some data only components and wanted to confirm that was the case, if anyone knows?
ta.
I’m curious why you would want it as a component versus just doing a variable in the Blueprint for it? What’s the advantage you’re going for?
Because I’m doing it from C++ and don’t want to touch the blueprint side for it (with the context switch overhead).
There are 2 bools you can set in the constructor to reduce the CPU usage to minimal
bWantsBeginPlay = false;
PrimaryComponentTick.bCanEverTick = false;
I have over 100 data only Components connected to a database and they seem to be more or less dormant until I call upon them. I’ve not really gone into depth testing them yet so there may be something else to set to get close to zero cpu usage.
Hope that helps
–Fij
In my case, I want to add data components to items that provide concealment and cover so I’m using the components more as annotations with data than anything. I guess I could use tags for the same thing too. But components can have extra data associated with them (i.e. how much concealment they provide, if they are destructible etc).
I’m doing a similar thing (conceptually) using ActorComponent rather than SceneComponent.
UActorComponent is the base class I derive my data components from, it has no transform like the SceneComponent does.
It also means it cannot be a child of another SceneComponent but that doesn’t matter in my case, it just sits in the root if I add it to a BP component list.
Could you give us a small example?
Well, I’m doing a line trace to an enemy threat. I do a trace that gives me all the objects the trace passes through, so I look for any “concealment” objects in line between my guy and my enemy. So I want to add some way to annotate the objects that provide concealment. So I might have a “concealmentcomponent” that I can add to the actor to allow it to denote the actor is concealment (so I’d add it to a bush say), it might even have some properties for concealment (how much concealment it provides for example).
Thats the kind of thing. Of course I could simply use Tags, but I don’t know if I like using tags for this.
I’m not sure if there’s some confusion here with data-only blueprints? (Which are simply blueprints that don’t have any visual scripting added)
The term data-only component doesn’t mean anything to me. I still haven’t got up to speed with 4.8 so may be missing something, but as far as I’m aware it was always possible for a component to have its tick disabled. When this is done, it certainly minimizes its overhead, but its mere existence will still lead to some overhead.
If you really want to minimize overhead, I’d suggest perhaps creating a single UCoverAnnotationComponent which houses properties relating to all the parts of your system (eg. bProvidesConcealment, float ConcealmentSize, bDoesSomethingElse, float SomethingElseRelatedValue, etc). That way you only ever need to search for a single component in an actor. To be honest though there’s a good chance the performance difference would be negligible, so if having separate annotation components for each thing gives a better workflow, I’d just go with that.
Kamrann: The component not ticking is reasonably old yes, but it wasn’t that way in the first release AFAIK, similarly the actor itself would always tick, where now I think you have to hook up something to begin play for it to actually tick? (or maybe its a checkbox ;)). I’m just concerned that there is still something else I may not be aware of in terms of component overhead. If its just memory overhead them i’m fine with that.
Either way, looks like I’ll use a component for it and be damned.