Event tick hooked to a line trace and only one "cast to actor" node make my fps fall slowly to unplayable. Is there any alternative to fix this ?

Hi

I have this line trace on event tick.

My fps go down with time if i have it this way. For example i start with 90 fps and it takes around 5 min to dip down to 80 another 5 min and im at 70 fps and so on. Is this not how line trace should work (connected to tick event) or is the “cast to…” node making this issue when connected to tick event ?

So… you’re saying that if you disconnect this Tick, the performance drop goes away? Do you have any errors / warnings in the log?

1 Like

Yes i tested it without the cast to node and performance stay constant around 90 fps

But i need the cast to node im not sure how to make this work without. I try to replace it with “get actor of class” but rest of my code is not working :frowning: I have some billboard widget which show up when aiming at some minion and hide when not aiming at it.

Then there is down there more code drawing more info from this same line trace if i aim at the minion or not. So far not sure how to make it to work without the cast to node

That cast shouldn’t affect the frame performance, I don’t see anything in that function that I would consider weird. I think the problem is somewhere else.

You need to profile the game to see just what is actually costing the frame time. I recommend checking out Maximizing Your Game’s Performance in Unreal Engine | Unreal Fest 2022 if you don’t have experience profiling in Unreal Engine.

2 Likes

But why would my fps slowly go down with the cast to node and stay constant if i disconnect it ? I can make a video in real time and you can see the fps drop with cast to node vs no performance issues when its disconnected

thx for the video tough i will check it out

There are some strange things going on:

Even though you do have a reference variable. Looks like you do it often, accessing data pins from non-exec branches. Unsafe, potentially catastrophic.


The cast is not to blame here. But you can use an interface instead. I’d look for issues elsewhere. You did not answer about log warning / errors.

True i forget that…

There are errors

it sends me to this then

I will try replace the mesh variable you marked and test again

Unsafe, potentially catastrophic.

Yeah, that’s your slowdown. It’s the log error spam. :smiley:

1 Like

Ok so priority number one is to fix all those ?

I have other access none errors i tought that wouldn’t matter that much scince logic is working ?

What if the code is working and would this log events not matter after packaging the game ? If the log error spam dissapier would that not mean that in the packaged game performance should be then better ?

You reference stuff for a reason:

Use the Validated Get variable elsewhere in your script so you do not need to have wires snaking all over the place.


And if you need to access the pawn elsewhere. Do the cast elsewhere. Do not reuse pins from other exec branches unless it’s a SET node whose right hand side pin acts as a GET.

  • this is not OK:

  • this may be acceptable:

  • ideally you would:


i tought that wouldn’t matter that much scince logic is working

I’ll admit that I do not understand what the script is supposed be doing.

1 Like

Basicly i can spawn a minion and he has a billboard widget showing up on him when i aim at him. Billboard works here really good so i can see him in the distance that i aimed at him. Normal widget wouldn’t work for this (or so i think maybe im wrong). So when aiming at him i can give him commands. Awso we are linked togheter with some energy beam where it fires awso on event tick and it changes it colors when i do curtain commands. For example life transfer by aiming at him and only then i can press and hold a key to sacrifice life from the player character and give it to him… Anyway stuff like this and it all works now pretty flawless. Except this performance issues…

Thx for all those examples i will dig more into this and see where i can optimize the code.


This part does not matter, it can be made with anything. Here’s an example and a project with this (slightly more advanced) behaviour:

An Interface may be preferable if you want to interact with unrelated classes.

1 Like

What I really meant was this:

You’re comparing whether the Hit Actor is the Hit Actor.

I do have interafece for the health bar over him lol and i even remember the post from above that you linked. I think i made this health bar widget from it long ago on all my enemies… Maybe i should move this minion command Icon widget there as well thats acctually a good idea but the helath widget that i have is awso made with an interface and show up on collision overlap but i need to aim at it pretty much like on the example video

Yeah i want to get if the hit actor is hitting him then show this billboard widget if is not him do not show it. Same is with the commands that i want to give to him only if i hit him with the line trace. This is the way to do it no ?

Only like this all my logic works without it nothing works.

Here is where i use it on other places (i dont think hit actor=hit actor random or so but hit actor = to minion actor then the widget show up when aiming or not. I missread. I think you wanted to know this so it counts as line trace hit actor = to my minion actor as it seems else the first logic wouldn’t work with showing the widget when i aim at the minion)

The entire commented logic for this behaviour if we’re using casting:

In the Minion, instead of triggering the timeline, the custom event would show / hide its widget / billboard.

1 Like

I made something out of this last post and it seems to work fine. The performance issue is still there tough. I tested it around 1 hour long on improving the code then just chill for 5-10 min and stare at the fps drop. So far it seems with this code that i’m losing around 1 fps each 30 sec so in 10 min i drop around 20 fps less. I tested this without the event tick at all and performance is stable no fps drops after 10 min of waiting and watching fps…

This is how it looks like now and i made it work (kinda not exact same from above). If this saves some extra performance then was worth for sure.

I guess it must be the errors and the log files created as you say. So i will mark this as solved where you mentioned it. Ty for the help tough lot of new stuff to learn here…

This is will crash & burn at some point once accessed and evaluated in another execution chain:

If you need this data elsewhere, do the trace there to obtain it. Or store a ref to the hit actor and use it after checking its validity. Tracing is very cheap, casting is more than OK and Tick is necessary. What’s expensive is using it incorrectly.

ok i will try that

It just came to my mind is it any good idea to disable the error logs (completely disable log files or so ) ? Or maybe at least disable them to test if this really is the performance bottleneck when i have that many errors ?

I’d work on fixing the errors.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.