Get the name of pawn by trace function

[evr]

take into account iterating functions are costly and should be used only when necesary. Even if this is just a learning project, this can become a real bad habbit, best to start learning good habbits

You do understand that iterating AllPawns client-side every tick is probably faster than performing a trace every tick?

[evr]

Ok, Meowcat, I will test it when I get in home.
Thank you.

I don't really see why you should, it's basically the exact same thing except it will perform a trace each tick even when there's no pawn in sight and the traces might be way too long or not long enough.

[meowcat]

@ evr: You and I had two different sets of assumptions for what he is using this code for. I assumed his initial request was for a standard "get the name info to display on HUD" function, a similar feature that has been in every UT (only ever checking a few hundred UUs in front of the player). I only posted this old code because in the past numerous official sites, and some comments in the old uscriptsource, warned that using the iterators could be slow (normally this was related to the ones that could not use an easy hash check (collision or visibility) to be iterated across), and in many ways the older source code was as simple/optimized as it could be since it was meant to run on computers with CPUs in the 400 MHz range if I recall correctly. It would appear that the pawns iterator in UDK *should* be fast given its specialized nature (only lists pawns, does not have to perform a 'class' evaluation check etc. unlike iterating across the old AllActors list), but without some debug testing (which is recommended), we would not know which method is truly faster for his purposes (basic frustrum check every tick with dot product calc for every single pawn, then trace when possible for a non-predetermined distance, or just the trace every tick only in the direction the player is facing for a fixed distance). Although long line traces can potentially have to evaluate against hundreds of triangles in this version of the engine and could be slow (as compared to the much smaller number of triangles and BSP surfaces in the older engine versions), if other actors are moving in game (e.g. PHYS_Falling, walking, projectile, swimming etc.), using the basic unreal collision cylinder, there can be literally a couple hundred traces (albeit many much shorter) occurring every tick for the basic gravity and move collision checks (using non-zero collision extents) already, so adding one more trace of reasonable length every 'tick' may not really harm performance in any noticeable way.

@ Humberto: I'd recommend trying both, seeing if there is any noticeable difference, and sticking with whichever method works best for your purposes. As evr noted, the code I posted assumes a fixed maximum check distance of 1000 UUs, this would need to be adjusted for longer distance checks. His posted iteration method should work universally at all distances (the big benefit comes in for checking long distances, since you avoid long traces except when necessary). As a side note, where are you using the name information? (writing it to the HUD?) The sample I posted above could probably have the "Canvas" parameter removed from the function specifier as it is not used in the function itself.

[Acecutter69]

what meowcat said

In the end it all comes down to what suits you. Iterating and tracing are costly but needed process and should be used wisely. When I mentioned a bad habit, what I mean is that there are a lot of people who use these process without the need for them. Some will even ignore warning about the process time because what they did "works" until they deploy the game and see it run at 20 fps and wonder whats wrong