Is it OK to add a TimerByEvent in a Gameplay Ability?

I’m asking because AI says no. But I cannot implement my own C++ Ability Task. I’m not a coder.

I’m trying to run a Line Trace on every tick, basically, to look for actors/components with a certain interface.

Thanks.

You might want to put that sensor in a component on the owning pawn, as a line trace (or maybe even better, a capsule trace) and sense the overlap events from that component.

This will be more efficient, because it’s run as part of overall collision detection, not as a separate afterthought separate from the physics step.

1 Like

Thanks. Lyra documentation says they made the interaction system using the Gameplay Ability System. So I was trying to grant an ability to the player that traces for interactables. But AI said it’s a bad idea to put a Timer in a Gameplay Ability.
So, I should just put that logic on a component instead, and ignore GAS on that one, right?

cant see i problem with it myself, in a lot of ways it makes sense as you can interact with it, ie other abilities can block/cancel interactions

1 Like

This is usually done by a separate “vision” or “sensor” component as @jwatte pointed out. This way you can make the component tick every half a second (instead of every frame) which will decrease your computational load at least x15 with negligible impact on game-play. It will also allow further optimizations managing its tick interval depending on your game.

If you want to tie that to a Gameplay Ability just make the ability add a tag and notify the component to start ticking. Make the component turn itself off when this tag is removed.

Making it all in an ability is not entirely out of the question but it makes it harder to implement, support and modify down the line.

2 Likes

Thank you. I tried that, but I find it too slow if it’s not on tick. I’m displaying a crosshair everytime the player looks at an interactable, else the crosshair is hidden.

Yeah, that would be it. But I wanted to avoid using 2 entities to do one job. I thought it’d be less scalable.

AI says I should put it in an Ability Task, but that can only be done in C++. I got AI to write it for me, but it doesn’t work.

Yea, you are right - I was distracted and I thought the trace doesn’t come from the player. In your case tracing on every frame is the better approach.

BTW if TimerByEvent in the Gameplay Ability works in your cases - go for it.

It is often better to implement something “somehow“ and go on with your prototyping instead of getting bogged down in the details. (IMPORTANT NOTE: This advice does NOT apply to production code!)

I’m a bit rusty on the Gameplay Ability System but I can share the best documentation I’ve ever used for it:

I hope it helps you write your Ability Task if your initial approach doesn’t work.